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

©2025 Poal.co

143

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).
[–] [deleted] • 0 pt

In all reality at this stage of the game developers shouldnt be building Authorization and Authentication into their apps. Even a mid tier or small business should have oauth of some type or at the very least an AD server or equivalent managing that.

[–] • 0 pt (edited )

Here is the problem with oauth. It's a huge privacy concern. Encouraging everyone to sign in with an offsite identity like their google account lets the site you are using know what your google account is, and lets google know what sites you use. It also is a threat to user interests in this crazy world we live in, in which companies cross lines they should have never crossed like it was nothing. Google could decide to cancel and prevent you from logging into any of your accounts even if its accounts on sites not owned by google. Last, google technically could sign into your account pretty much any time they want and mess around. Even without manipulating your accounts they can gain access to anything and feed data to a government or shady political organization.

Yes, oauth is secure against the rouges of the internet, but those who call themselves white hat aren't as white as they believe themselves to be. White hats work for shady government, unscrupulous contractors, and definitely not evil companies like google. Security doesn't end with protecting yourself from black hats.

[–] [deleted] • 0 pt (edited )

Sure but there are packages out there to run your own oauth servers on whatever hardware you want too. In the cloud or in your own DC. I bet I could search on github and find a dozen. Most mid sized places will have an adfs server. You have to put time into picking one but the software is pretty readily out there. If you are doing any kind of real user management you should be splitting that whole user management piece out of the app as much as possible. For small clients with a web store they may as well go with google auth or something theyll likely do something dumb and disclose everything worse than google will anyway. Every place iv'e worked at had auth wrong and the dev teams eventually go stand up an oauth server to handle login and credential validation as well as deliver a token with roles embedded. Been at 3 places and have done the same lifts pretty much every time. Some of them try to fight it for a while until they figure out a hole some noob dev created in an app somewhere.

[–] • 0 pt

It isn't that hard to do though, and that was op's point. When i make a small app I do what he says (minus the extra step), and this is just for heavily firewalled internal stuff.

[–] [deleted] • 1 pt (edited )

It's more realistic to tell the street shitters never to do it and provide them with an auth service than to expect them to write secure applications even if you explained to them how. Suppose you get them through getting a properly hashed password stored. They still would have to deal with roles and privilege escalation.