If the input for the security question is completely digital, should the answer to a security question be hashed (or at least encrypted) on the authentication server?
|
|
I'll assume the model you're trying to defend against is where an attacker has access to the database. If that's the case, yes, it's a bad idea if an attacker can compromise an account by only knowing those details. My advice would be to convert the answer to uppercase, then salt + hash it. Optionally also trim it or collapse all whitespace. This provides a reasonable security measure without reducing usability. |
|||||||
|
|
If those questions provide the same level of access as the password, then for all practical purposes they are a password and should be treated like one. Apply the same level of protection to all passwords that you store. |
|||
|
|
As mentioned by @Polynomial and @B-Con, storing the security questions unencrypted is dangerous if those can effectively be used as password. But even if this was not the case, you should not store the security answers unencrypted. Common security questions ask for personal details, like "What is your mother's name?" (assuming a system where you cannot put custom questions in or where the user just picks one of the existing questions). You are not the only server that may ask for that detail, the same information can be used to compromise information on other systems that have the same security questions and answers. |
|||
|
|
|
The answer is yes, you should always hash this. Why do we hash stuff like passwords at all? Basically because people may use the same password for multiple services, and to prevent people from logging in with read-only database access. So don't you think the user's first pet or mother's maiden name is also data that he would use across multiple services? Or that could potentially be used for social engineering attacks? Or could be used to reset the password and also gain access? For that reason, you should protect answers to security questions against attackers (and admins!) the same way as you do with passwords. Why not encrypt it? Encryption is reversible, it makes it possible to access the data while there is no need to. One of the cases you're trying to prevent by protecting the database data, is a case where the server is compromised, or where an insider has bad intentions. In both cases, they could use the decryption key to reverse the protection. With decent hashing, this is no longer possible. |
||||
|
|