Securing your users' authentication | Hacker News Reader

Securing your users' authentication

stavros.io

104 pointssirodoht50 comments

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.

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

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.

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

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.

This is just offloading the responsibility for security to the email provider. If their security is weaker than yours, you've disadvantaged your users. If you have an easy way to do ID verification, that's great, but that's not always possible.

Isn't email still the skeleton key? Most popular email providers can be secure enough for many uses. We could imagine e.g. a bank that hands out OTP devices to its high-value customers who bring passports to the bank, but that's overkill for many situations.

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

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

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.

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

That would be a good service for the USPS to add, though unlikely that they would provide it for the same reason they no longer provide Notary services: in the US identification is generally considered a role for the state-level (it's a wonder we don't have state-issued passports and there is a federal agency involved in that much).

That said, I wonder if it would be useful to encourage more usage of Notaries for ID verification in such matters. There's no easy digital API to request a notary's involvement (yet?), and there are complications between states/countries in what powers/abilities/checks/balances notaries have. But it is an ancient business practice to ask "please get this form notarized with valid ID", so why not just update that for contemporary needs?

Also, if we’re talking about high-security applications, it’s really not enough to focus on authentication. Detecting account hijacking can prevent an attacker from executing some damaging action (transferring money, buying stuff) even though the credentials might be compromised. I think user authentication needs to be a holistic process that looks at a bunch of factors.

> how hard is it to implement TOTP?

I've been asking BofA and Merrill for awhile. Apparently for the institutions that control my money, "very."

If you're a dev, there are a lot of implementations, or code examples online.

Here is an open source Java example of some of the algorithm impl, and an HTML / JS example to test out in the browsers.

https://github.com/inversoft/prime-two-factor/blob/master/sr... https://github.com/inversoft/prime-two-factor/tree/master/we...

My comment was made in the hopes that someone can interest financial institutions in real 2FA.

The expense is in added support, not in software development cost.

I don't think this is correct for most uses of SMS currently. 2FA (MFA) is on top of password authentication, not to the side of it. If you forget your password, 2FA does nothing to help you out.

I think what you are talking about is "SMS password reset", which is a different beast. And it also sounds like you are talking about SMS based identity verification for customer service representatives. If you are only using SMS for identity verification in your CSR workflow, that is a broken workflow.

