Arch Linux

Yes, I've been thinking about this recently. I think it should be one of the most important things to do in v2.0.

Passwords aren't stored in plaintext. This was actually my idea, since I didn't like the idea of people with access to the DB knowing what my password was, as I like to keep things simple and use the similar or the same ones in several places at times.

I'm not sure this is possible to implement anymore, since what's in the database is just a hash of the real password. What would be doable is a password reset of some kind, where the system just generates a random new one and emails it to the registered address.

What do you think of that? It's not too tricky...I've taken the task.

I don't think anyone ever thought about sending an old password. 'Retrieval' was supposed to mean sending either a new generated password or a secure link to a page where user could change his password himself.

Maybe it was just my interpretation that the idea was to send out the current password.
Something that just came to mind: having a simple reset button like that is sort of open to abuse. For instance, I type in "swiergot" under username and then hit reset. Sure, I'm not actually doing anything malicious, and have no access to the password, but I could keep doing it and be really annoying. Any thoughts on how to remedy this? Some solutions on other sites include things like secret questions. I find that solution bad, because I usually forget my exact answer anyway, so it's just as bad as forgetting your password in the first place.

I see two possibilities.

1. User enters his login and birth date. It's hard to forget (unless he lied about that but then he is guilty). The date could be encrypted in the database just as passwords are so that users could be sure we will not use it.
2. The reset button doesn't reset password but just sends a link user can follow to change his password. To protect against spamming you mentioned we could allow using it only once a day.

I wonder how many people this problem is affecting. How about they email one of us and ask us to change their password? We email them back to make sure it's them. Then we change it to some temporary password which they change later.

Seems like we should try the manual solution for now, until we can be sure there's a problem large enough to be spending a lot of time fixing.

Well, to solve the problem of some person clicking on the reset button you can do the following:


If you click on reset button, then, an email will come with some kind of link to the password reset

http://www.example.com/passreset.php?login=rudy&id=046Dae38Ft482476f85320431867129120572856820

Where ID 046Dae38Ft482476f85320431867129120572856820, will be some id for the password reset request. It will be unique (and hard do guess).

If the person dont click on the link, the password will just remain the same. This can prevent abuse...

By the way, some1 knows the email of one of the AUR admins? I have to find a way to retrieve mine...

Two patches to implement a password reset facility. First patch adds a uid_from_email() function which is based on uid_from_username() and the second does the rest.

See the log message on the second patch for an summary of the method used to validate password reset requests.

Serious review is needed, as we're messing with people's passwords and this could possibly introduce a security vulnerability. :)

It would be a good idea IMO to implement this and  FS#17109  at the same time.

Thanks for the patches. They've been pushed to the git repo.
Please send patches to the mailing list in the future and then link to the thread instead.

Please don't close bugs for features that have not been released as stable yet.

Can we get this pushed to the live site so the password reset threads on the forums can be closed? :)

If these patches are already committed to git, why are they not pushed to the site yet? Is there a problem?