13 ms·

There are still a lot of questions I'm not clear with passkeys. How do you recover your keys if you lose your hardware? What happens if you lose your phone and

There are still a lot of questions I'm not clear with passkeys. How do you recover your keys if you lose your hardware? What happens if you lose your phone and have no extra trusted device? There will be no more phone number, and no more trusted device. Most MFA implementation, which heavily rely on phone number, will no longer work. And, for Yubikey, how do you backup? Do you need multiple Yubikeys? Do you need to manually make a copy of every keys? How do you know if the copy is synced with the main one?

Wool2662 3y ago
Recovery is the same as with passwords. Depends on the services policies. Passkeys and YubiKeys are different things. But generally it is recommemded to have a second YubiKey in a safe place and to register at least two keys on every service. Unfortunatly the implementations for using hardware keys are often pretty bad and require to activate alternate MFA which defeats the purpore of having a hardware token in the first place. For backing up a yubikey. If you manage it you get a massive bugbounty. The whole purpose of a yubikey is to not be able to read the embedded key. Yubikey guarantees physical posession of the key itself if you can prove knowledge of the key within. For passkeys: Only the authentication/creation process is specified. How passkeys are stored, shared, backedup etc is totally up to the implementing party. So Google and Apple will synchronize the keys using their existing password infrastructure. In the end the only difference to passwords is: - It is always randomly generated - You can have multiple passkeys per service - The application managing passkey is required to verify that passkeys are only transmitted to the service they were created for (making them phishing resistant) Passkeys are basically the point between passwords and hardware tokems like the yubikey. Safer than passwords and less safe than a yubikey but easily usabale by everyone.
snagg 3y ago
The short answer is that it's non standard and it depends on where the passkeys are stored. To be precise, the original WebAuthn standard did not account for a recovery mechanism at all and instead recommended adding multiple credentials to an account. Practically if the passkeys are stored in your iCloud Keychain, they are automatically synced across your Apple devices and the recovery mechanism is the recovery mechanism for iCloud. Similar consideration for Google/Chrome and other password managers. We wrote a relatively long blogpost about this + implementation and threat modeling considerations in case it's interesting: https://www.slashid.dev/blog/passkeys-security-implementation/#how-are-credentials-shared-and-stored https://www.slashid.dev/blog/passkeys-security-implementatio...
warkdarrior 3y ago
> How do you recover your keys if you lose your hardware? What happens if you lose your phone and have no extra trusted device? You get a new device, create new passkeys, and re-enroll into the online service again. > And, for Yubikey, how do you backup? See above. > Do you need multiple Yubikeys? Yes. > Do you need to manually make a copy of every keys? How do you know if the copy is synced with the main one? Apple's and Google's solutions both sync the passkeys via their cloud services. You cannot sync passkeys to Yubikeys, AFAIK.
decryption 3y ago
You need to add multiple passkeys so if one breaks, you can still access the service. Ditto for Yubikeys (which can be added as a passkey), you need more than one so if you lose it you can still access.
- zoomTo125 3y ago
  What happens if some websites don't allow you to add more than one passkey? Now, you need to keep track of which site has backup key, and which site doesn't have one. Also, the website needs to store multiple public keys now.
  - gabeio 3y ago
    > What happens if some websites don't allow you to add more than one passkey? Do you know of any which currently only allow one passkey?
    - woodruffw 3y ago
      I don't know about Passkeys specifically, but this is unfortunately common enough with WebAuthn rollouts. I'm not sure if it's true anymore, but Twitter for years only supported a single WebAuthn token.
      - dinvlad 3y ago
        I think even Amazon does that too still, such a shame
        JimDabell 3y ago
        If you’re referring to AWS, they added support for multiple MFA devices last year: https://aws.amazon.com/blogs/security/you-can-now-assign-multiple-mfa-devices-in-iam/ https://aws.amazon.com/blogs/security/you-can-now-assign-mul... Amazon’s shopping site also lets you set up multiple devices, but I’m not sure when they added that.
taberiand 3y ago
Those issues are applicable to using password management tools generally, rather than specifically to passkeys, aren't they? It sounds to me like passkeys are a simpler and more secure approach that apply within the existing context that requires unique complex passwords for every account. In terms of solving those issues, a 1Password account configured on multiple devices with a secured accessible backup of the emergency toolkit has been a robust solution in my experience
- crote 3y ago
  Not really. Every single password management tool allows plaintext export, so making a backup or transferring them to a different tool is trivial. You can even make a paper copy if you want to. Passkeys, not so much. They are opaque blobs which are never supposed to leave the manager.
