6

I came across this article and got a basic understanding hash, salt and brute force attack.

My question is in the article, the author emphasises how hard it is to reverse the hash/salted password to the original one. But if the intruder has write access to the database, he can

  1. create a new account with pwd "12345678"
  2. record the hash "69410532sfb9234234" (just an example)
  3. change other accounts hashed pwd into "69410532sfb9234234"
  4. login from the front end as other account holder via pwd "12345678"
  5. profit

Did I miss something here? Or is write access to db nearly impossible to get? The latest steam and psn databases don't give any detail if write access is compromised.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
Will
  • 163
  • 4
  • 1
    The article you mentioned is a reasonably good intro to hashing and salting but it doesn't mention any hashing algorithms suitable for actually storing passwords. Here is [some](http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) [further](http://codahale.com/how-to-safely-store-a-password/) [reading](http://security.blogoverflow.com/2011/07/a-tour-of-password-questions-and-answers/). – Ladadadada Nov 18 '11 at 13:33
  • For every security measure, it is very important IMO to understand what kind of attack it is designed to neutralize - and what other kind of attacks it can do nothing against. Indeed, you have described a kind of attack that password hashing **do not** prevent. I think it is very important to understand that password hashing can be useful, but is not magic! – curiousguy Nov 19 '11 at 17:15

3 Answers3

19

Hashing passwords is a defense against a specific attack. The attack is: stealing a copy of the entire password file (users table, ldap db, etc), downloading it to one's computer, and attempting to retrieve the users' passwords. The goal of the attack is: to find users who reuse their usernames and passwords across websites, and log into those users' email, bank, social-network, and other accounts.

The hashing-passwords defense works like this: the passwords are not stored directly, and any attempt to retrieve the original passwords requires the attacker to perform an extremely large amount of work, at least compared with the work required to check whether a password the user enters when logging in matches the password on file. There are multiple variations on this defense, including choosing better hashes, salting the hashes, iterating the hashes, etc., the purpose of them being to make the defense better than otherwise and to defend against variants of the attack which are capable of getting around the simpler defenses.

The hashing-passwords defense is not a defense against just any attack. For example, it doesn't help against an attack where the attacker gains arbitrary write access to the database, rewrites all users' passwords to his own, and logs in to all the users' accounts on that website. The defense only defends against the offline password-stealing attack.

So you need to be aware of the different types of attacks, and to defend against each of them using a defense which works against that type of attack.

yfeldblum
  • 2,807
  • 20
  • 13
  • then what's the defense commonly adopted for "write access to the database"? i guess it's very serious tho since the attacker = dba in that case – Will Nov 18 '11 at 02:27
  • 1
    There are many techniques for locking down the operating system, network, database server, etc. There are also many access control rules and processes one can implement in one's company to control access to the operating system, network, database server, etc. You've got firewalls, change requests, individual accounts per admin, ACLs, etc. – yfeldblum Nov 18 '11 at 02:32
  • @will.c yfeldblum mentioned ways to prevent people getting full blown write access to a database. As for if they **do** get it. All bets are off. The damage they can do is almost unbounded(depending on how much the application depends on the DB). This is why there are so many preventative measures for this. – Cruncher Jun 24 '14 at 18:13
4

You are right, if an attacker gains write access they can change other people's passwords and gain access to the accounts. The main purpose of salting passwords is to raise the bar on cracking passwords (which could be useful even if an attacker has write access as finding out someone's password could give the attacker access to that user's other accounts since people reuse passwords all the time).

Now, that said, it is important to remember a few subtleties when it comes to the benefits of salts. For example, if the attacker only cares about cracking your individual password, salts don't help much. They only really help when the attacker is trying to crack as many passwords as possible.

For example, lets assume that there are N possible passwords and M possible salts. If the attacker wants to crack your individual password, she will pull your salt from the database and try all N passwords, and eventually get it.

Now, if the attacker just wants to crack as many as possible, she will have to try each of the N passwords with each of the M salts, meaning she will have to do NM computations.

mikeazo
  • 2,827
  • 12
  • 29
-2

As an aside, it is useful to include the username/userid as an additional salt for the password. That way two users with the same password don't get the same hashed password.

Gary
  • 884
  • 7
  • 12
  • 5
    Wouldn't a normal salt take care of that case? If I have a 10 byte salt generated randomly for each user, what is the probability that two users will have the same salt and the same password? Fairly low. – mikeazo Nov 18 '11 at 12:43