51–60 of 321 posts
Earlier quoted context omitted.
I could have sworn it used PBKDF2-SHA256 and Salsa20/8 internally, which is what I meant by "based on".
It also uses xor internally, but I wouldn't say that scrypt is based on xor. scrypt does not use PBKDF2 for any PBKDF properties; it's just a convenient arbitrary-length-output hash function. I would have used a sponge if they had been widely available when I created scrypt.
Earlier quoted context omitted.
Timing attacks aren't useful against password hashes, but avoiding them is a good habit to be in.
This is "mostly true" but with an edge case... If the attacker knows which algorithm and work factor you're utilising and your system doesn't use randomly generated per user salts (or an unknown pepper) then theoretically an attacker could use a hash timing attack, combined with a rainbow table, to massively reduce the scope of a user's potential password. For example, let's say your rainbow table has 20 million pass…
It would be great if, in 2020, or sooner, but probably later, the answer is "don't use passwords any more. They are deprecated components of society."
"How to Safely Store a Password in 2016" Don't. Unless it's 100% absolutely necessary. If you must, continue reading on.
Earlier quoted context omitted.
This is "mostly true" but with an edge case... If the attacker knows which algorithm and work factor you're utilising and your system doesn't use randomly generated per user salts (or an unknown pepper) then theoretically an attacker could use a hash timing attack, combined with a rainbow table, to massively reduce the scope of a user's potential password. For example, let's say your rainbow table has 20 million pass…
I chose the words "password hash" carefully. If you're using a secure password hash, you're not worrying about salts, because they take care of randomization for you. If you are worrying about salts, you probably have bigger problems than memcmp timing.
Password hashing has existed since at least the 1970s and until the 2000s salting wasn't common. While some hashing libraries do insist on you supplying a salt, it is still ultimately up to the application developer to generate and store the salt for later usage.
Therefore it is still common for an application developer to "worry about salts" even if just for storage and generation reasons.
Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in the realm of a "password hash." Plus some wonderful developers hard code the salt (salt = "secret") which too could leave them vulnerable to timing attacks if an attacker knew what hashing algorithm and workfactor (e.g. the default) was in usage.
Earlier quoted context omitted.
I chose the words "password hash" carefully. If you're using a secure password hash, you're not worrying about salts, because they take care of randomization for you. If you are worrying about salts, you probably have bigger problems than memcmp timing.
I literally don't understand what it is you're getting at. Password hashing has existed since at least the 1970s and until the 2000s salting wasn't common. While some hashing libraries do insist on you supplying a salt, it is still ultimately up to the application developer to generate and store the salt for later usage. Therefore it is still common for an application developer to "worry about salts" even if just for…
I truly hope this will help then: https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass...
"Password hashing" is its own compound noun. The acceptable algorithms (as defined in the blog post this HN thread is about) take care of this for you.
> Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in the realm of a "password hash."
3DES is a block cipher. MD5 is a crytographic hash. Neither of them are password hashes.
> Plus some wonderful developers hard code the salt (salt = "secret") which too could leave them vulnerable to timing attacks if an attacker knew what hashing algorithm and workfactor (e.g. the default) was in usage.
What you're describing is closer to a "pepper".
http://blog.ircmaxell.com/2012/04/properly-salting-passwords...
For 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")
Earlier quoted context omitted.
great, thanks. because i was about to reply with "on a piece of paper in the same place you store your diamonds"
I'm starting to think that if you're a security-conscious person and understand what's at stake, then the best solution for you would be to simply memorize it. Your mind is the only place from which an attacker can't steal your password without drugging you or beating you up until you give it out.