Hacker News Reader

Comment by jmuguy | Hacker News Reader

It drives me nuts when sites insist on using SMS or Authy instead of TOTP for 2FA. I get that some users might not be sophisticated or motivated enough to setup TOTP but when somewhere like Cloudflare insists on ONLY using Authy it makes me want to look elsewhere for service.

I've spoken to AT&T numerous times to see what extra steps I can take to secure my account against any changes. So far all that's led to is an eight digit number I have to provide when making any changes. Better than nothing, but something tells me their CS people would still cave too easily to social engineering.

View on HN

but when somewhere like Cloudflare insists on ONLY using Authy it makes me want to look elsewhere for service.

Cloudflare supports Authy and Google Authenticator (or any TOTP-compliant app): https://blog.cloudflare.com/you-can-now-use-google-authentic...

Thank you, I didn't know this, and it was something I was judging against CF for years. It makes me a little uncomfortable though that there aren't any offline recovery codes in the event the TOTP device is lost/stolen/etc

EDIT: as pointed out below, there is one briefly on the QR dialog, it's not a separate sheet you generate/download like GitHub/Google/etc

Be careful using 2FA on CF. I got locked out of my account because I reformatted my phone and hadn't kept backup codes. That's my fault, not CF's. They wouldn't accept email verification or uploading a html file to the root of my domains to grant access.

But here's the kicker: Cloudflare were happy to grant access if I could recall some previous name server history for some of my domains. Information that is in the public domain and can be purchased as a report.

