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

©2025 Poal.co

654

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)

[–] • 6 pts

But these stupid companies that hire lowest bidder street shitters kinda deserve it. The customers do not. Software development and security are not cheap.

[–] • 0 pt

yes, the actual people who have to deal with this aren't in charge of hiring consultants, and so some exec hires the lowest. It is also an issue with the current "CYA" environment where they can now say "It wasn't us, security was handled by xxxx"; so it might make the company look bad, but internally nothing will change.

[–] • 3 pts

Mmm. Hash and salt. Makes me hungry for breakfast.

[–] • 2 pts

My password is password.

[–] • 0 pt

Make it secure, use

Password123

[–] • 1 pt

That's not how most password leaks happen.

Most password leaks happen because fucking idiots click shit and put in their passwords.

The download malware, get keyloggers installed, etc.

[–] • 1 pt

So, writing all my passwords down on a yellow legal pad and storing in my desk drawer, instead of clicking yes whenever I’m asked if I want to “store” my password, is good or bad? Apologies in advance for being a technophobe or technoidiot.

[–] • 2 pts

writing all my passwords down on a yellow legal pad and storing in my desk drawer

If nobody can ever access that desk drawer then it’s pretty safe lol.

[–] • 0 pt

Only 1 person besides me and spouse that can access it, atm. If that ever changes, I likely won’t have any electronic devices. Glad to know I’m good lol.

[–] • 1 pt (edited )

That's good. It's pretty easy to access the passwords stored in a computer. Even if you are worried about people with physical access, looking up the entirety of stored passwords inside chrome, brave, firefox is just a few clicks in settings and they can snap a photo with a phone.

The downside of using paper is you are more likely to reuse passwords multiple times (only so much you can fit on paper), and eventually one of these sites will leak it. If you are going to be reusing passwords anyway I would suggest making them strong while you are at it.

Me, I have a few really weak passwords I don't care about, and the rest I generate and re-generate in a program I wrote based on the name of the website and a key encrypted on my computer. That gets me super random passwords about 120 characters long (that I shorten to 20 when sites complain) that aren't actually stored anywhere. I just need to know one master password for the decrypt of that file that I never put on the internet. I then have that key on multiple computers (also the program) so I never lose it.

[–] • 0 pt

The word you're looking for is techdumb, some people are techdumb, and some techdumbs have super powers; I had a friend (yes) who would make anything computer go sideways just by laying his hands on a laptop's keyboard for instance, not even typing anything, just resting, and everytime you just had to wait for a couple of seconds or minutes before something started to break and bug. True story.

[–] • 1 pt

I feel like you’re speaking of me haha. I have BAD electronic mojo. Everything electronic I touch turns to shit. Been that way a long time, long before home desktops, laptops, and phones. Techdumb fits better than technophobe. Not afraid of it, but perhaps “it” is afraid of me lol.

[–] • 1 pt (edited )

It's a gift, god's gift...

Some have the power of clairvoyance, some have the power of telepathy, some have the power of psychokinesis... You got the power of techdumb. You can dumbdown any electronic device just by being there

[–] • 0 pt

Exactly correct, this is what I did to implement password management at my job. It's really not that complicated, and there are probably libraries for pretty much every language that will do most of it for you.

The guy before me used md5 to hash passwords with a hard coded salt. Yeah that's bad and I had to clean up a lot of stupid shit like that.

The other part of the security equation is for your web service or app or whatever to implement delays and lockouts when someone gets the password wrong multiple times in succession. Prevents external brute force attacks.

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

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

[–] • 0 pt

Because you can't trust companies to not diversity hire devs. Always use a totally random, different password for each site. Expect that your password will leak and don't use it anywhere else.

[–] • 0 pt

It's a losing game.

With supercomputers and quantum computers on the rise, it doesn't matter how many iterations you rehash with or without salt. There's service capabilities that allow anyone to crack or reverse lookup any password near instantaneously or within a short time. Your best bet would be to access one of these service machines and perform a significant amount of iterations on the most advanced algorithms with the highest password strength. But even then you are only buying yourself a bit of time and the illusion of security. MFA with an increasing number of authentication methods is more secure but less desirable for the user experience.

In the future, there will be little need to hashes and passwords will be stored directly because the authentication vectors matter more than the password strength.

Load more (1 reply)