Re: [vwrap] authentication : remove reference to MD5

[Meadhbh Hamrick <[e-mail]>]

yes. but until the migration is complete for all users, do we
implement the new spec with SHA256? do well tell users they have until
a certain date to login and regenerate the hash?

it would be nice if we could have SOME reverse compatibility so we
could use the maintenance facility to do the rehashing. so you could:

1. on a certain date, stop returning seed caps from a successful login
with MD5, but include a maintenance cap with an URL pointing to a page
users can use to rehash their password.

2. at the web page, users re-enter their password, it's hashed with
SHA256 and it's stored in the database.

3. the next time that user logs in, they hash their password with
SHA256 instead of MD5 and avoid having to go through the process
again.

4. at some point in the future, you disable logins for people with
only MD5 hashed passwords (maybe).

what we would need to make this work would be:

a. a way to log in with MD5 until you can use VWRAP to carry the
SHA256 password.

b. a way to figure out which hashed password to send (MD5 or SHA256).

in the case of second life, you probably COULD get away with using MD5
with the legacy protocol. i can't remember if the current legacy
protocol supports maintenance caps. if it does you could use a
maintenance cap. if not, you simply fail and wait for the user to call
the support line. this would be pretty costly, but if we really want
to avoid legacy in the new protocol, we're probably going to see a
number of issues like this.

if we had just enough legacy in the new protocol to support MD5, we
could use the maintenance capability as described above. if we added a
return value from the auth request that had the meaning of
"unsupported algorithm" the client would know to retry the MD5 request
with SHA256.

just my $0.02.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Tue, Apr 6, 2010 at 2:25 PM, Barry Leiba
<[e-mail]> wrote:
>> so if we simply said "we're going to ditch MD5 in favor of SHA256"
>> there would be a problem with reverse compatibility of the
>> authentication data. this is because you can't generate the pre-image
>> from an MD5 MIC and then use it to generate a SHA256 MIC. (or you
>> can't do that in a way that insures that your MD5 pre image is the
>> same as the password.)
>
> The usual way to handle this is with a migration process.  Credentials
> are re-hashed with the new algorithm when they're changed, over time.
> After a time, there's a cutoff and users are forced to change their
> credentials the next time they log in.  The old login has to be
> supported as long as there are users who have not yet changed... or
> until someone decides to toss those users.
>
> Barry
>