[Catalog-sig] Mandatory Reset of PyPI Passwords

Donald Stufft donald.stufft at gmail.com
Wed Feb 13 20:57:58 CET 2013


On Wednesday, February 13, 2013 at 2:42 PM, Antoine Pitrou wrote:
> Donald Stufft <donald.stufft <at> gmail.com (http://gmail.com)> writes:
> > 
> > There's no way to determine if users have changed their password. The passlib
> > branch will be deployed with automatic migration upon logging in turned off. 
> > 
> 
> 
> So why is the automatic migration turned off? Why not migrate everything
> at once as originally proposed?
> What's the point of deliberately keeping weak hashes in the database?
> 
> Regards
> 
> Antoine.
> 
I think there's some confusion as to migration.


CURRENTLY: unsalted sha1
DESIRED: standard bcrypt
MIDTERM: bcrypted sha1's

The midterm "at once" is still possible, it just bcrypt's the existing sha1 passwords.
This is better then unsalted sha1's but it's *worse* than just plain bcrypt. When users
log in passlibcan upgrade them to just bcrypt (this can only happen when the users
login because we need access to the plaintext password to do it). When I talk about
the automatic migration upon logging in being turned off it's this "when I log in upgrade
me from sha1 or bcrypt+sha1 to just bcrypt"

The reasoning for having the automated migration turned off is so we can determine
who has manually changed their password (or is a newly registered user) by seeing
if their password is hashed with bcrypt instead of either bcrypt+sha1 or just sha1.

Now with only a weeks timeline I don't think it's particularly important to migrate the
database from sha1 to bcrypt+sha1 because that code is not well tested (I tried to test
it manually but there may be edge cases and such) however both sha1 and bcrypt by
themselves are well tested. So yes for that week if the DB gets stolen we will be vulnerable
to those passwords being bruteforced, but with an upcoming forced reset that risk is
pretty minimal and the risk of my custom bcrypt+sha1 code breaking in an edge case
is higher. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130213/fd46c1df/attachment.html>


More information about the Catalog-SIG mailing list