If the pepper is stored as an environment variable, adding it in addition to the salt can be a minor increase in the password security. The thing is it often isn't that hard to get if someone has access to your server.

If it's just the db that is exposed though, it could be a small added layer of protection.

And yes, I would not ever do it instead of a salt.

Would in this scenario be running each service (database/backend/frontend) in separated clouds/envirorments be benefitial to mitigating risks?

Let me explain. for example, I might have my NextJS frontend in Vercel using it's secret management /env tools.

The backend as a vanilla node-apollo-server-express could probably be on a cheap VPS, being monitored/restarted/load-balanced by PM2.

The database would be cloud, either PostgreSQL as a Service, or Fauna or something.

Would this scenario be better than just cramming everything into a VPS and trying to get that as secure/closed down as possible and be done with it (do monthly updates and whatnot)...

I've faced recently this conundrum at job. Small new app will not have more than a few hundred concurrent users optimistically...

As @wongarsu said, I think running the DB separately makes a lot of sense. Also, that (in theory) protects any ENV variables on the main host server from exposure if your DB is compromised. And the DB is likely better protected and up-to-date if you use a DB-as-a-service. But I wouldn't go extreme either. There are a lot of hidden costs associated with utilizing additional machines, whether they be via lamda functions, VPSs, etc.

One other good thing about keeping things separate is updates in theory should be easier, as besides OS stuff, you only have a handful of applications on each machine. But again, for small apps, it's generally not worth the extra complexity. 3 platforms is likely as far as I go (client-side server, API, DB) in the majority of cases with small apps, and most of the time I'd probably just go with 2 assuming Node can serve both the client and API.

Theoretically, more separation means more security. On the other hand, securing many things is harder than securing few things.

PostgreSQL as a service (or whatever DB you prefer) is worth it, that means somebody else can get backups, security relevant settings, patches, version upgrades etc right. Everything else is probably fine on one server, but it doesn't sound like that would be much besides the backend in your case anyways.

> pepper instead of salt is a bad idea because if your pepper is leaked the attacker can brute force all of your passwords at once.

This isn't true, you could simply do encrypted_pw = md5(pepper + md5(password)) or whatever.

Edit: Getting a bunch of comments on this, just want to clarify that I used md5 purely to illustrate a one-way hashing function. In actual practice, you'd use something else (HMAC with SHA256 most likely).

> md5(pepper + md5(password)) or whatever.

(Ignore md5)

No, I strongly recommend not to do so. The reason you put an salt in is to prevent multiple hashs to be the same (because people use the same password) with a pepper you still protect against cross reverencing the hash with other databases, but any two users in your database will still have the same hash and people tend to reuse passwords (or similar passwords) so this is a very real attack vector to get passwords without really braking any hash fully (E.G.: user with known password on different platform => try out similar passwords => broke hash for anyone with similar password).

So a unique per hash specific salt is the most important thing to do.

Pepper/shared secret can make it additionally harder to crack any hashes as while you know all salts (they are stored alongside the hash) you don't know the pepper.

Lastly there is additional data (AD) (named sometimes differently). Which can prevent some form of hash reuse attacks where you e.g. find some form of attack which allows you to override hashes+salt in the db (but not more). Then you could rewrite all hashes to known ones and get access. Tbh for many systems if an attacker can do something like this they don't need to do that anymore. But for other (often large and complex) systems it's helpful.

The idea behind AD is that you (somehow depending on algorithm) include some additional data which needs to match. The most common example is to use the user id (if immutable) as AD so this hash+salt(+pepper) is only usable for given user and never for any other user.

If you ever write a auth sub-system for a big enterprise system I would recommend you to use salt+pepper+AD(uid), for everything else I would think salt+pepper is enough. But never should you use a hash without unique salt under any circumstance. It's always the wrong path to take.(For password hashing.)

Or at least that's my opinion.

Is it worth it to salt in scenarios when the passwords (actually tokens) themselves are guaranteed to be unique and instead only use pepper?

Short answer: if they are unique because they're a small sample from a large space (e.g. UUID v4) no salt is needed. If they're unique but maybe predictable, salt.

Thanks! Yes, they are random GUID-like values and are short lived (2-4hrs). Had a need to store them for a reason and decided to only add pepper to hash considering they are unique and short lived anyway.

SHA256 is also no good for storing passwords, you need to use a PBKDF like scrypt, bcrypt, or pbkdf2.

The SHA-family cryptographic hash functions are purposefully designed for throughput, if you combine them thousands of times like in PBKDF2 they can be fine. One round of SHA256 is trivial to brute-force especially with the plethora of ASICs available.

HMAC is also completely unnecessary here, and see the article title for your variable naming: it's not encrypted_pw it's hashed_pw.

I know this is just a comment on HN, but I want to point out that MD5 is not a password hashing function, and is broken even for a number of other hash purposes. For passwords something like argon2id or another modern slow hashing function is appropriate, and for general purpose, SHA2 and SHA3, as well as BLAKE2 (and maybe BLAKE3) would be good choices.

Further, there’s so little reason not to salt, so you ought to do it. It’s built in to the hash strings in most modern pw hashes. Peppers are also a great idea. Defence in depth!

MD5 is broken, but HMAC-MD5 is still impossible to break afaik. And md5(pepper + md5(pw)) is basically HMAC.

Not commenting on the overall idea, just pointing out that the criticism of md5 happens not to be valid in this case. I was surprised too.

The discussion of "MD5 collision resistance is bad, but md5 preimage resistance is still ok, so using md5 for applications where preimage resistance is required is ok" is I think completely valid (however pointless it is)

However for password hash functions to be useful they also need to have a high work factor to make brute forcing even more difficult.

The only unknown in that equation, once you get hold of pepper, is password. So, what added security does it provide, other than requiring another md5 computation?

How does that help? They can iterate through possible passwords and generate md5(pepper + md5(password)) just as easily as md5(pepper+password). The point is that they can iterate ONCE and match against all passwords in the DB. With salt they have to iterate for each row in the DB which is much more time consuming.

If that gets leaked the attacker could brute force that, and match the results to your entire list of hashes. If they're salted, they would still have to brute force each password individually.

Totally agree with this, hence the caveat that the code doesn't get leaked/compromised :)

I think you don't quite understand the purpose of a salt. Pepper and salt protect against very different things. And frankly, salt is much more important.

am I missing something here? the attacker still only needs to know the pepper to brute force all the passwords with this scheme. Since the pepper is deterministic, and especially with md5 which is already extraordinarily quick to reverse, the attacker can just take md5(pepper) then do the extremely quick operation of the hash extension md5(password)

Noone uses MD5 in the real world. SHA-256 is generally the minimum now (for anyone serious about passwords)

Please not md5. Please.