FS#52297 - Passwords should be stored more securely
Attached to Project:
AUR web interface
Opened by Alex Muller (alexmuller) - Thursday, 29 December 2016, 07:25 GMT
Last edited by Lukas Fleischer (lfleischer) - Tuesday, 11 July 2017, 05:09 GMT
Opened by Alex Muller (alexmuller) - Thursday, 29 December 2016, 07:25 GMT
Last edited by Lukas Fleischer (lfleischer) - Tuesday, 11 July 2017, 05:09 GMT
|
Details
I'm new to the aurweb codebase but I've had quick look
around and
it looks like the `salted_hash` function that creates a password returns `md5($salt . $passwd)`. Also, `passwd_min_len` is set to 4 characters. If the aur database was compromised, an attacker could enumerate passwords easily [1]. I'd recommend using a different hash to MD5 to store passwords, and increasing the minimum length of a password. [1]: https://security.stackexchange.com/questions/61712/cracking-md5-passwords-with-the-same-salt |
This task depends upon
Closed by Lukas Fleischer (lfleischer)
Tuesday, 11 July 2017, 05:09 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in 4.5.0.
Tuesday, 11 July 2017, 05:09 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in 4.5.0.
Would all users be forced to change their passwords on their next login?
Would there be "backwards compatibility" with old passwords and allow users to change their passwords at their leasure?
Plus, I'm not entirely sure if this change is urgent or not. On a personal note, if someone figured out my password on the AUR, I would not be too bothered by it since I don't use the password anywhere else.
Would be interesting to have a discussion on this.
I think this is probably fairly important - if there is a single user who reuses passwords across multiple services then any leak of the aurweb database is essentially exposing accounts for other services. I don't know anything about the infrastructure that runs aurweb but if this change isn't going to happen soon it might be worth rotating database passwords, verifying which users have access to the production database and things like that.
I see an issue if you just drop an old column in the database with old password information, anyone can then hijack accounts that weren't reset. That would be a bigger problem in my opinion. This is assuming that the method you suggested is used.
This bug ticket should be closed.