24 ms·

The cryptography behind passkeys

276 points by tatersolid 1y ago

toprerules 1y ago
[flagged]
- deleted 1y ago
  [deleted]
labadal 1y ago
I love passkeys. I love them being on my phone, requiring biometric authentication before unlocking. I just hate the vendor lock in that comes with it. Does anyone know the state of the standard wrt this? I know that they planned on doing something about it, just haven't kept up.
- hiatus 1y ago
  Can you expand on the vendor lock aspect? I have stored passkeys in my password manager, so they feel pretty portable to me. Is it that each service requires a unique passkey? That seems comparable to how each service would require its own TOTP seed.
  - supportengineer 1y ago
    Your password manager came from a vendor. As a thought exercise, switch vendors.
    - EnPissant 1y ago
      Bitwarden exports include passkeys.
      - dboreham 1y ago
        Have you actually tried exporting a passkey and importing it into another manager, then successfully authenticate with it?
        coldpie 1y ago
        KeepassXC lets you export the private key, which you can then back up or import into another KeepassXC instance. I have tested this, it works. I even shipped my exported private key off to a friend in another state and he was able to import it into a KeepassXC instance and log in to my account. Presumably another password manager could support importing the data, as it's just plaintext, though I don't know if any do. Unfortunately the spec authors think this export feature violates the spec and have threatened KeepassXC with being banned by authenticating websites[1]. This explicit support from the spec authors for client banning makes passkeys non-viable to me. The websites I log in to should not be able to restrict what clients I choose to use to manage my own data. [1] Spec author writes, "To be very honest here, you risk having KeePassXC blocked by relying parties. ... (RPs [may] block you, something that I have previously rallied against but rethinking as of late because of these situations)." https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407
        timeflex 1y ago
        Furthermore, they "heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers." Basically, do what we say or expect us to have our corporate sponsors write bad press about your security.
        EnPissant 1y ago
        Just having the data exported is peace of mind for me. It's trivial to import or convert to another format (even if not implemented now), so the worst-case scenario is acceptable, especially considering how much better Bitwarden + Passkeys are to every other form of authentication.
        cyberax 1y ago
        BitWarden is OpenSource. I did try importing the export using my own hosted BitWarden server, it worked.
    - koakuma-chan 1y ago
      https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/ https://blog.1password.com/fido-alliance-import-export-passk...
      - recursive 1y ago
        > we have no interest in creating a walled garden or locking you into 1Password. They have no interest... in collecting subscription fees? I'm a satisfied 1Password customer, but it's hard to take this claim seriously. What does it mean? They literally get paid. Isn't that the definition of an interest?
        koakuma-chan 1y ago
        Maybe they can get more customers by being based.
        dataflow 1y ago
        I think you're thinking of incentive not interest. Like how you can have incentives to steal from the supermarket, but still have no interest.
        recursive 1y ago
        I'm thinking of another definition of "interest". e.g. "have an interest in"
  - Steltek 1y ago
    From the article: > But how can websites know whether its users are using secure authenticators? Authenticators can cryptographically prove certain facts about their origins, like who manufactured it, by generating an attestation statement when the user creates a passkey; this statement is backed by a certificate chain signed by the manufacturer. How many scummy companies trot out "Let me protect you from yourself" to justify taking away their users' freedoms?
- yladiz 1y ago
  Unfortunately I don’t think there’s much to help with vendor lock in directly (like, you may or may not be able to export the private key(s) depending on the tool, and in some cases it’s definitely not possible like with a hardware key), but any website that supports passkeys supports WebAuthn in general so you shouldn’t have difficulty migrating to another tool if desired, although you would need to register again.
  - reginald78 1y ago
    Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service. Lock-in is built into the design. One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.
    - parliament32 1y ago
      Attestation is probably the best feature of passkeys. From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation. With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.
      - yladiz 1y ago
        But most passkey providers don’t return attestation data. How do you get the data?
        parliament32 1y ago