- megous 3y ago
  > It sounds to me like passkeys are a simpler and more secure approach that apply within the existing context that requires unique complex passwords for every account. It does not to me. It requires complicated cryptography/tools. Passwords are just directly usable information that are much easier to reason about and work with. I can ask a question about passwords and I can figure out the answer or soltuion for myself without looking up any standards, implementation details of someone elses software or wading through heaps of marketing bullshit. Say I just want to temporarily share access to an account with someone? How? I know how with passwords. Give it out, change it later to revoke access. Say I want to export access to just select few accounts (and not the rest) I'll be needing when doing X away from my devices to limit the possiblility of forced compromise. I know how with passwords. How does backup and recovery work? Can I do it fully offline without invloving any third parties? Will I need anything other than a piece of paper? I know with passwords without looking anything up. If it's anything, it's not simple compared to passwords. It may be better in a few aspects (or not) but it certainly is not simpler to think about. The difference between password manager with unique passwords per account and this complicated crypto-thing seems very miniscule. You're either sharing a shared secret or you're proving a possession of a unique secret key per service. The only difference is how things need to be handled if the service itself is hacked. If it only stores pubkeys, the user's secret keys can still be used for authentication. The problem with this thinking is that attacker may have swapped user's key on the server with his own, hijacking the account anyway. In any case this doesn't lead to compromise of any other services used by the user. Also, FIDO2 can be used to force you to have to use a device you don't trully own for authentication, taking away your software freedom. Passwords can't be abused like this.
skybrian 3y ago
This will vary depending the provider, but you could think of passkeys getting synced between devices in much the same way that saved passwords get synced. Apparently Google's implementation stores an encrypted backup of the passkeys in your Google account [1]: > A single passkey identifies a particular user account on some online service. A user has different passkeys for different services. The user's operating systems, or software similar to today's password managers, provide user-friendly management of passkeys. From the user's point of view, using passkeys is very similar to using saved passwords, but with significantly better security. [...] > In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup. > To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys. Note, that restoring passkeys on a new device requires both being signed in to the Google Account and an existing device's screen lock. So, if you use Google to store passwords or passkeys, it would be a good idea to save backup codes for your Google account somewhere safe. (Like you should do anyway.) [1] https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html https://security.googleblog.com/2022/10/SecurityofPasskeysin...
- makeitdouble 3y ago
  > So, if you use Google to store passwords or passkeys, it would be a good idea to save backup codes for your Google account somewhere safe. (Like you should do anyway.) Alternatively, if you're locked out of your Google account, these passkeys are also dead as the encryption keys are bound to the account. And passkey reset through email for instance would also probably out of question if it was your primary email account... People should think long and hard about what services they assign passkeys with their Google accounts, it's a lot more binding than plain password or standard 2FA was.
  - skybrian 3y ago
    Yes, if your threat model is "what if Google locks me out?" Then you won't want to rely on a Google passkey as your only way of logging into a website. Ideally, websites will support multiple passkeys per account. I think having both Google and Apple passkeys would be sufficient since I think I would be unlikely to be locked out of both. Apparently Tailscale doesn't have multiple passkeys per account, but they recommend creating a backup admin account, and you could use a different kind of passkey for it.
dfabulich 3y ago
It's way simpler than you think. You reset your passkey the same way you'd reset your password. So, how do you reset your password when you forget it? Well, it depends. Some apps/sites just send you a password reset email. Apps/sites like those would reset your passkey the same way: they'd send you a passkey reset email, you'd click the link in the email, and they'd let you regenerate your passkey then and there. Some apps/sites try to do something cleverer, e.g. requiring additional factors to reset (MFA), or appointing a "trusted contact" user who can confirm your password reset, or asking "security questions" that only you know the answer to. Those apps/sites would put you through the same process to reset your passkey. "How do I reset my password when I forget it" is an infamous balancing act between user friendliness and strict security. The "reset my passkey" problem is exactly as hard, no easier and no harder, as the "reset my password" problem. (Of course, it's possible to have a site that has no way to reset your password, and just assumes that you'll never forget your password. Similarly, those sites could have no way to reset your passkey. In that case, the problem is as you say: there'd be no way to recover your keys if you lost access to them.)
- hartator 3y ago
  > Some apps/sites just send you a password reset email. Apps/sites like those would reset your passkey the same way: they'd send you a passkey reset email, you'd click the link in the email, and they'd let you regenerate your passkey then and there. Sounds like email based login with extra steps then.
