[progmetaldev]

Reminds me of when I saw a junior developer calling SHA-1 on an incrementing integer ID, with no salt. We had a long talk about it, he thought it was too "scrambled" to allow anyone to recognize what was being done. He shouldn't have been so junior, he was 4 or 5 years into his career. I had to be the bad guy and override his decision without further discussing why it was a bad idea, and I really tried for a good 45 minutes to explain things. He got it a week later when I showed him rainbow tables, and I felt bad having to tell him to just do what I said for the solution, but sometimes you just have to make the decision to say "do what I said, I'm sorry you don't understand, I tried to explain."

[ack_complete]

I've seen this before, a belief that just because the output looks random that it is secure. It's like storing license plates -- just hashing them without additional seasoning is of little use, because the number of possible license plates is so low that they can easily be brute forced.

Similarly, a developer I worked with once claimed that CRC32 was sufficient verification because CRC32s changed so drastically depending on the data that they were difficult to forge. He was surprised to find out not only is it trivial to update a CRC32, but also to determine the CRC polynomial itself from very few samples.

[progmetaldev]

I guess it feels good to let someone know that what they're doing is not cryptographically secure, but at the same time, you have to tell them that seemingly random numbers and/or letters doesn't mean they've come up with something useful.

I've tried to stay positive and explain that they will fool nearly everyone, the technology they used is usually recognizable to the type of people that would want to bypass it for their own gain (or knowledge, assuming white hat types poking around). Usually putting a spin on how they came up with something that looks secure was a great idea, but the type of people that will exploit something like what they built, will recognize patterns easily (and now that AI is around, you could even make them feel better by stating how there is software built to recognize these patterns).

[bux93]

Ah, the tale I could tell you about "encrypted ZIP codes".

[bawolff]

Rainbow tables is not the (only) reason you dont want to hash something low entropy like an incrementing int, and adding a salt wouldn't make this secure.

[Im assuming the usual definition of salt where it is known by the attacker... a pepper would be fine]

[progmetaldev]

I agree, and I guess I did use salt differently than how most people see it, rather than how it is most effective. I never stored the salt in the database alongside the password. I would use something from the user that wouldn't change without a password change, as well as some type of semi-long data that also got hashed and put into the "pepper". Even if it's a file on disk that contains data that is read into memory and hashed with something that doesn't change (or at least can't change without the user also re-entering or creating a new password). Also, thank you for teaching me the term "pepper", because I feel like that is so relatable, but also different enough to correlate the two, but show how "pepper" is more powerful and useful!