
Securing your users' authentication - sirodoht
https://www.stavros.io/posts/securing-user-authentication/
======
cal5k
Overall some good ideas - but I’m curious, why would SMS-based 2FA be LESS
secure than no 2FA at all for unsophisticated users?

Yes, SIM-jacking is a real threat, but it still requires directed effort on
the part of the attacker. It can’t be done en-masse.

I think the author also fails to mention techniques for detecting account
hijacking - Facebook and google for example both look at IP addresses and user
agent strings, probably along with other factors, to detect unusual account
activity.

~~~
StavrosK
> why would SMS-based 2FA be LESS secure than no 2FA at all for
> unsophisticated users

It's not about the user, it's about the attacker. If your account has
something worth bothering with, SMS 2FA is a way for an attacker to tell
support "yes, I own the phone number, I just forgot the password", which gets
the account transferred to the attacker more easily. It's a tradeoff between
that and a keylogger meaning game over, but, really, how hard is it to
implement TOTP?

> I think the author also fails to mention techniques for detecting account
> hijacking - Facebook and google for example both look at IP addresses and
> user agent strings, probably along with other factors, to detect unusual
> account activity.

That's a very good point, but those are more high-effort functions and only
allow detection after the fact, rather than prevention. They're definitely
great to have, but I wanted to show two simple features that can help your
users' security greatly while being easy to implement.

~~~
cal5k
What you’re saying about support indicates poor process rather than an issue
with SMS per se. All password resets should require email verification... so
an attacker would have to either compromise both the email account and the
phone number, or the password and the phone number.

It’s still not great - U2F is the way to go in my opinion - but good luck
getting my dad to use any of that stuff.

~~~
StavrosK
> good luck getting my dad to use any of that stuff

That's exactly the reason for the "poor process", most users have trouble with
these things and it's not uncommon for people to say "the email address I
signed up with is old and I don't have it any more, but I do have my phone
number". So common that support can't just ignore those, unfortunately, which
is how attackers get in.

That, and support staff are people and sometimes just want to help users, even
though you've said "absolutely no password resets without email verification".

~~~
cal5k
I understand the point of view, but it still smacks of weak process. Support
should not be able to do anything other than trigger an email reset link. If
they lost the email password, they need to take it up with their email
provider. Otherwise a manual process involving ID verification of some type
should be required to reset the email or phone number on the account.

I’m not saying doing this properly is easy, but I think “don’t use SMS ever”
is a bit extreme.

~~~
jschwartzi
Ideally the manual process should require ID verification live and in-person,
not over the phone. This raises the bar for an attacker from "has to have
access to the Equifax hacked database" to "has to get a decent fake ID made
before their appointment with the ID verification people."

~~~
cal5k
That's actually a really good point. I'm not sure what options are available
in the US, but Canada Post has a service for exactly this purpose:
[https://www.canadapost.ca/cpc/en/business/postal-
services/di...](https://www.canadapost.ca/cpc/en/business/postal-
services/digital-proof-identity.page)

~~~
derekp7
One way of implementing it in the US is what Paypal does, which is assume that
your bank has authenticated you, then deposit a couple small random amounts
that you have to report back.

Another way is to charge a fee for last-resort password resets. Charge $10.00
to the user's credit card, if the account info matches, and refund $5.00 in
two random small amounts for them to retrieve off their online account
statement and report those numbers back to you.

~~~
jschwartzi
What if the user's bank account is compromised using the Equifax dump?

------
C4K3
One thing not mentioned that I like is having 2FA be non-enforced for a set
period of time after enabling it. So you still have to enter it the next N
days, but if you set it up wrong or did something stupid you can disable the
2FA without authenticating with it within that period. The only place I can
think of where I've seen this is facebook.

That also prevents scenarios like the one given about the user never writing
down their 2FA details. (Though the recovery codes should not work for
enabling 2FA in the first place.)

Thinking about it, it might make sense to have it non-enforced for the next N
logins rather than basing it on time. Or perhaps make it non-enforced for the
first login that happens 24 hours after 2FA setup. I haven't seen it
implemented this way anywhere yet.

~~~
carbocation
This doesn't make sense to me. Either you confirmed that it's working (by
tapping your key or entering your token) or you didn't. Why prevent the user
from actually securing themselves in this fashion?