- NikolaNovak 3y ago
  >>So, how do you reset your password when you forget it? Well, it depends. But I don't! I can write a password in any amount of low and high tech ways! I have them printed on paper in safe deposit box (my wife is bad with passwords, so this is safety if I should perish:), I have them in a password manager on USB sticks at home in a safe, I have them copied on my NAS and laptop and so on. Whereas passkeys, it seems from everywhere I read to be far more fragile, far more locked in to specific perishable hardware device and a specific vendor ecosystem, and very limited or no ways to handle passkeys in a low tech way or as a file/artifact to be backed up. Basically they assume I live on and with my phone. To put it bluntly: Passwords are something I can use if I show up naked at a stranger's house. They can be with me in and through an emergency (physical emergencies exist! Computer geeks forget about those!). Or more commonly, I can use them to check my email or comms if I forget my phone at a friend's house. Passkeys are... strictly worse?
n42 3y ago
if you're someone who uses a password manager already, and is generating unique random passwords for every website, the only appreciable difference between a passkey and what you do today is: - the passkey is never transmitted anywhere when logging in, eliminating the largest attack vectors for stealing passwords - you can no longer manually type the passkey in on random devices that don't have your password manager on it it's basically a really really long password you don't know with some added security guarantees. if you are not already doing this, then it requires adaptation to a world where you do not know your passwords and they are stored in a vault. this does mean ironing out account recovery for the account the vault is associated with. passkeys don't change that, though.
- crote 3y ago
  Not quite. The biggest difference is that websites seem to trust a passkey as both a password and a 2FA token at the same time. So security-wise it essentially means giving up 2FA altogether, as passkeys are about as secure as a password manager. So for anyone with a password manager and 2FA tokens, passkeys are a downgrade.
  - n42 3y ago
    that'd be more of a choice by the service operator than a design detail of passkeys, right?
  - stavros 3y ago
    This is wrong. Everyone here confuses "Passkeys the standard" with "some hardware implementation they've heard of". Yubikeys require a PIN, and the key is wiped if you enter it wrong ten times. Nobody stops you from making a hardware key that requires a long password to access it. You can do whatever you want, the standard doesn't care how you want to secure your keys. The standard just asks for a key at enrollment and then asks you to sign something with that key at signup. Anything after that is up to you and your choice of device. EDIT: I've written a short post to clarify a few misconceptions: https://www.stavros.io/posts/clearing-up-some-passkeys-misconceptions/ https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
- 3y ago
martin-adams 3y ago
I replaced my iPhone in-store and they transferred all my data. All my data except my Google Authenticator codes. I lost access to at least one account as a result and had to submit identity documents to recover the account. I now make sure I have backup codes stored somewhere. Interestingly, in the past couple of weeks, Google Authenticator can now back up to your Google account.
- tough 3y ago
  Authy is a nice alternative to google's Authenticator Was bought by Twilio, but still rocking. I love the plugin for raycast.app for it You set a master password and can login back with your phone number/master password in any device Much easier to not fuck up 2FA with it when changing phones
  - yrro 3y ago
    FreeOTP is another alternative - passphrase-encrypted backups can be saved to local or cloud storage and imported to FreeOTP running on another device.
aetch 3y ago
The passkey people won’t give you a straightforward answer because you won’t like the answer. If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”. If you lose your phone and delete your existing login cookies you don’t get access again. If email or sms is the recovery method, you might not be able to login on a new device or IP without your phone. But if email was the recovery method it’s just the same as sms 2FA which is reasonably secure and fail safe for the average person because there is a trusted third party in the loop…
- stavros 3y ago
  > If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”. That's an uncharitable interpretation. A more charitable way to say this is: You can choose between secure/uncloneable and less secure but more flexible. Passkeys let you make the choice and don't dictate it for you. Choose whatever better suits your use case. EDIT: I've written a short post to clarify a few misconceptions: https://www.stavros.io/posts/clearing-up-some-passkeys-misconceptions/ https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
  - jasonjayr 3y ago
    Who gets to choose? If it's the user, how do I as a user choose right now? If it's the service implementing passkeys, why wouldn't they force a solution that's easier for them (less testing/less support/less maintenance, by forcing attestation to a specific list of providers), instead of letting users have an option? Passkeys are an awesome solution to a difficult problem. But they are one bitflip away from eliminating user choice. Fix that problem, and I think folks here will jump on it in a hearbeat.
    - stavros 3y ago
      The user gets to choose. When enrolling an authenticator, you can choose what the authenticator is. I don't like Google's, so I use my phone and my Solo 2 as authenticators.

