[Catalog-sig] Pull request to migrate PyPI to bcrypt

[Giovanni Bajo]

Il giorno 11/feb/2013, alle ore 14:54, Giovanni Bajo <rasky at develer.com> ha scritto:

> Il giorno 11/feb/2013, alle ore 14:38, Donald Stufft <donald.stufft at gmail.com> ha scritto:
> 
>> On Monday, February 11, 2013 at 8:15 AM, M.-A. Lemburg wrote:
>>> Giovanni Bajo wrote:
>>>> Il giorno 11/feb/2013, alle ore 13:25, Jesse Noller <jnoller at gmail.com> ha scritto:
>>>> 
>>>>> Actually I was thinking about this in the shower: the likelihood that pypi users used the same passwords as they did on the wiki is probably much higher than any of us assume.
>>>> 
>>>> Given that the passwords were unsalted in both instances, a set intersection is enough to verify.
>>> 
>>> The moin wiki passwords were salted.
>>> 
>>> The reason we reset the passwords, was that the attackers had
>>> access to both the salt and the hashes.
>>> 
>> What were they hashed with? Even with a salt a fast hash is trivial to
>> bruteforce for a large number of passwords in practically no time
>> with trivial hardware. 
>> 
> 
> 
> Yes, and that's why all passwords were reset.
> 
> PyPI is even worse (unsalted SHA), but there is no current evidence of compromise. The discussion here is that I suggest to migrate all hashes immediately to bcrypt (by bcrypting the SHA1 hash, and then detecting this at startup), while Christian's proposal is to migrate as users login, so leaving SHA1 hashes in that DB for an unknown number of days/weeks/months.

.... detecting this AT LOGIN ....

-- 
Giovanni Bajo   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130211/4f50191d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130211/4f50191d/attachment.bin>