Lessons from the use of personal knowledge questions at Google (2015) [pdf] | Hacker News Reader

Lessons from the use of personal knowledge questions at Google (2015) [pdf]

static.googleusercontent.com

79 pointstptacek36 comments

I think I have a 0% success rate with secret questions. They always ask things that don't apply to me, so I have to make them up. Then I forget them. (Sorry, Charles Schwab, I've never owned a car.)

I have learned the hard way that these are just easy-to-guess extra passwords that let attackers bypass my hard-to-guess password. I dump them in my password manager so I don't get locked out, but I know they're a ticking security time bomb. Every site asks the same questions, so if the database gets compromised, it lets someone compromise other accounts. And, they're probably not even one-way-hashed, because customer service people ask for them on the phone and can probably see the answers. I don't even know how it's legal to use these things anymore. They set the field of information security back two decades.

(I have always assumed that they exist to save money on call centers. You get locked out, you have to talk to a real person, and real people want salary and benefits. But with the abysmal success rate that the paper shows, I'm not even sure it's saving people money. It just seems wrong on every level. For that reason, I know they're here to stay for good.)

If you use a password manager, then its easy to make and save secure answers.

Question: what is the name of your first car's cousin?

Answer: rnrogbpqhey..!105

Sorry your reply must be a maximum of 12 characters. Punctuation is not allowed.

And run through tolower() silently.

For cases where the questions are used by automation, it's okay. Not so much when humans come into play, that can be social engineered: A friend called his bank for something. They verified his idenitiy, him answering to 'what was your first pet's name' with: The answer is random letters, numers and symbols. He was verified to be the owner, not having actually told the support person a single matching character.

For those cases, generators for random answers that read legit would be better. I started putting in random word sentences like 'DoYouHaveAPetCalledPeter', stored in pwdstore metadata to the accounts.

Also it's fun when you have to speak to customer support and you're not sure if you made up the answer or not. It's extra fun when the security question is something embarrassingly obvious like "what town did you grow up in?" or "what is your mother's maiden name?" and you get it wrong (and have to say "No really, I know this but I lied on your form").

The good news is that you are very good at keeping secrets. :)

Cory Doctorow highlighted a particularly 'head-desk' example of challenge questions' failure modes yesterday – a credit union that mixes the user's free-form answer (which might be an attempt at a strong password) with mundane alternate responses in a multiple-choice presentation:

https://twitter.com/doctorow/status/1289214916960780291

Whenever you think you've seen the dumbest bit of anti-secure design, some bank, airline, or government will provide a "hold my beer" topper.

