121–130 of 139 posts
Earlier quoted context omitted.
All my 2FA codes are backed up. On paper. I have a physically-secured cache of the QR codes which can be pretty quickly imported into a new app.
I see people say this a lot in the tech community, but it’s a preposterous expectation that regular users would be doing something like this. MFA needs to usable by everyone, not just the tech elite.
I stopped using Authy because it has auto-update that you cannot disable. One day it auto-updated itself to a version that would not run on my OS. Also, it's an electron app, so it is absurdly heavyweight for the tiny bit of functionality it provides. I ended up writing my own TOTP app. It's about 50 lines of common lisp code.
Authy Desktop Memory / Real / Shared 71.3 MB 116.8 MB 96.3 MB
Earlier quoted context omitted.
Totally agree, I had my phone stolen a few years back. Had to buy a new one. What a surprise when I restored Google Authenticator and all my sites were gone. However I do have an issue with 1password's feature of auto-filling those codes, seems like it's just invalidated the whole "something you have" party of MFA. For me Authy is a happy medium
Google Authenticator is backed up on iOS if you use an encrypted local backup via iTunes (or macOS Catalina) or iMazing.
It isn't that bad, it still a 2nd factor, but it's worth considering it.
Last time I checked, by default, Authy codes were susceptible to SIM-swap attacks.[0] This is a bad article. You should perhaps consider switching off of Authenticator to an Open Source manager like AndOTP; I think that's something reasonable to propose. But I don't understand the argument that I should be very concerned a lack of biometric locks, but not concerned about invalidating the "something you have " part of…
Authy keys are encrypted with your passphrase before they are synced. You can't reset this password even after SIM-swap.
Authy could encrypt your entire database before syncing it, regardless of the key type, but they don't. I mention in the Twitter thread that (at least at the time) Cloudlfare's tokens fell under this category and were vulnerable to SIM-swap attacks[0].
It's possible since then Cloudlfare has switched back to using the Open standard instead. I haven't checked because I don't use Authy anymore -- I dropped Authy specifically because I personally verified 3 times in a row that my Cloudflare token did not require a passphrase to decrypt on new devices.
[0]: https://nitter.42l.fr/DanielShumway/status/10920953954785566...
Earlier quoted context omitted.
Google Authenticator is backed up on iOS if you use an encrypted local backup via iTunes (or macOS Catalina) or iMazing.
Mmm, does that mean that now your iCloud password unlocks all your 2FAs? It isn't that bad, it still a 2nd factor, but it's worth considering it.
I stopped using Authy because it has auto-update that you cannot disable. One day it auto-updated itself to a version that would not run on my OS. Also, it's an electron app, so it is absurdly heavyweight for the tiny bit of functionality it provides. I ended up writing my own TOTP app. It's about 50 lines of common lisp code.
Strongly disagree with the premise of this article: - Passcode or biometric locks on an app are a gimmick and offer negligible value. - The keys not being backed up or or synchronised across devices is not a bug, but a feature. You're supposed to keep offline backup keys. Any sort of synchronization feature adds a ton of attack surface. - In particular, Authy, LastPass and 1password have a giant attack surface compar…
I've used Google Authenticator for a long time, but the lack of backups is a really serious downside. What I would really like is encrypted backups using a strong passphrase that I can write down on paper (like Authy), but from a trusted source like Google, and with no other features to widen the attack surface (no internet access, no SMS). Without backups, having a phone die or get lost is a very frustrating experie…
I built exactly this: https://github.com/yeo/bima
I stored everything into a SQLite in `~/.bima/bima.db`
Your OTP secret is encrypted using a master password that you chooese. I use AES GCM for encryption: https://github.com/yeo/bima/blob/master/shield/encrypt.go#L1...
You then has 2 options to backup/sync among device it:
1. backup that file using dropbox, icloud, google drive 2. Enable sync to my backend. You sync encrypted data, even me cannot see it. Then other device can sync from my backend, and you enter your master password to decrypt it.
Entire thing is open source, implement using Golang Fyne UI toolkit so it run across linux/mac/window/ios/android.
If you want to help beta test it, I can send you a beta build.
Earlier quoted context omitted.
Or, I keep using single factor because services MFA implementation sucks tremendously, and as per service agreements service is liable in any security compromise case. Frankly, most of MFA is security masturbation, is nowhere near to being a real solution, not even a real problem. Its just neat from a technical standpoint (if done well, which nearly never happens). A minimum of 2 registered u2f keyfobs, that's all yo…
MFA is always better than single factor. At the very least it makes drive by/automated attacks significantly harder. Everything you read about SIM jacking and the like is at bare minimum, much harder than hacking your password.
Bitwarden is a pretty good solution for this! It's not the smoothest since the browser extensions don't know how to fill in your codes like they do your password but it's leaps and bounds above the UX for Google Authenticator. Being able to access my codes from any device with a web browser is very nice. INB4: "But this reduces your security." * Yes, but I'm already using a password manager with 64 char generated pas…
As a sibling mentions, when you fill inn the user/pw of an account with 2fa enabled, the 2fa pin should be copied into the clipboard by default. (so the flow is: autofill username/password; submit, paste pin;submit).
Still think it's silly there's no simple way to get an encrypted backup of the 2fa-secrets from Google authenticator - it leaves the user and an attacker (with effective root on the phone) on uneven ground. For the user the app pretends that there is no shared secret with the server that could be compromised - the attacker simply access the sqlite db.
Lots of cross-platform apps to use.