CODEWITHSUNDEEP
databasehashpasswords
Yanone
Yanone

Reputation: 195

Password, salt, hash, DB: For the millionth time

I know this topic has been discussed a million times. But it's new to me and the more I read about it the less I understand what's actually happening or supposed to happen.

I add a per-user salt to the hashed storage of a user's password, so the stored password hash looks like this: hash(password + perusersalt). This results in same passwords of different users being stored as different strings in the DB. Cool. But I'm not worried about someone breaking into the DB and looking up the hashed passwords. I'm worried about someone brute-force-querying my server for combinations of username and password. In this case the salted and hashed storage of passwords is useless, because the correct combination of username and password will yield a successful login. Right?

Am I correct under the impression that in this scenario the salt is pretty useless? Because the server only accepts username and password at the interface (no salt transmitted), a normal dictionary attack will do, right?

So the salt is only there to obfuscate the password of a user (obtainable only by reverse Rainbow Table lookup) from someone who has access to the DB. Hmm.

Related: My web app doesn't even transmit plain passwords. Passwords are already hashed client side, only to entirely reject responsibility about someone's stolen passwords, and the whole thing uses SSL.

Does this mean I'm more or less at the highest possible security level, because correct combinations of username and password must of course yield a successful login?

Thank you for clearing up the mess in my head.

Upvotes: 1

Views: 324

Answers (2)

ysdx
ysdx

Reputation: 9335

"Passwords are […] hashed client side […] to […] reject responsibility about someone's stolen passwords, and the whole thing uses SSL."

Does the client send hash(password+salt) ?

With this design, a client does not really need the password in order to login successfully, it only needs the hash. So you might still be responsible for leaking the real password (the hash).

Upvotes: 0

PREEB
PREEB

Reputation: 1362

You are correct in your assumption about the brute force attack. If the user has a simple password, the salt and hash won't really matter. The dictionary attack will guess "password" and allow the attacker in. You have to require a secure password from the user, then do the one-way encryption (hash it with the salt), and use SSL like you are.

Upvotes: 2

Related Questions