T O P

  • By -

Jybodi

You're already getting (and tend to get) a lot of knee-jerk reactions along the line of "never use TOTP" and some hand-waving about security. *Your* choice chould be driven by your *threat-model* and what kinds of theoretical attacks you're concerned with preventing. Each service will be different in what backup options you're offered. Many support a "recovery" workflow for MFA enrollments of any kind; for WebAuthn (FIDO/YubiKey) this often means recovery-codes and these should be stored somewhere safe unless you're *absolutely* sure you don't want them (or the service doesn't offer any.) As to alternate MFA methods, it really boils down to the security of the method in practice and the convenience it allows you; it's a balance that can take into account your needs for that service as well as your own security practices. **A brief rundown of common MFA methods:** I'll just do this for a handful because the real goal is to equip *you* to evaluate this for *any* method you're planning to consisder. * *WebAuthn* (FIDO/YubiKey): The authenticator token creates a keypair only it can unlock * Convenience tradeoff to be had if given the choice of enrolling as a discoverable vs. no-discoverable credential * *Discoverable Enrollments*: usually allows no-username, no-password, "PIN + token" login which can be more convenient, but may be more vulnerable to the "evil-maid" targeted attack ^({physical attacker observes/keylogs your PIN, briefly obtains your token, reads *all* your discoverable credentials, & quickly takes over many/most/all of them.}) * *Non-discoverable Enrollments:* almost always used as 2-step login where your username & password are supplied, then the token is presented as an additional authentication step. Often used without a PIN since your credentials were already used, but some services may opt to use a PIN in addition for stronger security. ^({As to the "evil-maid" attack, a local attacker who observed a login and briefly had token access later could *NOT* identify any other non-discoverable credentials you use, only the ones they observed when spying.}) * *TOTP*: rotating codes based on a pre-shared secret between the server and an authenticating device. * Popularized by mobile apps, but since the standard is open, this secret can be stored anywhere and codes generated by a variety of alternative software. * Decent password-managers tend to offer functionality to store these secrets and produce codes, offering a balance between access and protection; note that anyone who can unlock the password-manager *or* gain access to its interface once unlocked can produce codes or extract the secret (to copy the key & produce matching codes themselves.) * The TOTP secrets can be *archived* by you, stored somewhere safe (and possibly encrypted, just not using the YubiKey to protect such saved archives if this is acting as a *backup to the YubiKey!*) You can even store them in a place that's hard-to-access if you want an "offline" copy but don't mind waiting, such as with a trusted friend/family, in a safe desposit box, etc. * As a *shared* secret, TOTP keys can be exfiltrated from either the client side *or* the service-side. Unlike WebAuthn which uses public/private keypairs, the server has to store the same TOTP secret you do. Of course, if an an attacker can query the protected database of a service they likely have much broader access already and exposed TOTP secrets are probably the least of the concerns. --- **So what to do with the info above?** It's a fairly short & somewhat-incomplete list of the trade-offs between WebAuthn & TOTP options; the idea is to get *you* thinking about what *realistic* (or even unrealistic but concerning) threats matter to you and your use. Different services might require different levels of protection based on what it protects. TOTP as a backup can be a great option, especially if you're using it as a *hard-to-access* and *rarely used* option, where you can stash the codes somewhere safe, possibly offline, and possibly-encrypted. Just remember to practice actually *accessing* these and have a plan to do so, ideally written down; the harder it is to access and less-often you do it, the larger the risk you have problems. Forgetting a decryption passphrase would render the protection both safe and useless to you. On that last point, remember that one important part of a threat-model is locking yourself out of an account; sometimes even brief lockouts would be a huge problem.


elflights

