[Rt-devel] Password storage format in RT3.6

[Arne Georg Gleditsh]

Ruslan Zakirov wrote:
> I think we should allow admins(if it possible) to:
> * choose between MD5 and MD5 salted
> * script that changes stored hashes at once. Is it possible to add
> salt to MD5 hash with password string?

Not that I am aware of.

> It was big surprise to when I saw that we'd switched from md5 in
> base64 to md5 in hex. And also it's very hard to auth against RT's DB
> when some password hash strings are base64 encoded while other are
> hex-encoded.

This I can see.  Instead of overwriting the original password in the db, 
perhaps a new column should be added where updated passwords are written 
when users log in.  Existence of non-null entries in this column would 
then dictate that this be used for authentication instead of the old 
column.  External entities authenticating towards RT's database could 
then switch to using the new format when the administrator decides 
everyone has had sufficient time to log in to RT and so refresh their 
accounts.

This also has issues, obviously.  Do password updates change both old 
and new columns?  Given that the old-format password store is a security 
liability, when do you remove it?  How should the application logic 
detect that it is removed and stop updating it?

Overall, I'm not sure this is not at least as painful as just migrating 
the way it is done today, switching any external entities to use the new 
format immediately and then telling the users to refresh their accounts 
by logging in to RT before attempting to access services provided by the 
mentioned external entities.  Mileage will no doubt vary.

(The password scheme implemented by the proposed patch is general and 
widely deployed, so the need for further migrations should not arise in 
a good while.  That is, until someone decides we need to move to SSHA1 
or somesuch. :)

-- 
							Arne.