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?
-
14Does anyone else hate security questions?– user606723Commented Aug 17, 2012 at 19:35
-
1You mean hashing by the way, not encrypting. Encryption can be reversed in the case of a compromised server, one of the cases you're trying to protect against, and thus adds little security.– LucCommented Aug 17, 2012 at 23:51
Add a comment
|
6 Answers
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.
answered Aug 9, 2012 at 13:07
-
4Ok let's not defend ourselves against a case where an attacker has access, but what can all admins do with the security question info? How many sites ask for the same data?– LucCommented Aug 17, 2012 at 22:07
-
@Luc: If the "security" question is "What's your zodiac?" or "What's your pet's name" then its as good as ROT13. Commented Aug 19, 2012 at 1:52
-
Can the salt be the same one used for the password or should it be different? Can all security questions use the same salt or should each have a unique salt?– yitzihCommented Jul 26, 2017 at 19:23
-
1@yitzih There's no reason to reuse the password's salt. (And if the password changes and its salt changes too, then you'd either have to re-hash the security answers or store the salt additionally somewhere else...) You should use a library like bcrypt which stores the hash and salt together in one string. There's no need to keep them separately or re-use salts.– MacilCommented Jul 26, 2017 at 22:02
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.
-
5And even if they don't provide the same level of access, you should still hash it. See Lekensteyn's answer.– LucCommented Aug 17, 2012 at 22:04
The answer is yes, you should always hash this.
Why do we hash stuff like passwords at all? Two reasons: mainly because people often use the same password for many different things, and additionally (it's more of a fortunate side-effect) to prevent attackers from logging in when they obtained 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.
But what about punctuation? You can't match a hash unless it's exact.
People might use multiple words in an answer, and one time they might use capitalization, other times they might remove spaces between words or put a period behind the sentence... so I'd suggest normalizing it to at least remove spaces, remove punctuation and lowercase any capital letters.
Regardless of whether you have it stored plaintext or encrypted, you need to write a normalisation algorithm to compare them anyway (so that does things like lowercasing). That algorithm will boil it down to a basic version to be able to decide whether it a match. If you apply that before hashing the result, it will work just the same.
PS. Don't do security questions. They're super bad for a lot of reasons. But if you do use them, then at least protect your users a little bit and hash the answers.
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.
answered Aug 17, 2012 at 20:00
Although there is an accepted answer and a consensus that it should be hashed, it is worth noting that there are cases where that might not be desirable.
The most obvious one is where you are asked for selected characters from the answer. This provides protection against replay attacks. But you can't verify the response against hashed data without storing every possible hashed combination - and as a result you make it much, much easier to brute-force the clear text (i.e. you loose the benefit of hashing). Typically this approach is used in conjunction with a (hashed) password for authentication.
A further case where this might be applicable is where you might want to provide some lassitude in the validation, for example permitting variations in capitalization. A use case for this would be for a token which is used infrequently, e.g. in a password reset, but should be applied with caution and in conjunction with other controls (e.g. sending a reset token to the registered email address rather than allowing an immediate password change).
These are security trade offs. But perfect security is expensive and gets in the way of the thing users want to do.
The most secure way where password can only be reseted if secret answer is known do the following:
x={hash(password)}priv_S
where priv_S is the secret answer(private key) and public key(pk_S) is stored.
And to verify do:
I=user's typed secret answer
x=={{x}pk_S}priv_I
To login:
$username=<username>&&$hash=={x}pk_S
This allows the ability to only change the password if the secret answer is known but allows to login without it.
-
This doesn't make sense to me. You are setting x to something and comparing it with something else.– LimitCommented May 12, 2018 at 0:17
-
nope {x}pk_S = hash(password) as they are inverse functions so they cancel out, and the statement will only be true if
priv_I=priv_S. Commented May 12, 2018 at 0:31 -
Well, first of all secret answer cannot be a private key. and by your logic you are storing x as the plaintext password because applying your public key on the password and then applying private key on it will simply return the password in plaintext– LimitCommented May 12, 2018 at 0:35
-
4This answer is difficult to make sense of in its current form. Your notation is unclear, and there's no explanation as to why public key cryptography is relevant in the first place. Commented May 12, 2018 at 0:36
-
@Limit password is not stored in any way just the hash applying public key will only give you the hash (this is required for login). Commented May 12, 2018 at 0:38