Hacker News Reader

Comment by kalleboo | Hacker News Reader

Two-factor authentication terrifies me.

For my bank from my country of origin that I maintain, I get a battery-powered RSA token. From that I can generate a mobile 2FA token in an app that I can use to log in for day-to-day transaction. If I lose the devices with the 2FA token, I have to pray that that CR2032 is still alive or I lose access to that account until I spend thousands of dollars on international flights (replacing the battery resets the device)

View on HN

I lost access to my bank account in UK because my token ran out of battery. The only way to fix this is to fly to London and show up in person. This is a pain because I can't even figure out my account balance - and this is something I must report for U.S. taxes.

Similar thing happened here to my wife (US, bank in UK). "We don't send those out any more, just use your phone". But... a) my wife didn't have a phone at the time (not one capable of running their only supported version of their app) and ... one of the signup questions was asking about bank balance (or... recent transactions, etc) - but... there's been no recent transactions and we don't know the balance because... we can't log in.

This was... ~ 6-7 months ago. I'm unsure what options are left, or... if my wife sorted it out (she did recently get a newer iphone, and that may have been able to get it sorted).

Similar experience here, but when using the mobile app.

My bank in my country of origin also used to use a token, but they changed to a "token app" in the phone about 10 years ago.

However to authorise this app I had to use an ATM. Since this bank only has ATMs in one country, this means I couldn't lose or trade my phone.

After I moved I kept a super old iPhone in a drawer only for this bank, but at some point the app kept threatening me to upgrade, otherwise it would stop working in the next version. But I couldn't upgrade because my decade-old phone was too old for the new version.

Since even blocking my debit card via phone required using the "token app" (something incomprehensible to me), it became too risky to keep this account.

At this point I had no recourse but to close the account.

The Bank of America app only lets you install it if your Google (or presumably Apple) account country is set as America. I am abroad but needed to use the app. I had to create a VPN on an American cloud instance and connect my phone to it so that I could set my country to America and install the app.

I had similar problems. For one, the LloydsTSB banking app is not available outside the UK App Store, so I had to keep a second iPhone with a UK number while living in the USA just so I could have the app installed.

There's a youtuber/streamer I sometimes watch, an American living in Ukraine until the war. She fled to Portugal when the invasion started, and paid for an item with her credit card enroute. This triggered an automated lockout from the card suddenly being used abroad.

The bank's bureaucracy advised her to unlock it she needed to go in person to her home branch in Ukraine (which has a decent chance of being a pile of rubble given her neighbourhood was hit by shelling in the time after she left).

2FA can be "backed up" by either using a 2FA soft token program that allows for backups, like 2faone or Authy, OR by the services themselves granting backup codes for emergencies. For my threat profile, I have no problem storing my 2FA backup passwords/codes in my master password safe. If that is compromised, I was doomed anyway.

If a service does not allow the use of "generic" TOTP ala Authy or Google Authenticator, AND it does not allow for one time use backup codes, then I do not use 2FA with that service unless required. My main bank forces the use of their own built in 2FA (Symantec VIP on the backend) which pisses me off. My work uses Okta and RSA. Oh well.

Pretty much all the banks in my country (Sweden) use a local national digital ID system called BankID which is issued by the banks themselves to mobile devices as a second factor and gets tied to your national ID number (and once issued by your bank is used by your bank, other banks, the government for tax filing/address change/receiving official mail digitally instead of physically, signing contracts for e.g. apartments, and even retailers to address auto-fill).

All the banks I know of require 2FA in the form of either a physical, battery-powered RSA token (sometimes in the form of a EMV card reader) or a valid BankID.

The assumption is you live in the country and can just visit a branch if you have any trouble, which works for 99% of customers. But not for me.

python-vipaccess might interest you. I used it for both PayPal and eBay at one point. https://github.com/dlenski/python-vipaccess

IMO the primary reason they're pushing 2FA is for the people who are careless enough to eg log into their personal email on their work computer.

I wish there was an exam you could take that would get you a "computing license" that you could show to bypass a lot of this stuff.

Enforcing 2FA is the most effective security rule ever created. Vastly more effective than password rules, rotation, user education, any anything else ever tried.