Customer Support (well, humans in general) is the biggest threat to security, unfortunately .. :(

This one comes to mind, I think I remember an Amazon-related story along the same lines .. https://www.macrumors.com/2012/08/05/apple-support-allowed-h...

You may not even need backup codes. Just save a copy of the google authenticator setup QR code. It's just email/key, when decoded.

Thanks for writing this. I will talk to the support team about it.

There is a backup code.

"Your second-factor backup code is 'blah'. This can be used for manual setup, and is necessary to recover your account in case your mobile phone is lost or stolen."

What annoys me most about using SMS for 2FA is that it's useless if you ever travel to another country and don't have global roaming enabled.

SMS receiving is free everywhere, it has nothing to do with data roaming and generic roaming - available on the network - has been free since I had a mobile phone (~17 years).

Doesn't make it a the best option though.

That must be based on a very limited experience. In the U.S. it was common up until maybe 5 years ago for carriers to charge 10c per sent and received SMS. And that's still true unless you have a plan that explicitly makes them unlimited and free (which is admittedly most of them).

If your carrier is e.g. AT&T you have to sign up for an international service plan or you simply do not receive text messages. The typical thing my friends do is pay $10/day for the international day pass. Crazy. It's why I bought an phone without carrier lock, and when I get to a country just buy a SIM (UICC) with pre-paid texting and data, I don't even car about voice. Since my U.S. number is google voice, the texts come in as data, and local texts are cheap or free in that country.

Charging for receiving is mad. Are they chargign for receiving letters as well? You can make someone pay by sending sms to them, this is crazy and evil.

Don't know where you are from, but with the company and pre-paid plan I use, I can't receive an Australian SMS from my Australian phone when I'm not in Australia.

Europe, and even in China I was able to receive sms. MMS is a different story.

China has great mobile infrastructure that, at least from a user perspective, is better than what Australia has to offer (it's significantly cheaper and covers significantly more area).

I still can't receive SMSs from my Australian phone when I visit there however and always pick up a local SIM for the duration of my visits.

It's not about pricing, it's just that my Australian provider has no agreements with carriers for other countries.

I don't know who downvoted this; I'm stating facts.

You may be surprised to learn that in some countries (particularly the Land of the Free) the standard, for some weird reason, is for sending SMS to be free and receiving them to be paid.

What ? Definitely no true if you travel cross continents.

I thought Authy was TOTP?

I think it is.

https://www.twilio.com/docs/api/authy/authy-totp#production-...

It is, I use it

it's TOTP, but it backs up your TOTP codes in the cloud and will happily restore them to any device that can receive SMSes to your phone number.

a feature, that saved my ass after i forgot my phone in the rain (yeah, not smart).

I'm torn between the insecurity of the cloud and being thankful that all accounts could be restored with ease.

Unless you disable multi-device

It's largely TOTP. IIRC, it's just an additional AND at the end (and selecting 7 digits, not 6).

There are other companies like Google that first require you to set it up over SMS before they allow you to add a security token.

They do that to prevent account farming. Google is one of the very few companies that refuses to accept my VoIP DID number for 2FA, because they know it's not a "real" number. A wise move, considering that SMS-capable DID numbers only cost a few dimes when you buy in bulk.

They're not insisting on 2FA-by-SMS since you can immediately disable it after you prove that you own a valid phone number and thus is much less likely to be a spammer.

This is unfortunate. They presumably do it because people routinely lose 2FA keys, but rarely lose their phone number, and so requiring an SMS backup first cuts down support requests.

What it means in practice is that when we train people to set up 2FA, we have to teach them a somewhat elaborate dance of enrolling their phone number, adding the U2F and TOTP authenticators, removing their phone number, and then making sure they don't have a recovery phone number set.

I just consider them as not supporting 2FA. I'm looking at you, Namecheap. My domain registrar not having two-factor authentication in 2017 is preposterous.

I have run into several occasions when I need to urgently sign into my NameCheap account only to discover that the SMS 2 factor auth is not working. (I hit the button to send the code and nothing comes through)

Very convenient!

Namecheap does have 2fa... https://www.namecheap.com/support/knowledgebase/article.aspx...

Do you mean because they only support SMS based 2fa?

Considering they have a drop down menu it's possible they just have not had time to develop the other options?

As of January, 2014 Namecheap said[1]: "Currently, we only accept SMS authentication but Google Authenticator, Authy, and TOTP authentication are planned."

More than three years seems to me a long development cycle to add TOTP support. Am I being disingenuous to think they just don't care?

[1] https://blog.namecheap.com/account-security/

It's not that they don't care. It's that $CARE_AMOUNT < $ESTIMATED_COST.

That formula would immediately shift if a high profile website registered on Namecheap encounters an SMS hijacking.

So what's the meaning of caring then? If they aren't implementing the feature, it means that they don't care. It doesn't make a difference to me that they care a bit, just not enough to actually implement it.

TOTP codes are straightforward to bootstrap. It's not rocket science.

At scale the cost of implementing a feature as wide ranging as 2FA is well beyond the tech cost. A basic TOTP implementation can be coded from scratch in an afternoon[1].

The real cost is testing to make sure a code change like this doesn't break existing users and estimating the additional support overhead of dealing with users that lose their two-factor devices.

[1] Seriously the RFC is very straightforward and readable: https://tools.ietf.org/html/rfc6238

I agree, I wrote an implementation in an afternoon for work, and that was back when there were no libraries to do this for me.

Yep, SMS 2FA just makes my account less secure, therefore it doesn't count as 2FA.

It only makes an account less secure if you can get into an account without knowing the password just by having the 2FA code (through customer support). Social engineering is also a problem with TOTP 2FA.

I'll take poor SMS based over none at all.

https://lolware.net/assets/images/netregistry.png

I won't, SMS is worse than nothing.

A quick question for someone who knows little about 2FA. If I were to use my Google Voice account as the SMS number does that make it any more secure since it's not tied to a SIM card?

It still goes through a bunch of providers, including Google, so it would not be as secure as TOTP. If the provider doesn't use it as a replacement for the password (ie you can't change your password using it), it may be more secure than just the password alone, but I don't trust it.

thank you

We should be just satisfied with TOTP, to be honest. It's just 6 digits by default, and unless you've got good anti-bruteforce protection, it can be broken in a matter of hours to days by just trying enough combinations. I'm sure Google and other big players do a good job of blocking these attacks, but would you trust every TOTP implementation of the web to get that right?

Why do you need a 2nd password when using TOTP? and if you don't then TOTP-1FA should be good enough...

Reply on news.ycombinator.com