[Catalog-sig] Mandatory Reset of PyPI Passwords

[Giovanni Bajo]

Il giorno 14/feb/2013, alle ore 00:17, Richard Jones <richard at python.org> ha scritto:

> On 13 February 2013 22:32, Giovanni Bajo <rasky at develer.com> wrote:
>> Il giorno 13/feb/2013, alle ore 12:14, Richard Jones <richard at python.org> ha scritto:
>>> 
>>> 2. fix the email password reset debacle (mostly written, not tested),
>> 
>> Is this committed anywhere I can take a look?
> 
> It will be presently. In short, the old procedure was:
> 
> 1. user enters username in form and is emailed a link back to PyPI
> which embeds the username and password,
> 2. user clicks link and, on receiving both username and email address
> a new password is generated and mailed to the email address.
> 
> If the user knows both the username and email address they can skip
> straight to step 2.
> 
> The new scheme involves:
> 
> 1. user enters username in "I've forgotten my password" form,
> 2. PyPI emails user with a link back to itself with a reset OTK (32
> random chars from letters+digits) valid for 6 hours,
> 3. On clicking the link the user sees a password reset form where they
> enter their new password, and
> 4. On submitting the reset form the OTK is deleted and password changed.
> 
> If an invalid username is entered PyPI will say so: the set of pypi
> usernames is public anyway through APIs and general web scraping and
> this behaviour is more user-friendly than the more common "I may or
> may not have emailed you a reset email."

The package "itsdangerous" provides some drop-in crypto for sending a time-based token that doesn't need to be stored on your database (or wherever you're now storing the OTK). Up to you if it's worth it, since IIUC you've already implemented it.



>>> 5. add automated email sent to package role holders (maintainers and
>>> owners) when their package is updated in any way.
>> 
>> In my doc (task #12) I propose using a separate per-package security email, and in fact I was also proposing to ask confirmation by email, rather than just notify it.
> 
> I think it's reasonable for my initial implementation to just email
> the maintainers to notify them, given that "updated in any way" would
> include publication of releases or editing of release information.
> 
> 
>> Basically, PyPI would warn the maintainer that the requested action is a security change for the package, and it needs to be confirmed through a link sent to the security email. A security email would be an email associated to each package, that must be different from the maintainer email (possibly even a different domain, in fact, though I'm not sure we want to enforce it rather than just suggest it). The email text must say "user X has requested change Y to package Z. If you are user X, click here to approve it". Only the maintainer that originated the change request can approve it through the link. The email can be an alias that forwards it to different maintainers, though.
> 
> Would that workflow apply for a release? Seems quite burdensome.
> Requiring users to have different email addresses for the two is quite
> unrealistic.


Oh, well, no :)

Task #12 applies to "security-related changes", for which a definition is given:
https://docs.google.com/a/develer.com/document/d/1DgQdDCZY5LiTY5mvfxVVE4MTWiaqIGccK3QCUI8np4k/edit
==================================================
We define “security-related” change any profile change in PyPI that allows a new GPG fingerprint to be valid for a given package. The currently identified security-related changes are: 
	• Modifying the GPG fingerprint in a package owner or maintainer profile.
	• Adding a new owner or maintainer to a package 
	• Any change to the second-factor authentication system itself
==================================================

So if your goal was to send an email when a new release is published, that's not a security-related change.
-- 
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/20130214/066d7448/attachment.bin>