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?
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!")
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.
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.
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.
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?