Hi, I'm "researching" (for a school project) how IMP (2.2.x) (http://www.horde.org/imp) handles user sessions etc. One thing I don't like about IMP is how it stores user's password in database: The password is stored in cleartext (base64-encoded) in the database, so anyone who has (or can get) access to the active_sessions table can get logins/passwords of all users who are currently logged in. (IMP needs access to the cleartext password to connect to the IMAP/POP server). A possible way of encrypting user passwords before they are stored in the database is to create a random encryption key(K) (and sessionID) for each client and encrypt the password with K. The sessionID and K are stored in client cookies and all other user info is stored in the db (sessionID is the lookup key). So the cookie is going to be something like: Set-Cookie: IMP-session=sessionID&EncryptionKey ... Now because the user's password is encrypted and only the client stores the encryption key it's not possible to get the cleartext password without also getting the cookie from the client (so it's going to be much harder to collect passwords from eg. db-backup). I guess to make session bruteforcing harder one could use HMAC: something like this: IMP-session=sessionID&EncryptionKey&HMAC(sessionID&EncryptionKey) ... but if the sessionID is "unpredictable" I don't see much use for the HMAC ? Also accepting the sessionID cookie only from one ip-address should make session bruteforcing harder (and possibly lock out legitimate users). (What about accepting the cookie only from the same subnet (/24) ?) Is somebody aware of any studies how often client's ip-address changes when accessing www-services ? As I recall in the "Dos and don'ts of client authentication on the web" (yahoo section) that it's not that big of a problem ? Well anyway: Is there a better way of letting IMP have access to the user's cleartext password and at the same time trying to keep it secret/encrypted ? Cheers, -Jarno -- Jarno Huuskonen <Jarno.Huuskonenat_private>
This archive was generated by hypermail 2b30 : Tue Jul 23 2002 - 16:41:32 PDT