Storing secret Q&A - hash or plain text.

My passwords are using sha512 but secret question and answers are plain text. The question is: Do I need to hash the secret answers? If so what datatype to use for开发者_开发知识库 it, would it still be char(128)?I assume secret question has to be plain text right?

Just get rid of the secret questions, they're a pointless measure:

1. they do not increase security, they actually diminish them as it's quite easy to find the answer especially because, as you said, there will be stupid usere around who will use "what is your favourite pet?" as a "secret" question.
2. they can be frustrating as you may spell the answer slightly differently (or uppercase/lowercase) when trying to recover your password.
3. if your password is hashed you cannot give the password back to the user, you'll have to send him/her an email with a new password or a link to change it, so why don't you just let the user enter his email address in the first place?
4. it's just another extra field to fill up upon registration. There's already too many...

You shouldn't really have to hash either. If a user wants to reset their password via question/answer, it should send out an email with a link to do so. If an attacker managed to get their hands on the questions/answers, it still wouldn't help them unless they already had access to the user's email, which means that all bets are pretty much off already. You could hash the answers if you wanted to, and they would be stored in the same manner as the passwords are since they'd wind up in the same format.

One question though, do the users type in their own question or do they select from a list? If from a list, why not just use an identifier for which question was used, and have the potential questions either in another table or hard coded into the script?

This is an old post, but I wanted to add some thoughts on nico's answer (I'm too new to add comments). Security questions are useful when users no longer have access to the email address they registered with (it happens frequently). You need some other way to identify them or they will never get back to their account.

You can mitigate the risk of mis-entry by normalizing the inputs (lowercase, trim leading/trailing spaces, etc.).

Back to OP, if you still use them, one reason not to hash them is exactly nico's second point - if the answer is "St. Cloud" and the person types "St Cloud", a poorly-written system might deny the reset. But an administrator would see that the answer is obviously correct if the answers weren't hashed. If the answers were hashed, there would be no way to know if the user was even close.