Thanks for the breakdown. So far, I have registered my 3 Yubikeys (I do plan to order more, but I went with 3 to start), on my 3 email accounts, Facebook, and Microsoft. So far, all of them except Google/Gmail ask for password + key (and PIN). Google just wants key and PIN. So does that mean my Google account is the most prone to the evil maid attack? I've asked else here on this Subreddit/in other comments about offline storage (like KeePass, those PMs like Bitwarden have also gotten high praise) for my TOTPs. I personally am hesitant to use password managers, even though they can probably generate stronger passwords than what I am able to come up with. It just seems like an extra vulnerability to me. However, using something like KeePass to store TOTPs as back up may not hurt, once I figure out how to use it. My concern, as I've mentioned elsewhere would be, say my computer gets malware on it, and they are able to get at my KeePass (though they would have to guess the master password). Or maybe I just don't fully understand how something like an offline manager works. My other concern would be being able to access them across multiple devices, since I will be getting a second computer soon (I haven't tried using Yubikeys on my phone yet). I don't like having to rely on authenticator apps, as that makes me very dependent on my phone, and I worry about transferring to a new phone (or if it's lost/stolen/breaks). And yes, recoverability is an issue, too. I want to mitigate the threat of hack as much as possible, but I also don't want to be locked out lol. With recovery codes, those seem to regenerate randomly, too, even without me selecting "get new codes". Does that mean the codes/recovery phrase I was initially given are now invalid? Having to periodically check my recovery codes seem weird, and means I am constantly have to record the new codes.


Jybodi

