Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Storing Passwords Securely

throwingfire.com

Post reply on HN
Print view View original

61–70 of 144 posts

Re: Storing Passwords Securely

#61

Post by pbsd »

DanielRibeiro wrote: post #2

SRP note was very nice: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol On a more esoteric note: If you are looking to resist quantum algorithms attacks, there are post-quantum algorithms for that[1] (they are computed on normal machines, but the problems behind the crypstosystems are hard to solve even for quantum computers). [1] http://crypto.stackexchange.com/questions/494/what-is-the-po...

If you're worried about quantum computers when thinking some website's security, you're either doing it wrong, or living in the future.

Post-quantum is cool alright, but it's not really a thing that implementers need to worry about.

Re: Storing Passwords Securely

#62

Post by dekz »

AgentConundrum wrote: post #49
sillysaurus wrote: post #7

I know I won't be able to easily convince anyone of this, but I thought I'd mention... Colin Percival's "scrypt" password hash is: 1) production-ready (and has been for a long time) 2) superior to bcrypt, as it is designed to be expensive in both CPU and memory (hence, scrypt is "memory-hard", whereas bcrypt is not) I don't have time to go into further detail. I encourage you to check it out. It's quite simply "the f…

I think I answered my own question, but I'll ask anyway - why does memory intensiveness matter?

Processors get faster and faster, so we increase the work factor to compensate and keep it a time-hard problem. This has no real restriction on memory though, so the amount of memory only has to grow linear to the amount of time.

Making it memory-hard makes it also memory hard.

Re: Storing Passwords Securely

#64

Post by daeken »

tptacek wrote: post #13
amalcon wrote: post #12

Earlier quoted context omitted.

The usual concern with scrypt is that it has less research behind it. The bcrypt hash function has gone through over twelve years of attempts without being broken in the cryptographic sense. The scrypt hash has only around three years of the same. I would expect that within 5-10 years, scrypt will be the normal suggestion. It really is much better on the fundamentals, so much so that some experts recommend it even in…

You are going to have a hard time finding a professional cryptographer who will look at scrypt and say that it's risky. These are KDFs, not message authentication codes; they aren't risky constructions. If you have no other choice but to iterate SHA1 many thousands of times, that's still better than what most apps do, and in the grand scheme of things almost "ok". scrypt is fine. If you have a library that supports i…

> If you have no other choice but to iterate SHA1 many thousands of times, that's still better than what most apps do, and in the grand scheme of things almost "ok".

While I won't recommend people simply iterating a hash many times, I also won't slap people down for it anymore. In the grand scheme of things, there are a billion more likely routes of attack than someone breaking your 20000-rounds-of-SHA1 hashes.

Re: Storing Passwords Securely

#65

Post by rorrr »

> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication.

Bullshit. MD5 is just fine, as long as you use the salt.

Here, hack this:

    MD5(password + salt) = "b520542710812f347432232b2a1fba83"

    salt = "MD5 rules"

Re: Storing Passwords Securely

#66

Post by kmfrk »

jharding wrote: post #11

If you're storing passwords as MD5/SHA hashes, how difficult is it be to switch over to bcrypt? I've never had to do this, but I would imagine it would be somewhat trivial. With all of the password leaks that have happened over the past few years, I'd imagine a good amount of developers are aware that storing passwords as MD5/SHA hashes is somewhat risky, so I can't understand why big websites (LinkedIn) are still do…

In Django, as I recall, you just check for a hashing indicator that's prefixed to the hashed password, and do something like this on a user's log-in:

    if hashed_password.startswith("sha$"):
        hashed_password = bcrypt(hashed_password)
(or `... = "bc$" + bcrypt(hashed_password)`. However it's done.)

Here is the relevant code for django-bcrypt: https://github.com/dwaiter/django-bcrypt/blob/master/django_....

In your case, you could probably do this:

    if not hashed_password.startswith("bc$")\
       and sha(entered_password) == hashed_password:
        hashed_password = "bc$" + bcrypt(entered_password)
You don't have the prefix identifier, but that's okay; you just roll out an equivalent now instead, so you only have to check the start of the hash string and do the conversion, if it hasn't already been performed.

Of course, you have to account for the prefix identifier when validating an entered password against the stored hash.

YMMV.

Re: Storing Passwords Securely

#67

Post by dekz »

stickfigure wrote: post #44

How about this: Don't store passwords at all. There are a multitude of sophisticated third-party solutions to authentication. Facebook, Twitter, and Google all offer competent solutions. Don't like those? Use BrowserID. Integrating any of these is actually quite a bit easier than rolling your own solution. It reduces hack risk, provides a better experience for your customers (what was my password again?), and almost…

This naively assumes that your entire userbase uses those services and would like to attribute their Google (et al) account with your service. This may not always be the case.

Someone has to store the passwords, it would be good if there was a way you could be assured your data at rest was safe.

Re: Storing Passwords Securely

#68

Post by dekz »

indygreg2 wrote: post #35
tptacek wrote: post #27

Earlier quoted context omitted.

The == operator is a proper string comparison function in this setting.

Assuming all the steps in the article are followed, yes, you are correct. I still think any article talking about verifying credentials is obligated to mention that string comparison could be an attack vector. Like I said, it plants a seed. And, I've seen way too many naive implementations where it is needed (like simple token-based auth systems) to know that this seed needs to be spread a lot more.

I believe what tptacek is trying to say that an attack on the == operator is not a timing attack but a brute force attack. Sure the function may return quicker but it doesn't reveal any more information and will be a brute force attack of data returned from a hash function.

For other readers, the == operator is comparing a password hash, as opposed to a password itself. One of the properties of a secure hash function is that, changes to the input drastically changes the output. Thus this attack is one of brute force and not a timing attack on the == operator.

Re: Storing Passwords Securely

#69

Post by pud »

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database.

This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too.

I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks to get (1) the salted hashes, and (2) the salt.

Am I misunderstanding?

Re: Storing Passwords Securely

#70

Post by Dylan16807 »

pud wrote: post #69

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…

Salts are not secret. They make you run unique calculations per attacked password and do absolutely nothing else.

You might feel like adding a hidden component but it won't noticeably help security and it's not a salt.

Post reply on HN