Security Trade-offs: Convenience Against Identity

Thursday, 11:10, at Stonebridge Insurance, in the design meeting for the self-service reset project. Rosa owns security for the company and has read the plan. Jonah runs the desk and wrote it. Rosa's first question is not about the plan. "When Mark from claims phones you today and says he is locked out, how do you know it is Mark?" Jonah thinks about it honestly. "I recognise his voice, mostly. And I ask his start date." Rosa writes that down. "So today, anyone who sounds a bit like Mark and knows roughly when he joined can get into his mailbox." There is a pause of the kind that happens when something true has been said in a meeting. "Right," says Jonah. "So the new thing has to be better than that." That sentence is the whole of this article, and it took Rosa one question to get there.

Verification is the act of checking that the person asking for a reset is the person who owns the account. It is the only thing standing between a password reset and an account takeover. Whoever can reset a password can log in as its owner. A factor is one kind of proof used in verification: something the person knows, something they have, or something they are. Self-service reset replaces the desk's judgement with a fixed set of factors checked by a machine. That is both the opportunity and the risk. The trade-offs between convenience for the user and certainty about identity are the subject here. This article is part of our Password Reset Self-Service series. And it is written generically, because the principles do not depend on which directory or which tool you have.

It covers the question Rosa asked and why the desk's current standard is the baseline. Next come the three factors in plain words, why the reset route is a door, and how to think about it defensively. Then it covers why security questions are weak, what a second factor is and what it costs, and what good self-service verification looks like. It finishes with what to log and who reads it, a short war story, and the trade-off table to copy.

How Do You Know It Is Mark?

Every desk already has a verification standard, and most desks have never written it down, which is why Rosa's question lands so hard. The standard is whatever the technicians actually do. On most desks that is a mixture of recognising the voice, knowing the person, and asking a question with an answer in the directory. That answer might be a start date, an employee number or a manager's name. When none of that is available, the desk goes with the plausibility of the call. None of this is foolish. It works for the honest callers, who are nearly all of them. And it has the great convenience of needing nothing from the user in advance. It is also the weakest route into most organisations, and the people who make a living getting into organisations know that.

The self-service project is the first time most desks are forced to state the standard, because a machine cannot "mostly recognise the voice". The approach you choose will offer a list of verification methods. Each must be chosen or declined. And the choice must be defended to the security owner. That is uncomfortable. It is also the best thing the project does for the organisation, because the standard written for the machine becomes the standard for the desk too. The manual reset in The Manual Reset, Done Safely, for the Rest is built on it. The first rule, then: self-service must verify at least as strongly as the desk should, not as weakly as the desk currently does. Write down what the desk does today, honestly, and treat it as the floor.

The Three Factors in Plain Words

The first factor is something you know: a password, a PIN, the answer to a question, a date. Its strength depends entirely on how many people could know it. A password you chose and never shared is strong knowledge. Your start date is weak knowledge, because your manager, your team, the HR system and your professional profile all know it too. The mistake desks make is to treat any fact as a secret because the technician does not know it. The test is not whether the technician knows. It is whether a stranger could find out in ten minutes with the person's name. For most facts about a person's employment the answer is yes.

The second factor is something you have: a phone that receives a code, an authenticator app that generates one, a hardware token, a badge, a laptop already trusted by the directory. Its strength depends on how hard the thing is to copy or steal, and on whether the person would notice. A code sent to a registered phone is reasonable proof that the caller holds that phone. The phone's owner would notice it missing. A code sent to an e-mail address is proof that the caller can read that mailbox. That is weaker, because mailboxes are read from many places and their passwords are reused. Possession factors are the backbone of self-service reset, and they are what enrolment registers.

The third factor is something you are: a fingerprint, a face, a voice pattern measured by a machine rather than a technician's ear. These are convenient and hard to share, which is their strength. They cannot be changed if copied, which is their weakness. So they are usually used alongside another factor rather than alone. For most self-service reset projects at small and mid-size organisations they arrive, if at all, as part of a phone's own unlock. The authenticator app then relies on that unlock. Treat them as a bonus rather than a plan.

Two factors from two different categories are stronger than two from the same one, and that is the entire principle behind the phrase two-factor. A password plus a security question is two things you know. Anyone who has researched you well enough for one has probably managed the other. A code to your phone plus a PIN you chose is something you have and something you know. The stranger needs both the phone and the PIN. When the chosen approach offers a list of methods, ask of each pair: "are these the same kind of thing?" If they are, the pair is weaker than it looks.

The Reset Route Is a Door

Think of every way a password can be reset as a door into the account. And remember that an attacker uses the weakest door, not the front one. An organisation can enforce long passwords, lock accounts after five wrong guesses and train everyone to spot a suspicious e-mail. Suppose a stranger can phone the desk on a Monday morning, sound stressed, give a start date and get a new password read out to them. In that case, none of that mattered. The login is the front door. The reset route is the side door. The side door is the one that matters, because a person who can reset the password does not need to guess it.

