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

[Giovanni Bajo]

Il giorno 11/feb/2013, alle ore 13:56, Christian Heimes <christian at python.org> ha scritto:

> Am 11.02.2013 13:05, schrieb Giovanni Bajo:
>> This is harder to fix. Christian's main concern is that he doesn't trust me and my proposed solution because he didn't see it elsewhere. I saw it mentioned many times around, but I think that, at the end of the day, that's a red herring: the point is that I'm not in his (and/or your) trust circle, but that's fine, we can still find a way around it. It's probably useless for me to keep arguing though.
>> 
>> I think that a migration path on login from an unsalted SHA1 is completely wrong, so I have a proposal: I will submit it if we agree on resetting all the passwords immediately; or within a short timeframe (eg: 2 months), and notify all the users to login once as soon as possible (so after 2 months we reset passwords of users who haven't logged in).
> 
> Please don't get me wrong. It's not that I don't trust *YOU*. I don't
> trust unknown stuff when it comes to security. Cryptography has a
> tendency to blow up in your face when you leave the trail and wander of
> into the jungle.

I understand it's not personal. I'm still baffled because applying a hash on top of a hash can't be less secure than the least secure hash is. In fact, PBKDF2 is based on hash compositions; it's worth noticing that it's a generic construct that can be applied to any crypto hash function, meaning that composition is meant to be safe in general, as long as the underlying hash function is. Composing hash functions can't possible make them less secure than the least secure of the group is. 

In this case, we're just composing to hide the weak SHA1 hash. I totally can't see how applying bcrypt on a SHA1 hash can make it weaker, or can open the door to anything. I don't see any *theoretical* attack, given that SHA1 output is basically a random sequence of 20 bytes. Even if SHA1 is ever broken to the point of finding patterns in its output (which would contradict years of statistical analysis), you would have then to use those same patterns to force bcrypt.

My overall feeling is that the level of paranoia here is way higher than me asking to use the *default* number of rounds for bcrypt, suggested by everybody in the crypto world, including passlib authors. If I'm "Fort Knoxifying" PyPI by asking to simply go with the best practice, I can't see why being so paranoid about hash functions compositions is not a paranoia.

> I actually *like* the idea to move to a proper adaptive key derivation
> algorithm with salting. Although I personally prefer PBKDF2 over bcrypt.


I have no issue with that. I tend to prefer bcrypt because pbkdf2 design allow it to be run over GPUs while bcrypt currently can't (it requires custom ASICs), so my gut feeling is that the security margin of bcrypt is higher. But I wouldn't oppose PBKDF2 of course.
-- 
Giovanni Bajo   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

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

-------------- 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/0648538f/attachment.bin>