Return to Answer

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.

If you have it stored plaintext or encrypted, you need to write a comparison algorithm anyway. That algorithm will also have to boil it down to a basic version to be able to decide whether it a match. Whatever you would do when writing that comparing algorithm (so things like lowercasing), you should apply before hashing to get the same effect.

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.

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.

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 remove spaces, punctuation and capital letters.

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.

If you have it stored plaintext or encrypted, you need to write a comparison algorithm anyway. That algorithm will also have to boil it down to a basic version to be able to decide whether it a match. Whatever you would do when writing that comparing algorithm (so things like lowercasing), you should apply before hashing to get the same effect.

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.

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.

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 remove spaces, punctuation and capital letters.