9

The best practice is we should hash a user password using algorithms such as bcrpyt to protect the user, however, given the following conditions, is hashing in the backend still matters?

  • the password is randomly generated by backend with enough security factors
  • user will not be able to change it

Since the password is randomly generated by us, user will not be using the same password on other services like ebanking, so hashing the password really add security?

Ryan
  • 467
  • 1
  • 5
  • 13
  • 1
    In order to answer this question, you need to provide much more information on what exactly you are trying to accomplish. A password is a password, a public key is nothing like a password. You hash passwords, you don't hash public keys. You keep passwords secret, you advertise public keys openly. – David Houde May 01 '14 at 10:58
  • @DavidHoude , you are right, I removed the public key in my question. – Ryan May 01 '14 at 11:17
  • 1
    If your password has high entropy (100+ bits) you can use a cheap unsalted hash like SHA2 instead of an expensive salted hash like bcrypt. – CodesInChaos May 01 '14 at 11:53
  • If anything I would say you should hash the passwords anyways just incase your site ever becomes a "big thing" and the media can attack you for not hashing (even though it may not really matter)! – Albert Renshaw May 01 '14 at 17:08
  • Why do you assume that the user won't use the same password elsewhere? It's less likely, but some users might think "Hey, this a really good password that nobody could guess -- I'll just use it everywhere!". And why does it matter? – Keith Thompson May 01 '14 at 22:53
  • 1
    "user will not be able to change it" - what's your plan for when a user reports that the piece of paper on which they wrote down *the complicated password you made them use* has been lost or stolen? – AakashM May 02 '14 at 08:43
  • @CodesInChaos No, no, no, no... There's still the possibility of multiple users having the same password, which renders an unsalted algorithm hopelessly broken. And saying this puts a heavier burden on the system to guarantee a high level of password entropy. Why even contemplate using SHA2 all by its lonesome? Use an HMAC algorithm, and feed your hash into it recursively many times. Just use bcrypt, or pbkdf2. – Craig Tullis Dec 09 '14 at 01:33

6 Answers6

20

The point of hashing passwords is that if the attacker can gain access to your password file (by breaking into your server, stealing backup media, hacking your hosting provider, etc.) he/she still can't recover the password from the hash and log in as the user.

Jedidja
  • 103
  • 3
Nir
  • 321
  • 1
  • 4
  • If he has access to the db, he has access to anything, my point is: since the password is randomly generated by us, he will not be using the same password else where like ebanking, so hashing the password really add security? – Ryan May 01 '14 at 11:15
  • 15
    @Ryan, you cannot assume that access to database information means access to everything. There are attacks against databases which can cause information leakage without someone owning the box. – GdD May 01 '14 at 11:27
  • 1
    Additionally, a well designed service will have authentication data stored in a different database as production data. In this context, if someone can read your password database and the passwords are hashed, he still will not have access to the rest of the data since he will not have access to your service: he will still have to crack each password individually. If you store the passwords in clear text, though, he immediately has full access to every account. – Stephane May 01 '14 at 13:08
  • 2
    @Ryan - someone obtaining access to db will have access to the data you have at the time of the exploit, the data access would be done through the exploit's channel (which may be detectable), and they might have only read access. Someone obtaining unhashed passwords would be able to access data even long after after the hole is patched; would access data in a less detectable way, and would also be able to alter data by impersonating users. There is a difference. – Peteris May 01 '14 at 20:15
8

There are two levels:

  1. You need some hashing as a second line of defence, so that what you store on the server (I call "server" the system which does the authentication by verifying a given password) is not sufficient to actually impersonate users. This avoids escalation of a partial, read-only breach (e.g. stolen backup tape) into a more complete, read-write access. See this blog post for a longer discussion.

  2. If you hash the password, then you may need to use a password hashing function if the source password has low entropy. Passwords chosen by human users have low entropy. If you generate the passwords "randomly" then you may obtain high-entropy passwords. Or not. The good point of generating passwords through a known, systematic process that feeds on a cryptographically secure PRNG is that you can compute the entropy, instead of merely estimating it. However, you must still make sure that you get enough of it.

For instance, if you generate a password as a sequence of 10 random characters (lowercase and uppercase letters, and digits), and all characters are chosen uniformly and independently of each other, then there are 6210 possible passwords and each of them has the same probability of being chosen than any other. Entropy is then equal to log(6210) (base-2 logarithm), i.e. 59.54 bits. That's not bad, but possibly still a bit too low for comfort if a simple hash function is used, since a good GPU can run billions of MD5 or SHA-1 per second. You should then add salts and iteration, i.e. use bcrypt (but a small iteration count would already be fine).

If your passwords have at least 80 bits of entropy, then you can consider that they are strong enough to defeat even rich and determinate attackers, and you can use a simple hashing (i.e. you can get away with a simple hash call and also with not using salts). With random letters-and-digits, this translates to 14 characters. I insist that this is true only if the 14 characters are chosen randomly, uniformly, and independently of each other. These are requirements that you can fulfil with your password generator, but you cannot realistically expect them from a user-chosen password.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
4

You should treat it just the same as any other password.

You can't guarantee that the user won't reuse your password on other systems unless you control them - as an example when I had to chose a password for my new ISPs mail server I used the automatically generated one from the previous system so that I would remember it (for a rather longer temporary period than planned).

If you force the user to use a randomly generated password they are still moderately likely to use it for other things - a significant number will write it down or store it in plain text somewhere, and it's easier to keep that list short. You can't assume that your users have even 1/2 a clue about password security, and even those that do may not value your service enough to bother with decent security.

Chris H
  • 4,185
  • 1
  • 16
  • 22
1

In the given scenario, having hashed passwords would protect you in the case when the attacker obtains read-access to the password store, but not write-access or access to any other data. In that case they could use the password to log in and obtain access to more data.

When the attacker obtains write-access to the password store, they will be able to just replace the hash with that of their own password, so hashing wouldn't protect you in that case.

Also, when the password database is compromised, you can assume that any other data on the server is compromised too, so the attacker might not even have a reason to log in.

Philipp
  • 48,867
  • 8
  • 127
  • 157
  • This isn't necessarily *entirely* accurate. If the attacker obtained write access to your password store, they would still have to know exactly which password algorithm your system is using, and exactly how many iterations of the algorithm you are using. If you're iterating 1,000 times with pbkdf2, and they hash 999 times with pbkdf2 to create an imposter hash, your system still won't authenticate the fake credentials. But if they've obtained write access to your password store, they probably have write access to other things and you have bigger problems to cope with. – Craig Tullis Dec 09 '14 at 01:29
1

Simple answer is yes.

some thing that seam to be a recurring is the notion that if the user has access to the password section of the db, then they have access to the entire db. This is a good assumption to make when protecting your data, but not a good assumption to make when trying to justify not hashing passwords. That same logic in theory could be applied in normal use case where the user can change there password.

Passwords in general (not just computing) are a form of verification against a known variable on your end. Storing passwords in plain text leads to internal security leaks and will lower your trust for no reason.

Think about this, would you trust your personal information to a site that did not hash there passwords, even if the password had the same requirements?

Jdahern
  • 121
  • 2
0

I don't think you have to. Only thing you have to look it for is this: If your database is comprimised, a hacker is able to log into any account really fast and perform any actions your users have permission for. If this system is linked to some other service that could create a mess really fast. It's your call, I personally wouldn't do it, but I would consider it depending on other services my users can access trough my program.

Sacrome
  • 1