Welcome • User Guide
ToS • Privacy • Canary
Donate • Bugs • License

©2025 Poal.co

708

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)

You are currently inside a comment thread.
Click here to see all the comments (26).
[–] • 0 pt (edited )

Seems like you're wasting a bunch of CPU cycles every time the password is entered in order to cause an attacker to have to waste a bunch of CPU cycles running a dictionary attack. Surely there is a better way to do that.

Perhaps after you hash the password, encrypt it with a private key stored in a different spot than the database, then store the result in the database? I guess it depends on how an attacker is getting your database, whether they have access to the memory of the running authentication code, but if their general strategy is going to be to get access and then just copy your database, the lack of your private key would make it difficult to run dictionary attacks, and there's only 1 extra step (decrypt) for your authenticator

[–] • 0 pt (edited )

Public private key encryption is so slow that hashing something a ridiculous number of times is less intensive. But that is interesting if you had the private key on an offsite computer running no other applications and accepting no other traffic at the firewall and router level. Then if you had a breach you could literally turn that computer off and the password database would be useless. But if you are storing hashes and don't need reverse encryption you might as well do something like hmac and just have your "secret hash server" just apply a secret long salt only it knows before hashing it once more. That would be way faster than asymmetric encryption.

Maybe not a bad idea. But if you are doing that in lou of pbkdf2 you are basically betting on no one ever getting access to that offsite computer. Maybe you daisy chain it and have a third computer it consults. If you build the server simple enough you can basically guarantee that physical access would be necessary and you can make it nearly impossible that anyone could physically obtain both computers, especially if one of them is behind tor and unlocatable.

I may adopt this.

[–] • 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.