I've experienced a couple of times, an organisation has called me, but they require me verify who I am with security questions.

Most recently, this was my credit card company who left a voice message with a number to call re: possible fraud on my account.

The obvious security risk here, is that it could be a scammer, who is then going to use those details gain access to my account.

In these scenarios, having a modicum of security conscientiousness, what I do is acknowledge the call, request a ticket number if there is one, and look their phone number up on the website, and call back that way.

In my credit card example - the number they'd given me wasn't listed, so I called their general helpline and requested to be transferred.

I think from a end user/consumer's point of view, this is the right protocol.

The question is - what should the organisations themselves be doing to encourage good security? It seems like a very bad habit to teach their customers - to reveal identifying information to people who call them.

  • 1
    Great question. I'd like to see some of the answers. I think it ultimately boils down to, how do we authenticate over the phone -- and make it feasible enough so that most consumers would do it. – keithRozario Mar 19 at 9:07
  • This is a great question, and I've had similar experiences as you when the fraud department calls up. – Steve Sether Mar 20 at 14:15
up vote 4 down vote accepted

The best way is to make it trivially easy for a customer to get to the right place through the number on their card, on their statement, on your website; more, to make it impossible for a bank department to have a number not listed on the bank website.

You can do this via a reference number, a code word, (eg, "please call us back on the number on your card, and say "fraud" as soon as our messages start.") You need to ensure that when the customer calls in this way, they get to the right place.

You also need to train customer service reps to respect the customer's choice to call back. Far too often, CSRs will denigrate or undercut the desire to return a call. They might suggest that caller ID is trustworthy or even tricky to spoof. It is not.

When I was at Microsoft, we studied this pattern, which is where an organization acts the same way a fraudster does, and results in people being unable to form a model of secure behavior. We called this pattern "scammicry" for the mimicry of a scam.

There are additional tools you can use, including biometric voice authentication, asking questions which don't expose the answerer to identity theft, such as knowledge of recent transactions, so that calls from the bank are not so worrisome. (Note that if there are a small number of recent transactions, then a scammer who calls can get those, and then authenticate to the bank.)

  • This is a good example for the case of a credit card company. But what about where it's a lesser known organisation or one where the user doesn't have a card handy in their wallet. For example your doctor, the tax department. Saying 'look our number on our website' might be ok - but isn't very friendly for less tech savvy users. – dwjohnston Mar 20 at 23:05
  • +1 for a clear and concise answer. However, small nitpick: my bank uses recent transactions to identify me when they call me, but I'm not convinced it is a good security measure in practice. When done with me they have asked me to verify particular transactions from large and common retailers and gave me some hints that would have made it possible for me to guess the right answer even if I was someone else. As a result, it may not be a great security measure if a criminal has stolen both credit card and phone, or in edge cases that could be more common if it was a common bank practice. – Conor Mancone Mar 21 at 12:21
  • @ConorMancone I agree, the measure can be implemented badly, but that's an argument against bad implementation. The key idea is that there are secrets known to a small set: you, your bank, the merchant (ideally, different merchants). But these are secondary to the key of the customer in control. – Adam Shostack Mar 21 at 15:30
  • @dwjohnston the tax department is quite different from your doctor. For your doctor, odds are the call is in your recents list. The tax department is trickier, since they often have insane call queues and the "we'll call you back" feature is helpful. In that case they could get permission to talk to whomever answers the phone, or offer up a one use phrase that they'll use when they call you back, for example "horse anvil green"; you'd only be expected to recognize it for a few hours to days. – Adam Shostack Mar 21 at 15:35
  • 1
    Bugger off, @ConorMancone, you sniveling orc!! :) – Adam Shostack Mar 21 at 19:38

