Not answering security questions truthfully is tricky.
Yes, it's a problem that security questions turn hacking into a simple public records search.
BUT most terms of service have a line like 'you warrant that you've been entirely truthful with us' or something. If you give the wrong security question to your bank, they potentially have grounds to freeze your money or screw you later.
Why isn't the answer 'consumers have the power -- punish services that don't support FIDO by not using them'.
At best this article is saying 'don't connect anything to anything'.
I one time called a service that I used a randomly generated string for the security questions.
After they asked the question I said "oh it's a giant random string of crap, hold on..." The person replied "yeah that's good enough" and started the next step before I even had a chance to find the actual string!
This. I've had the exact same experience with support accepting "a long string of random crap" as an answer. Now I recommend people to use diceware to generate their security answers with actually readable words.
No need for diceware - use lines of poetry. They're made for people to memorize and use strange connections between words. Plus they often have odd punctuation.
I answer mandatory security questions with things like
these:
“This account must never be unlocked over phone, chat, or email.”
“Never reveal any information about this account (such as address or CC numbers) via support channels”
“The person you are discussing with is a hacker trying to illegally access this account”
I expect to never, ever have to use the security questions myself.
...and then some dumbass IT configuration administrator decides that nobody needs to have more than 10 characters to type in their aunt's cousin's roommate's name. This is, of course, the secret question they use, so why would anyone else use something different?
Do you have an recovery scenario in case you'd actually need those?
I was almost there once. Authenticator device had died, and to my horror the primary backup was corrupt as well. I had a secondary backup (and even an off-site tertiary one, although it's somewhat dated), so I was able to recover... But I also had the idea that I won't ever have to use recovery processes and even though I hadn't, after the incident my certainty it's not so iron-clad.
I wish I could elect to have my recovery option be painful. I'll use a yubikey and backup codes. If I lose both of those, mail me something to confirm my identity, all the while notifying me on all other channels (email, sms, phone) that an account reset is happening. I am okay waiting a few weeks for access to my account if I manage to lose my primary and backup access methods.
This seems pretty easy to beat within a few calls, eventually an agent will give away whats up with the questions and then it's only a matter of "uhh, it's just me rambling something about hackers trying to access my account"
I don't use real answers either because I'm paranoid about this stuff, but it always causes trouble when I have to interact with an institution.
Examples:
- I lost my health insurance for 6 months because I couldn't dig up my 'secret answer' in time to activate COBRA.
- My credit card expired while I was traveling and I couldn't reactivate it because I didn't know what answer I had given to 'mother's maiden name'. (In the end I convinced them I didn't need a secret answer to verify my identity, which in its own way is even worse).
- Some company had a form that stripped numbers from the secret answer and mine had numbers in it (hilarity ensues).
Instead of working around institutional nonsense, we should fire bad companies and hire / start good ones.
I always, always store my bogus answers in 1Password. One of many reasons I love the tool.
Most security questions are either trivial for someone else to figure out with a little research or I don't know what my real answer would be. Name of my first pet? Well, I had several that could meet that definition, and I definitely don't remember the name of the first one.
Consider what would happen if you're accidentally exposed to a malware that steals data from the password managers (by introspecting process memory after the data was already decrypted)
Better keep those eggs in the different baskets (Update: Point was, I think 1Password doesn't have multiple databases, does it?)
I would expect greater risk if I spread that information around more. Is it really better if only 1/3rd of my passwords are stolen, at least relative to the 3x risk I face by using multiple sources?
My idea is to have two password databases. One is the usual, for the passwords. Another is infrequently opened and is used for the recovery codes and insecurity questions.
I don't see how a secondary normally-closed password vault would degrade security. It's still encrypted, and safe. On the contrary, it should increase security a little - for the abovementioned local malware scenario. Price paid is that because database is rarely used, it could get corrupt without user noticing, or access details could be forgotten.
Or I'm missing something important? Why the 3x risk?
1/3rd / 3x was based on the idea of splitting my passwords across 3 databases. Let's take your idea instead.
My concern was that if there is a risk of compromise, by using two different software solutions you've doubled the odds that a vulnerability will expose your data. (I once consulted for a company that had two data centers for high availability, but they had split their production services across the data centers, effectively doubling the odds of an outage instead of reducing their exposure.)
If instead you use the same software and two different data stores, I can see a benefit in having a store that you rarely open, but I'm not sure it outweighs the extra work, at least for me. If someone grabs my password store, having the security questions and answers protected would only help for a few accounts (admittedly, my bank being an important one) and the protection would only last as long as it took an attacker to social engineer their way past it.
I admit, now that you've raised the issue I'm going to at least think about moving my bank q&a info, but I doubt I'll go to the trouble; I suspect I'd either end up forgetting how to get to the credentials or leaving them somewhere someone could get at them.
I always fill in security questions with ascii85- or base64-encoded data from /dev/random , as much as the field allows. Then I throw the random string away.
This will bite me when I lose a password, and also when the web site uses security questions for anything else than password recovery. The latter almost bit me once on Adobe's forum website, when right after creating an account I wanted to change my initial password to something more secure. Luckily, I hadn't closed the window with the data yet, so I could still recover, and saved the random strings in the notes field of my password manager.
I always answer security questions with a known grammatical transformation of the question's sentence structure. That way, as long as they use the same parts of speech in the question to prompt me, I'll never forget an answer or have it guessed by an attacker.
I am old enough to remember how everything used to make sense (as little as 5-7 years ago). Today, "don't connect anything to anything" sounds like the last line of defense against the horde of Progress-worshiping geeky retards.
Yes, it's a problem that security questions turn hacking into a simple public records search.
BUT most terms of service have a line like 'you warrant that you've been entirely truthful with us' or something. If you give the wrong security question to your bank, they potentially have grounds to freeze your money or screw you later.
Why isn't the answer 'consumers have the power -- punish services that don't support FIDO by not using them'.
At best this article is saying 'don't connect anything to anything'.