It’s 2020. Are You Still Using Old-Skool Passwords?

Phishing-resistant methods and standards have arrived.

Published in

The Startup

13 min readJan 22, 2020

I was in Tokyo having dinner at the bar-counter of a Yebisu diner in the Ginza Corridor¹, nursing a beer and eating barbecue ribs with chopsticks, when an exhausted twenty-something sat heavily next to me and ordered a meal in English (well, in an American accent). We got talking and it turns out that he was a white-hat hacker working for Amazon.

I won’t bore you with our varied conversation about the world of penetration testing, intrusion detection etc. (perhaps for another day) but the key message that has stayed with me and that is relevant to our discussion is this: that when a hacker successfully cracks or finds a password, the latter for instance through a data breach, she tosses those passwords into a growing database. This database, essentially a dictionary of passwords, is what is used against new targets.

Passwords and human frailty

Unless you are blessed (or cursed) with eidetic memory, most of us mere mortals employ the strategy of using only a handful of memorized passwords, or variations of even fewer core passwords.

Since we have more logins to deal with than memorized passwords that we can (or want) to create, we re-use passwords, or slight variations, for different websites.

Now consider what happens when one of your passwords gets compromised because a service provider was hacked. If you use the same password for several different sites or services, all of those are compromised. Good luck remembering all the sites you have used that password with in order to change them.

But I use variations of the same password, cleverly substituting “@“ for “a”, “!” for the letter “l”, and I add a year after the text to make it different, you say. This pattern of substitution and extension (and others) is well known and it is trivial to write a script to expand the dictionary to include those passwords. In fact, cracking a password by exploiting those all-too-human strategies of creating “memorable-ish” variations is called “Mask attack”, and those tools are readily available on the internet. In the documentation of one such tool called hashcat, there is an ominous claim: “In Mask attack we know about humans and how they design passwords”.

So there are 2 lessons here. Firstly, to prevent a single breach (which may be beyond your control) compromising other websites or services that you also log into, each password has to be unique. So much for memorizing all your passwords.

Secondly, to prevent Mask and other combinatorial attacks, the passwords have to be as different from each other as possible. So much for coming up with the passwords yourself!

And let’s not forget that whatever solution you choose, you have to be able to retrieve and use those passwords easily!

The only viable solution is to use a password manager. These applications have come a long way over the last few years.² Modern password managers are able to generate random and unique passwords for each website you log into. They are integrated into your web browser though extensions, and often times with your desktop, and work well on mobile devices. You just need to remember a single password to unlock the password manager. Because there is only one master password to remember you can make it more robust and unlocking can also be delegated to biometric methods (like FaceID) if your devices have them.

If you swim in a particular ecosystem, there are even password managers built into browsers such as Chrome. Apple’s iCloud Keychain is core to its authentication services and is integrated with Safari. In fact, if you use the latest iOS and macOS, you will notice the system suggesting unique, strong, passwords each time to sign up to a new website.

Remember that the real utility of password managers is not only the storage and retrieval of passwords but the ability to suggest robust, unique passwords when required.

Multi-factor authentication: One-time passwords by SMS, voice, app and trusted device

What about the scenario where you have enabled, and use, two-factor authentication (2FA) or multi-factor authentication (MFA)?

Let’s say your favourite web service got hacked and your password there is compromised. 2FA/MFA will help prevent access to your account because a one-time password (OTP) is required in addition to your username and password if the system detects that a new login attempt is from an unfamiliar location, and/or being done on an unfamiliar machine.

However, if you have used the same, or similar password (see the section above on password similarity) with other sites that do not have MFA enabled, all of those other sites are compromised.

More importantly, 2FA or MFA is vulnerable to phishing, and indeed you may find that since the hacker knows your email address in addition to your password, you may be subject to spear phishing, where she targets you specifically and tries to take advantage of the known weakness of OTPs to gain access to your account.

One-time passwords and human frailty

What is phishing? It’s an attempt at getting you, the user, to divulge information that can be used to gain access to your online accounts (which includes web-services such as email, Dropbox, etc. and bank accounts). This is typically done by presenting you with a web-page masquerading as a bona-fide login or a page asking you to enter data to prove it is you behind the computer.

You may have received training from your company to spot phishing attempts, such as checking the URL of the presented sign-in page, and looking for inconsistencies on the webpage such as mis-spellings, but there are 3 factors working against us.