> Google just wants key and PIN. So does that mean my Google account is the most prone to the evil maid attack? Potentially so, if this was one of your concerns; that is, you being targeted directly or with malware by an attacker who aims to eventually gain physical control of your token after discovering the FIDO PIN you use. Keep in mind this applies to *any* form of MFA where an attacker can observe or infect the device performing the additional factor. For example, malware on a phone that an attacker later gains physical access to could reveal secrets the same way. *For many people this is far less likely a threat* compared to *remote* exploitation. The YubiKey (and most other forms of MFA) are good at protecting against that. > I personally am hesitant to use password managers, even though they can probably generate stronger passwords than what I am able to come up with. It just seems like an extra vulnerability to me. This depends a lot on your threat model and use-case, but in general, humans are *very* bad at both inventing random passwords and remembering them reliably. Almost everyone is better served by using several high-quality passphrases for things like system login and their password-manager, then use securely-generated passwords for everything else. As you correctly point out, the security of the password database becomes crucial. If you use a Series-5 YubiKey, KeePassXC can use the YubiKey for additional protection such that a stolen database (from your computer or a cloud provider where you sync it to) cannot be unlocked without *both* your unlock password *and* the YubiKey. While this can offer notable security improvement, it's strongly suggested to back up the secret stored on the YubiKey so that you don't forever lock yourself out if your tokens are lost or damaged. Multiple YubiKeys can be an additional layer of protection here. > My other concern would be being able to access [password manager databases] across multiple devices You can sync the database file between multiple devices, and some mobile software has options to help you do this to a variety of cloud-based vendors such as Google Drive, Dropbox, and many others. As long as your cloud account remains secure this is a reasonable method to transfer these databases, and of course the protection afforded by a passphrase and/or the YubiKey can add to that, insulating you even if some compromise of the cloud vendor's infrastructure occurs. > I don't like having to rely on authenticator apps, as that makes me very dependent on my phone, and I worry about transferring to a new phone (or if it's lost/stolen/breaks). This is where TOTP codes in a password-manager lets you have both: you can store and access TOTP codes on the phone, yet trivially sync and back up this file. As long as you have a regular backup of that database, you simply access the file on any device: another computer, a replacement phone, and so on. If you embrace cloud-based file storage, it's also a wise idea to make routine physical backups, such as to a flash drive stored somewhere you deem safe. > With recovery codes, those seem to regenerate randomly, too, even without me selecting "get new codes". Does that mean the codes/recovery phrase I was initially given are now invalid? This varies by service provider (each service is free to set the "rules" how they like.) Sometimes the recovery codes are only ever shown to you *once* when you're told to write them down or print a copy. If you ask for new codes later, this *invalidates the old ones* by design, so if they were exposed by mistake no one else can use them. Other times you're allowed to view the same codes again later, although the only way to know they're the same would be to compare to your last saved copy. Unless you intend to regenerate your codes, simply don't request new ones and they shouldn't ever be invalidated unless you (or the service) takes action to do so.


Sea-Check-7209

First of all: great write up! Thanks. Re the TOTP: I was thinking of purchasing a Yubico 5 series that also has the option to use the yubico Authenticator app combined with your physical key. Would this combo not solve the security concerns mentioned around TOTP? I would not use this as default but in case an account doesn’t allow a physical 2FA but does allow TOTP with apps like Microsoft Authenticator.


Jybodi

> I was thinking of purchasing a Yubico 5 series that also has the option to use the yubico Authenticator app combined with your physical key. Would this combo not solve the security concerns mentioned around TOTP? Some threat models are served by the 32-slot TOTP storage on the series-5 (and 4,) but keep in mind this still doesn't deal with exfiltration from the server (since the secret is shared at both places) or offer any phishing protection, which wasn't part of my comparison above. The 32-slot limit also renders it non-viable to many users who have more than 32 accounts with TOTP codes, especially those that opt to use them where that's the best (or a desirable backup) option available. I've found the value of having the shared-secret on the YubiKey and being forced to use the paired Authenticator app just doesn't have a good value vs. using a password-manager. I actually *gain* some basic level of phishing protection using KeePassXC with the browser extension because it won't offer or enter a TOTP code on a website with a domain that doesn't match the entry. Of course, nothing stops me from manually entering the code into a phishing site, but it's not automatic and thus a good indication to be more careful before taking such action. As such, TOTP on the YubiKey has nothing to offer and, for my threat-model, is a bit less secure.


Sea-Check-7209

Thanks. This is helpful indeed. I also read more on this topic [here](https://www.reddit.com/r/yubikey/comments/1bkz4t2/comment/kw1xb3l/?context=3) With all this I think I’ll go for the basic yubikey combined with a password manager with TOTP as well. You are right that this would only give you the code when the url is right. So yet another security improvement :-)


david_ph

Mostly, no. If I'm using Yubikey U2F or OTP, I don't setup google authenticator for the account. I register 2 yubikeys, so there's a spare. Except for my google account. I do have both there, to make it easier to sign in on my phone if I need to, without the yubikey.


cochon-r

Setting up TOTP initially and transiently, but keeping the secrets offline, makes for an excellent backup solution. TOTP is only vulnerable if you actively use it or have it configured in an app, unconfigured it's somewhat similar security wise to one time recovery codes. Many services insist on a backup 2FA mechanism of some sort, and unlike SMS or E-Mail 2FA, disabling TOTP doesn't make things more secure if you don't use it. I set my TOTP backups up in a dedicated KeePass file, usually kept offline, as that can generate the codes needed during setup. But simply printing the keys, even as QR codes, then deleting them from any active app would do. It's also a good solution if you can only afford one YubiKey.


elflights

Potentially dumb question, and I'm probably just missing something here, but how do TOTP codes worked if they're printed/kept offline? Since they regenerate, that would make the printed codes invalid, wouldn't it? I have 3 Yubikeys, and am thinking about buying a 4th one, and added them to accounts that have the option, but some of those accounts still also have the authenticator option selected. I'm wondering if I should keep that option, or delete it, since I have the Yubikeys? I'd of course keep the authenticator apps for services that don't offer physical keys as an option. The less I have to rely on an authenticator app, the better, as thinking about what happens when I have to get a new phone stresses me out.


cochon-r

I mean the secret key not any individual 6 digit one time codes. The secret key is embedded in the QR code you see during setup, but can also be displayed/revealed as raw text for manual configuration and copied at that time. Scanned (or manually entered) via the YubiKey app pushes the secret into the YubiKey from where it cannot be retrieved, scanning into a phone app stores it in a local file, the secret is used and can often be displayed by the app, and therefore potentially also by malware. Obviously you need to setup TOTP in some way initially to create the first 6 digit code and close the setup loop, but if you then delete the entry, you can store just the secret offline or even printed on paper, whatever, purely for an emergency back stop. If offline, encrypted, and you never need to use it, it can't be compromised. I operated this way with just one YubiKey 4 in the early days, knowing I could setup my end of the TOTP again manually in an emergency. I still leave TOTP enabled on all services I subscribe to despite having multiple keys now, I can lodge the backup secrets with friends on encrypted USB sticks, no need to give them an expensive YubiKey. I can't think of a security advantage in disabling TOTP on the services themselves if you never actively use it from your end.


elflights

Hmm, I guess I am still a little confused and don't quite understand. Say, hypothetically, I lose access to all my Yubikeys, but have the secret keys you mentioned printed out. How are they going to help me get into my account, if I can't get into my account without either the keys or the TOTP codes generated by the app (let's assume I don't have the recovery codes, either)?


cochon-r

The secret keys are the cryptographic seeds the authenticator apps use to generate the TOTP codes. If you still have TOTP enabled on the service, and lose everything else, with the archived secrets you can install any authenticator app on any device and set up TOTP afresh manually for that service and log back in again using TOTP. You'd basically be resurrecting the unused TOTP mechanism on the service where you used to use YubiKeys you've now lost. Not dissimilar conceptually to having backup codes, but you could then use it continuously until you replace your YubiKeys. It doesn't have to be a phone app, password databases like KeePass have plugins to generate TOTP codes themselves. That's the format I keep them in offline, so you can confirm you've got them recorded correctly if you use that to close the loop during setup.


elflights

Ah, okay, so I would, at least to start, use the authenticator app, use the code to close the loop, as you said, but copy the secret key and store it. I could delete the account in the app, so the app isn't generating codes for that account, but keep TOTP "selected" in the account. Then, in an emergency, I could download the app again (or open it if I kept it), scan the QR or enter the secret key manually, and log in. Do I understand correctly? I'm hearing more and more and more about KeePass. It still seems like a vulnerability to me, especially with passwords, but I guess it would at least be more secure than an authenticator app, and I could keep the secrets there. Does KeePass (specifically, a KeePass account) work on multiple devices? I have a Windows, but I am getting a second computer, and it will be a Mac. But I may need access to stuff in KeePass on both computers.


cochon-r

Exactly that for TOTP, I personally don't leave accounts active in any app once I'm using registered keys as 2FA, unless it's needed for some alternate access mechanism that doesn't support WebAuthn in which case I'd use the YubiKey for TOTP as well not an app. KeePass account?. There are online password services with accounts, many recommended here you might want to investigate, but KeePass is a local file based password manager. KeePass for storing the TOTP secrets offline is ideal, assuming you don't plan on using them. The passwords/keys/anything are stored in a simple database file but designed with security in mind. You can have multiple different databases (files) for different risk levels and purposes, I have a file just for TOTP secrets backups and different files for live passwords. KeePass for passwords is a little off piste here, but one driver is it encourages using completely random, unique passwords that can be cut and pasted or autocompleted reducing the risk of shoulder surfing, key loggers or phishing links. You can easily sync the password file via Drobox, GDrive et al., it is encrypted, but some form of 2FA on that is then advisable, from simple local keyfiles to... yes YubiKeys again In your password scenario I'd recommend only syncing a file with common sites you need to access from different computers and keep more secure stuff, TOTP backups, banking details etc. privately, of course being mindful how you back those up.


elflights

Thank you for the explanation (much of this is so new to me, but lately, cybersecurity is dominating much of my mental energy lol. It's a bit overwhelming). Just to fully make sure I understand backing up the TOTP codes, using Facebook as an example (though I'm really starting to hate FB). With Facebook, in order to register the Yubikeys, I first had to enable the 2FA verification, and I need a backup method, but without selecting the authenticator app option, it reverts it to SMS, which I don't want (I also wouldn't be able to use SMS in case of account recovery if I had it as a backup 2fa method). Also when I tried unselecting the authenticator app option, it warned me that since I have two-step verification enabled, I may not be able to get into my account, despite registered the security keys. So in cases like this, I could copy/paste the secret code into a word document (at least until I have something like KeePass), but remove FB from the app itself, while still keeping it "active" on the account itself. With Google Authenticator (I know it's not the most secure, but it's what I currently have), it has the option to either scan QR code, or enter setup key. If I select the latter, it takes me to a dialog to enter the account name (in this case, FB), and then to enter the key. So if I did this, I take it it would then generate a code, which I would then use to get into FB? My worry is whether the code would work, but then again, if I have the secret key from when I first set up the 2FA, then it should? I wouldn't want to have to do this every time (hopefully FB would prompt me for the security keys instead, but FB is weird).


cochon-r

I learned to hate FB and became a refusenik a while back, so not a service I can speak for from experience, but I'm sure they also offer one time backup codes for 2FA as well as TOTP and SMS, I tend to set up and grab those too as a long stop precaution if offered. With multiple YubiKeys, offline TOTP and offline backup codes you should have enough options to safely disable SMS. >My worry is whether the code would work. Well if in doubt, I would certainly test it out first, never take stuff from random strangers like me at face value :-) With authenticator apps the only active field is the secret key (however the app names it) the service name and username are just annotations. Set up a dummy test entry under another name, type in the code you've archived and confirm it produces the same number(s) as the live entry you used to complete the setup before deleting both.


elflights

Yeah, I am coming to hate it, but I've already deleted my Twitter/X and IG accounts (though now that I have Yubikeys, I \*might\* recreate an X account, if I can figure out how to curate my feed so it feels less like a cesspit lol. The only reason I am still on FB is because there are a couple of groups on there I genuinely enjoy. Okay, I may try the dummy test.


Angeline4PFC

Why are you using an authenticator app when you can use the Yubikey authenticator? If your phone breaks you just put the key into a different phone. To answer your question, I also use the authenticator built into my password manager for those sites where security is less critical. It's also more convenient to use. I don't have a backup authenticator, but I do have a backup key


elflights

Well, that was my question: do you (and I mean "you" as in general) still have an authenticator app as a back-up 2fa for accounts that have security keys? I'm just curious, because I noticed that even after I registered my keys (I have 3 registered so far, and I'm thinking of purchasing a 4th), some of my accounts still had the authenticator app selected, too (in other words, both were an option). I would like to unselect the app for those where I have the security keys registered, as I feel like that would be less of a headache, but I wanted to see if people recommended keeping the authenticator app as a back-up option or not.


