DEV Community

Antonin J. (they/them)
Antonin J. (they/them)

Posted on

A Bank Should Authenticate With You - And Vice Versa

I don't often see security-related articles on so I might as well get started.

A while back, I saw a tweet from Troy Hunt about having a bank authenticate with him over the phone as well as the other way around. I think about that tweet a lot and recently, I was in a situation where that type of thinking came in handy.

How we authenticate with services over the phone

You know how it is, you call your bank or your internet provider and they ask you a series of questions:

  1. what are the last 4 of your SSN?
  2. what's your address?
  3. First and last name on the account?
  4. Last 4 digits of your bank account number?

We provide some of this information, sometimes several times which gets frustrating.

It gives our bank, service provider, or whomever a reasonable-enough amount of trust that you are who you are.

Online on the other hand, you do this by providing your username/password. Or when you forget your username, you might get a reset email. Again, the service provider/bank trusts that your email is a trustworthy method of authentication.

(sidenote: some banks may require extra online authentication for password reset, like your Debit card information).

But how do services authenticate with us?

Let's start with online services. This one is easy. SSL.

Yeah, SSL. We trust that little lock in the top left next to the URL to tell us that we're not on a site that looks like our target site but is not (check out's certificate!). SSL works in a funny way.

Browsers trust certain certification entities and have their encryption (public) keys. This way, anyone that entity trusts, the browsers trusts as well. It's a chain of trust! When you initiate a connection, the browser checks against that chain of trust, and tells you if you're secure or not and who issued the certificate and for what URL. And so on.

Here's the thing, banks and other entities get a more secure SSL certificate which in turn displays their information directly in the browser! Go to your bank site and check out the address bar. You'll notice that you'll see the Bank's full legal name in the address bar! If you click through, you'll even get their address.

Easy verification that you're on the right site.

But how does a bank or a provider authenticate with you over the phone?

They don't, do they?

The problem with unauthenticated phone calls

Here's the thing. My wife's bank called her yesterday to verify something (a new account opening) and they asked her a verification question: how many accounts do you currently have open with the bank? She answered, it didn't match what the person over the phone saw on their screen. Red flag. BIG red flag. I seriously expected them to start asking more personal questions (full SSN, full debit card number, etc.).

We looked up the phone number online and received mixed reports. The phone number was listed as a scam. Other times, it was listed as an official number. Which was it? More importantly, it could've been spoofed! (just like you can spoof emails!).

So what do you do? We confronted the caller. We asked her, "How do we know you're from the bank?". And she was taken aback. She insisted she's with the bank.

How could we know however? How can a bank authenticate with us without divulging very important information? And how can we authenticate with a bank without divulging very important information to the wrong party?

Phone authentication methods

Eventually, the caller came up with an idea. She gave us the timestamp of when my wife applied to open the account. Day, hour, minute. Not super important information but it proved it was the bank. And we moved forward. The account mismatch (the original authentication question) happened because you can have an active but closed account. Or an inactive but open account. And we moved forward.

Here are some other methods I've seen:

  1. authentication PIN. You set one for yourself, and one for the service provider. During a phone call, you authenticate with basic info (address, name, etc.) and then exchange PIN numbers
  2. simultaneous online authentication. A PIN appears on your and their screen during a conversation. Upside is that this has to be triggered by the service provider
  3. unimportant but private information exchange. The caller telling my wife when she applied for an account was proof enough for example.

Have you had any similar experiences?

Whenever someone calls me these days, I immediately look up unknown numbers and I tend to be skeptical whenever the caller claims to know me somehow (like a bank, or electric company, or whomever). How about you?

Credit for cover goes to Tomasz Frankowski

Top comments (5)

lawrencejohnson profile image
Lawrence • Edited

Not sure if you're aware, but Chrome and Firefox ditched EV certificate displays just recently. They've argued that EV certificates are ineffective because users don't pay attention to it. Additionally, this can be circumvented simply by registering a business with the same name in a different state. This was proven by someone who re-registered as Stripe, Inc. and was able to obtain everything from business registration to EV certificate acquisition for just ~$100. Here's an article explaining the problems as well as why some of the biggest companies have dropped EV:

So, essentially users won't see the company name in their browser bar anymore (for Firefox and Chrome at least).

I can't speak much to the phone authentication bit. My bank never calls me, so I've never put much thought to it.

antjanus profile image
Antonin J. (they/them)

I thought I saw something about this! That's fascinating.

It looks like there aren't really any solutions to this problem then, are there?

lawrencejohnson profile image
Lawrence • Edited

Well, unless your computer has been hacked or your primary DNS has been hacked, all you really need to do is make sure the URL address matches the bank's URL. Let's look at a couple potential issues and how they are addressed in today's technology.