With 2FA, almost all of the traditional attacks are impossible and the only one left is specially crafted fake login pages.

Meh.

You're right when you're dealing with large groups of people which is exactly what I said in my original comment. If you understand these issues passwords on their own are fine. 2FA has some nasty edge cases that make it very easy to lose access to your account (which is what everyone in this thread is talking about.) So as always you're balancing security and availability. For some people the proper balance means just password authentication makes sense.

The best IMO would be client side certificates but no one except maybe Github supports those.

No, passwords on their own are never "enough" for you to be secure as you only control your side of the equation. You don't know if the place you are storing it is doing so in plain text, storing a decryption key right next to it, etc. Even if you are careful (I know what you said above), the network you are on could be compromised despite your best efforts/knowledge. Or any number of other things that could make it trivial for someone to gain access to your account in the event they gain access to simply the password.

I don't claim 2FA is perfect, it has its own host of issues as is being discussed. But it isn't just for "the masses that don't understand how to make strong passwords or how to be secure". Certs are good, but they need to be made simpler than they are now for the very people you claim 2FA is for or they won't be adopted (one of the reasons they aren't more ubiquitous, IMO). And some certs implementations have issues with account recovery as well if you lose access to them.

It's a really hard problem that you do a bit of disservice to when you dismiss it as "just a problem of the plebes".

> You don't know if the place you are storing it is doing so in plain text, storing a decryption key right next to it, etc.

Any service that is storing passwords in plain text is probably not implementing 2FA in an safe way, either.

That really isn't an argument against my point, that it's very hard to verify what is happening once you click submit with your password.

Password-only authentication still has its uses. I don’t want to use 2FA when I’m logging into a website I’ll use once and never again and does not have any private info about me, maybe to post a comment for example. Or try a service they are demoing.

Im glad news.yc and reddit don't require email to sign up...

Those are totally valid use cases. In no way was I saying everything had to offer 2FA. Just pointing out that it is not just for those that don't know how to craft strong passwords or those that practice poor security hygiene, that it is a useful option to have when security is important.

It can also reduce fraud reports -- if a transaction was authenticated with 2FA then it's less likely the fraud claim is legit and more likely it can be tossed.

> careless enough to eg log into their personal email on their work computer.

Can you explain why that is an issue?

Employers keylog. How safe are those logs, for one?

A lot of work computers MiTM all traffic using a corporate certificate authority. A middle box tears apart the requests, and repacks it using its own cert.

> eg log into their personal email on their work computer

Can you elaborate on the specific risk here?

One bank I have set up in a new country set me up with their mobile app and that mobile app is the only way to access the bank. They have a web-app, but login to the web app can only be authorized from mobile. At least an existing install can be used to authorize installs on new devices. Got it on 3 devices installed just in case.

It shouldn't. You can just use authy, which allows you to onboard devices using your phone number, and then a password to decrypt the existing entries. If you use 2fa with authy, remember that password, and remember your password Manager's password, something like this scenario won't ruin your life.

With 'old' banks (and other systems that use these tokens) with a physical token, you can (often?) not do that.

My bank doesn't use TOTP but rather the Swedish BankID system for 2FA

You open yourself up to a much more devastating attack vector though: sim swapping.

If someone can convince the human at the other end of the line that they are you and that they lost their phone, in most countries and with most telco's, they will be able to get up and running with a new SIM with _YOUR_ number.

Resettting your Authy password via SMS is then just a step away.

