Every day we hear of yet another data breach. One common reason is because of password compromise. The problem may be because of successfully phishing; it may be due to password re-use; it may be due to brute force attacks; it may just be weak passwords.
So it is now considered best practice to use some form of Multi Factor Authentication.
To quickly summarise, MFA is 2-or-more of the following factors:
- Something you know. Typically this is a password
- Something you have. Maybe a physical token of some form
- Something you are. This is form of biometric, such as a fingerprint
You don’t repeat the same factor, so two passwords isn’t MFA.
Factor Strength
Ideally these are also unique; it’s not just “something you know”, it’s “something only you know”, “something only you have”, “something only you are”.
This unique part isn’t a strict requirement, but it feeds into the strength of a factor. A PIN that is only 1 digit long (“something you know”) isn’t very strong ‘cos there’s a 1 in 10 chance of guessing it, and the attacker may have multiple attempts. A 4 digit PIN on a debit card may be considered weak, but we can mitigate some of the weaknesses by limiting the number of attempts.
That debit card I just mentioned? It’s a factor; “something you have”. Ideally only you have it… but the card stripe can be copied so the card duplicated. This is what card skimmers do; they read your card data and store it, allowing for a copy to be made.
We need to consider how strong a factor is and what mitigations can be put in place before deciding whether it’s suitable to be used as part of an MFA solution.
Human factors, of course, play a large part in evaluating the strength which is why passwords are frequently panned; they can be stolen in so so many different ways!
Even strong solutions aren’t perfect.
A very common solution to MFA is a hardware token such as the RSA SecurID.
Typically you also need a PIN to go with the token number; the combination of the PIN+token is the authenticator.
These are a relatively strong form of “something you have” because they are close to impossible to copy; the magic numbers can’t be extracted from the device.
I say “close” because there are ways around it. Is the provider securing the magic number properly? In 2011 RSA suffered a breach that exposed the seed tokens meaning that millions of SecurID tokens were compromised.
But user factors also apply. One I’ve seen, before, is to just point a webcam at it and expose that webcam to the internet. Now you can get to your token from anywhere in the world without carrying it. Of course this is bad security, but people do things to make life easier.
We understand this and accept that some people will be silly.
When similar solutions are totally different.
RSA also provide a “soft token” solution.
From their brochure:
First introduced in 2002, RSA SecurID Software tokens are cost-effective, convenient, and leverage the same algorithm as the RSA SecurID key fob style token. Instead of being stored in hardware, the software token symmetric key is secured on the user’s PC, smart phone or USB device.
This sounds great! All the benefits of SecurID, using the existing authentication infrastructure, and without the cost of shipping around physical tokens. Why wouldn’t you want this?
But is the solution of similar strength?
A softtoken requires a number of inputs to work:
- The Device ID. This is used as a form of encryption key to protect the seed.
- The token seed. This is the primary material used to generate the tokens
- A PIN. This is a shared secret known to the user and the authentication server
- The current time.
- The algorithm. This is pretty much public knowledge
If you know all of these things then it’s possible to copy this token.
Here is where management of the solution is important.
The RSA SecurID software exposes the Device ID. This is needed to request a token in the first place. The user knows the PIN. The algorithm is known, and the time… well, we better know the time!
So the security of the solution depends purely on the handling of the token seed. And, unfortunately, older solutions (still in use) can tell the user about this via email. It typically looks like a URL of the form
http://127.0.0.1/securid/ctf?ctfData=3D200040994....
The number after ctfData is the important part, and this is protected
by the deviceID.
With this it becomes perfectly possible to import the same data into the
stoken software:
% stoken import --token http://127.0.0.1/securid/ctf?ctfData=3D200040994...
This token is bound to a specific device.
Enter device ID from the RSA 'About' screen: blahblahblah
Enter new password:
Confirm new password:
(Leave the password blank to not encrypt the resulting config file).
Next we can store the PIN
% stoken setpin
Enter new PIN:
Confirm new PIN:
This information is stored in a simple config file
% cat /home/sweh/.stokenrc
version 1
token 200040994......
pin 12345678
The “token” value isn’t the one from the email; it’s been “unprotected” using the entered Device ID. And, no; that’s not my PIN!
And now the moment of truth:
% stoken
31636434
And that matches the number displayed on my phone. Without needing my phone or entering the PIN or anything else.
This is a simple configuration file that can be copied to 100 different places and all of them will work identically.
That’s the easy way to get the data. There’s always the hard way; compromise the device, steal the contents from the phone’s storage.
So, clearly, SecurID soft tokens have different security characteristics to a hard token. The data can easily be copied. We no longer have a strong “only” on the “something you have”.
We have effectively reduced the strength of SecurID to that of a TOTP solution such as “Google Authenticator” or “Authy”.
But it still may be good enough
You can mitigate the problem to some extent; newer SecurID softtoken solutions can perform auto-registration and hide the token seed from the user (if you don’t see it, you can’t copy it!). You could have an out-of-band management process that generates new seeds every week (to limit the exposure of stolen/lost keys). We can require rootkit detection processes.
There are ways of making it stronger. None are perfect, but security isn’t about perfection.
But even with the weakness of the old system, we have raised the bar to an attacker.
Google did a study that showed that even the relatively weak SMS based 2FA protects against all automated bot attacks and 96% of bulk phish attacks.
On-device authenticators prevented 99% of phish and 90% of targeted attacks.
So is SecurID Softtoken strong enough, even with the gaps I’ve identified? Probably!
Conclusion
MFA is around gaining a level of confidence that a person authenticating as a user is the person authorised to authenticate. If they have a password and a softtoken value then you have more confidence than if they have a password, alone.
It becomes a risk management evaluation as to how much money needs to be spent to raise the bar; going from 0% to 90% is pretty easy; going from 90% to 95% costs a lot more.
You need to decide the cost/benefit point for yourself. No solution is perfect.
As for me, authy works sufficiently for my personal stuff; if an attacker really wanted access to my account then this would probably work!