~~~
tedunangst
Users don't actually realize the implications of "you will never login without
this key" until they forget the key. That doesn't happen at the moment of
enrollment, but only the day after.

------
snowwolf
I'm beginning to think the only user friendly secure way of user
authentication is to go passwordless (except for the email account which
becomes the key for everything).

Setup an email account and lock it down - strong unique password, enforced 2
factor, etc.

Then on every site just email a magic login link.

The user only has to remember 1 password, they don't have to figure out how to
use (and trust) a password manager, they don't have to worry about a breach on
one site leading to all their accounts being compromised, and they don't have
to worry about whether some site has correctly implemented 2 factor, or has
side channel attack vectors to gain control of their account.

I actually attempt to do this where I can (set a randomly generated string as
your password and use the reset password route to get a magic login link). The
main problem I run into is where I want to be logged in to the site and their
mobile app and they log out all devices when the password is reset.

The biggest problem (and it is a big problem) is that if they lose control of
their email account or their email provider is breached, then they lose access
to everything. But right now that's already true (due to the reset password
route on many sites).

~~~
yogsototh
That was exactly what Persona was for. It was marvelous to use. It's a shame
that project hasn't gained sufficient traction and closed.

[https://developer.mozilla.org/en-
US/docs/Archive/Mozilla/Per...](https://developer.mozilla.org/en-
US/docs/Archive/Mozilla/Persona)

~~~
thx4allthestuff
This is in response to this comment, as well as the parent: Minimize your
trust in all-in-one authentication services. A password manager is reasonable
(still makes me nervous), because it makes it simple to have a different
complex password for every account. But taking Persona for instance, it claims
"free yourself from password management". Don't do that. When you free
yourself from managing your security, you are not secure. It really is as
simple as that. Security takes diligence. One could even say that security
_is_ diligence. The harder you make it for yourself, the more secure you are.

Regarding the possibility of locking yourself out of your accounts, one
suggestion that I have is to have one or more primary accounts that you use to
recover all of you less critical accounts, and keep the device used for
authenticating to those at home, preferable in a safe. Do not use this device
for your normal 2FA - only use it as 2fa and recovery for the primary recovery
accounts.

For the remaining accounts, use a separate device that you carry around with
you. This way when you eventually lose access to something, you'll have a
better chance of getting it back. In other words, a lost phone wont
necessarily turn into a catastrophe because you've lost your only means of
2fa.

~~~
StavrosK
This is wrong. Your email provider is already a SPOF for your security, since
anyone who owns your email de facto owns all your accounts. All you're doing
is removing another link from the security chain, i.e. the service
authentication method.

Essentially, you're replacing two (or a thousand) things someone can break
into with one thing someone can break into. That's much easier to secure.

------
techsupporter
I would immediately switch to a mobile phone provider and a financial
institution--even if they cost more and have fewer features--if these features
were implemented in one or both of those markets. Same for a domain registrar
(Gandi comes close but will still reset the password via support while leaving
2FA enabled, which I suppose is OK), but they have to be willing to deal with
someone with under 100 domains and under $5k/year in spend, which most
registrars who have this level of security (reasonably) don't.

Basically, I love that "do not let a password reset happen ever, ever" button.
I want to take full responsibility for the security of my access credentials
and NOT have to rely on a single-party app (I'm up to Microsoft, Entrust,
Symantec, Authy, and Steam standalone authentication apps on my phone; it's
annoying, just use OATH for them all, please).

~~~
cal5k
This. Most people don’t appreciate that banks are responsible for most of the
attack vectors that cause their customers to lose money.

No 2FA options. Passwords are used directly to connect your bank account to
third party apps rather than OAUTH.

For merchants, it’s worse. It’s 2018 and banks still allow Catch Me If You
Can-style NSF fraud, even for ACH/EFT payments. Poor KYC practices that allow
people to open accounts with fake identities. The list goes on.

~~~
dalore
A few banks in the UK send you a device which they use to challenge you with a
code, you put you card in and type the pin and then their code, and it gives
you back another code which you put into the website.

~~~
cal5k
Probably an RSA token. They're common for business banking but not for retail
banking, or at least not in North America.

------
jwr
> Do not use/implement/touch SMS-based auth, it is less secure than no two-
> factor auth.

Finally! I'm glad this is being said out loud. I am so tired of companies
implementing only SMS-based authentication. It's totally insecure and
inadequate!

