
Multi-factor authentication isn't necessarily strong - hsnewman
https://www.sweharris.org/post/2019-06-09-softtoken/
======
acdha
The material in here isn't terribly wrong but it seems like an elaborate way
to say “you should have a threat model when making security decisions” and
“RSA is overselling their software tokens to the point where legal authorities
should investigate”.

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.

~~~
lonelappde
Nothing wrong with elaborating on a true thing to educate people. Leagues
ahead of the usual fare, elaborations on opinions, exaggerations, and false
statements.

~~~
maxymajzr
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).

~~~
tialaramex
> 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...

------
notlukesky
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.

------
blfr
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.

~~~
sebazzz
How does Yubikey prevent against SSL spoofing?

~~~
graton
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.

------
ericalexander3
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](https://github.com/ericalexanderorg/SecurityBreach)

~~~
tialaramex
New systems should implement WebAuthn rather than U2F.

------
mindslight
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.

------
brians
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.

------
zimbatm
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

~~~
acdha
> 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.

~~~
leroy_masochist
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.

~~~
acdha
> 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.

------
rasengan
If the system you are authenticating to is hacked then MFA becomes useless
immediately.

~~~
acdha
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.

