Recently, I’ve gotten a handful of telephone calls from businesses wanting to talk to me about various matters that can reasonably be called confidential.
In each case, they began the call by giving the names of their companies; then, immediately insisted that to ensure my identity, they needed my date of birth.
What further astonished me is that these company representatives were shocked that I refused to provide my date of birth until I could verify their identity. Quite obviously, they were used to being taken at face value.
This is one of the problems I also see when confronting identity and security in programs: We tend to think of identity belonging to the client, but identity belongs equally to us.
Who are you? Who am I?
What I mean by that is, just as we ensure a client’s identity with a username and password, the client should also be sure that the application he is working with is also ours.
Mostly, we establish that fact with SSL certificates; if the signatures match against a certificate authority, then clearly the client is in the right place.
So when we consider website security, one of the things that needs to be foremost is, “How easy is it for a client to establish that yes, the site they are on is, indeed, my site?”
Don’t trust, do verify
Yes, SSL is probably the most effective tool to that end.
An exceptionally effective method is also the “security image”: A photo that the user selects, when signing up, that validates she’s looking at the correct login screen.
I’m not a fan of challenge questions, e.g., “What was your first pet’s name?”
It’s way too easy for the client to forget the answer provided. And depending on the question, a challenge might be easier to guess / answer than a correct password.
Of course, otherwise two-factor authentication is also two-way identity verification. Not only does it require the client to have access to something else; it requires your solution to correctly interact with that “something else.”
Admittedly, a cell phone or email address can also be compromised at the same time that someone’s credentials are compromised. But from the standpoint of establishing whether your website is legitimate, requiring 2FA is strong proof.
Clear about communication
We should clearly communicate to clients under what circumstances we will send them messages. And have a means for them to check whether a communication they received was from us / a way to report suspicious communications. And employ reputable partners to help us with those communications.
And to expect that we need to fully and reliably establish who we are before asking the client to prove who they are.
In short, our clients should know when they will hear from us, and we should be overt about positively establishing our identity if we do communicate directly to our clients.
That won’t stop phishers from trying to spoof us. But if we are explicit in establishing our identity, and warn our clients that they should be absolutely certain it’s us they are talking to.