Hacker News Reader

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?

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

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.