Multi-factor authentication isn't necessarily strong(sweharris.org)
sweharris.org
Multi-factor authentication isn't necessarily strong
https://www.sweharris.org/post/2019-06-09-softtoken/
36 comments
> no mention of U2F/FIDO
I came here to say this. U2F is my authenticator of choice, as I believe it is the most secure of all the alternatives. The only downside is having to manage multiple tokens on each account, but it is worth the trade off for the security it adds.
I came here to say this. U2F is my authenticator of choice, as I believe it is the most secure of all the alternatives. The only downside is having to manage multiple tokens on each account, but it is worth the trade off for the security it adds.
Nothing wrong with elaborating on a true thing to educate people. Leagues ahead of the usual fare, elaborations on opinions, exaggerations, and false statements.
But it's not educating anyone. A handful of people who deal with this particular area on daily basis are capable of understanding what the blog post is about.
Gist of the post is that if you have all the info needed to construct the secret used to extract 6 numbers - you can copy it around and have copies of the device that produces one time passwords.
Obtaining the shared secret and knowing the user's credentials is difficult to achieve (obtaining both). Even if it were to happen, you, as a service provider, have undeniable evidence that the user was negligent because leaking out the secret for MFA isn't exactly easy to do.
Data leaks due to malicious employees is often the attack vector in these cases. I'd argue that safe-keeping the data in a way that employees can't access it easily is what's actually a big deal in data breaches, not the actual mechanisms (RFC4226 and RFC6238 algorithms and their derivatives) that rely on keeping data safe.
Attacking a service that's been breached by leaking shared secrets is still extremely hard - you have to know the credentials and corresponding shared secret out of hundreds of thousands of leaked ones. Only way to attack the service is brute-forcing it. That doesn't go unnoticed.
Plausible attacks are extremely rare and difficult to achieve and edge cases that are possible only when extremely sensitive data is leaked aren't an argument against MFA.
The post we're commenting on mentions U2F - that particular approach completely obviates all the problems mentioned in this blog post, on top of being vastly easier to use to the end user (stick the token in the usb port, press the flashing button, job done).
Gist of the post is that if you have all the info needed to construct the secret used to extract 6 numbers - you can copy it around and have copies of the device that produces one time passwords.
Obtaining the shared secret and knowing the user's credentials is difficult to achieve (obtaining both). Even if it were to happen, you, as a service provider, have undeniable evidence that the user was negligent because leaking out the secret for MFA isn't exactly easy to do.
Data leaks due to malicious employees is often the attack vector in these cases. I'd argue that safe-keeping the data in a way that employees can't access it easily is what's actually a big deal in data breaches, not the actual mechanisms (RFC4226 and RFC6238 algorithms and their derivatives) that rely on keeping data safe.
Attacking a service that's been breached by leaking shared secrets is still extremely hard - you have to know the credentials and corresponding shared secret out of hundreds of thousands of leaked ones. Only way to attack the service is brute-forcing it. That doesn't go unnoticed.
Plausible attacks are extremely rare and difficult to achieve and edge cases that are possible only when extremely sensitive data is leaked aren't an argument against MFA.
The post we're commenting on mentions U2F - that particular approach completely obviates all the problems mentioned in this blog post, on top of being vastly easier to use to the end user (stick the token in the usb port, press the flashing button, job done).
> Even if it were to happen, you, as a service provider, have undeniable evidence that the user was negligent because leaking out the secret for MFA isn't exactly easy to do.
No. It's a shared secret, this means the accuser might also be the perpetrator as they too could leak the secret, through malice or incompetence. Maybe that's good enough to kick people out of a fan forum or something but it ought not to be enough in, say, a court of law.
The beauty of FIDO (U2F/ WebAuthn) is that it does public key crypto, and so there is no shared secret to get stolen. This makes it easy to reason about as a physical object. Does anybody have my private key? No, it is in my pocket, I can feel it there next to the wallet.
The same can't be said for my password (even if you've used argon2i and locked the databases down tight, every single time I log in your systems, and any employees with access to them, know the password for a fraction of a second) let alone PINs, TOTP secrets, messages sent over SMS or just hoping nobody but me remembers my mother's maiden name...
No. It's a shared secret, this means the accuser might also be the perpetrator as they too could leak the secret, through malice or incompetence. Maybe that's good enough to kick people out of a fan forum or something but it ought not to be enough in, say, a court of law.
The beauty of FIDO (U2F/ WebAuthn) is that it does public key crypto, and so there is no shared secret to get stolen. This makes it easy to reason about as a physical object. Does anybody have my private key? No, it is in my pocket, I can feel it there next to the wallet.
The same can't be said for my password (even if you've used argon2i and locked the databases down tight, every single time I log in your systems, and any employees with access to them, know the password for a fraction of a second) let alone PINs, TOTP secrets, messages sent over SMS or just hoping nobody but me remembers my mother's maiden name...
The problem is that it doesn't give people useful advice: everyone who reads it would be better off trimming it down to two paragraphs: instruction to buy a couple of FIDO keys and set them up everywhere, and the last thought about something being better than nothing suggesting that you setup TOTP when FIDO isn't an option and never use SMS.
There are many types of multi-factor authentication and randomly generated dynamic passcodes. There is time-based and counter-based (aka event-based) and combination of both. There is also MFA that have and don’t have seed registration.
There is MFA for corporate use and different ones for end users.
End user MFA often consists of TOTP, HOTP, FIDO U2F, WebAuth and SMS OTP. Each one of these have different security and usability profiles. SMS OTP has the lowest security profile but the broadest reach (no mobile app or token key necessary). Most mobile Authenticator apps support the TOTP and HOTP formats. But few of them are cross-platform and on multiple devices with auto-filling capabilities with an optional integrated password manager and Authenticator like SAASPASS. In addition most Authenticator apps do not have secure backup and restore capabilities. But the weak link in most consumer implementations of MFA is not the MFA but the automated account recovery process that is often susceptible to SIM Swap attacks (you are only as strong as your weakest link - irrespective of MFA usage). The SAASPASS mobile app has a Security Scan function that identifies duplicate and weak passwords and in addition services that have the Authenticator (TOTP/HOTP) format of MFA in the password manager.
As for corporates the choices of configurable MFA can vary from (from SAASPASS):
Manual OTP (offline supported)
Push Login Approval
Scan Encrypted Barcode
Remote Login 2FA (IoT)
Remote Lock 2FA (IoT)
Mobile On Device Login
Mobile Web URL callback
Proximity (offline supported)
App to App (with SDK)
SAASPASS Connect
SAASPASS system offerings:
SMS OTP
Email OTP
3rd Party Tokens:
HOTP tokens
TOTP tokens
FIDO U2F (offline supported)
Yubico OTP
Biometric Methods:
FaceID - iPhone
TouchID - iPhone
Fingerprint on Android
Facial on Android
Facial Authentication (offline supported on-premise)
-
Corporates should still use Access Control policies (even with the strongest of MFA implementations like Scanning Encrypted Barcodes).
Disclosure: I work in the IAM space and a reseller of SAASPASS.
There is MFA for corporate use and different ones for end users.
End user MFA often consists of TOTP, HOTP, FIDO U2F, WebAuth and SMS OTP. Each one of these have different security and usability profiles. SMS OTP has the lowest security profile but the broadest reach (no mobile app or token key necessary). Most mobile Authenticator apps support the TOTP and HOTP formats. But few of them are cross-platform and on multiple devices with auto-filling capabilities with an optional integrated password manager and Authenticator like SAASPASS. In addition most Authenticator apps do not have secure backup and restore capabilities. But the weak link in most consumer implementations of MFA is not the MFA but the automated account recovery process that is often susceptible to SIM Swap attacks (you are only as strong as your weakest link - irrespective of MFA usage). The SAASPASS mobile app has a Security Scan function that identifies duplicate and weak passwords and in addition services that have the Authenticator (TOTP/HOTP) format of MFA in the password manager.
As for corporates the choices of configurable MFA can vary from (from SAASPASS):
Manual OTP (offline supported)
Push Login Approval
Scan Encrypted Barcode
Remote Login 2FA (IoT)
Remote Lock 2FA (IoT)
Mobile On Device Login
Mobile Web URL callback
Proximity (offline supported)
App to App (with SDK)
SAASPASS Connect
SAASPASS system offerings:
SMS OTP
Email OTP
3rd Party Tokens:
HOTP tokens
TOTP tokens
FIDO U2F (offline supported)
Yubico OTP
Biometric Methods:
FaceID - iPhone
TouchID - iPhone
Fingerprint on Android
Facial on Android
Facial Authentication (offline supported on-premise)
-
Corporates should still use Access Control policies (even with the strongest of MFA implementations like Scanning Encrypted Barcodes).
Disclosure: I work in the IAM space and a reseller of SAASPASS.
A password manager and a handful of YubiKeys are pretty perfect. And they make for a good, simple advice to give to people if they're worried about security.
Yup. The target for MFA is not perfect security, but security better than passwords alone — the bar is quite low to start with. And all of the above techniques offer that to varying degrees.
I use strong passwords on all sensitive accounts, stored in a local password manager, with an authenticator app for those that don't accept my Fido2 Yubkey. Seems good enough to me.
I use strong passwords on all sensitive accounts, stored in a local password manager, with an authenticator app for those that don't accept my Fido2 Yubkey. Seems good enough to me.
If a workstation is compromised, having multi-factor authentication is useless for most services:
The real targets become the HTTPS session cookies and files on disk.
The real targets become the HTTPS session cookies and files on disk.
Even then the external services will still require first and second factors of authentication. If your workstation is compromised on an ongoing basis, then nothing matters. If its an one-time even, 2FA will protect the external services still.
Note that responsible sites do variations on IP / location fixation to reduce the value of exfiltrated session cookies and, of course, they're only valid for as long as you go between verifications. One really nice thing about FIDO is that it affords a low-pain “tap the button to confirm it's you” verification instead of a full password challenge.
The attacker can very easily use your workstation as a vantage point. Even used directly your browser and your SSH sessions.
It's makes it even more difficult to detect and trace.
It's makes it even more difficult to detect and trace.
Yes, which is a different threat than what was under discussion. Don't argue that we don't need seatbelts because they don't help when the driver is a kidnapper.
This is correct, which is why I am a big fan of FIDO U2F software like https://Krypt.co . This requires your phone which is essentially a second workstation to authenticate. So now you need to exploit two workstations.
No. Once you authenticated your sessions are the target.
These are great for operators in an ops center or devs at workstations. They’re not enough for managers on email or execs traveling across interesting borders.
What if they keys get lost/stolen or your house burns down. Do you keep a backup somewhere?
They mentioned having a handful of Yubikeys. The nice thing about U2F is that many providers support having multiple U2F tokens. For example Google, Github, and Gitlab do. Though others do not, for example AWS (last time I checked). So you can keep one or two on your keychain and keep others in different locations as backups.
One nice thing about the Yubikeys is that they can also support TOTP like Google Authenticator. So you could store your authenticator token on both your phone and on the Yubikey. Then use the Yubikey Authenticator app to get the code from the Yubikey. I do recommend requiring touch to access the code from the Yubikey. You most likely need to setup this up at the same time on both your phone and Yubikey. As most authenticator apps (but not all) don't let you have access to the secret once stored on your phone.
One nice thing about the Yubikeys is that they can also support TOTP like Google Authenticator. So you could store your authenticator token on both your phone and on the Yubikey. Then use the Yubikey Authenticator app to get the code from the Yubikey. I do recommend requiring touch to access the code from the Yubikey. You most likely need to setup this up at the same time on both your phone and Yubikey. As most authenticator apps (but not all) don't let you have access to the secret once stored on your phone.
> The nice thing about U2F is that many providers support having multiple U2F tokens. For example Google, Github, and Gitlab do. Though others do not, for example AWS (last time I checked).
Note that in the case of AWS it is not as bad as it seems, if you use your AWS account they way Amazon recommends. When you initially create your account, the credentials you make (email and password) have full privileges on the account. This is called the "root" user.
The root user can create other users on the account, and delegate to them most of the privileges of root (but not all). Amazon recommends that you make one or more admin user accounts to wield all the privileges that can be delegated, and then no longer use the root account except for those few tasks that can only be done with root.
Use the admin user(s) to create regular user accounts for everything else.
If you have N U2F tokens, make N admin users and associate each with a different token. Associate each regular user account with one of the tokens you carry on your key chain.
If you lose a token, use one of the remaining tokens with the admin account it is associated with to reset the accounts that were using the lost token and then associate them with one of the remaining tokens.
If you use U2F with the root account and lose its token you can do a reset of your 2FA setup via email and phone. You should only rarely need to use the root account, so its token should probably be one of the ones you keep in some safe spot like in your fireproof safe, not one you carry around on your key chain.
Note that in the case of AWS it is not as bad as it seems, if you use your AWS account they way Amazon recommends. When you initially create your account, the credentials you make (email and password) have full privileges on the account. This is called the "root" user.
The root user can create other users on the account, and delegate to them most of the privileges of root (but not all). Amazon recommends that you make one or more admin user accounts to wield all the privileges that can be delegated, and then no longer use the root account except for those few tasks that can only be done with root.
Use the admin user(s) to create regular user accounts for everything else.
If you have N U2F tokens, make N admin users and associate each with a different token. Associate each regular user account with one of the tokens you carry on your key chain.
If you lose a token, use one of the remaining tokens with the admin account it is associated with to reset the accounts that were using the lost token and then associate them with one of the remaining tokens.
If you use U2F with the root account and lose its token you can do a reset of your 2FA setup via email and phone. You should only rarely need to use the root account, so its token should probably be one of the ones you keep in some safe spot like in your fireproof safe, not one you carry around on your key chain.
The WebAuthn (and presumably older U2F) spec explicitly tells implementers to allow multiple keys and the protocol is designed to make this work smoothly.
I can kinda see AWS deciding your team administrator should take responsibility for enrolling new people etc. and so it's not necessary to support multiple keys but it means I don't enable it for my personal account, and I think it was a mistake to take this approach.
I can kinda see AWS deciding your team administrator should take responsibility for enrolling new people etc. and so it's not necessary to support multiple keys but it means I don't enable it for my personal account, and I think it was a mistake to take this approach.
How does Yubikey prevent against SSL spoofing?
Somewhat related. U2F, which Yubikey supports does help prevent against DNS spoofing. A DNS name which looks very similar but is not the true DNS name of the site you want to connect to. Something that a human might not notice or get confused by will be stopped by U2F.
Totally different threat. The lock on your car door won’t stop a tow truck.
U2F > TOTP > Any MFA > no MFA
Why? About 23% of the classified breaches in this data set are due to compromised valid accounts and any MFA would probably have prevented the breach. Often security isn't about out running the bear, it's about out running the person next to you.
data set: https://github.com/ericalexanderorg/SecurityBreach
Why? About 23% of the classified breaches in this data set are due to compromised valid accounts and any MFA would probably have prevented the breach. Often security isn't about out running the bear, it's about out running the person next to you.
data set: https://github.com/ericalexanderorg/SecurityBreach
New systems should implement WebAuthn rather than U2F.
Real security is hard work, because it requires imposing a burden on users, as well as diligent design to not then squander it.
Snake oil is profitable, because you can sell it in place of security while not making the users and developers do that work.
"Multi factor authentication" has trickled down into snake oil drip pan. That is what a "soft token" is. That is what text message / email verification is. That is what additional passwords are (eg "what is your favorite high school"). These "solutions" let companies check an "MFA" box with no substantive changes.
Not that I want any of these companies pushing "MFA" onto users to insist on more invasive methods either. I like that their bullshit SMS challenge goes to a cloud provider and pops up in a terminal ready to be pasted, because frankly that challenge wasn't wanted by anybody except whomever in their company needed to check that box!
It's Sturgeon's / Gresham's law all the way down.
Snake oil is profitable, because you can sell it in place of security while not making the users and developers do that work.
"Multi factor authentication" has trickled down into snake oil drip pan. That is what a "soft token" is. That is what text message / email verification is. That is what additional passwords are (eg "what is your favorite high school"). These "solutions" let companies check an "MFA" box with no substantive changes.
Not that I want any of these companies pushing "MFA" onto users to insist on more invasive methods either. I like that their bullshit SMS challenge goes to a cloud provider and pops up in a terminal ready to be pasted, because frankly that challenge wasn't wanted by anybody except whomever in their company needed to check that box!
It's Sturgeon's / Gresham's law all the way down.
It seems like “delegation” is the idea that would most help build on this. I’ve had assessors tell me that I had only a single factor in the cookie on disk after an authentication process that involved TLS client certs and an off-device OTP.
Another one is when the user puts the password manager on the same phone that receives the 2nd factor by SMS or in an OTP app. Now all the data is available and unlocked at the same time on the same device again.
Or when the user puts the OTP 2nd factor in 1password.
The best way to prevent that type of cheating is to enforce the user of physical keys like Yubikeys
Or when the user puts the OTP 2nd factor in 1password.
The best way to prevent that type of cheating is to enforce the user of physical keys like Yubikeys
> Now all the data is available and unlocked at the same time on the same device again.
This really depends on the device in question: if you're talking about an iPhone 3GS or later or an Android phone which is less than a couple years old, the device has pretty strict protections against cross-application access. It's still technically possible for a rooted device to compromise both but in practice that's not true for most users — call it 1.5-factor auth or something but it's a lot different than the classic desktop model where any running code has access to all of the data which you care about.
This really depends on the device in question: if you're talking about an iPhone 3GS or later or an Android phone which is less than a couple years old, the device has pretty strict protections against cross-application access. It's still technically possible for a rooted device to compromise both but in practice that's not true for most users — call it 1.5-factor auth or something but it's a lot different than the classic desktop model where any running code has access to all of the data which you care about.
If you have the latest iPhone/Mac, you can still get iMessages delivered to your desktop, easily facilitating a state in which (almost by default, given how eager Google is to remember your passwords) anyone who has access to your unlocked computer can log into your bank account just by visiting the bank's website and get immediate access to the 6-digit verification code that they text you.
Sending codes within a native app that exists only and specifically on your handset is a much more robust solution; I'd imagine the reason why it's implemented so infrequently is that its upshot is a lot of angry, frantic calls to tech support.
Sending codes within a native app that exists only and specifically on your handset is a much more robust solution; I'd imagine the reason why it's implemented so infrequently is that its upshot is a lot of angry, frantic calls to tech support.
> If you have the latest iPhone/Mac, you can still get iMessages delivered to your desktop … to your unlocked computer can log into your bank account just by visiting the bank's website and get immediate access to the 6-digit verification code that they text you.
What you're thinking of is the Handoff feature which allows your desktop to get access to SMS, not iMessage, and that's been recommended against for exactly this reason for many years. It's also somewhat dwarfed by the fact that SMS is inherently insecure and not a responsible choice for MFA in any scenario.
In the case of banks, they really need to be pushing FIDO since that protects against this threat and also the phishers who create very realistic sites including requests for SMS/TOTP codes.
What you're thinking of is the Handoff feature which allows your desktop to get access to SMS, not iMessage, and that's been recommended against for exactly this reason for many years. It's also somewhat dwarfed by the fact that SMS is inherently insecure and not a responsible choice for MFA in any scenario.
In the case of banks, they really need to be pushing FIDO since that protects against this threat and also the phishers who create very realistic sites including requests for SMS/TOTP codes.
If the system you are authenticating to is hacked then MFA becomes useless immediately.
This is like arguing that a seatbelt is useless because it doesn't help if someone plants a bomb in your car. You have to have a threat model to talk about security: in the case of MFA, it protects against someone getting your password without your knowledge — whether or not the remote site is compromised is outside of that scope. MFA does help in one scenario related to that, however: when someone compromises SiteA and gets your password which you also used on SiteB, they can't use it if SiteB has MFA setup — even if they compromised SiteA's MFA implementation. That's a pretty useful characteristic in an era where breaches are common.
Whats your point? That its pointless to use 2FA because of it not being a perfect protection for all scenarios?
In particular, it's about 5 years obsolete with no mention of U2F/FIDO, which avoids all of the problems mentioned and prevents phishing attacks from succeeding if they capture TOTP/SMS challenges.