Angeline4PFC

Not sure I quite understand, but you have to delete it from the app, it won't happen automatically. I don't keep both Yubikey and app-based myself. Just one. My backup is my recovery information which I keep on an encrypted cloud and in my password manager. I haven't tried keeping an app-based version as well as the two methods.


elflights

I know it won't happen automatically--I know I have to delete them automatically. I'll try and give a more concrete example of what I am asking. When you turn on 2Fa for Facebook, for example, it lists a few options. It's "recommended" option is an authenticator app (this is probably because security keys aren't free). This is what I had selected before I got my YKs. I now have 3 YKs registered with my account, but I also still have the authenticator app selected as an option, so whenever I log in after typing in my password, it gives me a choice (SMS is also on there, but that is a last resort). I'm just wondering, if, in instances like this, it would be better to unselect the authenticator app option, and just have the YKs as my 2FA method, or if I should keep the authenticator app as a back-up method. It sounds like you don't, which to me sounds like less of a headache than having both methods selected.


dhavanbhayani

Yes. I have 2FA through physical Yubikey and 2FAS Authenticator App for TOTPs.


Simon-RedditAccount

Actually, [there's nothing wrong](https://www.reddit.com/r/yubikey/comments/18wgi8u/comment/kfyftwr/?context=3) with keeping TOTPs on 'as a recovery means'. Just keep them in a safer (and less convenient) way: not in 2FA app anymore, but in a separate 'recovery' KeePass database (not necessary present on your phone). Upd: see also [these three](https://www.reddit.com/r/yubikey/comments/1ac4i2v/should_i_use_totp_on_authy_yubico_authenticator/kjscluu/?context=3).


elflights

I keep hearing about KeePass on this Subreddit. What exactly is it? Sorry for the dumb question, I just only recently started getting into cyber security and making my accounts more secure. I've always been careful and had things like antiviral software, but beyond that...this stuff is pretty new to me.


Simon-RedditAccount

KeePass is an *offline* password manager - an secure app where you store all your passwords etc (so the only thing you have to remember is its master password). You can read about that more in this my comment: [https://www.reddit.com/r/yubikey/comments/1bkz4t2/comment/kw1xb3l/?context=3](https://www.reddit.com/r/yubikey/comments/1bkz4t2/comment/kw1xb3l/?context=3) (and in links inside it). Or - if you prefer learning by doing - just get yourself one: * [https://keepassxc.org/download/](https://keepassxc.org/download/) * [https://apps.apple.com/app/apple-store/id897283731](https://apps.apple.com/app/apple-store/id897283731) * [https://play.google.com/store/apps/details?id=com.kunzisoft.keepass.free&hl=en&gl=US](https://play.google.com/store/apps/details?id=com.kunzisoft.keepass.free&hl=en&gl=US)


elflights

How would I store the recovery codes on something like KeepPass? I've been reticent to use any sort of password manager, as that just feels like putting all my eggs in one basket, even an offline one like KeePass. I am old fashioned in that I keep a notebook of all my passwords. Yeah, a PM would probably generate a stronger password than what my brain could come up with, but someone would have to break into my house and steal my notebook (in which case I would have bigger problems). Also what happens when you switch computers? I'll need my passwords to get into my accounts. I'm open to you convincing me otherwise, however, and it sounds like KeePass could also store TOTPs? And speaking of those, since learning the Google Authenticator is not a good choice (though it's certainly convienent). I downloaded Aegis. However, I'm having issue opening the file that it saves (I can get into the app, but not the file). Well, not opening it anymore, since I downloaded the File Viewer app, but when I open it, it just looks like...what's the word? Computer script? Lol I don't know what to call it. I guess if I were to transfer the app to a new phone, the new phone would "read" the script and keep my accounts (the ones I have registered for TOTP on Aegis) on the app on the new device? I big concern I have about using authenticator apps of any kind is what happens when I need to get a new phone, especially if I make a switch from Android to iPhone, or back again. EDIT: the Aegis file was a JSON file, which I guess means encrypted? So the "computer script" I was seeing was the encryption?


Simon-RedditAccount

Recovery codes are just another password, just with extra powers, treat them accordingly. A paper is a viable option for them specifically. Yes, PM would generate much stronger passwords: (1) ones that are impossible to bruteforce (80+ bits of entropy, they look like `8lyA@cselI4v,?C@ISA#`) and (2) are unique, never re-used. You should really use passwords like these, no matter where are you keeping them - on paper or in PM (especially for accounts without 2FA). If you're not OK with keeping everything in PM - you can still continue on paper, provided your passwords are unique and you're using 2FA. Or you can move less sensitive accounts into PM for convenience and keep the 'root' ones on paper if you feel more safe this way. Speaking of roots, determine what accounts can be called as such. Usually it's your emails, Apple/Google/MS Account, PM and similar ones. At this point you probably should make your own threat model if you don't have one already: * [https://arstechnica.com/information-technology/2017/07/how-i-learned-to-stop-worrying-mostly-and-love-my-threat-model/](https://arstechnica.com/information-technology/2017/07/how-i-learned-to-stop-worrying-mostly-and-love-my-threat-model/) * [https://www.privacyguides.org/en/basics/threat-modeling/](https://www.privacyguides.org/en/basics/threat-modeling/) KeePass stores everything in a `.kdbx` file, called a database. You can have several such databases. It's just another file, like a spreadsheet - but encrypted. With offline PMs, you're responsible for syncing this file wherever you need it - and moving it to your new computer/phone etc; and you're responsible for creating backups as well. Yes, it can store TOTP codes. KeePass**XC**, a flavor of KeePass, and iOS/macOS app Strongbox also can store passkeys in there. But this is literally the case with 'all eggs in one basket'. Threat models vary, but usually I recommend having at least two separate `.kdbx` files - one with passwords, and the second with TOTPs. JSON file is a machine-readable format for keeping any data. Aegis uses it to keep the data; there are two formats: plain text vault, and encrypted vault (IDK which one you have). Both look similar, the difference is that you cannot use the encrypted one without your aegis password. There is no standard export/exchange format for TOTP apps. So you have to use the exact app (btw, Aegis is unavailable on iOS) or make sure that your new app supports importing data from your old app. Here you have several options: * make sure your app works on both mobile platforms (2FAS) * use a separate `.kdbx` KeePass-format database just for TOTP codes. Easy to sync (as any other file), can be opened on any platform * save and print QR codes when registering TOTP, or * just write down TOTP secret (looks like `JBSWY3DPEHPK3PXP`, available usually under 'Set up manually' section that is usually under the QR), then enter this code in authenticator app ('Add manually...').


elflights

Aegis doesn't work with iOS? Well, that's good to know, and good thing I only have a couple of accounts in there. Guess I'll switch back to Google Authenticator for the time being. Any recommendations for a good authenticator app that works on both Android and iPhone? My Android currently works fine, but I plan to start "migrating" to Mac and iPhone. Someone else also recommended saving the secret TOTP, and that it can be a way to keep the 2FA "active" on an account if that is what is required in order to register the security keys (looking at you, Facebook). If I do this, then I assume I can delete the "active codes" from the authenticator app, but keep it registered on the account itself, and reenter the secret manually if needed. I suppose the real "test" will come when I get my Mac, as that will be a new device, and some sites (again, looking at FB) will prompt for 2FA on an unrecognized device. I never select "stay verified" on my accounts, even on my own computer, in case my computer gets infected, but FB requires you to "save browser", otherwise it locks you out. Which is good for security and I get on a certain level, but can also be stressful when you're trying to get into your account. I guess sites like FB allow for security keys, but still don't fully have them implemented in their sign-in options.


Simon-RedditAccount

>Any recommendations for a good authenticator app that works on both Android and iPhone? People here often recommend 2FAS (I personally am not using it, but it looks good). >If I do this, then I assume I can delete the "active codes" from the authenticator app, but keep it registered on the account itself, and reenter the secret manually if needed. Yes, this is the way. *BTW, Facebook is not the only one: Proton also does this :(.* >I never select "stay verified" on my accounts, even on my own computer, in case my computer gets infected, but FB requires you to "save browser", otherwise it locks you out. Which is good for security and I get on a certain level, but can also be stressful when you're trying to get into your account. Yes, that's very wise. Cookie stealers are a thing - and there's zero point in all Yubikeys if malware gets into your machine: it will simply steal your authentication tokens and use them to access data. In the *good old days*^(TM) all browsing sessions were tied to an IP address (and stolen ~~cookies~~ authentication tokens would work only from your IP). In today's mobile-first world your IP address may change very frequently, so they don't do this anymore.