What Risks Are Left?
First of all the user might be using a weak, guessable password. Something like their name, strings like “123456”. Sometimes this might be backed up by meaningless tips suggesting that they should use one capital letter, one special character and one number which effectively transforms passwords using the “password” -> “Password1!” pattern.
Moreover, some users might have the same password for multiple services. If the password for the other website gets compromised, access to our website gets compromised as well.
Last, they might become victims to a phishing attack. A cracker might send them a link leading to a website that looks like a login to some service they are using that does not actually log in to this service but steals their credentials.
Hardening the Authentication – Password Managers and 2FA
1. Password managers
Many of those risks can be easily mitigated using proper password managers. They can generate long, random passwords unique for each website. Additional advantage is the possibility of connecting such manager with website so that when we see login page, the password manager finds password to it in database. Below you can see this in action for my current bank.
This can serve as a protection measure against phishing attacks. If I try to visit a page that only pretends to be hosted by my bank, the password manager will not find a password and this will be a strong warning not to enter the credentials.
Some browsers have built-in password managers that automatically take care of creating a strong password when we register in a new service. Below you can see Safari proposing a password for facebook.
It’s a matter of how much you trust your browser and synchronization among its desktop and mobile versions if this solution is for you. Personally I need something that would allow me to enter passwords outside of the browser (like encrypted disk volumes) so I need an independent password manager nonetheless and I like to switch my browser from time to time. But for cases like logging into gym to sign up for training I find it OK.
2FA stands for “Two Factor Authentication”. The idea is to require something user “has” among with something they “know” (like login/password data). This helps to prevent logging into a service even if a password to it has been discovered. What “they have” can be an email account, mobile phone, authentication app and so on.
In former two cases service sends a one-time code to the user via different way of communication than the login form. This can be not entirely true for email since there is a risk that the email account also has been compromised. SMS on the other hand is vulnerable to SIM card duplication and unfortunately sometimes it’s ridiculously easy to obtain a copy.
The atter case is a bit more itneresting since there is no direct communication between the authentication app and the service we are logging to. An example can be Google Authenticator.
It works by sharing a common secret that is remembered both by the app and the service. This secret is used later to compute a unique code valid for a short period of time that is displayed to the user by the app and needs to match in the service in order to authenticate. In order to change this token simultaniously both service and an app synchronize with the same time server.
We already have a strong, uniue password, know the purpose of 2FA, but we still are not protected against phishing attacks. Sure, password managers do help, but some users really do want to hurt each other. I remember Adam Heartle’s from zaufanatrzeciastrona.pl talk on this issue, who said that when one person saw an antivirus protecting them from some malware, they used a second computer to run it (it was a malicious email attachment). And if I suffered from some heavy brain damage the chances would be that even if my password manager didn’t match website to the entry in database, I would still manually copy login and password and become a victim to such attack.
The answear to this problem is U2F (Universal Second Factor). This method is based on the following flow:
- The U2F device stores some private key and a public key corresponding to it.
- During registration process the public key is sent to the registering service (the one user will log into in the future) together with its checksum and nonce. The keys are composed of service’s url, some secret that only the U2F device knows and the nonce – random number.
- Service sends the checksum, nonce and challenge to the client (user’s browser). This is just another random number.
- U2F device takes this data to calculate private key once again and checks its checksum.
- If this matches challenge is signed and resent to the server.
What is really cool is that it can bring the amount of phishing attacks to zero. The key must know that the challenge came from a valid server and the server must know that it received the response from a valid key.
This post summarizes most important ways of further hardening the authentication proces and fullfills somewhat my thirst for knwoledge in the way U2F works. I hope I’ve convinced you at least to use password managers and to use 2FA preferrably as U2F.
I know that enhancing one’s security is a process (it took me months to migrate my passwords to password manager and introducing proper 2FA methods is a still ongoing process) and that there’s always something to be done. Personally I am still convincing my nearest and dearest to follow my steps when it comes to password managers and maybe we’ll all buy ourselves some U2F keys on some Black Friday (since I also need one).