So when it comes to security, when I have an idea that seems good, but no one else seems to be doing, I try to assume that I'm overlooking something obvious or otherwise significant. This is one such case...
The context of this question is an authentication system that I'm beginning work on. I've implemented similar systems in the past, and generally have my head around the "salt and hashing" thing, but I'm by no means an expert in cryptographic security.
As I was in the process of defining the storage for 16 random bytes of salt on my user records, it occurred to me that there may be a way to reduce the attack surface in the event that someone has stolen or otherwise accessed my user data. I'm operating off of the following assumptions:
- If a hacker steals my user data, they have access to a salted + (repeatedly) hashed representation of the user's password, and the salt value itself.
- If the hacker wants to determine the plain text value of that password, they have some bruteforce labor in front of them.
- However, given the salt, the search space of that brute force attack is greatly reduced.*
*I'm not 100% sure that point three is correct, but it makes sense to me that if a brute force algorithm can assume that the pre-hash value consists of
<8-or-so-bytes-of-password> + <16-bytes-from-stolen-salt> (or similar combination of the password and salt values), then we've reduced the search space by algorithmically significant quantities.
<obligatory mid-question apology for the length of this question here>
So with the above being my current line of thinking, the solution that I'm considering essentially boils down to using known, constant values about a user to dynamically generate a salt for use during the hashing step.
Given that salt values don't really need to be cryptographically "anything", so long as they are unguessable to the point of requiring bruteforce discovery, is it sufficient to essentially take some transformation of, say, the provided username and password (e.g., apply some SHA-2 goodness and proprietary ciphers), and use that in the hashing step?
Of course if someone were to steal the code as well, the "secret" salt generation is pointless. The only added security I'm attempting to achieve is forcing the hacker to steal both my data and my code if they want the convenience of the reduced search space described above in point 3.
I hope I've adequately (and not too verbosely) described my question and reasoning. The specific question I'm hoping to have answered is whether or not this is a cryptographically (or otherwise) secure means of storing and comparing user passwords.
Edit: It appears the key points of my question may have gotten lost in the noise above. Let me try to be more explicit:
- Does having access to the salt used in generating a hashed value substantially aid a brute force attack on discovery the actual password?
- If so, does it therefore make sense trouble the hacker with having to steal my code in addition to the data itself?
- Is the general approach of dynamically generating the salt (using reproducible, non-random, but unguessable means) ill-advised?