Firstly, phishing attempts are becoming very sophisticated. Today, phishing websites can look and behave like the real site: even the green lock next to the URL that you are trained to look out for could be green. The URL is the only element that cannot be spoofed, but hackers try to make it as close to the original as possible with long strings after the domain to confuse our brain in complexity. Google’s research showed in 2018 that well designed phishing websites had a 43% success rate!³

Secondly phishing has overtaken malware as the main threat on the internet and the number of phishing websites have been growing at a phenomenal rate. Google tracks unsafe websites and adds them to it’s database for the “Safe Browsing” service, hence we have an up-to-date picture of the threat (see figure below).

Number of “dangerous” sites tracked by Google. Source: Google Transparency Report

Thirdly, there are times when we are in a hurry, or in the middle of something else, and just want to quickly log in or prove our identity to a service or website, so as to get back to life. It’s times like those that we become less vigilant and more vulnerable to phishing. Good phishing campaigns are designed to inject a sense of urgency in the target, hoping that they’ll get flustered and not notice those subtle tell-tale signs.

Can you guarantee that if you arrive at a log-in page through a link from a genuine-looking email purportedly from your IT department explaining how an attempted breach was detected and all passwords have to be changed ASAP, that you would go through your checklist to ensure that the page you are looking at is bona fide? What if this happened while you were in line at a supermarket check-out, or in between meetings and running to the next one?

But won’t 2 or Multi-Factor Authentication protect me from phishing? Isn’t that what it’s for?

The vulnerability of one-time passwords to phishing

Sophisticated phishing sites are not just stand-alone data collectors. At the back-end they are linked to the genuine login page in real time. Think of it like when you’ve made a telephone call to your bank or credit card company. As you give information to the operator, he enters it into the system to gain access to your account. Similarly, as you enter your username on the phishing website, your username is entered into the actual page (which you do not see) in real time. This is called a “man-in-the-middle attack” (there is no “man”, it is all automated).

Now consider this: you first enter your username followed by the password on the phishing website, then a 2FA or MFA message pops up and asks you to enter the one-time password. Since behind the “man-in-the-middle” an actual login process is being initiated, the real website will send you the one time password by whichever means you have chosen: SMS, authenticator app, voice etc. You confidently enter the OTP into the phishing webpage and instantly, the hacker forwards that same OTP to the real page and gains access to your account.

The really devious phishing sites immediately re-direct you to the genuine website after login, so you are none the wiser. What the hacker has done is collect the cookie that the website sent to the computer logging in (in this case the hacker’s computer) tagging it as a trusted computer since 2FA/MFA was used. All the hacker needs from now on is just your user name and password, which she already has, to have a field day with your account at her leisure.

Efforts to thwart man-in-the-middle attacks

One of the tell-tale signs of a man-in-the-middle phishing attempt is the location of the computer seeking the request to log in. The man-in-the-middle computer connecting to the genuine web site is unlikely to be close to you (if you are the phishing target) or locations you have signed in from in the past.

Some 2FA/MFA one-time-password apps show you the location of the computer trying to log in. Apple’s 2FA system for iCloud, for instance, puts the location prominently on an OTP request pop-up. If you are paying attention, and not under the pressure of urgency, at this point you could theoretically thwart the attack. However, hackers could spoof the location by using VPN.

So, SMS and voice OTPs are the weakest, since they merely provide you with the password, compared to an authenticator app that informs you of the location of the requesting computer. But none of them are foolproof.

There is actually a method that stops a phishing attack in its tracks. More importantly, this method is independent of the state of mind or attentiveness of the user: the security key.

Security keys are phishing resistant!

Security keys are physical keys that connect to your computer or mobile device either by USB, bluetooth or NFC. Google’s Titan Security Key and Yubico’s various models are examples. They defeat man-in-the-middle attacks in a very simple and elegant way.

When you first set up an MFA security key method with a website (such as Gmail or Dropbox), you connect your security key to the computer by USB. A pair of cryptographic keys is created. Think of it like a pair of encoder-decoder keys that allow you to create and read text encoded with a cipher. One of the keys created, the public key, is sent to the website. The private key is kept on the security key. Every key-pair that is created is unique.

Later when you use the security key to log in, and an authentication is requested by the website, you activate your security key by pressing the physical button on the key. At this point your security key looks up and encrypts the URL of the login page you are on (along with other data discussed below) with the private key, and sends that back to the website’s authentication server.