Click Jacking
This was the most common form of abuse for a number of years. Essentially, an email goes out with a link that looks like its from your bank, you click it and what you see is your bank's website. But, if you look at the URL, you'll notice it's different. This is an attack form where malicious users used to essentially iframe your bank's website within their page that had javascript that could monitor all of your keypresses. This doesn't really work anymore at least not with modern web browsers because banks (should) be using an HTTP Response Header called X-Frame-Options which explicitly tells the browser that the website is not allowed to be pulled into another website (with option DENY or SAMEORIGIN).

Host Entry or Domain Hijacking
If let's say your computer has been compromised, a malicious user can put an entry in your hosts file (\windows\system32\drivers\etc\hosts or /etc/hosts depending on your OS) that points the bank's domain to a different web server. In this case, you'd have no way of telling by the URL bar, but you'd likely see something that doesn't quite look like your bank because these hackers are usually either too lazy or too incompetent to make a decent replica). There's really not much you can do here if you don't take notice of the visual queues. Keeping your computer's defense up-to-date and making sure portable devices are not easily accessible would minimize this. I don't think it really happens anymore, but DoS attacks on DNS servers that would mimic this used to happen quite a bit 10 years ago or so.

Bank Website Compromised
There is always the possibility that the bank's website has also been compromised, but I'd say that the likelihood of this happening without the website going down is incredibly low. Maybe if you're using something like a small community bank that might not have the resources of the big banks, you might be at higher risk, but I'd still say it's pretty unlikely that a bank would forego the security needed to prevent this.

If there's one thing I would recommend, it's simply to never click links to your bank. If you get an email or text that asks for some action on your bank account, open your browser and manually enter the URL to get there.

simbo1905 profile image
Simon Massey • Edited

Identity on the internet is broken. Identity theft costs billions the figures are staggering. If you want to take the blue pill and live in ignorance with your identity owned by an advertising broker pretending to be a ”social network” stop reading now. If you want to take the red pill and learn what the crypto cure is to free your internet identity and cut identity theft losses by billons then read on.

💊 The solution is a purpose built public blockchain that is now live and backed by big players where you put your public keys. This is the sovrin foundation blockchain. You keep your private keys on any and every trusted device as its an open standard. The aim is to get open standards support into all platform wallets like apple and android holding the private keys in their wallet app just like they hold credit card IDs or airline tickets today. Now to ensure privacy you have hundreds or thousands of keys as they are small. Anyone with two private keys can prove to anyone else they control both by signing a message with both. You only do that when it's your choice to reveal to someone you are the same identity which can be helpful when it is in my interest to reveal that fact.

In a model where there is no central sign on service and the anonymous public blockchain database no-one “owns” your identity it is “self sovereign”. Looking up the public keys is a utility (public very fast blockchain). Private keys can be used to sign public keys and messages allow for a “web of trust” model. A credit card network provider can get physical proof of which public keys are controlled by which bank and sign that with its private key. Each bank can get proof of which public keys are controlled by companies who bank with them and can sign them. Company’s can get certain levels of proof of which customers control which public keys mainly by just generating a fresh key pair for the customer within the app. The app can write the public key to the blockchain and prompt the user to backup the private key to their main wallet. Let me give an example of how this combats identify theft and costs of identity assurance.

Lets say I want to do casual short rentals of my apartment via app company WaterBnB. WaterBnB have to ask a huge amount to register as a host to prove that i own my apartment. Fake host running a scam is the core threat to their business. Its a massive turn off to prove I own my apartment by standard methods it is the sort of thing needed to get a loan or credit card. Such credit checks are expensive and create massive risk when the credit rating agency like Equifax gets breached. Yet my bank knows I own my apartment they made me prove it to get a mortgage. My bank has to do strong customer verification as mandated by PSD2 and open banking so it knows when i open my app on my phone its me. So I have two apps on my phone, my bank who knows I own my apartment and WaterBnB that is willing to pay my bank a fee if I can just push a button on the bank app to push a signed message to the WaterBnB app to say ”i am a bank and yes the person who controls key X in your app happens to own the apartment you mentioned in your message”. Of course GDPR means I have to give explicit consent to my bank to release the information which I do with touch ID. The whole “who signed who’s keys” makes it possible for every party to trust one another. That is known as a “web of trust” or in this sort of scenario as a “trust framework”.

The open standard to do that sort if thing is W3C verifiable claims. How all that works with the sovrin blockchain isn't a secret the code code is open source rust written by well funded start ups.

simbo1905 profile image
Simon Massey • Edited

Oh back to the question: obviously to prove yourself to your bank and vice-versa they should push a notification to your app and you should respond to with touch id.