Inherent security flaws of single-sign-ons; 2FA without passwords urged
Inherent security flaws of single-sign-ons; 2FA without passwords urged

Stressed out. Overworked. Simply exhausted. The 2017 workplace is taking a toll on workers, who are feeling more squeezed than ever, with more work (for the same pay!) and less time for themselves.  Or so it seems. According to one study, fully three quarters of workers on Sunday night dread going back to the office on Monday morning.

So you can't blame workers – and the people who manage them, themselves feeling the squeeze – for trying to take a few shortcuts. Logging onto systems, for example: The amount of time employees spend logging onto their computers, e-mail, user accounts, services, etc. varies and depends on the industry; a Ponemon study says that hospital workers could spend 200 hours a year just signing onto services, and admins in a 3,500 person company, according to another study, spend seven hours a week resetting lost, forgotten, or deprecated passwords.

That explains the popularity of identity management single sign-on solutions – where users can register all their accounts in a “clearinghouse,” and use a single password to gain access to all their accounts and services. Besides saving time, SSOs save users from “password rage” as well, as they no longer need to remember dozens of passwords – or remember to change them on a regular basis, as many employees require to ensure maximum security. Identity management SSO solutions such as OneLogin, SecureLogin, Imprivata OneSign, PortalGuard, and others have become quite popular of late – with good reason.

In order to pull this off, security has to be top-notch – but there is an inherent weakness in the model. Many SSOs use usernames/password as at least one authentication factor to protect the accounts of users (ie their other usernames/passwords). And experience has shown that where there are passwords, hackers are not far behind.

That, in fact, is what happened to OneLogin, one of the biggest identity management services. The company's databases were hacked in June, with hackers having access to customer information for as long as seven hours before the breach was repaired. Customers were instructed to change not only their OneLogin authentication information, but the passwords of the services they used their SSO to log onto. And OneLogin is not alone; others, like Uber, which uses an SSO, have been breached recently as well.

OneLogin hasn't announced how hackers got hold of user credentials, but the most likely suspect is spear-phishing – the root cause of 91 percent of cyber-attacks. In any event, we see from that hackers can spoof even systems with ostensibly high security. If the target is worth the effort, hackers will invest a great deal in making the breach happen – and with its hundreds of high-profile clients, OneLogin databases certainly constitute a very high value target.

But the same could be said of any of the major hack attacks in recent years – where hackers breached servers belonging to Sony, Target, the Democratic National Committee, RSA, or the 63 universities and government agencies in the US and UK that were said to have been hacked just a few months ago by the infamous Russian hacker Rasputin. In each case, compromised passwords were the method via which hackers got access to the systems where they did their damage.

If not passwords, then what? How can identity management services better protect their users? To answer that, we need to examine the nature of authentication – how a user proves to a system they are who they claim to be. Usernames and passwords are an example of the “something you know” authentication factor. Other methods of authentication examine “something you have,” and “something you are.”

Perhaps it's time to rethink authentication altogether, and eliminate password-based “something you know,” the Achilles' heel of authentication. That leaves “something you have” and “something you are.” Either of those could provide a safer way to connect – and when used in tandem, they could provide an almost foolproof way to keep hackers away.

Device authentication using password-less authentication via randomised code sent over multiple channels to authenticate a connection provides a much safer authentication method – and saves users from the trouble of having to remember even one password. In this scenario, a device connects with a server, generating a random code from a large set of possibilities that the remote server has prior knowledge of – and because there is a large range of possibilities, hackers would have almost no chance of picking the right one. To further enhance security, the code could be sent on multiple channels, reassembled only on the authentication server – making hacking of the connection almost impossible.

A practical example of this authentication system in use now is mobile push-based authentication. In this scenario, a user vets who they are via their device (“something you have”), by opening an app that confirms that the device is indeed in the hand of the user who made the request (if a user loses his or her device, it's likely they would report it, and connections from that device would be flagged). The authentication request is sent via multiple channels, with the code generated from within the app. Add to that “something you are” - biometric authentication via a thumbprint reader (common on Apple and other devices), and the likelihood of hackers being able to breach security drops drastically compared to standard username/password authentication.

The same one-two authentication punch could work in any number of authentication scenarios, with device-based authentication taking away from hackers their best chance of getting access to user accounts. If there are no passwords, there is no “what you know” factor for hackers to steal – and there's no point in running spear-phishing scams to steal passwords, making SSOs, and any other system to access a service or an account a lot more secure.

Contributed by Raz Rafaeli, CEO of Secret Double Octopus

*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media or Haymarket Media.