Wool2662 3y ago

Recovery is the same as with passwords. Depends on the services policies. Passkeys and YubiKeys are different things. But generally it is recommemded to have a second YubiKey in a safe place and to register at least two keys on every service. Unfortunatly the implementations for using hardware keys are often pretty bad and require to activate alternate MFA which defeats the purpore of having a hardware token in the first place. For backing up a yubikey. If you manage it you get a massive bugbounty. The whole purpose of a yubikey is to not be able to read the embedded key. Yubikey guarantees physical posession of the key itself if you can prove knowledge of the key within. For passkeys: Only the authentication/creation process is specified. How passkeys are stored, shared, backedup etc is totally up to the implementing party. So Google and Apple will synchronize the keys using their existing password infrastructure. In the end the only difference to passwords is: - It is always randomly generated - You can have multiple passkeys per service - The application managing passkey is required to verify that passkeys are only transmitted to the service they were created for (making them phishing resistant) Passkeys are basically the point between passwords and hardware tokems like the yubikey. Safer than passwords and less safe than a yubikey but easily usabale by everyone.

snagg 3y ago

The short answer is that it's non standard and it depends on where the passkeys are stored. To be precise, the original WebAuthn standard did not account for a recovery mechanism at all and instead recommended adding multiple credentials to an account. Practically if the passkeys are stored in your iCloud Keychain, they are automatically synced across your Apple devices and the recovery mechanism is the recovery mechanism for iCloud. Similar consideration for Google/Chrome and other password managers. We wrote a relatively long blogpost about this + implementation and threat modeling considerations in case it's interesting: https://www.slashid.dev/blog/passkeys-security-implementation/#how-are-credentials-shared-and-stored https://www.slashid.dev/blog/passkeys-security-implementatio...

warkdarrior 3y ago

> How do you recover your keys if you lose your hardware? What happens if you lose your phone and have no extra trusted device? You get a new device, create new passkeys, and re-enroll into the online service again. > And, for Yubikey, how do you backup? See above. > Do you need multiple Yubikeys? Yes. > Do you need to manually make a copy of every keys? How do you know if the copy is synced with the main one? Apple's and Google's solutions both sync the passkeys via their cloud services. You cannot sync passkeys to Yubikeys, AFAIK.

decryption 3y ago

You need to add multiple passkeys so if one breaks, you can still access the service. Ditto for Yubikeys (which can be added as a passkey), you need more than one so if you lose it you can still access.

zoomTo125 3y ago
What happens if some websites don't allow you to add more than one passkey? Now, you need to keep track of which site has backup key, and which site doesn't have one. Also, the website needs to store multiple public keys now.
- gabeio 3y ago
  > What happens if some websites don't allow you to add more than one passkey? Do you know of any which currently only allow one passkey?
  - woodruffw 3y ago
    I don't know about Passkeys specifically, but this is unfortunately common enough with WebAuthn rollouts. I'm not sure if it's true anymore, but Twitter for years only supported a single WebAuthn token.
    - dinvlad 3y ago
      I think even Amazon does that too still, such a shame
      - JimDabell 3y ago
        If you’re referring to AWS, they added support for multiple MFA devices last year: https://aws.amazon.com/blogs/security/you-can-now-assign-multiple-mfa-devices-in-iam/ https://aws.amazon.com/blogs/security/you-can-now-assign-mul... Amazon’s shopping site also lets you set up multiple devices, but I’m not sure when they added that.

taberiand 3y ago

Those issues are applicable to using password management tools generally, rather than specifically to passkeys, aren't they? It sounds to me like passkeys are a simpler and more secure approach that apply within the existing context that requires unique complex passwords for every account. In terms of solving those issues, a 1Password account configured on multiple devices with a secured accessible backup of the emergency toolkit has been a robust solution in my experience

