Even if iMessage could be a more secure 1.5FA, it would still be 1.5FA and not true 2FA.
Even if iMessage could be a more secure 1.5FA, it would still be 1.5FA and not true 2FA.
Not to mention Google Authenticator deliberately prevents these stored tokens to be backed up and transferred to a different device, which makes upgrading devices troublesome.
I wish everyone would start using Yubikeys. WebAuthn is now widely supported by browsers.
iPhone backups back up its data correctly—my codes survive new phone restores where they do not with Google Authenticator.
I've wanted to get off Google Authenticator for awhile now, mostly because of the backup-restore problem, also a general trend of limiting my involvement with the company.
Isn’t google authenticator not using this on purpose? Central account and sync is googles thing and yet they deem it too insecure. Completely understandable
So how can using a central service that adds yet another attack vector be of value?
What I would love to have is a paper export. Every time you add a new account to google authenticator you can print it as QR code for later reimport.
Yes many services already provide this for you via recovery codes but having it on a per service basis directly from authenticator is probably much easier to use and not less secure
Any reason this wouldn’t work?
It's great that people use can use one app for both factors but it seems less secure than two apps.
For example, use Authy for TOTP and LastPass for long passwords. That's two things that have to be compromised. And both of them allow you to have multiple devices (for example iPhone and iPad).
The biggest thing 2FA protects against is credential stuffing. If you’re using a password manager and have high entropy site-unique passwords, the additional entropy by TOTP is mostly moot anyway.
Passwords - protect against unauthorized access of my service accounts, and 1Password - can be compromised via logging or breaches or just plain peeping
Secret key - acts as 2FA for my 1Password and thus protects my master password from unauthorized use - can be compromised if someone steals the physical paper on which it's stored
TOTP - protect against unauthorized use of my service accounts - can be compromised if someone compromises my mobile phone or phone number. Highly unlikely someone would spend that kind of effort and €€€ on me though
All in all its a pretty nicely tiered system. If someone gets my master password, they still need the secret key. If a burglar steals my secret key, they don't have my master password. If someone somehow compromises both of those, they still don't have access to my TOTPs and thus can't login into any of my 'cricital' accounts (basically e-mail, hosting providers, finance, etc. etc.)
Now imagine you have an malicious spouse or housemate or whatever: they could easily learn your master password by peeping over your shoulder, piecing it together bit by bit (ha). They have a lot of opportunity to search for your secret key as well. If you put your TOTPs on 1Password, you're boned. But if you have them in an authenticator app, even having access to your password manager means jack because they can't login without your TOTPs.
I know one of the big faux pas is to talk about your security but most of this stuff can be deducted pretty easily so I don't feel too exposed.
It doesn't offer export in the app UI. It's not doing anything to prevent you from backing up the tokens yourself; they're stored in the clear in the sqlite database for the app.
If that's too much for you, there's a good chance https://github.com/puddly/android-otp-extractor can get them automatically.
If that were possible then you would face the same problems that reused SMS numbers suffer from.
Classic Google Authenticator does not seem much more friction than that.
I am surprised your bank is moving to a weaker auth, what does that mean?
I have 3 bank accounts in 2 countries and they all switched to biometric because it's just a simpler experience then the hardware token or "mobile token" they used before.
A further cost is that they usually require the user to install and set up an app, contrary to SMS.
This scheme also works really well with payments from your computer. Just use the bank app to scan a qr-code on checkout, verify the payment details on your phone, touch a button, and you're done.
I'd guess that a majority of the bank's clients are using this method. This is in the Netherlands, by the way.
They are precisely equivalent to asking for two passwords on login instead of one password. "Something you know" and "something else you know". So pretty much, yeah. SMS may not be especially secure, but it is at least an actual second factor.
The website requires a temporary code, generated by a card reader and my card. It works like a 2FA code, as I need to _have_ my card and to _know_ its pin.
Recently however it has become somewhat less strict it feels[0] and I can now log in to my bank app using FaceID or a pin code.
Normal bank websites still demand a code from a hardware token (think RSA key, but with a pincode and sequence-based instead of time based.)
[0]: I realize it might be that they are just as strict only doing more work in background to verify me instead of bugging me.
Just wondering if there could be an easier non installed version that was always available.
Apologies if it's a really silly question!
But how do you protect access to the website - with a username and password? Or do people now need to remember another code like "JBSWY3DPEHPK3PXP" to set up the authenticator everytime they visit?
Mobile apps were one way to solve this although the hardware U2F tokens like Yubikey provide another authentication factor in a usable way (and more secure than TOTP because you can't be phished to enter them on the wrong site).
This is more generous than it should be. Your TOTP secret is just another part of your password regardless of whether you personally remember it or not; what matters is that, if I would like to be you, I only need to know the secret.
If it is an account you set up from home, probably the simplest thing to do is print the setup page before you scan the QR code for the secret. Even better, print the page, and then scan that QR code from the printout. Then store the printout where you keep other important papers (e.g., mine would go in my fire proof safe).
Another possibility is to scan the code on two devices. I scan on both my iPhone and my iPad. Nearly all realistic scenarios that involve me losing both of those at near the same time also involve me dying.
Encrypting a file is a bit arcane, but not difficult:
openssl enc -aes-256-cbc -pbkdf2 -iter 1024 -in plaintext.txt -out cryptotext.dat
Decrypting is about the same: openssl enc -aes-256-cbc -pbkdf2 -iter 1024 -d -in cryptotext.dat -out plaintext.txt
I'd suggest writing a couple of shell scripts. You might also want to overwrite the plaintext file with /dev/urandom afterward and delete it.I prefer one file per code. When I get a new code, I make a directory named after the account the code is for, save a screenshot of the QR code in there, save a text file with the text version of of the code and any one-time recovery codes the site provided. I then make a .zip for .tgz from that directory, encrypt that, and save a copy in the cloud and locally. The local copy is in a location that is included in offsite backups.
If you use one file per code, I'd recommend using a public key system for the encryption. That way you don't have to enter any secrets to encrypt a new code. You only enter anything secret when decrypting.
This has a few advantages.
1. Less chance of accidentally exposing the key.
2. If like most people you use the same key for all the files, no chance of unknowingly mistyping the key resulting in a file that you cannot decrypt later.
3. If you need to recover a code, you only need to decrypt that code.
If as you suggest you wrap this in shell scripts, you can address #2 there. Have a reference file encrypted with your symmetric key. For encryption, the script can ask for your key and verify it was typed correctly by using it to decrypt the reference file.
Also worth considering is using an encrypted disk image. I believe that all major desktop operating systems provide reasonably easy ways to create, mount, and dismount such volumes. Whether you use one file per code or all codes in one file, the file or files can live on an encrypted volume that you only mount when you are saving a new code or recovering an old code.
The advantage of that is that there is no need to use any arcane commands or install any extra software.
I prefer keeping it as simple as possible since the consequences of screwing it up are a whole lot of hassle and possibly being locked out of some accounts forever. One downside is when you add or change a code you have to update all of your backups. A second script that syncs all of the backup files is also helpful to have.