> and their secret questions and answers
Periodic reminder that these are just passwords too. They should be treated as such by users (generate random responses) and devs (hash and salt them).
Periodic reminder that these are just passwords too. They should be treated as such by users (generate random responses) and devs (hash and salt them).
I agree for tech savvy users it's prudent to treat them as passwords, but it doesn't extend to the general public. If they should be treated as passwords, what's the point of having them then? They're most often used in password reset flows. If it's a random string/phrase, they're basically useless in that use case. In what situation would you have the randomly chosen string for the security question, but not the randomly chosen string for the password?
As a user, if you want guessable recovery codes, that's fine. It's all in the threat model. The password for this account is very guessable. It used to be 000000. I don't care about any possible threat to it.
Their purpose these days is to provide a way for anyone to reset your account credentials using public information or the answers to Facebook quizes to find out your secret pirate name.
1) Don't answer the question that was asked. Mentally translate it to a different question entirely. "Name of first pet" is always answered as "color of first car", for instance.
2) Make the answers full sentences, not just single words. If the answer you're providing is "color of first car", the answer shouldn't be "white", it should be "The color of my first car was white".
1. That is likely to exceed the maximum length allowed for the form fields you have to use to enter it on web pages or in apps.
You might find that on the page where you initially set it up the page silently truncated it to say 1000 bits, and that's what got stored on the server. But the page where you need to use it for password recovery handles 1500 bits, and the form in their app only handles 500.
So you cannot get it to work in the app no matter what, and can only use it on the recovery page if you somehow figure out that only 1000 bits are on the server and truncate to that yourself.
2. Some places use the same security questions when you phone support. The support person asks you one of the security questions and can read the answer from the database. They compare that to what you tell them over the phone.
You probably don't want to go through that with a random 4096 bit string.
Fascinating. This is something I never encountered, so it never occurred to me that this might be done.
Honestly, I don't know if there's a point to having these questions. At least one security expert feels similarly: https://www.schneier.com/essays/archives/2005/02/the_curse_o...
None for the end user! (Although I assume there must be some corporate career incentives or something for implementing security theater like this, since they keep doing it anyway.)
No one except hackers or certain federal agencies would be able to compare the results of security questions across independent identity management systems.
Unfortunately this is not how almost any business treats them; they are frequently used as challenge/response authentication over the phone, so using a random response or hashing and salting them doesn't work.
Authenticating a user over the phone is a major unsolved problem IMO, and responsible for a huge swath of modern account takeover issues.