A Security Question Anybody Could Answer

Why they are weak

Security questions were designed when the information they asked for was genuinely private.

A mother's maiden name, a first school, a street you grew up on, and a first car are now variously in public records, on social profiles, in genealogy sites, and in the answers people give to quizzes without thinking.

Some are simply guessable, since a first pet or a favourite colour comes from a small set.

And unlike a password, the true answer cannot be changed once it is known, because it is a fact.

Where the answers already are

• Public records and registries.
• Social profiles and old posts.
• Your own about page.
• An obituary naming family members.
• Data from an unrelated breach.
• A conversation somebody had with you.

The third catches business owners specifically. An about page saying where you grew up, what you did before, and when you started is a helpful page that also answers two or three standard questions.

The answer is to lie

Plainly, since this is the whole recommendation and people hesitate over it.

Treat each answer as a second password: a random string, unrelated to the question, different for every account.

Store it in your password manager alongside the password, in the notes field, labelled with the question.

There is no obligation to answer truthfully, since the field exists to authenticate you rather than to record biographical facts.

Nobody is going to compare your answer against a record, because no such record exists.

The only requirement is that you can reproduce it, which is what the password manager is for.

The one situation where it matters

Worth knowing before adopting this everywhere.

Some services use these answers in a spoken conversation with support, where somebody reads the question and you answer aloud.

A thirty-character random string is impractical in that setting, and a memorable but false answer works better: a real word or short phrase that is not the true answer.

Banks and telephone providers are the common cases, and it is worth knowing which of your accounts work this way before choosing an approach.

Where it is only ever typed, use a random string. Where it may be spoken, use something false and pronounceable.

Either way, write down which you used, since remembering that you lied is not the same as remembering what you said.

A worked example

A business owner had answered security questions truthfully on several accounts over the years.

Going through them, his about page named the town he grew up in, his social profile listed his first employer, and a local news article from a charity event named his mother.

Three standard questions were answerable from public sources in about five minutes.

He replaced every answer with a random string stored in his password manager, which took about forty minutes across a dozen accounts.

The about page stayed as it was, since the problem was the questions rather than the page.

He also found two accounts where security questions were the only recovery route, which he changed to something stronger.

The answer does not have to be a name

A small point that resolves the hesitation people feel about the whole approach.

Nothing checks that the answer to a question about a city is a city, or that a maiden name looks like a name.

The field accepts whatever string you provide and compares it to whatever string you gave it originally, and that is the entirety of the mechanism.

So a question asking for your first school can be answered with forty random characters, and the service will accept it and store it exactly as given.

Once that is clear, the remaining objection is only about being able to reproduce it later, which the password manager handles.

Remove them where you can

Since the best answer is not to have them.

Many services that once required them now treat them as optional or have replaced them with better methods.

Where two-factor is available, enabling it frequently removes the reliance on questions entirely.

Check whether the questions are still an active recovery route on your accounts, since an old weak route left in place is usable even when a stronger one exists alongside it.

Where they can be deleted, delete them. Where they cannot, replace the answers.

The pattern is the same as with recovery phone numbers: a weaker route left configured is the route that gets used.

The same weakness in your own forms

Worth turning around, since businesses sometimes ask these questions of their own customers.

A booking system or a member area that verifies somebody by asking for a date of birth or a postcode is using the same weak method.

Those are exactly the details available to anybody who has seen an invoice, a parcel label, or a form left on a desk.

Where you need to verify a customer, use something transactional instead: the amount of the last payment, the date of the last visit, or a code sent to the contact details already on file.

That is both harder to guess and easier for a genuine customer to answer than a fact they may have given you years ago.

Do not answer them elsewhere

A habit worth acquiring, since the answers leak through ordinary behaviour.

The social posts asking about your first car, your childhood street, or your first pet are the standard question set, and answering them publicly is the same as publishing the answers.

Whether those are collected deliberately or are simply idle is beside the point, since the result is identical.

The same applies to profile fields, which people fill in completely because the form asks.

Once you have replaced your answers with random strings this stops mattering, which is another argument for doing it.

The counter-case

False answers create a recovery risk of their own.

Somebody locked out, with no access to the password manager holding the answers, is in a worse position than somebody who could have answered truthfully.

Which means this depends entirely on the password manager being backed up and reachable, and on somebody else in the business being able to get into it.

For an individual with no such arrangement, memorable false answers are the safer version of this advice.

Replace the answers, record them properly, remove the questions where you can, and check the manager is recoverable.

What to do

1. Check whether questions are still an active route.
2. Remove them where the service allows.
3. Replace the answers with random strings.
4. Use false but pronounceable where spoken.
5. Store them in your password manager.
6. Enable two-factor to reduce reliance on them.
7. Stop answering the same questions publicly.

Step three is the whole recommendation, and the hesitation people feel about it disappears once it is clear the field authenticates rather than records anything.

Where to keep all of this is covered in a password manager for four people.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.