Authentication is granted only if the URL is deemed kosher by the server. Since the security key was connected to your computer, it grabbed the URL from the browser you were looking at. Because the URL is the one thing that cannot be spoofed, this solution protects the user from man-in-the-middle phishing attacks. Indeed, Google claims that since deploying security keys to all of its employees, which numbered around 85,000 at the time of the report, none of its employees have been successfully phished!⁴

Other security key features

What if that message encrypted by the security key was hijacked on its way to the authentication server and the URL changed to the phishing website’s URL? That’s where the encryption comes in. In order to recreate the message, your private key for that website is required, which happens to be stored on the physical security key. If another cipher key is used, the authentication server will know because it cannot decrypt it since it only has one of the pairs of your keys which it received when MFA was set up.

What if the encrypted message was intercepted and used for a phishing attempt later? That is, what if the hacker somehow manages to intercept and store the encrypted message from an earlier bona fide authentication and tries to use it later? Each time a request for authentication is required, the server sends out a unique challenge code. This code is received by the security key and is encoded together with the URL, hence these messages cannot be re-used, defeating this method of attack.

Can’t a script be written to access the plugged-in key to create those authentication messages, especially if you keep your security key plugged in permanently? Part of the authentication process requires proof that a user was present. It does this by requiring you to press a physical button on the security key for example, defeating this method of attack.

WebAuthn API and security keys in mobile phones (finally!)

In order spread the usage of security keys, the World Wide Web Consortium (W3C) which recommends standards for use in web browsers and other technologies, adopted a standard for security keys called WebAuthn which it published in early 2019⁵.

What this means for us is that soon, we should be able to use security keys on the browser of our choice. For a long time, Google’s Chrome had to be used if you wanted to deploy a Yubikey or Titan Key out of the box.⁶ While Apple’s Safari 13 on both MacOS and iOS support WebAuthn, it will take time for Google and other providers to iron out all the issues. For instance you still cannot add a new security key to a Google account using Safari (v 13.0.4); although once added using Chrome, you can use it in that same Safari browser.

One advantage of a security key is that a single key can be used to authenticate multiple web services. In essence the security key creates unique cryptographic key pairs for each web service it is enabled on. Gone are the days of carrying multiple login devices.

However, that’s still buying and carrying an additional device.

In April 2019, Google showcased a new security key — one that is built into a mobile phone.⁷ Initially for a limited number of Pixel phones, today many phones are supported, even iPhones. The security key is essentially an app called Google Smart Lock on your phone that uses low energy bluetooth to connect with the computer you are trying to authenticate, just like a physical security key. Using low energy bluetooth means that you do not have to pair the phone with the computer which is demanding authentication.

How is this different from Google’s Authenticator App? Google Smart Lock requires the phone to be in proximity to the browser so that it can encode the URL, challenge code etc. just like a physical security key. Also, you have to press a button on the phone to prove that there is a human requesting the authentication. In contrast all the Google Authenticator app does is passively cycle through OTPs according to some pre-agreed algorithm.

The downside of using Google’s Smart Lock? It’s still very new and only few sites use it, such as Google services. In addition, there are still some niggling issues: for instance it can’t even be used with Safari on the Mac although you can enrol your phone successfully. This is not a problem though if you are a Chrome user, even on macOS.

What should I do?

If you have got this far, you would have hopefully learnt the following:

Do not reuse the same passwords for different websites, even though you may have varied them in some way, such as substituting “@” for “a”, etc. Hacking those passwords is trivial.
Use a password manager to generate unique and robust passwords for each website, and to remember them for you. The good ones try to make signing in as frictionless as possible on all your devices. This is the minimum you should implement for sites that do not have 2FA or MFA.
While still vulnerable to phishing, enabling 2FA/MFA is still better than not having this additional layer of protection.
To become resistant to phishing, use a security key. This technology will likely become more widely adopted now that W3C has standardized its implementation across different browsers. In addition, Google is making it easy by introducing a mobile app that works like a physical security key.
If you do end up using a security key, you should ensure that you have a backup method of authentication, such as OTPs. This is to prevent getting locked out of your account if your security key is damaged, lost or stolen. Alternatively Google’s Titan Security Key comes in a pack of 2. If you enrol both keys you can keep one stashed away as a backup. This is useful if you are at a high risk of phishing (politician, activist, etc) – disabling alternative authentication methods mentioned previously gives you the highest level of protection.
If you run a company or a team, you really should consider deploying security keys to remove the threat of phishing to your organisation. The more staff you have, the more likely a successful phishing attempt on the organisation as a whole. This risk is not trivial considering the 43% success rate for sophisticated phishing attacks.