Hacker News Reader

Comment by breck | Hacker News Reader

Agreed--not news.

However, this is a common security problem that doesn't get enough attention. I would guess the easiest way to crack anyone's bank account is to create some flimsy website that requires users to register. Chances are good they will use the same user/password combo that they would use for their bank. Or you could crack one of the thousands of existing login websites to get passwords, which would be a lot easier than hacking a bank's database.

If I'm writing a minor login website, I'll assign a random password to users. I don't want to be liable if one of my servers is hacked and someone's bank account gets accessed because of it.

What do people out there generally do about this problem? Do you take a similar approach or make additional efforts to secure your servers?

View on HN

I don't want to be liable if one of my servers is hacked and someone's bank account gets accessed because of it.

Don't store user passwords in plaintext.

and hash the passwords on the browser.

I agree that that will be safe, provided you use the same browser-side hash function that the bank uses

You can't have it both ways. If you are hashing the password before it is sent from the client to the server, you need the raw password on the server side.

(Assuming you are concatenating it with a server-provided random value before the hashing.)

You're assuming they're using a secure challenge response protocol. They're not. They're sending password-equivalent hashes over the wire, so they can say they're not sending passwords.

You'd be right to point out that this is a lot of silly acrobatics to go through to avoid a single SSL login page.

I use a hash. I don't quite know how secure that alone is though. My thoughts are if my server is compromised(and an endless stream of attempts lead me to believe it's not extremely unlikely) having both the scripts with the database could deduce the passwords. Am I wrong?

You are. One of the defining properties of a cryptographic hash is that you cannot easily deduce the input given the output, nor can you easily construct an input to produce a given output. (see the overview at http://en.wikipedia.org/wiki/Cryptographic_hash)

However, it's still possible to do a dictionary attack on the database of hashes ("is the hash of "password" the same as the user's password hash? yes? Bingo!")

Provided, of course, that P != NP.

Message digest functions are not, generally, number-theoretic.

How is this relevant? The question of P ?= NP isn't limited to number-theoretic functions -- if P = NP then it is possible to find a preimage to any (polynomial time) hash function in polynomial time.

You're right.

You should use individual salting for each password to make this at least a bit more difficult.

A hash is a one way thing so you can't reverse it. However, if they have that much access it'd be trivial to just change your script to dump the username/password combo into a plain text file whenever the login succeeds.

Reply on news.ycombinator.com