Some ways for callers to authenticate themselves:

  • Route all outgoing calls through a single official phone number
  • Introduce themselves by disclosing a shared secret (sort of like QubesOS' anti-evil maid)
  • Distribute a dedicated smartphone app that validates their numbers
  • Liaise with apps like TrueCaller to validate registered trademarks with the equivalent of Extended Validation Certificates

This list will be updated as more ideas come to mind.

  • The Qubes software is not relevant in this case. It is very specifically a hardware thing (unsealing a TPM secret). Disclosing a shared secret would be better using something designed for that purpose, such as the Socialist Millionaire Protocol. – forest Mar 20 at 4:04
  • @forest the concept behind QubesOS' anti evil-maid is not hardware specific: it just displays a secret message after the user unlocks their TPM. Similarly a company calling your mobile number would know it is you and could therefore safely authenticate themselves telling you their secret message. Protocols like the one you mentioned are very effective for computers but are too complex for ordinary people. – Enos D'Andrea Mar 20 at 4:38
  • Using a repeatable shared secret that can be read over the phone is not a good idea to prevent phishing. Once the secret is out, it's no longer a secret, and with this protocol, the secret could leak to either end (snooping on a legitimate reveal, or tricking the user into revealing it). The on-screen shared secret in Qubes is something that the user is not likely to reveal (typically an image) and is not communicated over a network (so less at risk of interception). – Gilles Mar 20 at 7:11
  • @Gilles Not to mention, the TPM is able to check the integrity of the computer. It's not proving that the computer has any secret, but is acting as an (internal) 3rd party to vouch for it. I don't know of any analogous way to do the same over a phone. – forest Mar 20 at 9:48
  • 1
    @forest Here we can assume that the user's phone is secure enough to protect the secret. If it's good enough for other aspects of banking, it's good enough to authenticate the bank. By the way, you can do the same on a phone with a TEE — in principle at least, because the list of practical problems is to long to fit in a comment. – Gilles Mar 20 at 10:00

You've pretty much got everything you need to answer your own question. Unfortunately this isn't a new problem either. Here's an article from the BBC in 2012 that describes your exact problem, questions, and concerns:


This article mirrors a lot of your same thoughts and has the same conclusion hiding between the lines: someone who calls you and asks you to verify your identity is doing things completely backwards. It absolutely trains people to have have habits (my bank says they called - let me give away my information) that make them more vulnerable to scammers in the future, and it's a poor way of doing business. Again, in the BBC article you get a clear impression of why the banks do it: it is a quicker and more cost-effective way of getting a hold of customers and stopping potential fraud early. On the face of it, that sounds like a good thing. However, as you point out, it will absolutely train people to have the wrong habits in the long-run, potentially increasing fraud.

It all boils down to a single unfortunate fact: just because banks handle our money doesn't mean that they are actually good at security or understand the broader ramifications of what they do. That fact is very obvious from the severe bungling that many banks still have in regards to passwords, as can be seen from any number of news stories (these are from 2016):

  1. https://threatpost.com/weak-bank-password-policies-leave-350-million-vulnerable-say-researchers/116574/
  2. Bad password policy at my bank
  3. https://www.securitymagazine.com/articles/86965-research-finds-bank-password-policies-often-weak

As I think you already understand, you can't just assume that these guys actually know what they are doing. So what should they be doing? In the end complicated problems like this will only be solved with a multi-faceted approach.

  1. Use an official app and to notify the customer through that. This actually has the best bet for quick responses. Unfortunately, there are probably a large number of customers that won't ever install the bank app which means that this can't be the only answer. Of course, you also have to make sure your app ecosystem is very secure: otherwise you just create a new avenue of attack for hackers. Moreover, you have to be extra vigilant against the potential dangers of stolen phones being a source of fraud.
  2. Calling people with an automated message and asking them to call you back on the number on the back of the card is probably the most effective all around option. It will reach the most people, and it will get them in the habit of the most secure method of contacting you. I would have the automated message say something like "please never give out personal information to unexpected callers who call you: always call the number on the back of your card if you have any problems". As you say, this gets people properly trained. However, there are some people who may ignore the message (I sometimes ignore phone numbers I don't recognize and I also don't have voicemail turned on).
  3. Text alerts are another good method of letting customers know there is a problem. Same thing: "We found suspicious activity, call the number on the back of your card ending in 1234".
  4. All of the above options still leave holes where the customers may not get back to the bank quickly. This is the banks biggest concern and why some banks (such as the ones in the BBC article) feel the need to send out automated calls in an insecure manner (i.e. asking you to verify yourself after they call you). Fraud that does not get resolved quickly costs the banks more money: there is a finite period of time when they can cancel the transaction before money is even sent, and if a card has been stolen the quicker they cancel it, the less fraud they have to deal with. Therefore, the bank needs to take action, and the sooner the better. As a result the best bet for a bank is a final step of freezing a card if fraud is suspected and a quick response isn't received from the customer. I've had this happen plenty of times: my card gets frozen because of suspected fraud, that forces me to call the bank, and then everything gets resolved. This is also an option that you have to use judiciously. People get irritated if you constantly freeze their cards for no good reason and ask them to call you to get it unfrozen.

Again, these aren't meant to be competing options: a banks best bet is to reach out to the customer immediately in a few different ways and establish communication over a secure channel (i.e. a well secured app or by calling the bank directly). Then you can ask them to verify themselves without worry, and you've taught them proper security best-practices. This also isn't particularly hard to do, or expensive to setup. Unfortunately, I doubt many banks operate this way.

But what about ...

This is worth a mention. The answer I gave is very straight-forward and simple, and is basically just: contact customers via phone/app, have them call you, and then straighten it out. This is such a simple answer that it is almost silly. There are plenty more options that we could come up with. How about the bank verify itself via some pre-shared secret? How about using some sort of OTP scheme? What about some form of pre-shared private-key encryption scheme? (that last one is practically gibberish). There are probably lots of ideas people could come up with to let a bank verify itself to a customer to get the process rolling and not force the customer to call the bank back. The underlying problem with all of these though is that it relies upon the customer to be able to understand and follow whatever the method is successfully a high percentage of the time. That is never going to happen.

The reason we know it is never going to happen is because it's hard to get people to follow even the simplest of advice: "Don't give out personal information to unsolicited callers! Just call your bank directly" or more generally "Don't reuse your password on multiple websites!". Banks aren't bad at security because banks suck: they are bad at security because WE are bad at security. Banks are limited in their options by what they can actually get their customers to do, which is not necessarily much.

I don't think there's any good way for an organization to verify themselves over the phone.

The primary reason is that consumers aren't familiar with how verification works, and could easily be fooled with providing some easily gotten information if the consumer expects the other party to verify themselves (Home address, first 4 digits of the credit card, etc). Even if you're a security researcher and not prey to this more simple form of social engineering, how are you supposed to be familiar with every credit card company or banks verification scheme, and whether it's "good" or not?

The implication here is that banks and credit card companies should never contact consumers and ask for any personal details. Fraud has been going on for a long time, and banks and credit card companies have dealt with it for many years without calling up consumers.

In other words, block the transaction, and let the consumer call YOU rather than the other way around.

Alternatively, send a text/email when a fraudulent charge is suspected and blocked. But even this might invite the potential for fraudsters to start emulating this behavior, and get consumers to contact them via a fake phone number in the text.

An organisation (particularly one where it is important to authenticate before passing too many details over) could leverage existing 2 factor authentication technology, like the one-time pad a user may use to authenticate access to a bank account or a phone application akin to Google Authenticator.

My bank's website uses this in 2 ways: firstly you simply generate a token to gain access to the site in the first place, using a little device that has the 'seed' locked to your account. This may be familiar to many as standard '2 Factor Authentication'. The other way it uses this is via a challenge/response method when I want to add a new account payee to the system: I enter the new bank details, the website then generates a 8 digit code. I punch this into the bank's device and it returns another 8 digit code - if the returned code matches what the website thinks it should be, that account payee is added to my list of authorised parties and I can then send money.

An organisation with sufficient will could utilise this in reverse - if the bank, credit card company, whatever calls you then you could give them an 8 digit number, they punch that into their systems which returns a response code. If that matches the response code that your device/phone app is displaying then you have effectively authenticated each other. It may initially be onerous for customers to use, but it would have 2 benefits; that of training people in good habits that may be of use elsewhere on the internet (and other untrusted zones) and also generating absolute confidence in the organisation.

There would be the proviso that this would need to be deployed properly with all the usual safeguards, code reviews, caveats and the like to make the system meaningfully secure.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.