In FusionAuth (https://fusionauth.io), we implemented SMS MFA that only works after the user has successfully put in their password. Therefore, the attacker would need their password and a clone of their phone. While this is still possible, the threat surface is quite small.

What is FusionAuth? Is this like an Auth0 or something like that?

Similar to Auth0, except you can run it anywhere (dev-box, bare-metal, VPS, Docker, etc). It has all the features that most applications need. Plus, it's free for unlimited users.

Adding a security measure knowing that it is insufficient or is relatively easily circumvented, just because, 'hey, it can't hurt!' is really dangerous.

You MUST ensure that ALL involved parties are aware that the secondary measure is a 'bonus' and CANNOT be used to consider the entire system safe.

For example, let's say someone calls the helpdesk and says: I forgot my password, but, I can answer the 2FA thing for you. Maybe the helpdesk operator makes a reasonable judgement here: That's pretty good, the party on the other end of the line sounds pretty convincing, okay, I'll reset their password for them. Whoops: Now JUST a SIM jack gets you in, whereas if there was no SIM based 2FA whatsoever, the helpdesker wouldn't have reset the password.

Another example: During a security audit, some pentester figures out that there is no rate limit on trying passwords, there are no logs or any other detection for figuring out that some system is trying a ton of passwords, and a password check is very fast (let's say no bcrypt or similar system in place either) and the server is hosted in a virtual datacenter, and it is not too difficult to spool up a (virtual) server in the same place: That would allow an attacker (because latency has now been reduced to next to nothing) to have guessed many billions of passwords over the past 6 months. The team analyses this potential leak and concludes that, due to the existence of the secondary system, there's really no need to go public or otherwise spend any further resources. However, you don't even need to be all that capable or motivated to do a targeted attack here; SIM jacking is easy enough, and getting a server under your control that is latency-wise extremely close to the target is pretty easy for, say, AWS ec2 servers. Had the 2FA not been there, this issue would have received more appropriate attention.

Generally, I advise to never add a security feature just because 'hey, can't hurt': It confuses the authentication pipeline and muddies discussion and understanding. Either a feature is adding real security, and any circumvention of said security is definitely something that should be escalated, or, it's useless and should not be added.

With that mindset, I'd prefer to just get rid of SMS based 2FA vs. keeping it around (I'd _strongly_ prefer to fix it and make it 2FA that isn't sim-jackable, for example by using TOTP protocol, but let's hypothetically posit that that's somehow not an option).

It's more secure than single factor no doubt...

Other good replies in this thread — I will just add some examples of why SMS-based 2FA is less secure than pretty much any other 2FA method.

Example 1: at a first approximation, 100% people have their phones set to display the content of SMS messages even if the phone is locked. So gaining the physical possession of a phone (even for a brief time) allows the attacker to gain access.

Example 2: taking out a SIM from a modern phone takes less than 10 seconds. Again, at a first approximation, 100% people have no PIN on their SIM cards. The card can be inserted into another phone and used to gain access immediately. Note that while you might notice that your phone is missing, you might not immediately notice that your SIM is missing.

I'm not even considering other (more complex) ways of redirecting SMS messages.

And what I hate most are services which allow you to use SMS or a phone number to recover/unblock your account. That makes it so much easier for attackers go gain access. The only way to recover your account should be with recovery codes. If you lose those, there should be no way to recover.

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.

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?

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.

I see it as an improved method of confirming that it's working. For power users it may be pointless, but for the average user who probably has never used any kind of 2FA (perhaps besides SMS) it makes them go through the real motions of authenticating with 2FA before turning it on for real, which will prevent many stupid user mistakes (which I admit I've done myself once.)

I think it's a major improvement for ease of use in exchange for having a small once off window where you're not protected by 2FA.

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

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

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.

This is all well and good for a tech savvy user. But for the user who "instead of properly setting up their authenticator app, they brilliantly used one of the ten backup codes to finish their 2FA setup (and didn’t even store the rest), thus locking themselves out of their account immediately.", this will all be too complex for them.

We need a solution that is actually usable by the masses that maintains a reasonable level of security.

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.

So all you've done is move the problem to the email account. The original article is about how hard it is to balance usability and security so having 2FA on email creates a problem.

No. I’ve isolated the problem to the email account. You only need to set it up once with a provider who hopefully has the resources to do it properly (like gmail). Rather than having to do it for every website who all decide to do it different ways so it’s never a standard process. And many doing it badly, forgetting to disable account recovery if 2 factor is enabled.

If that provider is one of the major ones, you an also use Oauth2 to sign in, no magic link needed. Also its more secure.

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

On a technical level, most likely it's that their backend considers all cookies generated prior to the reset to be invalid. In that case, a solution could be to "steal" (from yourself) the one valid cookie that came out of the reset, and place it into your various devices/browsers. So long as they don't hash the user agent string into it or something (which I assume they wouldn't, since the validity of the session survives browser upgrades).

Desktop browsers (having dev tools) will let you get the cookies and add said "stolen" cookies. Unfortunately, you'll have a hard time with mobile apps.

I like this method so much, that I wrote a Django library for it:

https://github.com/skorokithakis/django-tokenauth

For a demo, see https://www.eternum.io/ or https://www.pastery.net/.

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

Exactly, I have a password database that is backed up in three places, including offsite, a backed-up hardware security key where I keep my TOTP credentials/U2F, and I take good care of them. At this point, it's more likely that your support will get socially engineered than that I will lose all my credentials.

This is a minority of users, certainly, but users should have the option. The "recovery key" option is a very easy way to prove you own an account and get it reset, even if you're a less-savvy user.

This doesn't fix the problem because it only works for a small number of people who understand how to do this. The OP is about the difficulty for the provider to have a system that is secure but that doesn't confuse users.

In many cases, asking a user, "do you want to disable all password resets ever on this account?" you might as well ask, "blah, blah, blah" because a load of people won't know what it means and the semi-technical folk will not understand it well enough - basically goodbye registrations.

Blizzard also has their own stuff. OATH for everything would make things so much easier. I cannot understand why they wont simply do that.

What i hava a problem with in regards to account recovery options is that some services require you to also have enabled sms based 2FA in addition to TOTP or similiar as a fallback. That defeats the whole purpose of non-gsm based 2FA. The whole construct is as insecure as sms based alone, the TOTP part is entirely useless. at least make it optional if you think some users need it.

FWIW Blizzard is 8-digit TOTP, they just don't make it obvious/easy to use your own stuff.

Here's a command line tool I wrote that will generate a TOTP authenticator for you, with QR, base32 secret, etc:

https://github.com/jleclanche/python-bna

You can use it with andOTP, KeepassXC, 1Password etc.

Hey Jerome! Nice utility, but you may want to point people to andOTP (at least for Android devices), it's maintained (FreeOTP is unmaintained, I think) and much more featureful:

https://play.google.com/store/apps/details?id=org.shadowice....

Updated. :)

If anyone is looking to test out their own impl or a third party, this web based JS impl allow you to set up and test with a secret and a 6 digit OTP.

https://github.com/inversoft/prime-two-factor/tree/master/we...

nice, thank you

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.

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.

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

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

Reply on news.ycombinator.com