For your security, the answer to your question (as well as your password) is encrypted in such a way that SMF can only tell you if get it right, so it can never tell you (or anyone else, importantly!) what your answer or password is.
Doesn't make much sense to specify a secret/question answer, regardless of how it is encrypted in SMF's SQL, if the HTML page it's being submitted over isn't SSL.
It does if you want the authentication credentials to be secured. Passing username/passwords in the clear negates any other security measures deployed, regardless of any 'security question', and regardless if that data is actually encrypted in the backend database. If you're going to transmit clear text, there is no need for any other measures of security. I'm not suggesting this forum needs SSL to protect account data, I'm just saying specifying usernames/passwords/secret questions & answers all in clear text is not adding to any existing security.
This secret question is an extra security measure when a user requests a new password to be send at his email account, feel free to leave it blank
I'm aware of what it is. I worked at InfoPop (UBB folks, since renamed) from 1994 to 2000, developing forum software code long before the market was loaded full of IPB, vB, SMF...and those annoying damn emoticons. I'm just saying having a "secret question only you know the answer to" is futile if everyone can view that information traversing the Internet in clear text. That doesn't make it very secret.
I am a little wannabe hacker. I have access at your email but don't know your forum pass. I ask for a new one and voila! I am in.
Your hypothetical situation assumes far too much. Wannabe or not, you won't very likely have access to anyone's email credentials. IF, by chance, you do - the password mechanism was likely very weak, so weak, in that the person whose email account has been compromised, is very likely the kind of person who uses the SAME password everywhere. That being the case, you don't need to have the password emailed to you, you already know the password. So, under the very liberal assumption you've already made in this hypothetical situation, it's a moot point. Iosif Chatzimichail wrote:
Now if you have a secret question thats another step so I probably can't do that, can I? There goes my hacking career. :
I urge you to discover some statistics regarding "secret" questions. Without going into so much as typing up a whitepaper to address password security, stating how weak passwords are generally easy to guess as they're constructed of family member names (children, etc.), common dates (birthdays, aniversaries), and dictionary words - when people have the option to create their own "challenge question", they're going to comit the greatest sin. They will come up with questions like, "Pet's name", or "City of birth" - neither of which are difficult to determine. They may go so far as to specify, "Favorite food", or movie, or book - again, nothing complex at all. So, again, given your hypothetical situation where a wannabe hacker has email credentials, they're going to breeze through any security question, 14 year old or not. None of this matters when you consider my original concern is with the NON-wannabe hackers, being able to permiscuously sniff usernames, passwords, and secret questions/answers all in clear text. Do you know where jamboworks.com is hosted? (I don't, not the point) - however, the point being, are you confident there are no other shared hosts on this box who have exploitable scripts, rooted accounts? Are you absolutely confident the information you submit over non-SSL connections is actually NOT being monitored?
I don't.
My whole point is it doesn't matter how many different "hoops" the user is made to jump through. If those hoops aren't encrypted, the data isn't safe. Have 30 secret questions. Require 2 different passwords. If the data isn't encrypted in transport, it doesn't matter if it's encrypted in the SMF database. Which, brings us back to my concern.
Which, again, isn't all that much of a concern as this thread is making it out to be - it was originally just an observation I was noting.