Oh, man that's bad. The worst I've come across in the wild was some bank or financial institution (don't remember which one) which did some "sensible" validation at creation time. I.e., your first phone number had to look like a phone number, your mother's birth date had to be a real date, etc. That was pretty bad but you could still choose the phone number one and get a reasonably decent password. This is way worse.

Banks are just abysmal pretty much across the board. From things they should know better about (2FA over SMS) to just inexcusable - BarclayCard in the UK has accounts protected by a 6 digit pin and a secret word that needs to be a minimum of 6 characters long. No 2FA options available.

Most people on HN probably understand intuitively that account recovery questions don't work (the conventional response to them is "ignore the questions and use them as additional passwords"). But this paper highlights an interesting specific reason they don't work: there are demographic subsets of users for which specific questions, like "favorite food" or "city of birth", are particularly insecure.

Think of it as "falsehoods programmers believe about personal information security".

> ignore the questions and use them as additional passwords

Passwords that have no hashing or other protections against disclosure, and which use non-private information by design.

> "favorite food"

They don't say the answer, but it has to be pizza, right?

I worked at a place once that actively encouraged everyone to use the word "Mickey" as the answer to all these questions. What city where you born? Mickey. What's your favorite food? Mickey. Best friend's name growing up? Mickey. Apparently the person who started this trend was a big Disney fan.

So you could hack into any of their accounts by using password recovery mechanisms. Sounds like a bad idea.

Yes, exactly. It's kind of like the obtuse password rules which result in people writing their passwords on post-it notes stuck to their monitor. The net security result is worse.

>The net security result is worse.

Depends on what you're looking for.

Secure password written on a monitor (or on a pad in a locked drawer) is better than using "Passw0rd" (or some other trivial to the point of uselessness password that all the scripts will try) for most use cases assuming you have some semblance of physical security. Your coworker might login as you and F up something but some guy in Nigeria or Belarus is much less likely to encrypt the network share than if you had chosen the former. Just like everything else in security it's all about what your threat model is and what the trade-offs are.

Edit: do any of the people who are offended by my statement care to explain why it is so disagreeable to them?

You think you are safe, until a TV crew broadcast your post-it worldwide. It is not made up, it happened to TV5Monde in 2015

That's like the computer security equivalent of some rare disease that's only happened to a couple dozen people. Sure, one can win cheap virtue points by insisting it's something we need to take seriously and yes it is easy to guard against but it shouldn't be a realistic part of pretty much anyone's threat model. Given the choice of a pad of paper in a locked drawer (i.e. analog password manager) and sticky not obviously the sticky note is inferior but both are superior to having something that is trivially easy to compromise without having physical access to the workplace.

Are most attacks inside jobs?

Personal knowledge questions are just clear text passwords that can be determined from publicly available information. Apparently everyone gets that except the security people because they keep thinking it’s the best thing ever. It’s right up there with calling on the phone being a security factor - because yes everyone knows my voice so there is no possible way anyone can call and claim to be me.

Synchrony financial still takes top honors for locking out my account when I use a vpn, and giving a menu of phone numbers from Transunion to choose where to send SMS auth attempts - you don’t even have to ask my phone provider to port my number to your phone, just fill out a raffle ticket at the mall and wait for it to turn up on the report.

I can gripe about Google a lot but no denying they have done more then anyone to improve the security of the average user - TOTP, yubikey, per-device passwords for e-mail. Wish the banks would catch up.

"My voice is my passport. Verify Me"

HSBC (at least in the UK) has a Voice ID feature that literally has you say "My voice is my password".

It's not just a matter of how effective they are…one must consider the risk of these answers being included in a security breach's data dump. It's easy to imagine a sort of "dark web data broker" that has aggregated any "found" answers, keyed by each user's e-mail address. It would be extremely valuable to anyone trying to steal an identity.

That's why I lie whenever I see them, and I keep track of the lies in my password manager's notes, which are regularly printed and stored off-site for disaster recovery purposes.

I harden my security questions by either providing a random 32-character value from [1] or by passing the real answer through sha256 with a site-specific salt (i.e. sha256(domain name + answer)). I only do this when security questions are mandatory. Otherwise I never set them up & use U2F instead.

[1] https://passwordsgenerator.net/

This has usability problems. I don't always remember whether I used 'dr.', 'dr', or 'drive' for a street name. I can't remember if I put a space between two words. I don't recall the capitalization I used (was it proper, or did I go with lower case because I was rushed?)

If a site is going to require precise answers (and I suppose any other method probably creates additional bugs, reduces security...), then I might as well generate random responses and put those in my password manager, too.

That's correct. I usually put them in my password manager too.

Which means that if I can get a customer service rep on the phone, I can beat your security question and take over your account, by correctly answering "It's a bunch of gibberish."

I use a couple of words of pronounceable gibberish, like merbl krasnk. Same answer for all questions. At a few sites, the answers are required to be different, so I add a letter or two to the end. All of it goes in my password manager.

Yes, it is prone to targeted social engineering but so are the questions in general. At least data breaches aren't reusable across sites so I limit the damage of that attack vector. If you have a suggestion on a better technique I'm open to hearing it.

I think the better technique is to just accept that customer service is ran by malicious idiots, and that your account can and will be compromised.

Then, the proactive thing you can do is plan for how you will deal with the fallout.

Tried that, pita to read those off to the support people, and they usually get one of the 32 characters wrong the first time.

More recently I’ve started changing my answers to “I don’t know” which blows people’s minds when they type it in and it works.

When a site requires a response to these questions, I typically provide a purely-fictional response. e.g. (not real examples)

My childhood best friend: Ender Wiggen

City I was born in: Moscow, ID

etc...

and then log the specific lie in my password manager. They work if I need to read one off to a service rep over the phone, and they are in no way connected to my personal history...

Yep, and for truly random friends, streets grew up on, cities, schools attended, first person kissed, etc, fakepersongenerator works pretty well.

[1] https://www.fakepersongenerator.com/

It's a shame authors like this don't think to delve into the "other" category, because that's where surprising insights can sometimes be buried.

For example, I would really like to know the "other" reasons for providing false answers to security questions. The top reasons are obvious, and a couple of them are my reasons. For privacy, and better security, I would put, say, B7eoaOHv2se as my father's middle name, and store it in a password manager.

My guess is that "other" breaks out into:

- I have one or more of the above reasons but I don't want to reveal it/them.

- I don't have one of the above reasons but I don't want to reveal my reasons.

- I am lazy.

- I like to troll security questions even though I am just trolling a script program on the internet.

- I am trolling your survey.

- I use it as a chance to express my creativity.

- I have never encountered such a question.

- I forget how I answered and why.

These may overlap.

But it would be interesting to see if there are other sensible reasons.

One thing to understand is services which deploy personal knowledge questions for password reset do NOT take security as their primary aim. The primary aim will be a cost-benefit optimum between user security and cost of customer service.

This cost-benefit analysis is strictly from the point of view of the provider. If their costs for a customer security breach are low, they will be willing to trade lots of insecurity for a little bit of reduced customer support.

Reply on news.ycombinator.com