Re: [vwrap] MD5 must die [was: Re: authentication : remove reference to MD5]

[Joshua Bell <[e-mail]>]

On Tue, Jul 6, 2010 at 12:19 PM, Meadhbh Hamrick <[e-mail]>wrote;wrote:

> MD5 is bad, i think we all agree. US-CERT's advisory "MD5 vulnerable
> to collision attacks" @ http://www.kb.cert.org/vuls/id/836068 explains
> why.
>
> we had a couple of good recommendations:
>
> 1. patnad and barry said, "just force people to re-register and store
> the new password hash." and that's probably a good idea.
>
> 2. sean mentioned, "just keep legacy SL running the old system while
> everyone else uses the new." and that's probably a good idea too.
>
> 3. we could also do something funky like say that for peeps like SL,
> hash the password first with MD5, and then with SHA256. (i.e. - you
> use the MD5 hash as the shared secret instead of the password.)
>
> linden unfortunately has a bazillion users whose passwords are
> "stored" as MD5 hashes. and i wanted to ask josh and/or joe (who as
> far as i know) still work at linden... what do you think about this?
> is there a preference from linden? you guys are going to be the most
> affected.


(speaking as participant)

Yep, still here.

No preference from Linden; I think you should disregard Linden needs on this
particular issue.

* (1) is, of course, a possible option;
* (2) could be satisfied by Linden releasing a technical note (etc) on an
extension to VWRAP Auth that "introduces" algorithm=md5 (i.e. puts back the
text that is proposed to be cut); this would be sufficient for clients that
wished to auth against both "vanilla" VWRAP and potentially special-case SL
* (3) ditto, as a way of doing #2 with increased security during transport
("md5+sha256") - nice thought, Meadhbh!
* And, of course, there's the option of doing out-of-band authentication
using OpenID (etc) via CALM or the equivalent.

None of these appear to require codifying in the spec now, as long as there
are no "MUST NOT" requirements that forbid extensions (which would be bad
anyway), and Linden doesn't have sufficient data to commit to a particular
approach at this time.

Joshua