IMP and cleartext passwords

From: Jarno Huuskonen (
Date: 07/23/02

Date: Tue, 23 Jul 2002 21:53:03 +0300
From: Jarno Huuskonen <>


I'm "researching" (for a school project) how IMP (2.2.x)
( 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 ?


Jarno Huuskonen <>