Passwords are the seeming bane of cybersecurity practitioners’ existence. As credential theft—through password cracking or guessing, or successful phishing—allows criminals to easily compromise targets, security pros blame passwords: People use easy-to-guess passwords, people re-use passwords, people share passwords, and one and on. Passwords, alone, are not at fault.
There is plenty of blame to go around, but instead of playing that pointless pastime, it’s time cybersecurity teams looked seriously at alternatives to passwords, or minimally, how to make passwords better for the enterprise. Though some organizations are saying bye-bye to passwords, that world won’t become reality for most of us anytime soon.
Authentication expert and Chief Technology Officer at STEALTHbits, Jonathan Sander shares his perspective on the market today and how organizations can move past the dreaded user-input password for every site, system, and service.
Passwords, much to security practitioners’ dismay, aren’t going away quickly (though there are movements in that direction by a few progressive companies). Why do passwords remain the most used form of authentication, despite their inherent problems?
Passwords are still with us for simple, human reasons. As much as security pros fret about them, they still make sense to most of the people who are on the revenue-generating side of the business. The basic belief is: I have a secret, and as long as no one finds it out they can’t get my stuff.
When people see failures involving passwords, they are much more likely to blame other things. They think the person who created or used the password didn’t do a good enough job. They also tend to think that people who get hacked are bigger targets than they are, therefore the bad guys would have compromised that target, passwords or not.
Big problems with many of the password alternatives remain, too. Biometrics require special hardware and lots of integration. Fingerprint readers are getting better as they become ubiquitous on phones and with Microsoft building facial recognition into Windows. However, to use these authentication mechanisms across the board and not just on personal devices, the phones still need ways to interact with our laptops and browsers; even something built into Windows doesn’t magically become integrated with all your software. And today people are just as likely to be logging in—to work systems and data—to a device that’s not Windows.
The biggest thing the password has going for it is that every device on earth has a way to put a blank field in front of the user for her/him to type in a password.
On the flip side, organizations degrade password strength by setting password policies that limit the number of types of characters that can be input. Why? Isn’t that self defeating?
When I see a password creation field on a webpage where it tells me I may not use more than 8 characters, I smile. I smile because I can see the conference room where the frustrated security-conscious programmer or project manager lost a fight to someone in a different business unit who made the argument that having complex passwords will only lose the business customers and result in abandoned transactions when customers land on a logon screen. Not that I think it’s funny. It’s tragic in a way. But I smile because it’s so familiar to me to hear the old argument about security being a drag on productivity. That can be true, but there are also so many ways any application can avoid that today.
I marvel at websites that were developed so oddly that the built-in password-remembering features provided by browsers and third-party password managers can’t be used with them. I have, in fact, switched services when I’ve encountered companies that have made their site incompatible with password managers.
It’s equally frustrating to come across websites from smaller companies that choose to “roll their own” password security and expose themselves to prying bad guys and unhappy users rather than use Google, Facebook, or other ubiquitous social logins that have much stronger password policies.
How hard technologically would it be for organizations to make the leap to non-password authentication, and what are some other authentication alternatives that organizations could implement?
There are a lot of possible answers here. If we’re talking about an organization of decent size that has a team for security and operations, it’s likely to see that organization make a push with a number of technologies in concert. They would, however, need to select one standard authentication method for all services.
The most common non-password authentication today are things like smart cards (think: a card key for your tech life) and biometrics (e.g., fingerprint, face recognition, retina). The key point for these organizations is that their size and resources (scale reduces per person costs) allow them to pay the entry fee. As a result, these companies are able to ensure everyone is supplied with devices that will be compatible with the chosen non-password logon security. Everyone would be limited to laptop with fingerprint readers, for example. The company would also likely have a federated identity platform that takes much of the formerly password-driven logging on and have it run in the background with things like tickets, tokens, and other technologically complicated-sounding stuff that just means “passing around really long computer-only things” to do the logging in.
Now, even given the resources and capabilities above, there are going to be edge cases. Security teams will encounter business-critical applications that will not work with fingerprints or federation; they will need to engineer clever solutions. Warning: This is a danger zone. When faced with having to develop “aftermarket” solutions, many organizations sacrifice common sense to deadlines and make choices like storing text passwords in config files and such.
It doesn’t need to be that way, though. By working with vendors and spending the time up front, one can typically get these things to work reasonably well. Not to mention, for every customer that pressures a vendor to make their application work with federation, a standards angel gets her wings. Why? It’s only through organizations making the choice to take this plunge and pressuring vendors that the pressure mounts to a point where they are forced to act. That decreases the number of exceptions, lessens those edge cases, and means we get close to making passwordlessness more possible.
Of course, all of the above is feasible for organizations that can afford a big engineering effort and have the means to justify it. What about everyone else? For that matter, what about the consumer-facing technology world?
In large part, smaller organizations are adopting cloud faster than bigger ones. This is especially true for organizations that formed in the last 5-10 years. The cloud scenario is much better when it comes to authentication because it predominantly leverages consumer technology—the same stuff that lets you log in with Google, Facebook, and other social logins. In many cases, people using cloud platforms enjoy better logon experiences than their large, private-run technology peers because they are benefiting from the scale of the cloud providers’ operations. Cloud providers have the best teams in the world, and they are working to make things simultaneously seamless and as secure as is possible. The federation that engineers at other organization need to deploy is simply built into the fabric of the cloud. And most of these cloud platforms already know how to interoperate with phones and other devices to deliver a smooth two-step– or multi-factor– login that doesn’t involve a password people need to remember or manage.
Just like we experienced a shift ten years ago, where people had better internet speeds at home than at work, I think in the last three years we’ve seen a shift from having better potential security experiences in our consumer lives than at large organizations. Smart small organizations are taking full advantage of that, too.
