Multi-factor authentication isn't necessarily strong
sweharris.org
sweharris.org
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.
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.
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).
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...
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.
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.
The real targets become the HTTPS session cookies and files on disk.
It's makes it even more difficult to detect and trace.
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.
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.
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.
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
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.
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
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.
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.
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.