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

How To Safely Store A Password

codahale.com

Post reply on HN
Print view View original

41–50 of 110 posts

Re: How To Safely Store A Password

#41

Post by tptacek »

sordidarray wrote: post #39
kelnos wrote: post #31

Earlier quoted context omitted.

You're talking about a completely different problem. Yes, many users pick crappy passwords. That's a social problem, one that is difficult to address with technology[1]. Storing passwords on the server is unrelated to whether or not the user picked a good password. If an attacker gets ahold of a copy of your database, they will have a much easier time of turning SHA1 hashes of passwords into actual passwords than of…

I'm not talking about a different problem. The bruteforce attack described in the article primarily affects short and dictionary-based passwords. If the password is of sufficient length and complexity (the keyspace is large enough), then bruteforcing becomes computationally infeasible. What the article proposes is, essentially, to use a more computationally expensive algorithm for the benefit of protecting shorter, w…

You sound like someone who has never run John the Ripper.

There clearly are passwords that are impractical to crack. To get one, just "head /dev/random | openssl sha1".

Nobody uses passwords like that. They're irrelevant. Instead, the smart ones use passwords that contain a combination of words, numbers, and punctuation. John the Ripper has been cracking those passwords for over a decade.

"Salted hashes" are insecure. They'd have been rejected by the FreeBSD team in 1997. If you choose to make a religion out of not using bcrypt, do what the RFC says and use PBKDF.

Re: How To Safely Store A Password

#42

Post by tsally »

sordidarray wrote: post #33
tptacek wrote: post #24

Earlier quoted context omitted.

The mistake you're making is thinking of bcrypt as a protection for end-users and their passwords. It isn't. Bcrypt exists to protect application developers. A user with a crappy password is getting his account busted one way or another. You're right to point that out. Cryptography won't solve that problem. The problem crypto solves is this: a crappy web app that loses its user table is royally screwed if its devs se…

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information). Losing such a collection of salted hashes does not render one "royally screwed." Those hashes (or HMACs) are still cryptographically secure, which means it's computationally infeasible to find a first preimage provided the password do…

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information).

Are you suggesting that because a comprise is bad, nothing should be done to reduce the magnitude of the impact? This argument does not hold up in general, and it is especially weak when arguing about using encryption algorithms with freely available, high quality implementations. The developer effort required to use bcrypt is minimal.

Also, you seem to be making the incorrect assumption that only poorly written web applications get their databases compromised. Web applications with excellent security get their databases stolen for a variety of other reasons. Even if the programmers do everything right, a careless employee might get his/her password sniffed or stolen by a key logger. If a company uses external hosting, its database could get stolen because of a mistake by the hosting providers.

In summary, the risk of your database being stolen is always present, regardless of the diligence of the the programmers who implemented the web application. The fact that a compromise is bad is not justification for ignoring simple security measures that take minimal effort to implement.

Re: How To Safely Store A Password

#43

Post by peterwwillis »

I am a crypto noob, so please excuse me if I sound stupid. But why not force your users to pick a password that is at least 8 characters and contains at least one digit, one capitalized letter, one lowercase letter and one special character, then gen a 16-byte salt and run it through SHA-512? The examples given in the article are for 6 lowercase alpha-only characters, which has always been relatively trivial to crack.

This brief article I found from 30 seconds in google shows my example at the bottom ('96 characters'): http://www.lockdown.co.uk/?pg=combi

I acknowledge that bcrypt seems like a simple safeguard against password attacks, but I don't doubt a hacker's ingenuity in developing a method to make attacks against it reasonable - especially if it becomes widely adopted. And I think once you've lost your password database you're already completely fucked, in one way or another.

Re: How To Safely Store A Password

#44

Post by KirinDave »

cperciva wrote: post #38
ErrantX wrote: post #30

Earlier quoted context omitted.

That defeats the point of the hashing :)

Actually, it doesn't.

In this case, it does. If the client's job is to hash the password then send it to the server for comparison, you've basically got plaintext passwords. They may be quite long, but we're at that place where things don't scale anymore.

Re: How To Safely Store A Password

#45

Post by tsally »

peterwwillis wrote: post #43

I am a crypto noob, so please excuse me if I sound stupid. But why not force your users to pick a password that is at least 8 characters and contains at least one digit, one capitalized letter, one lowercase letter and one special character, then gen a 16-byte salt and run it through SHA-512? The examples given in the article are for 6 lowercase alpha-only characters, which has always been relatively trivial to crack…

I'll forgo a mathematical argument in favor of a practical one. If you have a choice between offloading complexity to your users or your developers, you should choose your developers every time. Rather that requiring complex password schemes from your users, have your developers use a slow hashing algorithm instead.

Re: How To Safely Store A Password

#46

Post by codahale »

sordidarray wrote: post #33
tptacek wrote: post #24

Earlier quoted context omitted.

