Authenticating users with passwords and "secrets" such as your hometown, high school, or first street name are all ridiculous strategies. My not-so-inner cynic suggests that banks know this but think they are safe from lawsuits as long as such methods are "industry standards."
Currently, we use email/password for authentication, but if our user forgets their password, they can answer their security questions to reset it. To design our list of questions, we worked off of http://www.goodsecurityquestions.com/examples.htm and tried to find questions which were relatively obscure, but not so obscure that users couldn't come up with answers. I suppose we can make "write your own question" an option, but we do think that most users given that option will write too easy a question, like mother's maiden name.
Our app contains a lot of sensitive data, including medical data, and privacy of this data is incredibly important to our business. We have to be attentive to regulation and industry standards -- and you're right that industry standards probably give us some cover -- but we have both the desire and the flexibility to do the right thing.
There are no easy answers if the scenario is that someone has "forgotten" their password AND you want to authenticate them using a web form that can be submitted anonymously from an arbitrary machine.
I think the banks also know that accounts are such high-value targets that criminals have better ways to steal, anyway. Straight up identity fraud is way more of a problem than account hacking.
Whenever forced to use one of these authentications, I just wail on the keyboard to provide an answer. My mother's maiden name? Why, it's "sfdgh,jsdzl.kg hjsldghs,hb".
Be careful doing this for a service with an offline/telecoms aspect. Both my bank and credit card companies ask to verify that information when I phone them,
Unlikely. The person on the phone doesn't have the right to make judgments like that. Furthermore, if they were to allow it, that means that everyone who writes gibberish can have their account compromised by someone who guessed that it's gibberish.
Whenever i need to open an important account (say, with the power utility) I make up answers and record them on paper. Simple. Effective.
It really frustrates me when sites require a question and secret answer like "hometown" or "mothers maiden name".
Those are both very easy to find pieces of information. Let me select the question myself too. By forcing me to give you answer here you're potentially making my account _less secure_.
Right now I have standard fake answers to those questions, let's hope they never cross reference those with anything else. I'm not sure how I'd convince someone my mothers maiden name is "<insert comedy name here>"
I don't think any site stipulates that you answer such questions truthfully. My solution is just selecting the top secret question, but actually answering my own secret question with an answer that is as good as any password. And of course a different set of those for the actually really important sites.
If the site allows the user to chose their own security question, the user will find a way to render it useless. They will either input something far more trivial, or they will input something they then forget.
Personally, I don't think businesses should implement half-baked security features -- and password request forms are as half-baked as it gets.
The best solution would be for important sites (my bank, my stockbroker, ...) to make me come into their office with documentation if I forget my password.
The problem, unfortunately, gets more difficult for "unimportant" sites... frankly, short of relying on a centralized ID provider that can ensure identity in person, there isn't a good answer.
The problem, unfortunately, gets more difficult for "unimportant" sites... frankly, short of relying on a centralized ID provider that can ensure identity in person, there isn't a good answer.
Keep in mind these are all meant to be in-channel "back-up" strategies for when usual authentication methods fail and/or human error results in a complete loss of credentials. Forcing a true side-channel workflow for re-authentication and credential recovery isn't practical for most organizations.
A more secure, but frustrating for the dis-organized, approach is to email out a small set (3-5) of one-time credential-recovery passphrases (often called a scratch-list) with the initial account approval message.
Another slightly more usable forced-in-channel alternative includes image file recognition where the user selects from a predefined set of pictures to use as their "shared secret" when the account is created. Typically, a salted hash of the image file is stored as the actual password value so multiple versions (slightly bit skewed) of the same visual representation can be leveraged for password expiration.
Alas, all of these more secure alternatives limit the user's ability to "personalize" their shared secret and require additional bookkeeping.
27 comments
[ 4.8 ms ] story [ 65.9 ms ] threadCurrently, we use email/password for authentication, but if our user forgets their password, they can answer their security questions to reset it. To design our list of questions, we worked off of http://www.goodsecurityquestions.com/examples.htm and tried to find questions which were relatively obscure, but not so obscure that users couldn't come up with answers. I suppose we can make "write your own question" an option, but we do think that most users given that option will write too easy a question, like mother's maiden name.
Our app contains a lot of sensitive data, including medical data, and privacy of this data is incredibly important to our business. We have to be attentive to regulation and industry standards -- and you're right that industry standards probably give us some cover -- but we have both the desire and the flexibility to do the right thing.
They'll get an earfull when they ask me for it though, futile or not :)
Whenever i need to open an important account (say, with the power utility) I make up answers and record them on paper. Simple. Effective.
Combustible.
http://www.zug.com/pranks/visa/index03.html
Those are both very easy to find pieces of information. Let me select the question myself too. By forcing me to give you answer here you're potentially making my account _less secure_.
Right now I have standard fake answers to those questions, let's hope they never cross reference those with anything else. I'm not sure how I'd convince someone my mothers maiden name is "<insert comedy name here>"
Also depends what sort of site it is and if it has a concept of "support staff".
Personally, I don't think businesses should implement half-baked security features -- and password request forms are as half-baked as it gets.
The best solution would be for important sites (my bank, my stockbroker, ...) to make me come into their office with documentation if I forget my password.
The problem, unfortunately, gets more difficult for "unimportant" sites... frankly, short of relying on a centralized ID provider that can ensure identity in person, there isn't a good answer.
I hear there's this thing called "OpenID".
A more secure, but frustrating for the dis-organized, approach is to email out a small set (3-5) of one-time credential-recovery passphrases (often called a scratch-list) with the initial account approval message.
Another slightly more usable forced-in-channel alternative includes image file recognition where the user selects from a predefined set of pictures to use as their "shared secret" when the account is created. Typically, a salted hash of the image file is stored as the actual password value so multiple versions (slightly bit skewed) of the same visual representation can be leveraged for password expiration.
Alas, all of these more secure alternatives limit the user's ability to "personalize" their shared secret and require additional bookkeeping.