26

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.

Improve this question
3
  • 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
    Commented Jan 17, 2016 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
    Commented Jan 17, 2016 at 21:39
  • You didn't tell if you want to add salt before or after taking dinner
    – elsadek
    Commented Jan 18, 2016 at 4:05

4 Answers 4

Reset to default
33

@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.

Improve this answer
6
  • 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
    Commented Jan 14, 2018 at 13:13
  • 1
    How exactly would frontend hashing protect against reused passwords?
    – Gendarme
    Commented May 1, 2019 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
    Commented Apr 2, 2020 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
    Commented Apr 2, 2020 at 16:22
  • 2
    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
    Commented Jul 31, 2022 at 15:44
18

You are confusing two things:

  1. Transport security
  2. Database security

Transport 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)

Database security

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.

Improve this answer
3
  • @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
    Commented Jan 17, 2016 at 19:00
  • which method would you prefer or is Scrypt ok?
    – rala
    Commented Jan 17, 2016 at 19:04
  • @rala yes scrypt is very good for password hashing. Make sure you use the right parameters.
    – John
    Commented Jan 17, 2016 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.

Improve this answer
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)

Improve this answer

Not the answer you're looking for? Browse other questions tagged .