- supportengineer 1y ago
  For me, the only thing that makes passkeys viable is backing them up in the cloud and automatically syncing them across devices. Otherwise, I do not trust them.
  - TechDebtDevin 1y ago
    What do you use?
    - dboreham 1y ago
      Not the parent, but the obvious answer is: a hard token (e.g. Yubikey). After all passkeys are just a software emulation of the smart card / FIDO2 mechanism that's been around for many years.
      - crote 1y ago
        This doesn't solve the problem, unfortunately. The issue with hard tokens is that there is only one of them. By design, you can't back up a Yubikey's content to a second token. This means that any time you add 2FA to a new account, you must have all of your hard tokens in your possession to enroll them. This means a "one token on your keyring for daily use, one token in a safety deposit box as backup" approach isn't possible. Yubico did propose a potential solution five years ago[0], but that proposal seems to have gone nowhere. Until something like that gets implemented, FIDO2 (and by extension Passkeys) requires some form software implementation backed by cloud synchronization to actually be usable for the average person. [0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protocol-extension-to-simplify-backup-security-keys/ https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
        hanikesn 1y ago
        It works well enough. When you need to signup for a new service on the go, you can add your backup key when you get to it. Having the backup key in a safety deposit box hardly accessible seems like a non-goal given you protect it with a pin with a very limited number of retries.
- taeric 1y ago
  I always ask how you expect to defeat the vendor lock in? Effectively you have a secret that you are using to authenticate yourself. With pass keys managed by a vendor, you are trusting that vendor to manage your secret. If they are able to give your secret to someone else, then they can no longer confirm who all knows your secret. I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone. I'm also sure smarter people than me can surprise me with something, here. But secrets that can be shared historically tend to not be secrets for long.
  - blibble 1y ago
    > I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone. the spec actually supports this, it's called caBLE
    - taeric 1y ago
      Right, that flow seems somewhat straight forward and is roughly what I had in mind with my sentence. It doesn't really break you out of vendor involvement, though? You both still have to be fully in on the whole flow. Right? Asked differently, how does this get a vendor out of the picture?
    - lxgr 1y ago
      caBLE is not a specification for transferring secrets, but for mediating (temporary) access to them. But the FIDO alliance is apparently working on that: https://fidoalliance.org/fido-alliance-publishes-new-specifications-to-promote-user-choice-and-enhanced-ux-for-passkeys/ https://fidoalliance.org/fido-alliance-publishes-new-specifi...
      - taeric 1y ago
        I actually thought it was more for mediating confirmation of access to them. You don't share the secret with the new party, but you and the vendor both do a flow with them to confirm that someone claiming to be an identity can support that claim.
- jp191919 1y ago
  I use KeepassXC on my PC. Not sure of an app for mobile though.
- vngzs 1y ago
  I can register my Yubikeys on account.google.com (and around the web, e.g., fastmail.com) as passkeys. If you visit the account security page[0] and enable "skip password when possible", then you can log in to Google with only a Yubikey-backed passkey. If you have old Google creds on your Yubikey, you may have to first remove those creds from your account (because there are older and newer protocol choices, and with the old protocols enabled Google will not support passwordless login). Multiple yubikeys are required if you would like to have backups; there is no syncing between keys. For support matrices, see [1]. [0]: https://myaccount.google.com/security https://myaccount.google.com/security [1]: https://passkeys.dev/device-support/ https://passkeys.dev/device-support/
  - zikduruqe 1y ago
    I just use a Trezor One (yes, a bitcoin hardware wallet). I back up my 12 word seed phrase, and then I can restore any and all my TOTP/FIDO/passkeys with another one if needed.
  - kccqzy 1y ago
    I tried setting this up for a non-technical friend who was gifted multiple brand new Yubikeys. The goal is to log in to Google using any one of the Yubikeys with no password. Unfortunately doing so causes Chrome to pop up a dialog requesting a PIN for the Yubikey. How did you solve that problem? Searching online I found an answer on Stack Overflow stating that a PIN is required in this case: https://stackoverflow.com/a/79471904 https://stackoverflow.com/a/79471904 How did you bypass it? I also find it idiotic that it is required. A PIN is just a password in another name, so we are back to using Yubikeys as the second factor in 2FA rather than a password replacement.
    - AnotherGoodName 1y ago
      Passkeys need to have two factor to count as a passkey per the standard. Otherwise in theory someone could steal your key alone and get in (a big risk). You need to buy a newer Yubikey with biometrics to make this work. I assume you have an older Yubikey and Google is getting to the standard by asking for a PIN. I have a https://www.yubico.com/products/yubikey-bio-series/ https://www.yubico.com/products/yubikey-bio-series/ and it works with Google exactly like you want it to, no PIN required. It's completely understandable to require a PIN if you don't have one of these though.
- namro 1y ago
  On Android, Keepass2Android developer is working on supporting passkeys in the near future (https://github.com/PhilippC/keepass2android/issues/2099 https://github.com/PhilippC/keepass2android/issues/2099) but I'll be honest, I haven't dedicated enough time learning about passkeys to be sure the app will be able to support all implementations of passkeys and avoid vendor locking completely.
- iknowstuff 1y ago
  https://strongboxsafe.com/ https://strongboxsafe.com/
- shellcromancer 1y ago
  The FIDO Alliance (who wrote the WebAuthn spec with the W3C) has a draft specification for a format (Credential Exchange Format) and protocol (Credential Exchange Protocol) for migrating passkeys and other credentials [1]. I don't think this is implemented by any providers yet, but it's being worked on. [1] https://fidoalliance.org/specifications-credential-exchange-specifications/ https://fidoalliance.org/specifications-credential-exchange-...
  - conradev 1y ago
    The big remaining issue in my mind is this one: https://github.com/fido-alliance/credential-exchange-feedback/issues/24 https://github.com/fido-alliance/credential-exchange-feedbac... I am worried about providers blocking exports “because security”. That’s Apple’s favorite argument
- an_d_rew 1y ago
  1Password integrates with all pass keys on my iPhone, my Mac, and my Linux box. By a far and away WORTH the subscription, for me!
  - drdrey 1y ago
    doesn't that mean your passkeys are now about as secure as a regular password?
    - kbolino 1y ago
      A passkey is a public-private keypair strongly tied to a specific site. Sites never have access to the private key, and the key will never be presented for use on the wrong site. Those two advantages remain even if the passkey is stored in software or synced over the cloud.
    - radlad 1y ago
      Passkeys are highly phishing resistant in a way that passwords are not and are not subject to credential reuse (though password managers somewhat solve the first problem and almost entirely solve the latter problem.) In effect, though, 1Password is both something you have (the device with 1P logged in, login requires a Security Key that you don't memorize) and something you know (the master password) or are (typically biometrics can be used to unlock for a period after entering the master password.)
      - jcattle 1y ago
        How do Password managers solve phishing issues? Even just somewhat?
        josephcsible 1y ago
        Your password manager will autofill your credentials on the real site but not on a phishing site.
        1y ago
- idle_zealot 1y ago
  > Does anyone know the state of the standard wrt this? Exporting/transporting keys seems to be optional on the part of implementors, but my solution has been to use Bitwarden, so I at least get cross platform keys.
- normalaccess 1y ago
  I use Bitwarden to store my passkeys. Syncs to all my devices and just works. I have very few issues with it. Also for the truly paranoid, you can run the open-source back end on your own server if you want. https://bitwarden.com/passwordless-passkeys/ https://bitwarden.com/passwordless-passkeys/
  - secabeen 1y ago
    Can you export the passkeys to an importable form that your heirs can use to get into your accounts if you have passed away? Something that's sealed in an envelope inside a fire safe, for example? Every vendor I see offering a solution has no documented export option at all. Yes, you can use the legacy method to login, but an authentication stream that is not used regularly is one that will break, or will ask for a factor that I no longer have access to (I wouldn't know this because I only use passkeys.) I also expect that there will be sites that only accept passkeys eventually, even if the spec says you shoudln't.
    - SchemaLoad 1y ago
      Yes. If you use a password manager like 1password you can print out the recovery slip and write your password on it. Then all of your passkeys will be accessible.
      - internetter 1y ago
        I think you missed the point. If I have a passkey in 1password how does it become my passkey? As in, a passkey I can freely read, redistribute, and store in platforms that are not 1password. This is a property of passwords but not of passkeys.
        SchemaLoad 1y ago
        Today you can do that with open source password managers, and in the future there is a passkey portability specification coming to do passkey migrations between managers. But in general it's a bad idea to have the passkeys just sitting around in text files so the current managers are largely designed around preventing the tech support scammer from instructing grandma to dump the passkeys and email it to them.
- deleted 1y ago
  [deleted]
supportengineer 1y ago
[flagged]
- deleted 1y ago
  [deleted]
- 01HNNWZ0MV43FF 1y ago
  Or an investment, like VTSAX
joelthelion 1y ago
Are passkeys seeing any traction?
- nixpulvis 1y ago
  I don't use them much because I don't have a good way to register them and use them across device ecosystems. I use all three OSes regularly.
  - WorldMaker 1y ago
    1Password and BitWarden both support Passkey sync across all three OSes. Though if you are using Android regularly enough that may imply you trust Google implicitly enough that you probably could also just get away with Chrome Passkey sync which I'm told also works on all three OSes today. Or treat it as an opportunity to try to avoid "vendor lock-in"/increase redundancy by using all three to have 3+ passkeys in every service. Windows 11 can act as useful a bridge for bootstrapping all of your keys into a service: register for a site first on iOS or Android, use Windows 11 bluetooth to login via the first passkey, add a Windows passkey, and use Windows 11 bluetooth again to add the third. (Or some combo of that with the Windows iCloud Passwords app and/or Chrome.)
    - nixpulvis 1y ago
      I guess I'm partially just stubborn because I don't want to pay for what should be a cross platform standard.
      - coldpie 1y ago
        KeepassXC is a good client that lets you handle your data how you want. I wrote a pro-Passkey blog post here[1] that explains how to do your own syncing, though I later discovered Passkeys are explicitly built to support proprietary software vendor lock in and had to revoke my support. If you are concerned about being able to control your own data outside of the big tech ecosystem, I strongly recommend avoiding passkeys entirely. It is possible for now, but they are not built for that and the spec authors are actively hostile to you managing your own data. [1] https://www.smokingonabike.com/2025/01/04/passkey-marketing-is-lying-to-you/ https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
andrewmcwatters 1y ago
Passwords and password managers seem good enough to me, and TOTP support is everywhere now. Passkeys just feel like a standard written by large tech companies as a flywheel technology to keep me locked into whatever hardware and software ecosystem I'm already in since seemingly no one besides maybe Bitwarden supports exporting them. Which seems pointless, because I don't know of any platform that supports importing them. I am also getting tired of corporate white knight nerds defending trillion dollar companies telling me that portability isn't a concern.
- advisedwang 1y ago
  Password/TOTP does not protect you against phishing. The phishing site can forward the password and TOTP you type into the real system, gaining your access. FIDO/WebAuthn/Passkeys protect you against phishing, because of the origin binding mentioned in the article. On the phishing site, the required credential cannot be generated, and so no matter how convincing it is you can't accidentally give them a credential to forward. Phishing is what these systems were trying to defend against. Now if you were to say that the move from plain FIDO tied to a hardware key to passkeys tied to a Google account was a lock-in ploy ---- then I might be more inclined to agree.
  - jgalt212 1y ago
    > The phishing site can forward the password and TOTP you type into the real system, gaining your access. To me this seems harder to pull off than a fraudulent password reset (either via social engineering, or a hacked email account). My TOTP fell in the drink a few years back, and some accounts very hard to reset and others were too easy.
    - jerf 1y ago
      If you're targeting a particular person, social engineering is probably easier. If you just want to illicitly harvest some accounts, and aren't too worried about which ones, blasting out emails linking to hacked websites that fake the login & TOTP flow is very easy.
  - deleted 1y ago
solarkraft 1y ago
Challenge-response with asymmetric encryption is pretty much perfect. I wish all auth worked like SSH. Passkeys kind of take that concept, but make it suck. No backups. Terrible interoperability. The other day I attempted to create one on my Mac with Firefox. The system passkey popup came up and made me scan a QR code with my iPhone that had to be connected to the internet. Bitwarden (my iOS passkey manager, that part works well) did open, but after selecting the profile to create the passkey in, it errored out. No passkey for me.
- deleted 1y ago
  [deleted]
- pabs3 1y ago
  Look at KeepassXC, they let you do backups.
- zie 1y ago
  I implemented passkeys @ $WORK, and we rolled it out to our tech department only first. Nobody could make it work reliably, and troubleshooting it was basically impossible. The best you could do was just wipe their passkeys and have them try again. I've since disabled passkey support and we have no plans to attempt a new rollout anytime soon. As far as I can tell the only people that have "successfully" rolled out passkeys are the companies with effectively zero user support and they just refuse to support passkeys at all, so if they don't work for a particular user: whatever. TOTP is fully rolled out and well supported. Troubleshooting it is "hard", but at least it's possible. TOTP troubleshooting basically boils down to 3 things: * Server time * User Phone/device time(most users opt to use their phone to generate TOTP, but we don't care) * More than one TOTP saved for a given site(i.e. they didn't replace the old and created a new TOTP shared key) or not saved at all. Our tech/user support helpdesk can handle this but it took a lot of training. We built special tools. We still get requests from them when they get overwhelmed with the complexity. Passkey troubleshooting: * Mobile network, including bluetooth * Server network connectivity * Computer/device network, including BT connectivity to mobile device. Most tech support can't handle that much complexity at once. Shoot, most developers and tech "whiz" people can't either. The error messages one does get, if they are lucky, are very general and not helpful at all(last I checked). Passkeys are not currently fit for production where you have to support the users. I hope they get there. 1Password is the only client/device implementation of Passkeys that pretty much just works. It saves the passkey in the 1p vault, and the 1p vault can be synced across devices.
NeuroForge08 1y ago
[dead]
whartung 1y ago
So how well do passkeys work when you don't sync passwords. When you bounce from machine to machine. From OS to OS. How well does password recovery work in those scenarios?
- hanikesn 1y ago
  It works great with physical keys. Just need one as backup you leave at home.
  - lxgr 1y ago
    And you need to register for every new service you create an account with. It's also not a good idea to store the backup at home – house fires are unfortunately a thing, and chances are you might not have time to grab either your main or your backup key.
- AnotherGoodName 1y ago
  This is a really common question but it has a really simple answer. They still have recovery methods. You can optionally change these with most providers (go into account settings, setup something like a recovery codes and check the option to be completely passwordless) but regardless they still have recovery methods. As in i lost my phone and i recovered the account with a combination of my secondary email and old password. You might argue "but if they still have the recovery methods isn't my account only as secure as those" and to that i'd point out that you're still way ahead with passkeys simply by not entering passwords on a routine basis. The recovery methods tend to be two factor as well, just without passkeys as one of the two factors (hence email+password) so still a win over password alone in any case. Passkeys should be thought of as no different to the old two factor authenticators. I mean that's literally what they are, essentially the latest fido standard that allows devices such as your phone to be a hardware security key in its own right. These always had ways to do account recovery with all the providers.
- nixpulvis 1y ago
  Should allow multiple passkeys. So you have one per device.
BoredPositron 1y ago
[flagged]
- TingPing 1y ago
  I wouldn’t group app authentication like that with normal passkeys that are stored elsewhere.
  - vaylian 1y ago
    I wonder which authenticator was used in this case (YouTube app). Was it an authenticator that was part of the OS or something else?
    - WorldMaker 1y ago
      I believe the complaint here is that the YouTube app on iOS is an Authenticator for Google Accounts today. I didn't know it was doing anything Passkey-specific on iOS, but that wouldn't shock me given all the other ways it currently is the de facto Authenticator app for your Google Account on iOS today.
    - TingPing 1y ago
      Google is basically just using the YouTube app as a second factor.
- AnotherGoodName 1y ago
  Passkeys live at the OS level not the app level. If they have a passkey that allows access to their Google account the passkey will still be there if they uninstall Youtube.
  - wubrr 1y ago
    Passkeys don't live at any particular level. They can 'live' on a piece of paper, and get lost from wherever they are stored.
- deleted 1y ago
petedoyle 1y ago
Somewhat off-topic: Does anyone know the underlying strength of the keys used as the "root of trust" behind passkey synchronization on Android/iOS? I can't find a lot of documentation on this. It seems like they're synced between devices using client-side encryption, with keys derived from your phone's lock code (typically only 4-6 digits). Is it possible that the passkeys are fully random, but then encrypted with far less than 128/256 bits of actual entropy while being synchronized between devices? Could it be possible to brute force the keys server-side (IIUC, derived from 4-6 digit pins) with non-excessive amounts of compute? What am I missing?
- some_furry 1y ago
  Typically you see symmetric encryption keys (AES-256 is the most common), derived from a Password KDF. I don't know what Google or Apple do specifically, but that'd be my first guess.
- deleted 1y ago
  [deleted]
- NicolaiS 1y ago
  A confidential channel can be established over an insecure medium using e.g. Diffie-Hellman key exchange. To protect against MITM, an out-of-band QR/bluetooth can be used.
throw7 1y ago
Is there a "platform authenticator" that allows import/export of the actual origin site, keypair, and credential id in plaintext? The next would be a variety of platform authenticators able to import and use those? I don't want vendor lockin and I don't want proprietary third party cloud based backup/recovery. Today with totp, I store the plaintext otpauth url and I can use oathtool to spit out codes when needed on my desktop. My phone has aegis, but I don't use any cloud based backup/recovery. I switched from Google Authenticator after they implemented their cloud based syncing to google.
- deleted 1y ago
  [deleted]
- coldpie 1y ago
  KeepassXC allows this, but the spec authors think this is bad and have threatened KeepassXC with being banned by authenticating websites. The spec has explicit support for banning clients built in. https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407
- SchemaLoad 1y ago
  Some open source password managers provide this, but the general industry is working on a way to transfer between hosts without having to dump everything out in plain text in between.
nemoniac 1y ago
Why does a browser have to be in the loop?
- vaylian 1y ago
  Because the browser knows the internet domain that the login/registration is for. And the browser also provides the JavaScript API to talk to the authenticator (navigator.credentials.create and navigator.credentials.get).
lxgr 1y ago
> Generally, authenticators are “something you have.” Shameless plug: Here's one that is "something you know" :) https://github.com/lxgr/brainchain https://github.com/lxgr/brainchain It derives all keypairs from a passphrase, and rederives the private key from the key handle, similar to "stateless" hardware authenticators. Please don't use it for anything important – it's a fundamentally bad idea, similar to "brain wallets"; I only implemented it to figure out whether it was possible, and to improve my own understanding of the WebAuthN and FIDO specifications.
- calrain 1y ago
  There was an interesting Kickstarter a while ago called DiceKeys https://www.crowdsupply.com/dicekeys/dicekeys https://www.crowdsupply.com/dicekeys/dicekeys that provided a physical mechanism to store the seed of a passkey. If you then purchased passkeys that supported a custom seed, you could then replicate this seed to as many keys as you needed. There are always security tradeoffs, but this was a mechanism to store something in the real world that had about 115 bits of entropy, as 'Something you know'
- IshKebab 1y ago
  Why is it fundamentally a bad idea? Seems like a reasonably good idea to me.
  - lxgr 1y ago
    The problem is that most humans aren't capable of remembering high-entropy passwords, and are even worse entropy sources. Most password managers and passkey implementations solve that problem by either requiring additional entropy (such as 1Password's "secret key") and/or rate limiting retrieval attempts using some zero knowledge based PAKE server-side (i.e. you can only retrieve the encrypted database if you can prove knowledge of the password, and attempts are rate limited). My project does neither, so unless your passphrase is very high entropy, this approach is not secure. (And if it is high entropy – where are you storing that in turn?)
    - imiric 1y ago
leelou2 1y ago
[dead]
sschueller 1y ago
I see everyone putting their TOTP and second factor in the same vault as their username/password. Doesn't this defeat the purpose of the second factor to some degree?
- larsnystrom 1y ago
  Sure, but TOTP still defends against password leakage. So it’s still more secure than only using a password.
- immibis 1y ago
  It's about accountability sinks. The purpose of requiring the second factor is for the company to blame the user when the user gets hacked. It has very little to do with actual security.
- nabeards 1y ago
  Agreed Stefan! I keep mine in separate vaults for this purpose. I’m still not on board with passkeys yet, but the discussion here makes BitWarden seem like the best solution.
- augustl 1y ago
  With TOTP you have a private key that you don't transmit over the wire, as opposed to your password, so security is improved even though the password and TOTP is in the same vault.
- jeroenhd 1y ago
  It definitely does. But many people don't want to use actual 2FA, or they don't understand the point behind it. As long as their vault is properly secured (with actual MFA) that shouldn't be too much of a risk, until they get hit with a virus, of course.
- felixfoertsch 1y ago
  To me, this totally depends on your threat model. Generally, a one-time password is an additional security measure that prevents someone from going to a website and simply using obtained credentials (eg from a leak) or brute-forcing them. An attacker needs the second factor. If you store your 2FA secret alongside your password in a password manager, you still gain protection from these attacks. And it's very convenient. However, you also increase your attack surface: if they break into your password manager, your done. If your threat model allows it (mine does), this is still very secure and also very convenient.
gitroom 1y ago
[dead]
exabrial 1y ago
Have a question, is the TLSSessionState part of the signature nonce? I remember this being an anti-MITM measure for u2f
- whs 1y ago
  My friend asked similar question yesterday, and while I don't know the answer I wish it don't Most large websites are hosted behind a CDN or a load balancer, which terminate the TLS session and is a MITM between the customer and the actual backend server. The problem is similar to TLS Client Certificate - you can't forward these to the backend now, and the load balancer is not smart enough to validate the data so it is impossible to use it. In recent years (~5 years), AWS ALB and competitors gained the client certificate support now which pass the certificate information to your application in HTTP headers - instead of a standardized way of reading client certificate the servers has to read from non-standard headers. If passkeys is also passed as HTTP payload, I don't see believe that the LB would read the payload anytime soon. It might become a selling feature for IDP-as-a-service like Auth0 that you can't do it with IaaS.
  - exabrial 1y ago
    Damn, I didn't of that. Yeah, Cloudflare is [technically] a [friendly] MITM attack. Didn't think of that.
wagoYYP 1y ago
[dead]
mirajames98 1y ago
[dead]
mirajames98 1y ago
[dead]

276 points by tatersolid 1y ago

toprerules 1y ago

[flagged]

deleted 1y ago
[deleted]

labadal 1y ago

I love passkeys. I love them being on my phone, requiring biometric authentication before unlocking. I just hate the vendor lock in that comes with it. Does anyone know the state of the standard wrt this? I know that they planned on doing something about it, just haven't kept up.

hiatus 1y ago
Can you expand on the vendor lock aspect? I have stored passkeys in my password manager, so they feel pretty portable to me. Is it that each service requires a unique passkey? That seems comparable to how each service would require its own TOTP seed.
- supportengineer 1y ago
  Your password manager came from a vendor. As a thought exercise, switch vendors.
  - EnPissant 1y ago
    Bitwarden exports include passkeys.
    - dboreham 1y ago
      Have you actually tried exporting a passkey and importing it into another manager, then successfully authenticate with it?
      - coldpie 1y ago
        KeepassXC lets you export the private key, which you can then back up or import into another KeepassXC instance. I have tested this, it works. I even shipped my exported private key off to a friend in another state and he was able to import it into a KeepassXC instance and log in to my account. Presumably another password manager could support importing the data, as it's just plaintext, though I don't know if any do. Unfortunately the spec authors think this export feature violates the spec and have threatened KeepassXC with being banned by authenticating websites[1]. This explicit support from the spec authors for client banning makes passkeys non-viable to me. The websites I log in to should not be able to restrict what clients I choose to use to manage my own data. [1] Spec author writes, "To be very honest here, you risk having KeePassXC blocked by relying parties. ... (RPs [may] block you, something that I have previously rallied against but rethinking as of late because of these situations)." https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407
        timeflex 1y ago
        Furthermore, they "heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers." Basically, do what we say or expect us to have our corporate sponsors write bad press about your security.
      - EnPissant 1y ago
        Just having the data exported is peace of mind for me. It's trivial to import or convert to another format (even if not implemented now), so the worst-case scenario is acceptable, especially considering how much better Bitwarden + Passkeys are to every other form of authentication.
      - cyberax 1y ago
        BitWarden is OpenSource. I did try importing the export using my own hosted BitWarden server, it worked.
  - koakuma-chan 1y ago
    https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/ https://blog.1password.com/fido-alliance-import-export-passk...
    - recursive 1y ago
      > we have no interest in creating a walled garden or locking you into 1Password. They have no interest... in collecting subscription fees? I'm a satisfied 1Password customer, but it's hard to take this claim seriously. What does it mean? They literally get paid. Isn't that the definition of an interest?
      - koakuma-chan 1y ago
        Maybe they can get more customers by being based.
      - dataflow 1y ago
        I think you're thinking of incentive not interest. Like how you can have incentives to steal from the supermarket, but still have no interest.
        recursive 1y ago
        I'm thinking of another definition of "interest". e.g. "have an interest in"
- Steltek 1y ago
  From the article: > But how can websites know whether its users are using secure authenticators? Authenticators can cryptographically prove certain facts about their origins, like who manufactured it, by generating an attestation statement when the user creates a passkey; this statement is backed by a certificate chain signed by the manufacturer. How many scummy companies trot out "Let me protect you from yourself" to justify taking away their users' freedoms?
yladiz 1y ago
Unfortunately I don’t think there’s much to help with vendor lock in directly (like, you may or may not be able to export the private key(s) depending on the tool, and in some cases it’s definitely not possible like with a hardware key), but any website that supports passkeys supports WebAuthn in general so you shouldn’t have difficulty migrating to another tool if desired, although you would need to register again.
- reginald78 1y ago
  Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service. Lock-in is built into the design. One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.
  - parliament32 1y ago
    Attestation is probably the best feature of passkeys. From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation. With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.
    - yladiz 1y ago
      But most passkey providers don’t return attestation data. How do you get the data?
      - parliament32 1y ago
supportengineer 1y ago
For me, the only thing that makes passkeys viable is backing them up in the cloud and automatically syncing them across devices. Otherwise, I do not trust them.
- TechDebtDevin 1y ago
  What do you use?
  - dboreham 1y ago
    Not the parent, but the obvious answer is: a hard token (e.g. Yubikey). After all passkeys are just a software emulation of the smart card / FIDO2 mechanism that's been around for many years.
    - crote 1y ago
      This doesn't solve the problem, unfortunately. The issue with hard tokens is that there is only one of them. By design, you can't back up a Yubikey's content to a second token. This means that any time you add 2FA to a new account, you must have all of your hard tokens in your possession to enroll them. This means a "one token on your keyring for daily use, one token in a safety deposit box as backup" approach isn't possible. Yubico did propose a potential solution five years ago[0], but that proposal seems to have gone nowhere. Until something like that gets implemented, FIDO2 (and by extension Passkeys) requires some form software implementation backed by cloud synchronization to actually be usable for the average person. [0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protocol-extension-to-simplify-backup-security-keys/ https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
      - hanikesn 1y ago
        It works well enough. When you need to signup for a new service on the go, you can add your backup key when you get to it. Having the backup key in a safety deposit box hardly accessible seems like a non-goal given you protect it with a pin with a very limited number of retries.
taeric 1y ago
I always ask how you expect to defeat the vendor lock in? Effectively you have a secret that you are using to authenticate yourself. With pass keys managed by a vendor, you are trusting that vendor to manage your secret. If they are able to give your secret to someone else, then they can no longer confirm who all knows your secret. I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone. I'm also sure smarter people than me can surprise me with something, here. But secrets that can be shared historically tend to not be secrets for long.
- blibble 1y ago
  > I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone. the spec actually supports this, it's called caBLE
  - taeric 1y ago
    Right, that flow seems somewhat straight forward and is roughly what I had in mind with my sentence. It doesn't really break you out of vendor involvement, though? You both still have to be fully in on the whole flow. Right? Asked differently, how does this get a vendor out of the picture?
  - lxgr 1y ago
    caBLE is not a specification for transferring secrets, but for mediating (temporary) access to them. But the FIDO alliance is apparently working on that: https://fidoalliance.org/fido-alliance-publishes-new-specifications-to-promote-user-choice-and-enhanced-ux-for-passkeys/ https://fidoalliance.org/fido-alliance-publishes-new-specifi...
    - taeric 1y ago
      I actually thought it was more for mediating confirmation of access to them. You don't share the secret with the new party, but you and the vendor both do a flow with them to confirm that someone claiming to be an identity can support that claim.
jp191919 1y ago
I use KeepassXC on my PC. Not sure of an app for mobile though.
vngzs 1y ago
I can register my Yubikeys on account.google.com (and around the web, e.g., fastmail.com) as passkeys. If you visit the account security page[0] and enable "skip password when possible", then you can log in to Google with only a Yubikey-backed passkey. If you have old Google creds on your Yubikey, you may have to first remove those creds from your account (because there are older and newer protocol choices, and with the old protocols enabled Google will not support passwordless login). Multiple yubikeys are required if you would like to have backups; there is no syncing between keys. For support matrices, see [1]. [0]: https://myaccount.google.com/security https://myaccount.google.com/security [1]: https://passkeys.dev/device-support/ https://passkeys.dev/device-support/
- zikduruqe 1y ago
  I just use a Trezor One (yes, a bitcoin hardware wallet). I back up my 12 word seed phrase, and then I can restore any and all my TOTP/FIDO/passkeys with another one if needed.
- kccqzy 1y ago
  I tried setting this up for a non-technical friend who was gifted multiple brand new Yubikeys. The goal is to log in to Google using any one of the Yubikeys with no password. Unfortunately doing so causes Chrome to pop up a dialog requesting a PIN for the Yubikey. How did you solve that problem? Searching online I found an answer on Stack Overflow stating that a PIN is required in this case: https://stackoverflow.com/a/79471904 https://stackoverflow.com/a/79471904 How did you bypass it? I also find it idiotic that it is required. A PIN is just a password in another name, so we are back to using Yubikeys as the second factor in 2FA rather than a password replacement.
  - AnotherGoodName 1y ago
    Passkeys need to have two factor to count as a passkey per the standard. Otherwise in theory someone could steal your key alone and get in (a big risk). You need to buy a newer Yubikey with biometrics to make this work. I assume you have an older Yubikey and Google is getting to the standard by asking for a PIN. I have a https://www.yubico.com/products/yubikey-bio-series/ https://www.yubico.com/products/yubikey-bio-series/ and it works with Google exactly like you want it to, no PIN required. It's completely understandable to require a PIN if you don't have one of these though.
namro 1y ago
On Android, Keepass2Android developer is working on supporting passkeys in the near future (https://github.com/PhilippC/keepass2android/issues/2099 https://github.com/PhilippC/keepass2android/issues/2099) but I'll be honest, I haven't dedicated enough time learning about passkeys to be sure the app will be able to support all implementations of passkeys and avoid vendor locking completely.
iknowstuff 1y ago
https://strongboxsafe.com/ https://strongboxsafe.com/
shellcromancer 1y ago
The FIDO Alliance (who wrote the WebAuthn spec with the W3C) has a draft specification for a format (Credential Exchange Format) and protocol (Credential Exchange Protocol) for migrating passkeys and other credentials [1]. I don't think this is implemented by any providers yet, but it's being worked on. [1] https://fidoalliance.org/specifications-credential-exchange-specifications/ https://fidoalliance.org/specifications-credential-exchange-...
- conradev 1y ago
  The big remaining issue in my mind is this one: https://github.com/fido-alliance/credential-exchange-feedback/issues/24 https://github.com/fido-alliance/credential-exchange-feedbac... I am worried about providers blocking exports “because security”. That’s Apple’s favorite argument
an_d_rew 1y ago
1Password integrates with all pass keys on my iPhone, my Mac, and my Linux box. By a far and away WORTH the subscription, for me!
- drdrey 1y ago
  doesn't that mean your passkeys are now about as secure as a regular password?
  - kbolino 1y ago
    A passkey is a public-private keypair strongly tied to a specific site. Sites never have access to the private key, and the key will never be presented for use on the wrong site. Those two advantages remain even if the passkey is stored in software or synced over the cloud.
  - radlad 1y ago
    Passkeys are highly phishing resistant in a way that passwords are not and are not subject to credential reuse (though password managers somewhat solve the first problem and almost entirely solve the latter problem.) In effect, though, 1Password is both something you have (the device with 1P logged in, login requires a Security Key that you don't memorize) and something you know (the master password) or are (typically biometrics can be used to unlock for a period after entering the master password.)
    - jcattle 1y ago
      How do Password managers solve phishing issues? Even just somewhat?
      - josephcsible 1y ago
        Your password manager will autofill your credentials on the real site but not on a phishing site.
        1y ago
idle_zealot 1y ago
> Does anyone know the state of the standard wrt this? Exporting/transporting keys seems to be optional on the part of implementors, but my solution has been to use Bitwarden, so I at least get cross platform keys.
normalaccess 1y ago
I use Bitwarden to store my passkeys. Syncs to all my devices and just works. I have very few issues with it. Also for the truly paranoid, you can run the open-source back end on your own server if you want. https://bitwarden.com/passwordless-passkeys/ https://bitwarden.com/passwordless-passkeys/
- secabeen 1y ago
  Can you export the passkeys to an importable form that your heirs can use to get into your accounts if you have passed away? Something that's sealed in an envelope inside a fire safe, for example? Every vendor I see offering a solution has no documented export option at all. Yes, you can use the legacy method to login, but an authentication stream that is not used regularly is one that will break, or will ask for a factor that I no longer have access to (I wouldn't know this because I only use passkeys.) I also expect that there will be sites that only accept passkeys eventually, even if the spec says you shoudln't.
  - SchemaLoad 1y ago
    Yes. If you use a password manager like 1password you can print out the recovery slip and write your password on it. Then all of your passkeys will be accessible.
    - internetter 1y ago
      I think you missed the point. If I have a passkey in 1password how does it become my passkey? As in, a passkey I can freely read, redistribute, and store in platforms that are not 1password. This is a property of passwords but not of passkeys.
      - SchemaLoad 1y ago
        Today you can do that with open source password managers, and in the future there is a passkey portability specification coming to do passkey migrations between managers. But in general it's a bad idea to have the passkeys just sitting around in text files so the current managers are largely designed around preventing the tech support scammer from instructing grandma to dump the passkeys and email it to them.
deleted 1y ago
[deleted]

supportengineer 1y ago

[flagged]

deleted 1y ago
[deleted]
01HNNWZ0MV43FF 1y ago
Or an investment, like VTSAX

joelthelion 1y ago

Are passkeys seeing any traction?

nixpulvis 1y ago
I don't use them much because I don't have a good way to register them and use them across device ecosystems. I use all three OSes regularly.
- WorldMaker 1y ago
  1Password and BitWarden both support Passkey sync across all three OSes. Though if you are using Android regularly enough that may imply you trust Google implicitly enough that you probably could also just get away with Chrome Passkey sync which I'm told also works on all three OSes today. Or treat it as an opportunity to try to avoid "vendor lock-in"/increase redundancy by using all three to have 3+ passkeys in every service. Windows 11 can act as useful a bridge for bootstrapping all of your keys into a service: register for a site first on iOS or Android, use Windows 11 bluetooth to login via the first passkey, add a Windows passkey, and use Windows 11 bluetooth again to add the third. (Or some combo of that with the Windows iCloud Passwords app and/or Chrome.)
  - nixpulvis 1y ago
    I guess I'm partially just stubborn because I don't want to pay for what should be a cross platform standard.
    - coldpie 1y ago
      KeepassXC is a good client that lets you handle your data how you want. I wrote a pro-Passkey blog post here[1] that explains how to do your own syncing, though I later discovered Passkeys are explicitly built to support proprietary software vendor lock in and had to revoke my support. If you are concerned about being able to control your own data outside of the big tech ecosystem, I strongly recommend avoiding passkeys entirely. It is possible for now, but they are not built for that and the spec authors are actively hostile to you managing your own data. [1] https://www.smokingonabike.com/2025/01/04/passkey-marketing-is-lying-to-you/ https://www.smokingonabike.com/2025/01/04/passkey-marketing-...

andrewmcwatters 1y ago

Passwords and password managers seem good enough to me, and TOTP support is everywhere now. Passkeys just feel like a standard written by large tech companies as a flywheel technology to keep me locked into whatever hardware and software ecosystem I'm already in since seemingly no one besides maybe Bitwarden supports exporting them. Which seems pointless, because I don't know of any platform that supports importing them. I am also getting tired of corporate white knight nerds defending trillion dollar companies telling me that portability isn't a concern.

advisedwang 1y ago
Password/TOTP does not protect you against phishing. The phishing site can forward the password and TOTP you type into the real system, gaining your access. FIDO/WebAuthn/Passkeys protect you against phishing, because of the origin binding mentioned in the article. On the phishing site, the required credential cannot be generated, and so no matter how convincing it is you can't accidentally give them a credential to forward. Phishing is what these systems were trying to defend against. Now if you were to say that the move from plain FIDO tied to a hardware key to passkeys tied to a Google account was a lock-in ploy ---- then I might be more inclined to agree.
- jgalt212 1y ago
  > The phishing site can forward the password and TOTP you type into the real system, gaining your access. To me this seems harder to pull off than a fraudulent password reset (either via social engineering, or a hacked email account). My TOTP fell in the drink a few years back, and some accounts very hard to reset and others were too easy.
  - jerf 1y ago
    If you're targeting a particular person, social engineering is probably easier. If you just want to illicitly harvest some accounts, and aren't too worried about which ones, blasting out emails linking to hacked websites that fake the login & TOTP flow is very easy.
- deleted 1y ago

solarkraft 1y ago

Challenge-response with asymmetric encryption is pretty much perfect. I wish all auth worked like SSH. Passkeys kind of take that concept, but make it suck. No backups. Terrible interoperability. The other day I attempted to create one on my Mac with Firefox. The system passkey popup came up and made me scan a QR code with my iPhone that had to be connected to the internet. Bitwarden (my iOS passkey manager, that part works well) did open, but after selecting the profile to create the passkey in, it errored out. No passkey for me.

deleted 1y ago
[deleted]
pabs3 1y ago
Look at KeepassXC, they let you do backups.
zie 1y ago
I implemented passkeys @ $WORK, and we rolled it out to our tech department only first. Nobody could make it work reliably, and troubleshooting it was basically impossible. The best you could do was just wipe their passkeys and have them try again. I've since disabled passkey support and we have no plans to attempt a new rollout anytime soon. As far as I can tell the only people that have "successfully" rolled out passkeys are the companies with effectively zero user support and they just refuse to support passkeys at all, so if they don't work for a particular user: whatever. TOTP is fully rolled out and well supported. Troubleshooting it is "hard", but at least it's possible. TOTP troubleshooting basically boils down to 3 things: * Server time * User Phone/device time(most users opt to use their phone to generate TOTP, but we don't care) * More than one TOTP saved for a given site(i.e. they didn't replace the old and created a new TOTP shared key) or not saved at all. Our tech/user support helpdesk can handle this but it took a lot of training. We built special tools. We still get requests from them when they get overwhelmed with the complexity. Passkey troubleshooting: * Mobile network, including bluetooth * Server network connectivity * Computer/device network, including BT connectivity to mobile device. Most tech support can't handle that much complexity at once. Shoot, most developers and tech "whiz" people can't either. The error messages one does get, if they are lucky, are very general and not helpful at all(last I checked). Passkeys are not currently fit for production where you have to support the users. I hope they get there. 1Password is the only client/device implementation of Passkeys that pretty much just works. It saves the passkey in the 1p vault, and the 1p vault can be synced across devices.

NeuroForge08 1y ago

[dead]

whartung 1y ago

So how well do passkeys work when you don't sync passwords. When you bounce from machine to machine. From OS to OS. How well does password recovery work in those scenarios?

hanikesn 1y ago
It works great with physical keys. Just need one as backup you leave at home.
- lxgr 1y ago
  And you need to register for every new service you create an account with. It's also not a good idea to store the backup at home – house fires are unfortunately a thing, and chances are you might not have time to grab either your main or your backup key.
AnotherGoodName 1y ago
This is a really common question but it has a really simple answer. They still have recovery methods. You can optionally change these with most providers (go into account settings, setup something like a recovery codes and check the option to be completely passwordless) but regardless they still have recovery methods. As in i lost my phone and i recovered the account with a combination of my secondary email and old password. You might argue "but if they still have the recovery methods isn't my account only as secure as those" and to that i'd point out that you're still way ahead with passkeys simply by not entering passwords on a routine basis. The recovery methods tend to be two factor as well, just without passkeys as one of the two factors (hence email+password) so still a win over password alone in any case. Passkeys should be thought of as no different to the old two factor authenticators. I mean that's literally what they are, essentially the latest fido standard that allows devices such as your phone to be a hardware security key in its own right. These always had ways to do account recovery with all the providers.
nixpulvis 1y ago
Should allow multiple passkeys. So you have one per device.

BoredPositron 1y ago

[flagged]

TingPing 1y ago
I wouldn’t group app authentication like that with normal passkeys that are stored elsewhere.
- vaylian 1y ago
  I wonder which authenticator was used in this case (YouTube app). Was it an authenticator that was part of the OS or something else?
  - WorldMaker 1y ago
    I believe the complaint here is that the YouTube app on iOS is an Authenticator for Google Accounts today. I didn't know it was doing anything Passkey-specific on iOS, but that wouldn't shock me given all the other ways it currently is the de facto Authenticator app for your Google Account on iOS today.
  - TingPing 1y ago
    Google is basically just using the YouTube app as a second factor.
AnotherGoodName 1y ago
Passkeys live at the OS level not the app level. If they have a passkey that allows access to their Google account the passkey will still be there if they uninstall Youtube.
- wubrr 1y ago
  Passkeys don't live at any particular level. They can 'live' on a piece of paper, and get lost from wherever they are stored.
deleted 1y ago

petedoyle 1y ago

Somewhat off-topic: Does anyone know the underlying strength of the keys used as the "root of trust" behind passkey synchronization on Android/iOS? I can't find a lot of documentation on this. It seems like they're synced between devices using client-side encryption, with keys derived from your phone's lock code (typically only 4-6 digits). Is it possible that the passkeys are fully random, but then encrypted with far less than 128/256 bits of actual entropy while being synchronized between devices? Could it be possible to brute force the keys server-side (IIUC, derived from 4-6 digit pins) with non-excessive amounts of compute? What am I missing?

some_furry 1y ago
Typically you see symmetric encryption keys (AES-256 is the most common), derived from a Password KDF. I don't know what Google or Apple do specifically, but that'd be my first guess.
deleted 1y ago
[deleted]
NicolaiS 1y ago
A confidential channel can be established over an insecure medium using e.g. Diffie-Hellman key exchange. To protect against MITM, an out-of-band QR/bluetooth can be used.

throw7 1y ago

Is there a "platform authenticator" that allows import/export of the actual origin site, keypair, and credential id in plaintext? The next would be a variety of platform authenticators able to import and use those? I don't want vendor lockin and I don't want proprietary third party cloud based backup/recovery. Today with totp, I store the plaintext otpauth url and I can use oathtool to spit out codes when needed on my desktop. My phone has aegis, but I don't use any cloud based backup/recovery. I switched from Google Authenticator after they implemented their cloud based syncing to google.

deleted 1y ago
[deleted]
coldpie 1y ago
KeepassXC allows this, but the spec authors think this is bad and have threatened KeepassXC with being banned by authenticating websites. The spec has explicit support for banning clients built in. https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407
SchemaLoad 1y ago
Some open source password managers provide this, but the general industry is working on a way to transfer between hosts without having to dump everything out in plain text in between.

nemoniac 1y ago

Why does a browser have to be in the loop?

vaylian 1y ago
Because the browser knows the internet domain that the login/registration is for. And the browser also provides the JavaScript API to talk to the authenticator (navigator.credentials.create and navigator.credentials.get).

lxgr 1y ago

> Generally, authenticators are “something you have.” Shameless plug: Here's one that is "something you know" :) https://github.com/lxgr/brainchain https://github.com/lxgr/brainchain It derives all keypairs from a passphrase, and rederives the private key from the key handle, similar to "stateless" hardware authenticators. Please don't use it for anything important – it's a fundamentally bad idea, similar to "brain wallets"; I only implemented it to figure out whether it was possible, and to improve my own understanding of the WebAuthN and FIDO specifications.

calrain 1y ago
There was an interesting Kickstarter a while ago called DiceKeys https://www.crowdsupply.com/dicekeys/dicekeys https://www.crowdsupply.com/dicekeys/dicekeys that provided a physical mechanism to store the seed of a passkey. If you then purchased passkeys that supported a custom seed, you could then replicate this seed to as many keys as you needed. There are always security tradeoffs, but this was a mechanism to store something in the real world that had about 115 bits of entropy, as 'Something you know'
IshKebab 1y ago
Why is it fundamentally a bad idea? Seems like a reasonably good idea to me.
- lxgr 1y ago
  The problem is that most humans aren't capable of remembering high-entropy passwords, and are even worse entropy sources. Most password managers and passkey implementations solve that problem by either requiring additional entropy (such as 1Password's "secret key") and/or rate limiting retrieval attempts using some zero knowledge based PAKE server-side (i.e. you can only retrieve the encrypted database if you can prove knowledge of the password, and attempts are rate limited). My project does neither, so unless your passphrase is very high entropy, this approach is not secure. (And if it is high entropy – where are you storing that in turn?)
  - imiric 1y ago

leelou2 1y ago

[dead]

sschueller 1y ago

I see everyone putting their TOTP and second factor in the same vault as their username/password. Doesn't this defeat the purpose of the second factor to some degree?

larsnystrom 1y ago
Sure, but TOTP still defends against password leakage. So it’s still more secure than only using a password.
immibis 1y ago
It's about accountability sinks. The purpose of requiring the second factor is for the company to blame the user when the user gets hacked. It has very little to do with actual security.
nabeards 1y ago
Agreed Stefan! I keep mine in separate vaults for this purpose. I’m still not on board with passkeys yet, but the discussion here makes BitWarden seem like the best solution.
augustl 1y ago
With TOTP you have a private key that you don't transmit over the wire, as opposed to your password, so security is improved even though the password and TOTP is in the same vault.
jeroenhd 1y ago
It definitely does. But many people don't want to use actual 2FA, or they don't understand the point behind it. As long as their vault is properly secured (with actual MFA) that shouldn't be too much of a risk, until they get hit with a virus, of course.
felixfoertsch 1y ago
To me, this totally depends on your threat model. Generally, a one-time password is an additional security measure that prevents someone from going to a website and simply using obtained credentials (eg from a leak) or brute-forcing them. An attacker needs the second factor. If you store your 2FA secret alongside your password in a password manager, you still gain protection from these attacks. And it's very convenient. However, you also increase your attack surface: if they break into your password manager, your done. If your threat model allows it (mine does), this is still very secure and also very convenient.

gitroom 1y ago

[dead]

exabrial 1y ago

Have a question, is the TLSSessionState part of the signature nonce? I remember this being an anti-MITM measure for u2f

whs 1y ago
My friend asked similar question yesterday, and while I don't know the answer I wish it don't Most large websites are hosted behind a CDN or a load balancer, which terminate the TLS session and is a MITM between the customer and the actual backend server. The problem is similar to TLS Client Certificate - you can't forward these to the backend now, and the load balancer is not smart enough to validate the data so it is impossible to use it. In recent years (~5 years), AWS ALB and competitors gained the client certificate support now which pass the certificate information to your application in HTTP headers - instead of a standardized way of reading client certificate the servers has to read from non-standard headers. If passkeys is also passed as HTTP payload, I don't see believe that the LB would read the payload anytime soon. It might become a selling feature for IDP-as-a-service like Auth0 that you can't do it with IaaS.
- exabrial 1y ago
  Damn, I didn't of that. Yeah, Cloudflare is [technically] a [friendly] MITM attack. Didn't think of that.

wagoYYP 1y ago

[dead]

mirajames98 1y ago

[dead]

mirajames98 1y ago

[dead]