crote 3y ago
Not really. Every single password management tool allows plaintext export, so making a backup or transferring them to a different tool is trivial. You can even make a paper copy if you want to. Passkeys, not so much. They are opaque blobs which are never supposed to leave the manager.
megous 3y ago
> It sounds to me like passkeys are a simpler and more secure approach that apply within the existing context that requires unique complex passwords for every account. It does not to me. It requires complicated cryptography/tools. Passwords are just directly usable information that are much easier to reason about and work with. I can ask a question about passwords and I can figure out the answer or soltuion for myself without looking up any standards, implementation details of someone elses software or wading through heaps of marketing bullshit. Say I just want to temporarily share access to an account with someone? How? I know how with passwords. Give it out, change it later to revoke access. Say I want to export access to just select few accounts (and not the rest) I'll be needing when doing X away from my devices to limit the possiblility of forced compromise. I know how with passwords. How does backup and recovery work? Can I do it fully offline without invloving any third parties? Will I need anything other than a piece of paper? I know with passwords without looking anything up. If it's anything, it's not simple compared to passwords. It may be better in a few aspects (or not) but it certainly is not simpler to think about. The difference between password manager with unique passwords per account and this complicated crypto-thing seems very miniscule. You're either sharing a shared secret or you're proving a possession of a unique secret key per service. The only difference is how things need to be handled if the service itself is hacked. If it only stores pubkeys, the user's secret keys can still be used for authentication. The problem with this thinking is that attacker may have swapped user's key on the server with his own, hijacking the account anyway. In any case this doesn't lead to compromise of any other services used by the user. Also, FIDO2 can be used to force you to have to use a device you don't trully own for authentication, taking away your software freedom. Passwords can't be abused like this.

skybrian 3y ago

This will vary depending the provider, but you could think of passkeys getting synced between devices in much the same way that saved passwords get synced. Apparently Google's implementation stores an encrypted backup of the passkeys in your Google account [1]: > A single passkey identifies a particular user account on some online service. A user has different passkeys for different services. The user's operating systems, or software similar to today's password managers, provide user-friendly management of passkeys. From the user's point of view, using passkeys is very similar to using saved passwords, but with significantly better security. [...] > In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup. > To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys. Note, that restoring passkeys on a new device requires both being signed in to the Google Account and an existing device's screen lock. So, if you use Google to store passwords or passkeys, it would be a good idea to save backup codes for your Google account somewhere safe. (Like you should do anyway.) [1] https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html https://security.googleblog.com/2022/10/SecurityofPasskeysin...

makeitdouble 3y ago
> So, if you use Google to store passwords or passkeys, it would be a good idea to save backup codes for your Google account somewhere safe. (Like you should do anyway.) Alternatively, if you're locked out of your Google account, these passkeys are also dead as the encryption keys are bound to the account. And passkey reset through email for instance would also probably out of question if it was your primary email account... People should think long and hard about what services they assign passkeys with their Google accounts, it's a lot more binding than plain password or standard 2FA was.
- skybrian 3y ago
  Yes, if your threat model is "what if Google locks me out?" Then you won't want to rely on a Google passkey as your only way of logging into a website. Ideally, websites will support multiple passkeys per account. I think having both Google and Apple passkeys would be sufficient since I think I would be unlikely to be locked out of both. Apparently Tailscale doesn't have multiple passkeys per account, but they recommend creating a backup admin account, and you could use a different kind of passkey for it.

dfabulich 3y ago

It's way simpler than you think. You reset your passkey the same way you'd reset your password. So, how do you reset your password when you forget it? Well, it depends. Some apps/sites just send you a password reset email. Apps/sites like those would reset your passkey the same way: they'd send you a passkey reset email, you'd click the link in the email, and they'd let you regenerate your passkey then and there. Some apps/sites try to do something cleverer, e.g. requiring additional factors to reset (MFA), or appointing a "trusted contact" user who can confirm your password reset, or asking "security questions" that only you know the answer to. Those apps/sites would put you through the same process to reset your passkey. "How do I reset my password when I forget it" is an infamous balancing act between user friendliness and strict security. The "reset my passkey" problem is exactly as hard, no easier and no harder, as the "reset my password" problem. (Of course, it's possible to have a site that has no way to reset your password, and just assumes that you'll never forget your password. Similarly, those sites could have no way to reset your passkey. In that case, the problem is as you say: there'd be no way to recover your keys if you lost access to them.)

