2단계 인증을 제공하는 여러 Roundcube 플러그인이 있습니다. 그러나 지금 내가 보는 문제는 (분명히) 2-FA 없이 IMAP/SMTP를 통해 간단히 로그인할 수 있다는 것입니다. 2-FA는 여기서 (효과적으로) 쓸모가 없습니다.
저는 애플리케이션별 비밀번호를 도입하고 Google이 2-FA 및 이를 지원하지 않는 애플리케이션에 대해 수행하는 것과 유사한 작업을 수행함으로써 이 문제를 해결할 수 있다고 생각했습니다.
이제 각 사용자에 대해 Roundcube 웹 인터페이스에 로그인하는 데 사용되는 비밀번호와 다른 Roundcube용 앱별 비밀번호를 자동으로 생성할 수 있다고 생각했습니다. 결과적으로 사용자는 Roundcube에 로그인하기 위해 여전히 자신의 비밀번호 + 2-FA를 가질 수 있지만 동일한 비밀번호를 IMAP/SMTP에 직접 사용할 수는 없습니다. 그러나 웹 인터페이스에 로그인하는 데 사용되는 것과 다른 IMAP 비밀번호를 사용하도록 Roundcube를 구성하는 방법을 찾을 수 없는 것 같습니다.
Roundcube와 Dovecot은 모두 동일한 시스템에서 실행됩니다.
여기서 뭔가 빠졌나요? 내가 하고 있는 일이 합리적인가? 이것은 내가 시도하는 것보다 더 우아한 방식으로 해결될 수 있는 문제인 것 같은데, 거기에 뭔가 빠졌나요? 제가 정말로 원하는 것은 가능한 경우 2FA 인증이고 다른 경우에는 애플리케이션별 비밀번호입니다.
감사합니다!
답변1
좀 더 시도해 본 후 적어도 이 간단한 경우에 대해서는 두 가지 합리적인 솔루션/해결 방법을 찾았습니다.
옵션 1:allow_nets 사용. Dovecot에서는 'allow_nets'(http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets). Roundcube에서 사용할 비밀번호에 대해allow_nets를 127.0.0.1로 설정하면 다른 소스에서의 모든 로그인 시도가 실패합니다. Roundcube가 다른 시스템에 있는 경우 당연히 IP를 조정해야 합니다. 이 접근 방식의 문제점은 비정적 IP 주소와 사용자가 Roundcube와 동일한 시스템에서 실행되는 프록시 등을 통해 로그인할 수 있는 2FA가 아닌 다른 방법을 사용하는 경우입니다.
옵션 2: CheckPassword를 사용하여 사용자 정의 인증 스크립트 작성.checkpassword 드라이버 사용(http://wiki2.dovecot.org/AuthDatabase/CheckPassword) passdb의 경우 사용자 정의 인증 스크립트를 작성할 수 있습니다. 거기에서 클라이언트 IP를 확인하거나 완전히 다른 작업을 수행할 수 있습니다. 여기에서 발생할 수 있는 문제는 성능이며 checkpassword는 사용자 조회를 지원하지 않으므로 사용자 조회를 위한 추가 구성이 필요할 수 있습니다. 또한, 사용자가 실제로 어떻게 로그인을 시도하고 있는지 확인하는 문제도 남아있습니다.