[Dovecot] Ideas for Webmail/OTP
I want to discuss some problems/enhancements for dovecot in a webmail/otp setup.
For access to an IMAP server like dovecot I see different client types: a) a "normal" MUA installed in a more or less trusted environment b) remote access via "webmail" from untrusted environments
For a) I see with dovecot and other IMAP servers no problems, tricky is the setup for b). If you use a webmail client in an untrusted environment the risk is high, that keyloggers and other malware steal your password. One easy solution is to use One-Time-Passwords (OTP). The otp setup for interactive logins (e.g. ssh) is easy, but until now I did not find any easy to use solution for webmail. The main problems I see
- In most cases a webmail client does not hold a persistent connection to the IMAP server, but makes a login for every request.
- The webmail clients are not prepared to display the otp password challenge to the user.
When we say "otp" with IMAP we further have to distinguish a) the OTP SASL authentication mechanism b) OTP configured by PAM.
I believe a) is implemented in new dovecot 1.1 version, but I prefer b), because
- it works with many clients without special client support
- all authentication setup is central in the os.
All above described problems are not specially linked to dovecot, but I believe with dovecot there is an easy solution to solve them. :-)
Solution 1: When PAM is configured for IMAP the user can use a one-time-password in the same way as before. The problem is, that the user must know the sequence number for the password (otp challenge), so we need a way to display it. The PAM module supplies the otp challenge in the conversation function, but the challenge is not processed by the IMAP server. My proposal: The IMAP server stores the challenge from the conversation function and includes it in the LOGIN response, when the login was not successful. So a user can try a login with a wrong dummy password and get knowlegdge about the current otp sequence.
The webmail server should be extended in a way, that it displays the complete IMAP error message, when a login fails.
Solution 2: Webmail clients do not use persistent connections in most cases. A OTP login needs different passwords for every displayed web page. My proposal: Use dovecot's login cache and do not ask the os for every login. :-)
Solution 3: When we configure PAM we can restrict/allow it's use depending on IP address of client. Unfortunately with a webmail client the IMAP client is always the the webserver. It should be possible, that the webserver forwards the client IP address to the IMAP server. Furthermore to use dovecot's login cache as described above in a safe manner, the IP address should be compared, too. My proposal: Create a new IMAP command "XSETREMOTEIP". With this IMAP extension a client can set the real IP address of remote client. The access to this command is restricted to the webserver with a new configuration parameter "trusted clients", which holds an IP address with mask.
I ask to discuss these solutions. It seems to work, I'm making the first tests now. I have patches for dovecot and squirrelmail, but they are very "quick and dirty". They show a possible solution, but not a clean implementation.
Do you believe, that we can build a good webmail system this way, or do you have better solutions?
Regards, Frank
Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.
On 7/23/2007, Frank Behrens (frank@pinky.sax.de) wrote:
I want to discuss some problems/enhancements for dovecot in a webmail/otp setup.
For access to an IMAP server like dovecot I see different client types: a) a "normal" MUA installed in a more or less trusted environment b) remote access via "webmail" from untrusted environments
What about: c) a "normal" MUA accessing via the internet from untrusted environments
This is the recommended way all of our users access their email - webmail is just for the occasional access from a friends or other computer that they don't use regularly.
For a) I see with dovecot and other IMAP servers no problems, tricky is the setup for b).
Webmail is very easy to do...
If you use a webmail client in an untrusted environment the risk is high, that keyloggers and other malware steal your password.
Eh? Thats what SSL/TLS is for... I agree that providing access - either via webmail or any other MUA - on an unsecured connection from an untrusted source is very hazardous - but setting up SSL is fairly simple too, and I even force SSL/TLS on all of my connections even inside our trusted network (no reason not to - the extra overhead is very small).
Sorry, but I don't understand the problem you are trying to solve...
--
Best regards,
Charles
Charles Marcus wrote:
On 7/23/2007, Frank Behrens (frank@pinky.sax.de) wrote:
I want to discuss some problems/enhancements for dovecot in a webmail/otp setup.
For access to an IMAP server like dovecot I see different client types: a) a "normal" MUA installed in a more or less trusted environment b) remote access via "webmail" from untrusted environments
What about: c) a "normal" MUA accessing via the internet from untrusted environments
This is the recommended way all of our users access their email - webmail is just for the occasional access from a friends or other computer that they don't use regularly.
For a) I see with dovecot and other IMAP servers no problems, tricky is the setup for b).
Webmail is very easy to do...
If you use a webmail client in an untrusted environment the risk is high, that keyloggers and other malware steal your password.
Eh? Thats what SSL/TLS is for... I agree that providing access - either via webmail or any other MUA - on an unsecured connection from an untrusted source is very hazardous - but setting up SSL is fairly simple too, and I even force SSL/TLS on all of my connections even inside our trusted network (no reason not to - the extra overhead is very small).
SSL/TLS is not going to solve the keylogger and malware problem.
Basically, if you're on a public (or even a friend's) computer and
someone decides to monitor keystrokes using some application, your
password will be completely compromised.
Sorry, but I don't understand the problem you are trying to solve...
Phillip T. George, on 7/23/2007 1:00 PM, said the following:
SSL/TLS is not going to solve the keylogger and malware problem.
Basically, if you're on a public (or even a friend's) computer and someone decides to monitor keystrokes using some application, your password will be completely compromised.
Well, thats true, but this really isn't a dovecot issue...
--
Best regards,
Charles
Charles Marcus wrote:
Phillip T. George, on 7/23/2007 1:00 PM, said the following:
SSL/TLS is not going to solve the keylogger and malware problem.
Basically, if you're on a public (or even a friend's) computer and someone decides to monitor keystrokes using some application, your password will be completely compromised.Well, thats true, but this really isn't a dovecot issue...
Well, actually it is. Dovecot could possibly need some sort of authorization module addition to achieve what Frank Behrens was wanting to achieve.
-Phillip
Phillip T. George, on 7/23/2007 1:30 PM, said the following:
Charles Marcus wrote:
Phillip T. George, on 7/23/2007 1:00 PM, said the following:
SSL/TLS is not going to solve the keylogger and malware problem.
Basically, if you're on a public (or even a friend's) computer and someone decides to monitor keystrokes using some application, your password will be completely compromised.
Well, thats true, but this really isn't a dovecot issue...
Well, actually it is. Dovecot could possibly need some sort of authorization module addition to achieve what Frank Behrens was wanting to achieve.
Interesting... does any other mail server support anything like this? Not that that should be the sole criteria to judge whether or not something should be added, but...
--
Best regards,
Charles
Charles Marcus wrote:
Phillip T. George, on 7/23/2007 1:30 PM, said the following:
Charles Marcus wrote:
Phillip T. George, on 7/23/2007 1:00 PM, said the following:
SSL/TLS is not going to solve the keylogger and malware problem.
Basically, if you're on a public (or even a friend's) computer and someone decides to monitor keystrokes using some application, your password will be completely compromised.Well, thats true, but this really isn't a dovecot issue...
Well, actually it is. Dovecot could possibly need some sort of authorization module addition to achieve what Frank Behrens was wanting to achieve.
Interesting... does any other mail server support anything like this? Not that that should be the sole criteria to judge whether or not something should be added, but...
I'm not sure if there is a mail server out there that has that specific feature. Security innovations are surely good innovations to bring forth.
Phillip T. George wrote:
Charles Marcus wrote:
Phillip T. George, on 7/23/2007 1:30 PM, said the following:
Charles Marcus wrote:
Phillip T. George, on 7/23/2007 1:00 PM, said the following:
SSL/TLS is not going to solve the keylogger and malware problem.
Basically, if you're on a public (or even a friend's) computer and someone decides to monitor keystrokes using some application, your password will be completely compromised.Well, thats true, but this really isn't a dovecot issue...
Well, actually it is. Dovecot could possibly need some sort of authorization module addition to achieve what Frank Behrens was wanting to achieve.
Interesting... does any other mail server support anything like this? Not that that should be the sole criteria to judge whether or not something should be added, but...
I'm not sure if there is a mail server out there that has that specific feature. Security innovations are surely good innovations to bring forth.
Oh...also his post did include "/OTP", which unless I'm mistaken, than means Off-Topic Post ..so it doesn't really matter if it had to do with Dovecot or not, right? :)
-Phillip
On 7/23/07, Phillip T. George Phillip@stellardreams.com wrote:
Oh...also his post did include "/OTP", which unless I'm mistaken, than means Off-Topic Post ..so it doesn't really matter if it had to do with Dovecot or not, right? :)
I took it to mean one time password once i saw the context, OT usually means off-topic
-- Gabriel Millerd
Charles Marcus dovecot@dovecot.org wrote on 23 Jul 2007 13:21:
Phillip T. George, on 7/23/2007 1:00 PM, said the following:
SSL/TLS is not going to solve the keylogger and malware problem.
Basically, if you're on a public (or even a friend's) computer and someone decides to monitor keystrokes using some application, your password will be completely compromised.Well, thats true, but this really isn't a dovecot issue...
Yes, that's true. I believe I must make some additional notes to explain the reason for my mail:
I believe one One-time Passwords can be useful, especially in untrusted webmail environments.
Until now I did not find an easy solution to setup OTP with common used IMAP servers and webmail packages. If somebody is able to show me a solution I would be happy and we can abort this thread.
I did not use dovecot before, but when I evaluated some IMAP servers I came to the conclusion, that dovecot has a clean structure and can be extended easily. I was able to patch dovecot in order to show that the proposed solutions are possible.
So dovecot has no errors in this context, but I believe it could be extended easily and that's why I wrote in this mailing list. My hope is, that people comment:
- My ideas are stupid or not.
- My proposol is a useful IMAP extension, or we should solve the problem in other ways.
- We should extend dovecot a litle bit or leave it, because other mail servers does not implement such a feature.
I do not complain about dovecot, I'm proposing some enhancements, but may be in the wrong direction. I hope I do not disturb the mailing list readers.
Regards, Frank
Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.
On 7/24/2007, Frank Behrens (frank@pinky.sax.de) wrote:
So dovecot has no errors in this context, but I believe it could be extended easily and that's why I wrote in this mailing list. My hope is, that people comment:
- My ideas are stupid or not.
Definitely not stupid - I hope you didn't get that from my response...
- My proposol is a useful IMAP extension, or we should solve the problem in other ways.
- We should extend dovecot a litle bit or leave it, because other mail servers does not implement such a feature.
As a plug-in I think this would be perfectly fine... in fact, when I replied, I had never heard of OTP - it is an intriguing concept...
I do not complain about dovecot, I'm proposing some enhancements, but may be in the wrong direction. I hope I do not disturb the mailing list readers.
Sorry if I came off a little harsh - it wasn't intended, and I do see now how this could be a useful feature... and now I see Timo has expressed interest, so I look forward to seeing what comes of this...
--
Best regards,
Charles
Charles Marcus dovecot@dovecot.org wrote on 24 Jul 2007 6:33:
Definitely not stupid - I hope you didn't get that from my response...
No, I did not read your response in that way. But the email was writte to discuss that, may be other people have much better solutions.
As a plug-in I think this would be perfectly fine... in fact, when I
I don't know the plugin architecture, but when it is possible as plugin - excellent.
replied, I had never heard of OTP - it is an intriguing concept...
Yes, isn't it?. May be in future you will love it. :-)
Sorry if I came off a little harsh - it wasn't intended, and I do see
No problem. I'm happy to get so many answers to my post, much better than ignoring me. :-)
now how this could be a useful feature... and now I see Timo has expressed interest, so I look forward to seeing what comes of this...
Meanwhile he got the patches, I don't want to publish them, because they are very experimental and dirty (a shame for every software developer, but I don't know dovecot's architecture enough).
Thanks to all people, who answered.
Regards, Frank
Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.
On Mon, 2007-07-23 at 17:15 +0200, Frank Behrens wrote:
Solution 1: When PAM is configured for IMAP the user can use a one-time-password in the same way as before. The problem is, that the user must know the sequence number for the password (otp challenge), so we need a way to display it. The PAM module supplies the otp challenge in the conversation function, but the challenge is not processed by the IMAP server. My proposal: The IMAP server stores the challenge from the conversation function and includes it in the LOGIN response, when the login was not successful. So a user can try a login with a wrong dummy password and get knowlegdge about the current otp sequence.
I'd like to see your patch for this. I've no idea how pam_otp works.
Solution 3: When we configure PAM we can restrict/allow it's use depending on IP address of client. Unfortunately with a webmail client the IMAP client is always the the webserver. It should be possible, that the webserver forwards the client IP address to the IMAP server. Furthermore to use dovecot's login cache as described above in a safe manner, the IP address should be compared, too. My proposal: Create a new IMAP command "XSETREMOTEIP". With this IMAP extension a client can set the real IP address of remote client. The access to this command is restricted to the webserver with a new configuration parameter "trusted clients", which holds an IP address with mask.
Cyrus Murder has something similar to this I think. We could make it compatible with it.
On Tue, Jul 24, 2007 at 09:42:29AM +0300, Timo Sirainen wrote:
On Mon, 2007-07-23 at 17:15 +0200, Frank Behrens wrote:
Solution 1: When PAM is configured for IMAP the user can use a one-time-password in the same way as before. The problem is, that the user must know the sequence number for the password (otp challenge), so we need a way to display it. The PAM module supplies the otp challenge in the conversation function, but the challenge is not processed by the IMAP server. My proposal: The IMAP server stores the challenge from the conversation function and includes it in the LOGIN response, when the login was not successful. So a user can try a login with a wrong dummy password and get knowlegdge about the current otp sequence.
I'd like to see your patch for this. I've no idea how pam_otp works.
I don't know a lot about the IMAP protocol's intricacies, but would it not be cleaner to either:
a) provide the otp sequence as a capability (e.g. X-OTP-SEQ=1234), or
b) provide a dovecot-specific IMAP command for finding out the current sequence value (e.g. X-OTP-SEQ)
The sending of a dummy password to retrieve the LOGIN response seems like a bit of a hack (no offense to Frank - I'm keen to see this OTP idea implemented), but again, the above is written without much knowledge of the IMAP protocol.
Jasper
Jasper Bryant-Greene jasper@albumltd.co.nz wrote on 24 Jul 2007 23:40:
a) provide the otp sequence as a capability (e.g. X-OTP-SEQ=1234), or
b) provide a dovecot-specific IMAP command for finding out the current sequence value (e.g. X-OTP-SEQ)
The sending of a dummy password to retrieve the LOGIN response seems like a bit of a hack (no offense to Frank - I'm keen to see this OTP idea implemented), but again, the above is written without much knowledge of the IMAP protocol.
The problem is, that the OTP sequence is user dependent. When you use PAM you can't determine, if a user uses OTP until you try a login (you call pam_authenticate()).
There is a existing mechanism in IMAP: SASL with OTP. But in that case you can not use the operating system configuration with PAM, but the IMAP server must handle the OTP challenge itself. I believe this is integrated in new dovecot 1.1 version. A problem with this setup is, that you need special support by a webmail client. I did'nt find any (easy) solution with suport for it, with the exeption of an extra IMAP-OTP-proxy server.
Or another view: Until now dovecot (and I believe nearly all other IMAP servers) use PAM in a restricted form only. PAM means
- you define all login capabilities and security restrictions and databases in the operating system.
- when you try to authenticate a user, the PAM module requests the information via callbacks. That means a prompt is displayed for user name, user name is passed to PAM. Then a prompt for password is displayed, the password is passed to PAM. Theoretically this can be continued. With traditional IMAP LOGIN (I do not speak about SASL) the client supplies username and password together and this must be mapped to the callback sequence. Here the PAM prompts are ignored and in case for OTP they contain important information. My (probably non standard IMAP) extension creates the possibility to return the PAM callback message to the user.
When you thing about it: A webmail client and the different IMAP login mechanisms fit not very well together. So some posters are right: you should better use a "real" IMAP client. But IMHO webmail is a useful solution, when you are on vacation or business travel and want to acces your email. And together with one time passwords the security risk is not too high, so you can use it.
Regards, Frank
Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.
On 24.7.2007, at 15.31, Frank Behrens wrote:
When you thing about it: A webmail client and the different IMAP
login mechanisms fit not very well together. So some posters are right: you should better
use a "real" IMAP client. But IMHO webmail is a useful solution, when you are on vacation or
business travel and want to acces your email. And together with one time passwords the security
risk is not too high, so you can use it.
This has also been in my TODO for years:
- support read-only logins. user could with alternative password get only
read-access to mails so mails could be read relatively safely
with
untrusted computers. Maybe always send [ALERT] about the previous
read-only login time with IP?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 23 Jul 2007, Frank Behrens wrote:
Solution 1: When PAM is configured for IMAP the user can use a one-time-password in the same way as before. The problem is, that the user must know the sequence number for the password (otp challenge), so we need a way to display it. The PAM module supplies the otp challenge in the conversation function, but the challenge is not processed by the IMAP server. My proposal: The IMAP server stores the challenge from the conversation function and includes it in the LOGIN response, when the login was not successful. So a user can try a login with a wrong dummy password and get knowlegdge about the current otp sequence.
You mean, the client issues LOGIN (with a dummy password), because Dovecot needs to aquire the OTP challenge first, this LOGIN attempt is failed, but the username can be used to aquire the OTP challenge. It is reported back, via the LOGIN failure string and, secondly, another LOGIN attempt is sent, this time with the same username and a real password.
I guess, you'll need to tweak the webmail interface a bit, that this sequence is working well.
There are time-related OTPs, where the sequence number is derived from the current time. When a client tries a logon, the server calculates plenty of OTPs in the "near" of the current time and adjust itself to the client, in case the device's clock is running too slow or fast.
I would say, this kind is more suitable for this purpose. However, one requires some sort of electronical device for it.
Solution 2: Webmail clients do not use persistent connections in most cases. A OTP login needs different passwords for every displayed web page. My proposal: Use dovecot's login cache and do not ask the os for every login. :-)
This will definitely a must then.
Solution 3: My proposal: Create a new IMAP command "XSETREMOTEIP". With this IMAP extension a client can set the real IP address of remote client. The access to this command is restricted to the webserver with a new configuration parameter "trusted clients", which holds an IP address with mask.
Hmm, any clients accessing webmail via the same proxy or from the same NATed organisation will use the same IP, dial-up IPs switch the users more often than anything else. I don't think that restricting by IPs you have no knowlegde about is save.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBRrgspy9SORjhbDpvAQIJmAgA06boNvZrFTS4kNyky6ywUiYv9CHu99tI GT4iQNezyZz0PensPgGJp6ZAJGDdlAZ1ZxWBth1JCvpVZSBCwnbmbEbWnYtCi9OR v/eynzRFta/11nFy0+AB1Pf2BuoFFPtXy+hC6DnpPcLutD4Q+bvm3Kqdry72PmyQ lBUg8TxTwuDZ0sY0TTAP6VaJCmTG1RvnC5dZp4f6C3yN7kwXbcgS1rkHGr8V6Frs z9ZXMkRYUCpG/ufCQqFB9YTAAOxWM8DrKsmQZNClmkypc+q+v0w11BfcF6SK7v9I cdQqSca7AmXR4q2UYoyvAGGn7rF0cDJJXKI0iQWfWr2nchnx0/PoUA== =wZxi -----END PGP SIGNATURE-----
Steffen Kaiser skdovecot@smail.inf.fh-bonn-rhein-sieg.de wrote on 7 Aug 2007 10:26:
You mean, the client issues LOGIN (with a dummy password), because Dovecot needs to aquire the OTP challenge first, this LOGIN attempt is failed, but the username can be used to aquire the OTP challenge. It is reported back, via the LOGIN failure string and, secondly, another LOGIN attempt is sent, this time with the same username and a real password.
Yes, this was my intention.
I guess, you'll need to tweak the webmail interface a bit, that this sequence is working well.
It's easy: If a login fails the webmailer has to write an error message in any case. Simply include the IMAP error response.
There are time-related OTPs, where the sequence number is derived from the current time. When a client tries a logon, the server calculates plenty of OTPs in the "near" of the current time and adjust itself to the client, in case the device's clock is running too slow or fast.
Of course, this is more sophisticated and more expensive. My proposol uses OPIE - One- time Passwords In Everything. But remember: With my proposal you use always the login configuration from operating system. If you have a pam module for an electronic one-time password generator you can use it with IMAP and webmail without additional changes in IMAP- or webmail-server.
Solution 3: My proposal: Create a new IMAP command "XSETREMOTEIP". With this IMAP extension a client can set the real IP address of remote client. The access to this command is restricted to the webserver with a new configuration parameter "trusted clients", which holds an IP address with mask.
Hmm, any clients accessing webmail via the same proxy or from the same NATed organisation will use the same IP, dial-up IPs switch the users more often than anything else. I don't think that restricting by IPs you have no knowlegde about is save.
I meant it inversely. You can allow the usage of "normal" passwords for all IMAP and webmail clients in local network and restrict external clients to OTP. With pam configuration you make this decision for all logins (ssh, ftp), not only for IMAP with dovecot.
Regards, Frank
Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 7 Aug 2007, Frank Behrens wrote:
Of course, this is more sophisticated and more expensive. My proposol uses OPIE - One- time Passwords In Everything. But remember: With my proposal you use always the login
Ah, OK.
configuration from operating system. If you have a pam module for an electronic one-time password generator you can use it with IMAP and webmail without additional changes in IMAP- or webmail-server.
"without additional changes" Then no change would be required in Dovecot ;-)
But it looks nice. How do you intend to pass the passwords to the users, via print-out? Or handhelds and Java opiekey?
Bye.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBRrhBYS9SORjhbDpvAQIomwf/ZEaDdZUtM2hiaZRQOecSrl+GnwzpFAnc SsRFtlU06MRpkfqQxB7Y+/PZ297lcP0dBeNDO+QNYwXOsOnNVavjhuEsszKlOvFa MI6Zzd9CgBI7fQ4j2HHwvUiOPS2gjrjS3JUWleAFcLF0XDUmp91sXytFpuiNy537 hCbxUmNiCnp1Vl4e5Hj0x7Ex0v/lQJ9GLxmWZRsfQ+Zrm3RU9zPuvjfzjZm7tjnZ 033CiHOLNSglAK40gTRHCxHAWy3NIsKWd1hydMTZpmdeV2MbM+b5AoJZ/Qt55OTj 8zZvgfn2E875I4CpvC38frR5Y7YPxPhXKt+3qhsQXfaTBJk/tOrYEQ== =oZHw -----END PGP SIGNATURE-----
On Tue, 2007-08-07 at 11:54 +0200, Steffen Kaiser wrote:
configuration from operating system. If you have a pam module for an electronic one-time password generator you can use it with IMAP and webmail without additional changes in IMAP- or webmail-server.
"without additional changes" Then no change would be required in Dovecot ;-)
participants (7)
-
Charles Marcus
-
Frank Behrens
-
Gabriel Millerd
-
Jasper Bryant-Greene
-
Phillip T. George
-
Steffen Kaiser
-
Timo Sirainen