Hi,
I have a table storing the login info, such as loginID, password, logTime, ... I create 2 stored procedures: one to encrypt and another to compare the password. Encrypting and comparing the password need a key. I'd like to know where should I keep the key. If I put in the store procedures or in my application, my development team will able to see it. And I want to know the best practices in keeping the key. Please advice.
Thank you.
You need to hash passwords not to encrypt them. Then you won't need a key at all.
Regardless where you store the password, it can ultimately be found. So if you won't to hide it from other developers, it won't work.
There are a variety of use-cases for storing authentication credentials, each of which requires a different solution:
If the credentials are for a user logging into your system, then best practice is not to store passwords at all. Instead create a one-way cryptographic hash of the password, and store that. When the user tries to login, hash the supplied password and compare the result with the stored hash. The hash should include a "salt" that is changed each time the user's password changes. This makes it harder for someone to apply a brute-force attack to reverse the hash codes if they manage to steal your system's hashed password file.
If the credentials are for a user logging into a third party system, you could generate a DIFFERENT one-way hash of the user's password for logging into your system, and use this as the key for a symmetric cipher for encrypting / decrypting stored user credentials. Once again, the core principle is that you do not store the information needed to decrypt the user's credentials. In this case, you should not store the hash used as the key.
If the credentials are for the system authenticating itself to other systems, the normal solution is to use a key store, and rely on the host operating system to protect it and the key-phrase that is used to unlock it. (If there's a better solution, I'd be really interested in hearing about it!!)
It is a bad idea to store user passwords in clear or encrypted because there is always a chance that someone can break in an steal them. Even if they passwords are encrypted, the decryption key must be stored somewhere. A determined hacker can probably find it. Alternatively a trusted administrator might be persuaded to reveal the passwords and/or the decryption key. By storing hashes rather than passwords, you have an extra degree of protection even if your database and/or application's keystore is compromised.
The second part of the equation is that many users use the same password for many systems. So if your system is compromised to reveal passwords, you are potentially exposing the users' accounts on other systems.