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

[Meadhbh Hamrick <[e-mail]>]

so i was thinking about auth things and thought i would revive this thread...

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.

so to paraphrase winston churchill: "we know it will be hard; we
expect it to be long, we cannot predict or measure its episodes or its
tribulations. but one thing is certain, one thing is sure, one thing
stands out stark and undeniable, massive and unassailable for all the
world to see. we cannot see how deliverance will come or when it will
come, but nothing is more certain that every trace of MD5's footsteps,
every stain of its infected, corroding fingers will be expunged and
purged and, if need be, blasted from the surface of the (virtual)
earth."

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



On Wed, Apr 7, 2010 at 9:58 AM, Sean Hennessee <[e-mail]> wrote:
> If VWRAP has no legacy support, can't the implementors still have mixed mode
> support as long as they decide to? Just because an implementor supports
> VWRAP, (with no legacy support), doesn't necessarily mean they can't support
> legacy protocols as well. Eventually one would hope all would transition to
> only VWRAP, but implementors are really the determining factor of how long
> that transition takes. Even many web browsers continue to support old
> versions of the HTML spec while still supporting newer versions.
>
> Perhaps VWRAP should include a protocol negotiation protocol allowing
> services to determine what protocols and versions of protocols are supported
> on each end. "Sorry, your client is not supported on this sim" should be an
> option. I see (saw) it often when connecting to SL after major client/server
> updates.
>
> Peace,
> Sean
>
> Meadhbh Hamrick wrote:
>>
>> actually. that does bring up a good point. LL _could_ just invalidate
>> everyone's password and make them go through password reset.
>>
>> i agree, patnad, i would do it too, but it may be difficult to
>> convince everyone to do it, and i'm not sure it's the kind of thing a
>> standards organization should require of one of it's implementers.
>>
>> just my $0.02, but yeah, i'll let the lindens speak for themselves.
>> --
>> meadhbh hamrick * it's pronounced "maeve"
>> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>>
>>
>>
>> On Tue, Apr 6, 2010 at 4:18 PM, Patnad Babii <[e-mail]> wrote:
>>>
>>> I think if someday LL ask me to change my password because they made
>>> their
>>> security system better i would really not mind. So typing a password take
>>> 1
>>> minute for changing it.
>>>
>>> Same for all opensim grid if they someday ask me to change my password
>>> because they enforced security i'd be more than happy to provide them
>>> with a
>>> new one.
>>>
>>> I don't think people will leave SL just because you "forced" them to
>>> change
>>> a password honestly.
>>>
>>> --------------------------------------------------
>>> From: "Meadhbh Hamrick" <[e-mail]>
>>> Sent: Tuesday, April 06, 2010 2:22 PM
>>> To: "Peter Saint-Andre" <[e-mail]>
>>> Cc: <[e-mail]>
>>> Subject: Re: [vwrap] authentication : remove reference to MD5
>>>
>>>> we need clarification about how much of the second life legacy
>>>> protocol will be used in VWRAP.
>>>>
>>>> for instance. second life stores the MD5 hash of user passwords in the
>>>> user database and uses it to authenticate users when logging in.
>>>>
>>>> but MD5 has some significant problems which were exacerbated several
>>>> years ago when there was a security breach of linden's servers.
>>>>
>>>> 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.)
>>>>
>>>> so in other words, there is an action we could take in this group that
>>>> COULD make it very difficult for linden and presumably existing
>>>> OpenSim instances to use the authentication protocol.
>>>>
>>>> so the question is, to which degree do we add an engineering burden to
>>>> existing implementations that would like to adopt this group's output?
>>>> the question of the two string identifier is a good one. linden could
>>>> probably make systems that adhere to all sorts of different changes.
>>>> but to what degree to we make it easy for existing implementers vs.
>>>> the desires of people who have yet to build and implementation?
>>>>
>>>> -cheers
>>>> -meadhbh
>>>>
>>>>
>>>> --
>>>> meadhbh hamrick * it's pronounced "maeve"
>>>> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>>>>
>>>>
>>>>
>>>> On Tue, Apr 6, 2010 at 11:01 AM, Peter Saint-Andre <[e-mail]>
>>>> wrote:
>>>>>
>>>>> On 4/6/10 8:19 AM, Meadhbh Hamrick wrote:
>>>>>>
>>>>>> okay.
>>>>>>
>>>>>> if we're going to remove VWRAP from all current implementations,
>>>>>
>>>>> What does that mean? I thought we were trying to build VWRAP into
>>>>> implementations, not rip it out. :)
>>>>>
>>>>>> i
>>>>>> vote we remove MD5 from the auth spec and replace it with a MIC with
>>>>>> better security properties, like SHA224 or SHA256.
>>>>>
>>>>> +1 to more secure authentication.
>>>>>
>>>>> My quick reading of the authentication draft led me to think that it
>>>>> needed a thorough review, but unfortunately I haven't had time to do
>>>>> that yet.
>>>>>
>>>>> Peter
>>>>>
>>>>> --
>>>>> Peter Saint-Andre
>>>>> https://stpeter.im/
>
> --
>
> Sean Hennessee
> Central Computing Support
> Office of Information Technology
> UC Irvine
>
>
> ... . .- -. /  .... . -. -. . ... ... . .
>