Self-service adds a second side door, and the defensive questions are the same for both. Who can reach the door: anyone on the internet, anyone on the office network, or only someone standing at a company machine? What proof does the door accept, and could a stranger with the person's name assemble that proof? What happens when someone presents the wrong proof several times: does the door slow down, lock, or keep politely asking? Does the real owner find out when the door is used, by a message to every registered route? That way, a reset they did not ask for is noticed in minutes rather than on Monday. And is every use of the door written down somewhere a human reads? A route that answers those five questions well is a safe door, whichever side of the building it is on.

The desk is targeted because it is built to be helpful, and that is not an insult. A technician's job is to get the stressed caller back into their account quickly. And a stranger who understands that will present as exactly the stressed caller the technician is trained to help. This happens on the morning the technician has eleven calls holding. The defence is not suspicion, which exhausts everyone and fails anyway. The defence is a fixed standard that does not depend on the technician's mood or the length of the queue. It is applied to everyone, including the chief executive, including the colleague whose voice you have known for six years. A standard that has exceptions has a side door with a sign on it.

Why Security Questions Are Weak

A security question is a question with a fixed answer the user set in advance, "mother's maiden name", "first school", "favourite film". And it is the oldest self-service verification method and the weakest one still in common use. The answers are facts about a person's life, and those facts are findable. They are in public records, in old social posts, in the conversation at the Christmas party, and with the colleague who sat next to them for a year. The honest user answers honestly, which makes the answer findable. The careful user answers with something made up, which makes the answer forgettable. So the question fails in opposite directions for the two kinds of person who use it.

The answers are also small. There are not many first schools, favourite colours or makes of first car. A stranger with a short list and a page that lets them guess five times is in a strong position. The answers are shared across systems, because people reuse them the way they reuse passwords. So a breach of one unrelated service hands out the answers for every other. And they age. The favourite film changes, the pet dies, and the city of birth is typed differently from the way it was typed four years ago. The user who fails their own questions becomes a reset ticket of a new and more irritating kind. A security question is something you know that other people also know, which is to say it is not a factor at all.

If the chosen approach offers security questions, decline them as a verification method on their own. If the security owner allows them at all, allow them only in combination with a possession factor and never as a way round one. The honest alternative, when a user has no phone and no second e-mail, is not a worse question. It is a different route. That could be a staffed reset at reception against a photo badge or a manager with their own verified identity vouching in person. Or it could be a planned manual reset at the desk to a written standard. Those are slower, which is the point. A verification method that is quick and uses only what a stranger could find is quick for the stranger too.

A Second Factor, and What It Costs

A second factor is a possession factor added to whatever the user already has. That means a reset needs the phone or the token as well as the knowledge. The second factor is what makes self-service reset safe enough to switch on. One common form is a one-time code sent by text message to a registered phone. Another is a prompt or a code from an authenticator app installed on a phone. A third is a hardware token that generates or holds a code. Each proves possession of a particular thing at the moment of the reset. Each is enrolled in advance, which is why Enrolment Is the Whole Project. Each has a cost that the plan must carry.

The first cost is the enrolment itself: every user must register the phone or install the app. And a user who has not cannot use self-service at all, so the verification choice sets the enrolment burden directly. The second is the user without the thing. That could be the warehouse worker with no work phone or the contractor who will not put a work app on a personal phone. It could also be the person whose phone is in a locker during the shift. The plan must say what those people do, in writing, before go-live. The third is the lost or replaced phone, which turns the second factor into a new kind of ticket: "I have a new phone and the code goes to the old one." That ticket is a reset ticket in a hat. It needs the same verification as a manual reset. And it will arrive on the day after every phone upgrade cycle. Somebody will be surprised by it. Try not to be that somebody.

The fourth cost is the one nobody writes down, which is the recovery of the recovery. If the second factor is lost, the user needs a route to re-enrol, and that route is a door too, with the same five questions. Most organisations settle on the manual reset at the desk, to the written standard, as the recovery for the second factor. That means the manual reset never goes away entirely and must stay strong. The convenience of self-service for the many is paid for by the care of the manual route for the few. A plan that weakens the manual route because "hardly anyone uses it now" has opened the side door for exactly the people who want it.

What Good Self-Service Verification Looks Like

Good self-service verification uses two factors from different categories. It accepts no proof that a stranger could assemble from public facts and makes the owner aware the moment the route is used. In practice that means a possession factor, a code to a registered phone or an authenticator prompt. That factor is paired with one piece of knowledge the user chose rather than lived, such as a PIN set at enrolment. Or there are two possession factors for high-value accounts. It means the reset page does not say whether an account exists, and does not offer unlimited attempts. It slows down or locks after a handful of failures in the same way the login does. And it means a reset sends a message to every route the user registered. That way, a person who did not ask for one is told within a minute and knows who to call.

