WelcomeUser Guide
ToSPrivacyCanary
DonateBugsLicense

©2025 Poal.co

1.0K

It's really not hard. You just use a library to make use of either pbkdf2 or scrypt to generate a hash the correct way for a password.

In either case it basically just means doing this. Take your password, add a salt to it (just a bunch of random extra text), and send it through a hash like sha1/sha256/sha512. Now take the result of that, add the salt to it again, hash it again. Repeat 100,000 times. That's the hash you store. This is basically a standard at this point so there really is no excuse. And there are libraries built into pretty much every language to do that basically as easily as generating any kind of hash. Also do a unique salt per user.

Extra step I take is to randomize the number of iterations a little bit for each password stored so if someone does try to break a password they have to compare every hash for every word they guess instead of finding that the code says 100,000 exactly and only looking at the hash at that iteration. It's just a little extra hassle. Now that password is still breakable if it's a dictionary word or super common, but two things are for certain, they aren't going to be able to crack good passwords, and they won't be able to afford to crack the entire database of passwords. The second part is what pisses me off about these password leaks. It's clear that some of the passwords I've used that are now in leaked databases were clearly bulk cracks. Anyone who targets your account specifically isn't then going to share it on an exchange.

If you are going to store passwords get it right. There is so much more about web development that is 100x harder. Just take 15 minutes to read your language's documentation on how to access that utility they've probably provided. 15 minutes is if you are a slow reader. It's more like 5. You are storing people's passwords. A 5 minute investment is not too much to ask for. If your language doesn't have that in a way that's easily accessible then you aren't in a web-dev language. If you are still building sites in perl you should fix that first.

Congratulations! Just by reading this you are now more qualified to be hired as a web-dev than the morons target and home depot hired who lost everyone's CC information. Go apply to a job.

It's really not hard. You just use a library to make use of either pbkdf2 or scrypt to generate a hash the correct way for a password. In either case it basically just means doing this. Take your password, add a salt to it (just a bunch of random extra text), and send it through a hash like sha1/sha256/sha512. Now take the result of that, add the salt to it again, hash it again. Repeat 100,000 times. That's the hash you store. This is basically a standard at this point so there really is no excuse. And there are libraries built into pretty much every language to do that basically as easily as generating any kind of hash. Also do a unique salt per user. Extra step I take is to randomize the number of iterations a little bit for each password stored so if someone does try to break a password they have to compare every hash for every word they guess instead of finding that the code says 100,000 exactly and only looking at the hash at that iteration. It's just a little extra hassle. Now that password is still breakable if it's a dictionary word or super common, but two things are for certain, they aren't going to be able to crack good passwords, and they won't be able to afford to crack the entire database of passwords. The second part is what pisses me off about these password leaks. It's clear that some of the passwords I've used that are now in leaked databases were clearly bulk cracks. Anyone who targets your account specifically isn't then going to share it on an exchange. If you are going to store passwords get it right. There is so much more about web development that is 100x harder. Just take 15 minutes to read your language's documentation on how to access that utility they've probably provided. 15 minutes is if you are a slow reader. It's more like 5. You are storing people's passwords. A 5 minute investment is not too much to ask for. If your language doesn't have that in a way that's easily accessible then you aren't in a web-dev language. If you are still building sites in perl you should fix that first. Congratulations! Just by reading this you are now more qualified to be hired as a web-dev than the morons target and home depot hired who lost everyone's CC information. Go apply to a job.

(post is archived)

[–] 0 pt

You are right that another hash would serve this use case as well as encryption. And I was imagining using lightweight symmetric encryption, yes.

I was imagining the initial 10k iteration hashing happening on a client, which then sends the hash over to the server. Not sure if that's how you intended it. But if that is the case: Then having one more hash happen on the server provides some obscurity (presumably an attacker can see your client-side hashing code, but he might not have your server code). And makes your database useless for dict attacks on its own.

As an alternative to running a "secret hash server" as a whole other OS instance, you could leverage encryption support provided by the OS+hardware to black box hash/encrypt involving a secret key that's not readable even if the attacker roots your server. A TPM can enable that.