hartator 3y ago
> Some apps/sites just send you a password reset email. Apps/sites like those would reset your passkey the same way: they'd send you a passkey reset email, you'd click the link in the email, and they'd let you regenerate your passkey then and there. Sounds like email based login with extra steps then.
NikolaNovak 3y ago
>>So, how do you reset your password when you forget it? Well, it depends. But I don't! I can write a password in any amount of low and high tech ways! I have them printed on paper in safe deposit box (my wife is bad with passwords, so this is safety if I should perish:), I have them in a password manager on USB sticks at home in a safe, I have them copied on my NAS and laptop and so on. Whereas passkeys, it seems from everywhere I read to be far more fragile, far more locked in to specific perishable hardware device and a specific vendor ecosystem, and very limited or no ways to handle passkeys in a low tech way or as a file/artifact to be backed up. Basically they assume I live on and with my phone. To put it bluntly: Passwords are something I can use if I show up naked at a stranger's house. They can be with me in and through an emergency (physical emergencies exist! Computer geeks forget about those!). Or more commonly, I can use them to check my email or comms if I forget my phone at a friend's house. Passkeys are... strictly worse?

n42 3y ago

if you're someone who uses a password manager already, and is generating unique random passwords for every website, the only appreciable difference between a passkey and what you do today is: - the passkey is never transmitted anywhere when logging in, eliminating the largest attack vectors for stealing passwords - you can no longer manually type the passkey in on random devices that don't have your password manager on it it's basically a really really long password you don't know with some added security guarantees. if you are not already doing this, then it requires adaptation to a world where you do not know your passwords and they are stored in a vault. this does mean ironing out account recovery for the account the vault is associated with. passkeys don't change that, though.

crote 3y ago
Not quite. The biggest difference is that websites seem to trust a passkey as both a password and a 2FA token at the same time. So security-wise it essentially means giving up 2FA altogether, as passkeys are about as secure as a password manager. So for anyone with a password manager and 2FA tokens, passkeys are a downgrade.
- n42 3y ago
  that'd be more of a choice by the service operator than a design detail of passkeys, right?
- stavros 3y ago
  This is wrong. Everyone here confuses "Passkeys the standard" with "some hardware implementation they've heard of". Yubikeys require a PIN, and the key is wiped if you enter it wrong ten times. Nobody stops you from making a hardware key that requires a long password to access it. You can do whatever you want, the standard doesn't care how you want to secure your keys. The standard just asks for a key at enrollment and then asks you to sign something with that key at signup. Anything after that is up to you and your choice of device. EDIT: I've written a short post to clarify a few misconceptions: https://www.stavros.io/posts/clearing-up-some-passkeys-misconceptions/ https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
3y ago

martin-adams 3y ago

I replaced my iPhone in-store and they transferred all my data. All my data except my Google Authenticator codes. I lost access to at least one account as a result and had to submit identity documents to recover the account. I now make sure I have backup codes stored somewhere. Interestingly, in the past couple of weeks, Google Authenticator can now back up to your Google account.

tough 3y ago
Authy is a nice alternative to google's Authenticator Was bought by Twilio, but still rocking. I love the plugin for raycast.app for it You set a master password and can login back with your phone number/master password in any device Much easier to not fuck up 2FA with it when changing phones
- yrro 3y ago
  FreeOTP is another alternative - passphrase-encrypted backups can be saved to local or cloud storage and imported to FreeOTP running on another device.

aetch 3y ago

The passkey people won’t give you a straightforward answer because you won’t like the answer. If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”. If you lose your phone and delete your existing login cookies you don’t get access again. If email or sms is the recovery method, you might not be able to login on a new device or IP without your phone. But if email was the recovery method it’s just the same as sms 2FA which is reasonably secure and fail safe for the average person because there is a trusted third party in the loop…

stavros 3y ago
> If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”. That's an uncharitable interpretation. A more charitable way to say this is: You can choose between secure/uncloneable and less secure but more flexible. Passkeys let you make the choice and don't dictate it for you. Choose whatever better suits your use case. EDIT: I've written a short post to clarify a few misconceptions: https://www.stavros.io/posts/clearing-up-some-passkeys-misconceptions/ https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
- jasonjayr 3y ago
  Who gets to choose? If it's the user, how do I as a user choose right now? If it's the service implementing passkeys, why wouldn't they force a solution that's easier for them (less testing/less support/less maintenance, by forcing attestation to a specific list of providers), instead of letting users have an option? Passkeys are an awesome solution to a difficult problem. But they are one bitflip away from eliminating user choice. Fix that problem, and I think folks here will jump on it in a hearbeat.
  - stavros 3y ago
    The user gets to choose. When enrolling an authenticator, you can choose what the authenticator is. I don't like Google's, so I use my phone and my Solo 2 as authenticators.