Yeah i stopped using authy the first time a token was automatically seeded this way (may have been another way, but it was automatic and I didn't like it because I was also using the seed on my Pebble which i could then no longer do with this method). i prefer manual control over stuff like that and definitely don't want it assuming some magic is okay.

I think you’re being a little paranoid:

https://support.authy.com/hc/en-us/articles/360036077534-Aut...

“How do you derive encryption keys from a Backup Password?

We use the National Institute of Standards and Technology (NIST) recommended algorithm PBKDF2.”

Oh no that's fine, I just didn't like the initial seeds for a new 2fa enrollment being magically transferred to the authy app without my control/intervention. See https://authy.com/guides/twilio/ and note that it's not the usual "scan the qr code". The seed is transmitted straight to authy, which, safe or not, takes away control from me to add that same seed elsewhere.

I don't believe you are correct. I believe an existing installation of Authy is required.

>Can I reset my Backup Password?

> Yes, it is possible to reset your Backup Password by tapping on Change Password in the Backup Password area of the Settings menu within the Authy app. You will have to ensure all 2FA account tokens are decrypted on your device (No red lock icons). Once a user resets their Backup Password on a device, all other devices with the Authy app for this user’s Authy account will require entering this new Backup Password.

https://support.authy.com/hc/en-us/articles/360036077534-Aut...

https://authy.com/blog/understanding-2fa-the-authy-app-and-s...

The fact that they disable SMS authentication for accounts that they deem "high profile" says it all.

Last time I looked, I don't recall there being a backup password (essentially a local encryption). If you SIM swap someone, you'll pull down their OTP seeds, but won't be able to read them without that code... so that's a slight improvement at least.

BUT! They have a recovery process. So the risk profile is convincing the telco to SIM swap + lodging a support ticket with authy (that takes 24 hours to complete).

You can reconfigure Authy to require an existing device to let you in as well. It won't prevent the "absolutely everything is fried" case but it's better than most password managers.

If someone tries to use SMS/Voice to activate Authy on my account it just gets rejected.

Pretty neat for everyone that uses two phones regularly! If you leave that other phone in your desk drawer for several years though, I wouldn't be surprised if it doesn't work...

Authy requires a backups password to restore, or least it can be configured to. Of course, hopefully you remember it in a disaster situation. If you have a cloud password manager you can end up in a chicken and egg situation.

Looks like the backup password can be reset too by support, so while that present an additional barrier to the attacker, it doesn't sound that effective.

I am, on the whole, more concerned about self-DoS via fire or similar disaster than I am about sim swapping.

Other people's threat models will certainly differ though, and whether mine is well chosen is certainly open to question.

I've got a 2fa backup code in a DNS entry on a free hosting provider. I've got another hidden in some public source code, masquerading as an example encryption key. There's all sorts of digital hiding places these days. Self signed certificates (serial number, subject, issuer, etc), http headers, etc. Other possibilities are accounts with determinate passwords (eg. a hash of your name) that are used only to store your secrets.

No, you need the password to decrypt your 2FA codes. There's no password for logging in. You're just incorrectly assuming how it works.

https://support.authy.com/hc/en-us/articles/360036077534-Wha...

>If you lose your Backup Password, you will not be able to decrypt your 2FA tokens from Twilio Authy servers and access them within the Authy app on any other device (Eg: If you bought a new phone to replace an old or lost device). If you still have access to the original device on which you set up the Authy app with your 2FA account tokens for the first time, you can follow these steps to re-configure your Authy app on a new device.

Authy admins cannot reset this password. It looks like they can disable encrypted backups, but not decrypt your shit.

So basically all an attacker should be able to do is gain control of your account, delete your old 2fa codes and then add his own.

How does that square with their blog post about understanding the risks of using SMS [1]?

>5 – 2FA Recovery

>Imagine this scenario: You installed Authy, lost your phone, your laptop is broken, and the bitcoin price is climbing like crazy. You need to login to your crypto wallets, but you either enabled multi-device and all the devices with Authy are not working or accessible, and your account has been tagged high-risk, and you can’t use SMS to install a new Authy app. What are your options?

>Authy has a 24-hour account recovery process. By providing your phone number to Authy Support, we can go through a set of security processes to re-enable your ability to install Authy. Some users may question why account recovery isn’t instantaneous, but our goal is to 100% protect our user’s accounts against an attack or hack, and that includes our recovery process. This 24-hour period allows us the time to perform the necessary due-diligence to verify that you are who you say you are. We’d be doing a disservice to all if we were to rush this process.

[1] https://authy.com/blog/understanding-2fa-the-authy-app-and-s...

Adding a device to your account and encrypting the tokens are distinct unreleated steps.

When you enable encryption, they derive an encryption key off the passcode you provide, encrypt the tokens, then store them on authy's cloud storage. The encrypption key is never sent to authy's servers, and only stored on device. When you add a new device, you're prompted to enter the passcode, which generates an encryption key and decrypts the tokens.

How is support going to decrypt the tokens for you? They need the password, which they don't have.

You use support to add a device to your account, and then you use the password to decrypt your tokens.

Granted, an attacker could gain access to your authy account and then delete all your tokens, but that's different from being able to log in and start using your TOTP 2fa codes. You should also have recovery codes written down somewhere in the case this happens for all your services.

I literally just restarted everything from my previous post with more words.

Then their blog post doesn't make any sense. The answer to their scenario is that the user is fucked and they are locked out of everything.

>You installed Authy, lost your phone, your laptop is broken, and the bitcoin price is climbing like crazy. You need to login to your crypto wallets, but you either enabled multi-device and all the devices with Authy are not working or accessible, and your account has been tagged high-risk, and you can’t use SMS to install a new Authy app. What are your options?

Google authenticator will also backup your keys to the google cloud so installing it on a new device will just work. You'll, of course, need to remember your google account password and not set it up with authenticator as the second factor.

(I don't know much about authy, I only use it to access m sendgrid account, but I didn't like the fact that it used SMS for setting up or restoring an account.)

Last i knew, Google hadn’t updated Authenticator in years. Maybe it’s a mature product and doesn’t need updating, but given Google’s history of dropping projects, I moved from Google AuthenticTor to Authy (by Twilio, an enormous company not fly-by-night)

Well, Google Authenticator uses a standard, well documented algorithm (TOTP) and there is really no reason to touch it unless they discover a security issue, it becomes incompatible with the latest version of android or there is a pressing need to improve the UX. But the UX is pretty simple.

I also have Authy, because that seems to be the only one that SendGrid will work with, but exactly because of this I thought that was non-standard. But as I can see now, they probably also support standard TOTP. But they rely on SMS for initial authenticaion (when you install or re-install the app) and I don't trust that. On a side note, Microsoft also has an Authenticator app, which also supports the TOTP standard. (So it can work wherever you would use the Google Authenticator.)

> But they rely on SMS for initial authenticaion (when you install or re-install the app)

It's been a long time since I installed it, so I'll take your word for it. They have my email address displayed in the app, so maybe I can do authentication on a new device over email, too. But regardless of how you initially authenticate a reinstall (email or SMS), as long as you are using the Authy cloud backup -- which is password-protected and cannot be reset over SMS or email -- what is your concern (genuine question)? I do not see the security risk, but I'm no expert.

Mainly the SMS thing. As far as I can remember, when I reinstalled it on my new phone (about a year ago) I just had to verify my phone number via the SMS they sent.

Also, as I have already been using the Google Auth app, I was somewhat ignorant to check out Authy more in detail. Up to know I thought it wasn't using standard TOTP but some in-house developed algorithm by Twilio (or maybe a lesser known/less standard one) because SendGrid specifically tells you to use Authy. Which in itself seemed like a red flag.

I would suggest keeping an eye on the voltage with a meter and when it starts to drop solder on a second battery while you replace the first, the same way people replace game cartridge batteries without losing SRAM saves.

That's a great recipe to fumble and accidentally reset the device.

How? The original battery provides power while you're soldering on the backup and the backup is solidly soldered on while you swap out the original. How could you be so clumsy you rip out a solder joint?

What if it's only held in by the case itself and not a clip? Then I'd disconnect it simply by opening the device?

Since you knew it was a CR2032 I assumed you were already familiar with it.

I just guessed by the physical size of the device. I guess it could be a smaller coin cell as well.

You are correct. Those BankID physical devices have tamper switches that erase RAM on device opening.

An alternative is debit card bankid (as a smartcard, then add Mobile BankID back), but it's being deprecated soon.

Accidentally disconnecting the original battery while messing with it. Or shorting something out.

A bit OT, but at least for the Game Boy you can pop the cartridge (front of the case off) into a console (GBA is especially good as it only covers part of the cart), power it on and then replace the battery. The game save will remain. Or you can use something like the GB Operator and backup the game save, replace the battery and then rewrite it to the cart :)

Reply on news.ycombinator.com