How to Safely Store Your Users' Passwords in 2016
paragonie.com
How to Safely Store Your Users' Passwords in 2016
1–10 of 321 posts
Re: How to Safely Store Your Users' Passwords in 2016
#2Assuming this is legit (seems like it), mega bonus points for walking through examples on the various platforms/languages.
Re: How to Safely Store Your Users' Passwords in 2016
#3Anyone have a good explanation of why, in the Python example, they recommend `hmac.compare_digest` instead of `==` for comparison?
Is there something obvious I'm missing here?
Re: How to Safely Store Your Users' Passwords in 2016
#4Anyone have a good explanation of why, in the Python example, they recommend `hmac.compare_digest` instead of `==` for comparison? Is there something obvious I'm missing here?
I'm not a python person but it is probably a constant time comparison. If you compare things in such a way that the time it takes to complete increases with increasing prefix match than timing attacks are possible to recover the secret.
Re: How to Safely Store Your Users' Passwords in 2016
#5For anyone who reads the comments before clicking the article, the subject is storing your users' passwords, not managing your passwords for a variety of services. I had interpreted it as the latter. A better title might be "How to Safely Store Your Users' Passwords in 2016".
(Title is currently: "How to Safely Store a Password in 2016")
Re: How to Safely Store Your Users' Passwords in 2016
#6Anyone have a good explanation of why, in the Python example, they recommend `hmac.compare_digest` instead of `==` for comparison? Is there something obvious I'm missing here?
== in python will stop comparing after the first character mismatch. You can use that fact to test byte by byte your password knowing that the more good characters you have, the longer the comparison will take, which is called a timing attack.
hmac.compare_digest is a constant time compare, in that no matter if there is a match or not, it will take the same amount of time.
Re: How to Safely Store Your Users' Passwords in 2016
#7Anyone have a good explanation of why, in the Python example, they recommend `hmac.compare_digest` instead of `==` for comparison? Is there something obvious I'm missing here?
hmac.compare_digest is constant time whereas == will return as soon as a mismatch is found. The difference in return time can be measured. The key phrase is a Timing Attack[0].
Re: How to Safely Store Your Users' Passwords in 2016
#8Or, we could move to not storing passwords at all, viz client certs and SRP.
Re: How to Safely Store Your Users' Passwords in 2016
#9If you're using node.js and you use these hashing methods, your entire server is going to pause for 0.5 seconds on a login because it runs on a single thread. Goodbye to all of your server performance.
You can create a worker system, or use a child process to solve this problem, but most of these articles never mention it
Re: How to Safely Store Your Users' Passwords in 2016
#10Anyone have a good explanation of why, in the Python example, they recommend `hmac.compare_digest` instead of `==` for comparison? Is there something obvious I'm missing here?
== in python will stop comparing after the first character mismatch. You can use that fact to test byte by byte your password knowing that the more good characters you have, the longer the comparison will take, which is called a timing attack. hmac.compare_digest is a constant time compare, in that no matter if there is a match or not, it will take the same amount of time.
I don't think that's an issue when your comparing salted passwords. AKA F('Passsword') = Hash('Passsword' xor 'some value') = "123456"
F("value") > "123455" which is close, but that does not let you get a 'better' guess.
PS: Assuming the Salt is hidden, and the Hash is secure.