The mistake you're making is thinking of bcrypt as a protection for end-users and their passwords. It isn't. Bcrypt exists to protect application developers. A user with a crappy password is getting his account busted one way or another. You're right to point that out. Cryptography won't solve that problem. The problem crypto solves is this: a crappy web app that loses its user table is royally screwed if its devs se…

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information). Losing such a collection of salted hashes does not render one "royally screwed." Those hashes (or HMACs) are still cryptographically secure, which means it's computationally infeasible to find a first preimage provided the password do…

He's implying that using bcrypt (and other iterative hash functions like PBKDF2 and scrypt) raises the cost of mounting a dictionary attack compared to commonly-used and -recommended hash algorithms like SHA256.

Which, uh, is an objectively verifiable fact.

Re: How To Safely Store A Password

#47

Post by sordidarray »

tptacek wrote: post #40
sordidarray wrote: post #33

Earlier quoted context omitted.

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information). Losing such a collection of salted hashes does not render one "royally screwed." Those hashes (or HMACs) are still cryptographically secure, which means it's computationally infeasible to find a first preimage provided the password do…

Losing a Unix password file in the 1990s would have been newsworthy. Password files were "secured" using Unix crypt(3), an algorithm that at least made a nod towards resisting brute force attacks --- so much so that when PHK wrote FreeBSD's md5 scheme, he iterated it PBKDF-style, because even then it was clear that using cryptographic hashes "straight" was a bad idea. The biggest differences between Mindvox losing it…

I never said SHA-1, a cryptographically insecure hash, was a good choice. It's important to note in your differences that, for the most part, cryptographic hash functions in current use have gotten much slower (e.g., SHA-256 vs MD5), but are also getting much better (SHA-3 competition).

The argument I have is this: The passwords that are going to be hitting Rapidshare in your scenario are the crappy or short ones, whether you use bcrypt, scrypt, PBKDF2, salted hashes or HMAC. Encourage them to use bcrypt or some other iterative technique for the security benefits, but don't exaggerate and tell them that they're "effed" if they have salted hashes. They're still a long way away from storing passwords in plaintext.

Re: How To Safely Store A Password

#48

Post by tptacek »

peterwwillis wrote: post #43

I am a crypto noob, so please excuse me if I sound stupid. But why not force your users to pick a password that is at least 8 characters and contains at least one digit, one capitalized letter, one lowercase letter and one special character, then gen a 16-byte salt and run it through SHA-512? The examples given in the article are for 6 lowercase alpha-only characters, which has always been relatively trivial to crack…

Once you go down the road of "not doubting a hacker's ingenuity", you might as well give up and stop applying OS patches. In any case, with "16 byte salts and SHA-512", you're pitting hackers against the folk wisdom of PHP developers. With bcrypt, you're pitting hackers against the IACR. You can't know everything, but you can pick the right battles.

Re: How To Safely Store A Password

#49

Post by cperciva »

KirinDave wrote: post #44
cperciva wrote: post #38

Earlier quoted context omitted.

Actually, it doesn't.

In this case, it does. If the client's job is to hash the password then send it to the server for comparison, you've basically got plaintext passwords. They may be quite long, but we're at that place where things don't scale anymore.

Derive a 256-bit key from your password, then send that 256-bit key to the server. Nobody is ever going to perform a brute-force search against the 256-bit derived keyspace, so any attack will need to run the KDF against a list of likely passwords in order to get a list of likely keys.

Re: How To Safely Store A Password

#50

Post by tptacek »

sordidarray wrote: post #47
tptacek wrote: post #40

Earlier quoted context omitted.

Losing a Unix password file in the 1990s would have been newsworthy. Password files were "secured" using Unix crypt(3), an algorithm that at least made a nod towards resisting brute force attacks --- so much so that when PHK wrote FreeBSD's md5 scheme, he iterated it PBKDF-style, because even then it was clear that using cryptographic hashes "straight" was a bad idea. The biggest differences between Mindvox losing it…

I never said SHA-1, a cryptographically insecure hash, was a good choice. It's important to note in your differences that, for the most part, cryptographic hash functions in current use have gotten much slower (e.g., SHA-256 vs MD5), but are also getting much better (SHA-3 competition). The argument I have is this: The passwords that are going to be hitting Rapidshare in your scenario are the crappy or short ones, wh…

You're arguing for the sake of arguing. The developing weaknesses in SHA-1 don't make it a poor password hash. That's an irrelevant factoid you threw in to cloud the argument.

Pick a number of passwords to lose from a table. Hash them with any of the SHA-3 contestants and a "salt": you will lose more. Hash them with bcrypt, you will lose less.

Again I'm left asking you: what's your point? What are you trying to prove? That you know that there's a SHA-3 contest? You haven't refuted anything this article says; in fact, you keep accidentally managing to validate it.

Post reply on HN