23

I have a Java Server with Spring Boot and a JS Frontend in AngularJS.

My teacher told me to use HTTPS for passwords, because I cannot hash them securely enough, that nobody can hack them.

With HTTPS, if I get it right, I do not have to hash it extra. My source: I just send username and password over https. Is this ok?

So now to my question: I store the pw in a DB of course. Where should I hash them? Frontend or Backend?

  • If I hash it on frontend, I do not have to do sth else on backend; but if the HTTPS certificate expires I'm insecure.
  • If I do it on backend, I do not have to do sth else on frontend; but if the HTTPS certificate expires I'm insecure.

I would use Scrypt, which is made for password hash.

Community
  • 1
rala
  • 341
  • 1
  • 2
  • 9
  • Backend, more control and is usually faster as well. Don't assume that HTTPS makes everything OK either. There are still numerous ways an third party hook in on the frontend (and backend in rare cases) – Yorick de Wid Jan 17 '16 at 18:51
  • 6
    What do you mean by "if the HTTPS certificate runs out I'm hackable"? Certificates don't just "run out" as in stop working. Unless of course you mean expire, in which case I'd like to point out that a certificate expiring doesn't just suddenly make you "hackable", it just makes your website inaccessible to the average user. (They'd have to click through a big serious-looking security warning to get to your site.) – Ajedi32 Jan 17 '16 at 21:39
  • You didn't tell if you want to add salt before or after taking dinner – elsadek Jan 18 '16 at 04:05

4 Answers4

28

@John already descriped the passing of the password over the network very well (use HTTPS).

To answer your question:

Where should I hash them? Frontend or Backend?

The backend. If you only hash them in the frontend, you are vulnerable to a pass the hash attack.

The reason that you hash passwords in your database is to prevent an attacker who already compromised your database from using those passwords.

If you hash the passwords in the backend, an attacker has to first crack them to use them on your website. but if you hash them in the frontend, an attacker doesn't need to do this, they can just pass the hash as it is stored in the database.

tim
  • 29,122
  • 7
  • 96
  • 120
  • Can you expalin what you mean with "prevent an attacker who already compromised your database from using those passwords" ? Can you please explain more. Isn't everything already lost when the attacker has the token you are using in the final strcmp operation? Because thats why i did code it that frontend sends the sha2 password hash. – Lothar Jan 14 '18 at 13:13
  • 1
    How exactly would frontend hashing protect against reused passwords? – Gendarme May 01 '19 at 14:18
  • Yeah, I don't follow how frontend hashing prevents against password reuse? That's why the hash is salted as well. – Chris Smith Apr 02 '20 at 15:23
  • @ChrisSmith You are right, it doesn't. An attacker just needs to crack `frontendhash(backendhash(password, salt))` instead of `backendhash(password, salt)`, so not much is won. Answer updated. – tim Apr 02 '20 at 16:22
  • 1
    I don't get the pass the hash vulnerability. If a 3rd party can intercept the hashed password, they could just intercept the un-hashed password. The reason to do a hash on the front end (AFiK) is to prevent the raw password from ever hitting the backend. There have been instances of passwords being exposed because they were stored in logs by the webserver prior to being hashed. – Jamie Marshall Jul 31 '22 at 15:44
  • @JamieMarshall Pass the hash becomes relevant when an attacker has access to the database (eg an old backup, via SQLi, etc). Then they can just use that hash and don't need to crack it, ie hashing becomes useless. You could hash in the front and backend though, if you want to avoid both issues. – tim Aug 03 '22 at 06:33
17

You are confusing two things: transport security and database security. HTTPS using TLS only protects the transportation of the data from the client to the server. This means an eavesdropper does not know what client and server are sending each other (simplified). The storing of passwords is an entirely different topic. You want to make sure, that even if an attacker gets access to your database, he cannot get access to the plaintext passwords.

No matter how you store the passwords you should always use TLS. Otherwise an eavesdropper can record what the client sends to the server to authenticate. Then it would not matter whether you do password HASHING on the client-side or server-side. The attacker could simply record what goes over the wire and replay the communication to gain access, impersonating the client.

(Note that you want to do password HASHING, not encryption. Hashing is one-way, encryption is not)

The hashing should be done at the back-end. The back-end is under your control, so you can enforce that the hashing is taking place as it should. Additionally you can have client-side hashing. You should not use client-side hashing alone, as the process would e.g. be done in JavaScript which the user could block or manipulate. It may not seem like a reasonable threat, but you should never trust any user supplied data. Therefore you should not assume that the client is doing the hashing properly. This implies you most definitely have to do it at the back-end.

John
  • 1,007
  • 6
  • 14
  • @rala that is one common way to do it. I would say you should definitely do it on the backend, but you could also do additional client-side hashing. – John Jan 17 '16 at 19:00
  • which method would you prefer or is Scrypt ok? – rala Jan 17 '16 at 19:04
  • @rala yes scrypt is very good for password hashing. Make sure you use the right parameters. – John Jan 17 '16 at 19:17
4

HTTPS provides security for the transport layer only. It has nothing to do with the security mechanisms needed for the storage.

You shouldn't crypt passwords. You should hash them, so you could not decrypt them later (nor an attacker).

And the hash step is always done on the backend, since doing it on client-side would allow an attacker which got access to your hashes a method to login on every account.

Benoit Esnard
  • 13,979
  • 7
  • 65
  • 65
2

HTTPS (HTTP over TLS/SSL) provides security over data in transit/data in motion it does NOT provide encryption on data at rest (Database, Files on a Hard Drive)-> Encrypted with AES, 3DES, BlowFish, etc.

You can provide encryption on the Database, but not the whole database as this will eat up your resources (Encrypted Files are larger than Unencrypted). Just encrypt a specific field i.e. Customer PII -> Credit Card Information.

It's not a best practice encrypting user passwords, just HASH and SALT it.

When your HTTPS cert will expire, it's ok that the attacker can sniff the passwords in plain text, just provide the layer of security on your code.

When user provides the password, your code should have a stored procedure (SQL) to match the HASHED+SALT value of the user's password on your database. If the the HASH+SALT value doesn't match, obviously it's a wrong password.

Note: Hashes provide integrity.

The SALT function will mitigate the risk of the attacker from running a rainbow table attack, because the attacker doesn't know the SALT value.

The Key: HASH+SALT

https://en.wikipedia.org/wiki/Salt_(cryptography)

vulnerableuser
  • 325
  • 1
  • 5