On Feb 28, 2020, “USA Today” published an article entitled “Dear passwords: Forget you. Here’s what is going to protect us instead.”:
“We are moving into a world which we’re calling passwordless, which is the ability for our applications, devices and computers to recognize us by something other than the old-fashioned password,” says Wolfgang Goerlich, advisory chief information security officer for Cisco-owned security firm Duo.
Passwords are the scourge of Internet security. They are easy to forget, they are too many of them, and they are relatively easy to steal or guess. As the article states, “Turns out the only fans of passwords are hackers and identity thieves.”
As of March 2020, there are tools like 1Password that solve the problem — but only partially. Users get to set a single secure password that they can remember and use it to decrypt a vault containing all of their application and service passwords. An ingenious 2-factor mechanism makes it almost impossible for a thief to gain access to a 1Password vault, making it a very secure mechanism.
Part of my work as Chief Architect is application security R&D, which includes finding ways to reduce reliance on passwords. Over the years, I’ve made a few observations.
Passwords
I’ve seen applications with ridiculous restrictions on passwords. If you are signing up for an application account and it tells you your password should not be longer than a specified maximum number of characters or that certain characters aren’t allowed, you should be asking how exactly they are storing passwords in their system because chances are it is clear text.
Last time I had to reset my password with Slomins, the home security company, of all companies, they allowed an arbitrarily long password via their web application but limited it to 8 or 10 characters on their mobile app. It is not clear to me what technological problem they are solving: arguably, the mobile phone these days has more computing power than the webserver the web app is running on.
Password change policies
Any application asking their users to change passwords regularly is asking for trouble. In most cases, users pick a password that is easy to remember and change one character. Requiring users to change passwords frequently does not solve any security problems and only exacerbates them.
Two-factor authentication via SMS
Two-factor authentication is generally a good idea. I strongly encourage my readers to enabled 2FA across all services they use where it is available, no matter the mechanism.
Two-factor authentication relies on two pieces of information: something the user knows that they share with the service (I.e., a password), and something the user has (I.e., a smartphone, a secure token.)
Applications usually try to simplify the configuration of 2FA for most users by relying on SMS to deliver a short-lived one-time token to their phone in the form of SMS. SMS, however, is not always available and instant deliveries are not always guaranteed. Consider the following scenario:
You are on a cruise ship with Internet access but no SMS service. You get an email alert from your credit card that there was an unauthorized charge. You open your credit card app and not only does it ask you for password, it sends you an SMS as a second factor that you never get. You are left unable to access your account to address the problem and you are forced to scramble in the middle of your vacation to find a way to make an expensive phone call to your bank from international waters.
The right way to implement the second factor is to generate the one-time passcode on their mobile phone itself, or using a device like Yubico. Ultimately, the user should select the one-time passcode mechanism that they prefer.
There are enough choices out there — 1Password, Google Authenticator, Microsoft Authenticator, and others. The trick, however, is that to use them, the user needs to be reasonably sophisticated and knowledgeable. I think the ultimate second factor is the smartphone itself, and the authenticators should not be dedicated apps at all.
Password-less authentication via email or SMS
Some services try to be smart. They offer a password-less authentication model by asking the user to enter an email or phone number and sending them either a link or a code. The user then has to leave the application, find the message, copy the code, go back to the application, and paste it.
Password-less authentication via email or SMS is an awkward experience. It doesn’t work with password managers like 1Password, and it doesn’t secure the user’s data any better. All it confirms is that someone attempting to log on has either the phone or access to the email address.
Session expiration and frequent authentication on mobile
Even the most basic modern smartphone supports locking with a passcode or a gesture. More sophisticated smartphones like recent iPhones also do biometric authentication of their owners, like the face or fingerprint recognition.
What security problem is being solved by requiring a user of such a device first to unlock the phone, and then enter another, distinct passcode to unlock the application?
Social logins
I find that most applications offer social logins out of the goodness of their hearts to spare the user from having to create yet another password. Social media companies are under no obligation to you to secure your users and their credentials.
Applications should not encourage users to use their social logins as single sign-on. It’s not a guarantee of security for anyone.
Solving the conundrum
So, how do we make our user’s lives easier? We need to learn from Apple.
Apple does not require any more authentication than whatever is required to unlock the phone (biometric and passcode) to open extremely private health data or to view Apple Card information. What security problem are you solving that Apple hasn’t solved?
As it stands today, the real challenge is the initial identity verification. There is no single good way for, say, a banking application, to confirm the identity of the user opening the banking app for the first time on their smartphone other than with shared secrets like passwords and keywords.
After initial identity verification, the application should not require the user to re-enter their credentials if the phone is secured, and only requiring biometric authentication on rare occasions to confirm sensitive operations such as viewing credit card numbers of health records. If the phone is not secured, traditional session expiration rules should apply while encouraging the user to secure their phone.
The Dulin Report 