[Dovecot] using one-time passwords
Hi,
Is there any way to use something like OPIE (one-time passwords in everything, S/KEY) with dovecot?
Here's what I want to do ultimately:
- have an AUTH=XYZ method that relies on S/KEY as provided by the libpam-opie module (well, maybe not through pam)
- have dovecot advertise authentication as follows:
- local : PLAIN, XYZ
- remote (encrypted) : EXTERNAL, and rely on certificate
- remote (unencrypted): XYZ
Thats the dovecot part. Then I would modify squirrelmail to a) negotiate PLAIN with an authorized web client certificate b) negotiate XYZ when without SSL or SSL without a valid certificate
This way I could check my mail even from computers that I don't trust at all to not do key-logging, since I can have an S/KEY generator on my cell-phone.
Does this sound feasible? I see the following advantages:
- allows checking of webmail on the road, on untrusted computers, giving out only whatever you decide to look at
- allows checking of mail via unencrypted IMAP, relying on one-time passwords so giving an attacker only whatever he can look at while your session is active (assuming he can't insert anything into the tcp stream...)
- is otherwise encrypted, and then doesn't force using one-time keys which may be somewhat a hassle to generate.
johannes
On Thu, 2004-05-13 at 20:16, Johannes Berg wrote:
Hi,
Is there any way to use something like OPIE (one-time passwords in everything, S/KEY) with dovecot?
Here's what I want to do ultimately:
- have an AUTH=XYZ method that relies on S/KEY as provided by the libpam-opie module (well, maybe not through pam)
I didn't really understand how libpam-opie works. Does it require some special client or how does it tell the seed/sequence? Or doesn't it?
But sure, Cyrus SASL has AUTH=OTP mechanism, we could be compatible with that. Want to write it? :) Shouldn't be hard to plug into Dovecot, I just don't really have time right now.
The OTP-data could be stored in same way as PASSDB_CREDENTIALS_DIGEST_MD5. Except the code doesn't currently allow multiple credentials per user, it only uses the beginning of the password field to specify the password type, eg. "{PLAIN}password", "{DIGEST-MD5}digest-md5-credentials", etc. I guess I should do something about that..
- have dovecot advertise authentication as follows:
- local : PLAIN, XYZ
- remote (encrypted) : EXTERNAL, and rely on certificate
- remote (unencrypted): XYZ
Thats the dovecot part. Then I would modify squirrelmail to a) negotiate PLAIN with an authorized web client certificate b) negotiate XYZ when without SSL or SSL without a valid certificate
1.0-test9 supports "ssl_verify_client_cert" option, but then it always requires it .. hmm. maybe with it enabled the configuration could support something like:
auth default { mechanisms = plain .. ssl_require_client_cert = yes }
auth otp { mechanisms = otp .. ssl_require_client_cert = no }
Yes, that looks good, I'll implement that.
Does this sound feasible? I see the following advantages:
- allows checking of webmail on the road, on untrusted computers, giving out only whatever you decide to look at
One problem is that it also gives the possibility to modify the mailbox which isn't very good. From my TODO:
- 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?
Maybe flag changes would be allowed (but not \Deleted). Anyway, this could be configurable as well (append :READONLY to default_mail_env).
On Mon, 2004-05-17 at 02:24, Timo Sirainen wrote:
I didn't really understand how libpam-opie works. Does it require some special client or how does it tell the seed/sequence? Or doesn't it?
For setting the password, it tells you the seed/sequence (will refer to that as s/s for now). You then calculate md5^sequence(key) (apply md5 sequence times) and give that to the server. It stores it, and lets you log in the next time if you can give it md5^(sequence-1)(key). If you really want to know the gory details -> s/key in opie(4). Opie uses this inside pam by just making the query string "opie: s/s" (similar, not identical to that) instead of "Password:".
But sure, Cyrus SASL has AUTH=OTP mechanism, we could be compatible with that.
Would have to investigate that SASL mechanism.
Want to write it? :) Shouldn't be hard to plug into Dovecot, I just don't really have time right now.
Sure.
The OTP-data could be stored in same way as PASSDB_CREDENTIALS_DIGEST_MD5. Except the code doesn't currently allow multiple credentials per user, it only uses the beginning of the password field to specify the password type, eg. "{PLAIN}password", "{DIGEST-MD5}digest-md5-credentials", etc. I guess I should do something about that..
I don't think that matters. In opie, that could be: {OTP}sequence seed md5 date or something. You really only need to store one tuple of data per user.
1.0-test9 supports "ssl_verify_client_cert" option, but then it always requires it ..
Yeah, I've seen that,...
hmm. maybe with it enabled the configuration could support something like:
auth default { mechanisms = plain .. ssl_require_client_cert = yes }
auth otp { mechanisms = otp .. ssl_require_client_cert = no }
Yes, that looks good, I'll implement that.
but that looks perfect :-)
One problem is that it also gives the possibility to modify the mailbox which isn't very good. From my TODO:
Good point! Hadn't thought of that so far.
Thanks for your answer. I'll be looking at SASL OTP, and dovecot source.
johannes
On Mon, 2004-05-17 at 05:44, Johannes Berg wrote:
Want to write it? :) Shouldn't be hard to plug into Dovecot, I just don't really have time right now.
Sure.
Looking at the code I see that you support cyrus SASL, and cyrus SASL in turn supports OTP even using the same database as OPIE uses. Would there be and disadvantage in simply using that? Alternatively, what about just libopie (the library behind opie-pam)? Over all, its not hard to implement this in dovecot itself, but I'm not sure that would be the best idea. What is your opinion on that?
johannes
On 17.5.2004, at 13:11, Johannes Berg wrote:
Looking at the code I see that you support cyrus SASL, and cyrus SASL in turn supports OTP even using the same database as OPIE uses. Would there be and disadvantage in simply using that?
Personally I have never liked Cyrus SASL. It's always been annoyingly difficult to configure to work like I wanted.
The code there to support it isn't actually working right now, but I guess it wouldn't be too difficult to fix it.
I guess there aren't any real disadvangates though.
Alternatively, what about just libopie (the library behind opie-pam)?
That doesn't look very good code .. Looks like if it was possible for user to set wanted seed there would be several buffer overflows. But I guess normally it's not?
Over all, its not hard to implement this in dovecot itself, but I'm not sure that would be the best idea. What is your opinion on that?
The reason why I implemented my own authentication instead of just using Cyrus SASL was that I wanted to be sure there were not going to be any serious security holes. I could have just audited the code, make sure the found security holes were fixed (actually did both once), and then just use it. But that doesn't give any guarantees about it's future versions, I'd have to constantly keep auditing the new versions to make sure they hadn't added more bugs.
Anyway, it's OTP code didn't look bad. That would be the easiest way to get it working.
On Tue, 2004-05-18 at 14:23, Timo Sirainen wrote:
Personally I have never liked Cyrus SASL. It's always been annoyingly difficult to configure to work like I wanted.
I don't have experience with it, so ... :)
The code there to support it isn't actually working right now, but I guess it wouldn't be too difficult to fix it.
I might try this.
That doesn't look very good code .. Looks like if it was possible for user to set wanted seed there would be several buffer overflows. But I guess normally it's not?
I'm not sure I understand you. opiepasswd allows you to set the seed when changing your otp settings. I guess I'll need to look at the code, though I'm not really a C wizard nor very knowledgeable about insecure C code. Can you explain further what possible problems you see?
The reason why I implemented my own authentication instead of just using Cyrus SASL was that I wanted to be sure there were not going to be any serious security holes. I could have just audited the code, make sure the found security holes were fixed (actually did both once), and then just use it. But that doesn't give any guarantees about it's future versions, I'd have to constantly keep auditing the new versions to make sure they hadn't added more bugs.
Makes sense.
Anyway, it's OTP code didn't look bad. That would be the easiest way to get it working.
Right. Cyrus SASL can (optionally) use opie as well.
johannes
On Tue, 2004-05-18 at 17:20, Johannes Berg wrote:
That doesn't look very good code .. Looks like if it was possible for user to set wanted seed there would be several buffer overflows. But I guess normally it's not?
I'm not sure I understand you. opiepasswd allows you to set the seed when changing your otp settings. I guess I'll need to look at the code, though I'm not really a C wizard nor very knowledgeable about insecure C code. Can you explain further what possible problems you see?
opiepasswd checks that the seed is valid size so it's kind of safe, but if you were able to directly modify the database and add a larger seed than normally allowed, the password verifying code could overflow some buffers.
On Mon, May 17, 2004 at 03:24:51AM +0300, Timo Sirainen wrote:
The OTP-data could be stored in same way as PASSDB_CREDENTIALS_DIGEST_MD5. Except the code doesn't currently allow multiple credentials per user, it only uses the beginning of the password field to specify the password type, eg. "{PLAIN}password", "{DIGEST-MD5}digest-md5-credentials", etc. I guess I should do something about that..
Please keep it as compatible as possible with the equivalent LDAP scheme! (Also bearing in mind that LDAP permits multiple credentials per user, although it can't do anything much sophisticated than retrieving them).
Thanks Joshua.
-- Joshua Goodall "as modern as tomorrow afternoon" joshua@roughtrade.net - FW109
On Mon, 2004-05-17 at 13:08, Joshua Goodall wrote:
On Mon, May 17, 2004 at 03:24:51AM +0300, Timo Sirainen wrote:
The OTP-data could be stored in same way as PASSDB_CREDENTIALS_DIGEST_MD5. Except the code doesn't currently allow multiple credentials per user, it only uses the beginning of the password field to specify the password type, eg. "{PLAIN}password", "{DIGEST-MD5}digest-md5-credentials", etc. I guess I should do something about that..
Please keep it as compatible as possible with the equivalent LDAP scheme! (Also bearing in mind that LDAP permits multiple credentials per user, although it can't do anything much sophisticated than retrieving them).
How does it do that? By simply having the same userid multiple times there with different passwords?
- Timo Sirainen tss@iki.fi (20040517 15:25):
How does it do that? By simply having the same userid multiple times there with different passwords?
The 'userPassword' is multi-valued.
-- olive
participants (4)
-
Johannes Berg
-
Joshua Goodall
-
Olivier Tharan
-
Timo Sirainen