On Tuesday, February 12, 2013 at 12:15 PM, Antoine Pitrou wrote: > Donald Stufft <donald.stufft <at> gmail.com (http://gmail.com)> writes: > > > > However I think a better approach would be to not automatically upgrade and > instead > > have the upgrade occur when a user changes their password. Then we should > > set > > a date (A month from now? 2?) where any user who has not reset/changed their > > password will have their password invalidated and will need to use PyPI's > > > > recovery > > options. > > > What would that change exactly? There's still a two months window during which > the leaked password can be exploited. > Also, I don't understand why you're tying this to the hashing scheme > migration. > They're two orthogonal schemes. > > I still think the original migration scheme should be applied (i.e. migrate > all > passwords immediately to bcrypt + sha1). Whether some passwords should also be > reset is a separate concern. > >
Sorry I still mean migrate passwords to bcrypt + sha1 immediately, I mean don't migrate to standard bcrypt upon login, only upon password change, so that we can determine who has changed their password (They'll have just bcrypt, not bcrypt + sha1) and exlude them from the password invalidation. > > Besides, keep in mind that many people will never explicitly login into PyPI, > they simply use "setup.py upload". As someone mentioned, their account might > be > tied to an e-mail that isn't even valid anymore. > > Yes I'm aware of that, however the greater risk to the community at large, at least in my opinion, outweighs the inconvenience to these users. The window was primarily there to give people who might not have access to their email anymore a chance to proactively change their password and avoid having it invalidated. An immediate (or very short windowed) reset would be better security wise but is far less friendly to people. There will likely be some people who need manually given access back to their account or to their projects after the reset occurs. Again that is an inconvenience but the risk that someone who has already committed a hostile act towards Python.org might locate a password in that dataset that gives him access to accounts on PyPI that give him the ability to mostly transparently replace existing files with new ones that can be used to exploit people installing from PyPI takes a much greater precidence. > > Regards > > Antoine. > > > _______________________________________________ > Catalog-SIG mailing list > Catalog-SIG@python.org (mailto:Catalog-SIG@python.org) > http://mail.python.org/mailman/listinfo/catalog-sig > >
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
