Which shouldn’t even matter because passwords are salted and hashed before storing them, so you’re not actually saving anything. At least they better be. If you’re not hashing passwords you’ve got a much bigger problem than low complexity passwords.
Salt the hash with something unique to that specific user so identical passwords have different hashes
Isn’t that… the very definition of a Salt? A user-specific known string? Though my understanding is that the salt gets appended to the user-provided password, hashed and then checked against the record, so I wouldn’t say that the hash is salted, but rather the password.
Also using a pepper is good practice in addition to a salt, though the latter is more important.
Some implementers reuse the same salt for all passwords. It’s not the worst thing ever, but it does make it substantially easier to crack than if everything has its own salt.
I remember hearing to not layer encryptions or hashes on top of themselves. It didn’t make any sense to me at the time. It was presented as if that weakened the encryption somehow, though wasn’t elaborated on (it was a security focused class, not encryption focused, so didn’t go heavy into the math).
Like my thought was, if doing more encryption weakened the encryption that was already there, couldn’t an attacker just do more encryption themselves to reduce entropy?
The class was overall good, but this was still a university level CS course and I really wish I had pressed on that bit of “advice” more. Best guess at this point is that I misunderstood what was really being said because it just never made any sense at all to me.
Can you elaborate further? Why would someone want to truncate passwords to begin with?
To save a few megabytes of text in a database somewhere. Likely the same database that gets hacked.
Which shouldn’t even matter because passwords are salted and hashed before storing them, so you’re not actually saving anything. At least they better be. If you’re not hashing passwords you’ve got a much bigger problem than low complexity passwords.
The place that truncates passwords is probably not the place to look for best practices when it comes to security. :-)
Hashing passwords isn’t even best practice at this point, it’s the minimally acceptable standard.
What is the best practice currently?
Use a library. It’s far too easy for developers or project managers to fuck up the minimum requirements for safely storing passwords.
But, if you are wanting to do it by hand…
Isn’t that… the very definition of a Salt? A user-specific known string? Though my understanding is that the salt gets appended to the user-provided password, hashed and then checked against the record, so I wouldn’t say that the hash is salted, but rather the password.
Also using a pepper is good practice in addition to a salt, though the latter is more important.
Some implementers reuse the same salt for all passwords. It’s not the worst thing ever, but it does make it substantially easier to crack than if everything has its own salt.
I remember hearing to not layer encryptions or hashes on top of themselves. It didn’t make any sense to me at the time. It was presented as if that weakened the encryption somehow, though wasn’t elaborated on (it was a security focused class, not encryption focused, so didn’t go heavy into the math).
Like my thought was, if doing more encryption weakened the encryption that was already there, couldn’t an attacker just do more encryption themselves to reduce entropy?
The class was overall good, but this was still a university level CS course and I really wish I had pressed on that bit of “advice” more. Best guess at this point is that I misunderstood what was really being said because it just never made any sense at all to me.