Treat some accounts as too important for self-service at all, and say so in the plan. Administrator accounts and accounts that can move money belong on an exclusion list. So do accounts with access to the directory itself and any account the security owner names. The people who hold those accounts get a manual reset at the desk every time. That reset happens in person or by a call back to a number already in the directory. This is not distrust of those people. It is an acknowledgement that a door to those accounts is worth more to a stranger, and should be harder. The convenience lost is a few resets a year. The exposure avoided is the one that reaches the board.

The organisation's rules or the directory's features may leave you a choice between more convenience and more certainty. In that case, ask what the account can reach and choose for the account, not for the user. A store assistant's account that reaches a till and a rota can be reset on one factor and a notification without much loss. A finance manager's account that approves payments cannot. Most directories let you set the standard by group. Most projects set one standard for everyone because it is simpler. That is a convenience for the project and nobody else. Two standards, written down, cost an afternoon. It is a good afternoon.

What to Log, and Who Reads It

Every reset, self-service or manual, must leave a record that answers "who reset this account, when, how were they verified, and who was told". The log is how a wrong reset is noticed and how a right one is defended. The self-service system writes its own log. Make sure, before go-live, that the desk can read it. A log only the directory owner can open is a log read once a year. The manual reset is logged in the ticket. The ticket and the log should agree. A reset in the directory log with no ticket and no self-service record is the first thing a monthly review looks for. If you run QuerySolv, the complete event history on the ticket holds the technician's verification note and the time of the reset side by side. That makes that monthly reconciliation a comparison rather than a search. In any tool, the standard is that a stranger reviewing the account in a year can see exactly how each reset was authorised.

The checklist below is the minimum a reset record needs, whichever system writes it. The last two items are the ones most often missing, and the ones that matter most when something has gone wrong. "The user was notified at this address at this time" is the difference between a reset the owner could have challenged and one they could not. Never log the password itself, temporary or otherwise, in any record the desk keeps, for the reasons in What Not to Write in a Ticket.

• The account that was reset or unlocked, by its directory name.
• The date and time, to the minute.
• Who performed it: the user through self-service, or the technician by name.
• Which verification method or methods were used, and whether any attempt failed first.
• Where the request came from: the network location for self-service, the channel and number for the desk.
• Which registered routes were notified of the reset, and when.
• For a manual reset, the ticket number, and for a self-service failure, the ticket it produced.

Someone reads the log weekly, and the reading has three questions. Which accounts were reset more than once this week? Which resets failed verification and how many times? And which manual resets have no matching ticket? The first finds the stale device still locking an account. The second finds a stranger trying the side door. That stranger looks exactly like a user who has forgotten their PIN until you see the same account tried from three places. The third finds the technician who did a reset for a friend without the standard, which is the finding nobody enjoys and everybody needs. Fifteen minutes on a Friday. The log that nobody reads is a log that protects nobody.

A Short War Story: The Doctor Who Phoned at Harbourview Clinic

At Harbourview Clinic, a caller phoned the desk on a Monday morning claiming to be Dr. Anand. She said she was locked out before a full list of patients. She offered her start month and the answer to the security question on her account. Both were correct. Both could be found by anyone who had read the clinic's own website and a short public profile. The technician, Leo, was on his ninth reset of the morning. The caller was convincing and anxious. And the standard he had been taught was "ask something from the directory", so he reset the password and read it out. The real Dr. Anand found out at 08:50 the next day when her own password did not work. The clinic spent the following week establishing what had been read in her mailbox and reporting the matter to its regulator. That week, it also wrote to the patients whose appointment letters had been opened. The investigation found that nothing Leo had asked for was secret, and that the clinic had never decided what a secret was. The new standard required a call back to the number in the directory or a code to an enrolled phone, for everyone, including doctors, including directors, with no exceptions. The cost was the week, the regulator's attention, and a letter to several hundred patients. And the lesson was Rosa's question in a different building: the desk had never asked itself how it knew it was Dr. Anand.

The Trade-off Table

The table below is the one to put in front of the security owner before an approach is chosen. Keep it after the approach is chosen, because it is also the standard for the manual reset. Each row is a verification method, generically described. It shows how convenient the method is for the user and how strong it is as proof. It also shows what the method costs in enrolment, who it fails for, and the recommended use. The strengths are relative judgements and the security owner may move a row. The point is that every method the project will accept is on the table with its weaknesses beside it, so that nobody later says they did not know. Copy it, add the methods your approach offers that are missing, and delete the ones you will refuse, in ink.

Rosa and Jonah spent forty minutes on the table at Stonebridge. They left with three rows crossed out and two standards, one for claims handlers and one for anyone who could approve a payment. They also left with an exclusion list of eleven accounts that would never see self-service. The project got slower by a fortnight and safer by more than that. Jonah's desk still gets a call from Mark now and then. The technician who answers now asks him to confirm the code that has just arrived on his phone. Mark finds that faintly ridiculous and does it anyway. Rosa's question did not make the desk suspicious. It made the desk consistent, which is the only kind of security a help desk can actually offer.

Frequently Asked Questions