7 ms·

I am a bit biased (I've been working on passkeys for about a year now on https://bulwark.id https://bulwark.id), but I don't think that passkeys either should n

• JohnFen 3y ago
  > From a technological standpoint, passkeys are just as versatile as passwords I don't need special software to authenticate with a password, and passwords can be used to authenticate on very low-grunt devices. So not quite as versatile. I'm not arguing against passkeys at all, but passwords are much more versatile and convenient than them, albeit at the cost of being more difficult to use securely.
  • katbyte 3y ago
    i kinda see passkeys being useful for all those websites i really don't care about and just have a short simple password for/something saved in a password manager i use once in a blue moon and wouldn't be too upset to loose access.
    • boring_twenties 3y ago
      I don't see how passkeys would be better for that (or for anything, really) than simply letting the browser autogenerate a password and save it in its built-in password manager?
      • acdha 3y ago
        It’s much faster, doesn’t require you to tweak the generated password to fit their weakening requirements, and you’re never nagged to rotate it. I have used a password manager since the 2000s and for most sites like that I end up hitting the forgot password flow because they broke their password database or use inactivity expirations. You also don’t have problems when their front end developers break their form entry or validation for your password manager, which is common, and pushing this removes the justification for adding insecure MFA systems like SMS or emailed codes.
      • WorldMaker 3y ago
        Think of passkeys as the browser autogenerating a password with much higher overall entropy (whose secret details can't be leaked if that website's database were to be compromised). The UX is basically the same: as a user, let the browser deal with it. Let the browser's password manager/keychain restore/backup/sync it. The overall security is higher (higher entropy, public-key cryptography). The DX for building that website is a little more complex, but not arduously more complex (especially for any website already previously supporting FIDO and WebAuthn standards for 2FA).
        • boring_twenties 3y ago
          How is it higher entropy? What's stopping a password from having 128 or 256 bits of entropy in it? If the website is compromised it doesn't matter either way since that password is not shared with any other site. And the UX doesn't seem to be the same at all. For one, according to comments in this very thread, Google and Apple aren't making these portable or user-backupable. On top of that, to log in from a new device, with a password I just need to get it from the password manager and enter i t on the new device. I can copy the entire password store to the new device, and immediately be sure that I can access any and all accounts. Unless I'm grossly misunderstanding, that's not possible with passkeys, or at least not in the Google and Apple implementations? I would have to generate a new passkey on the new device, then enroll it with the website, and I would have to do that separately for each individual website/account? Not to mention, both devices have to be online at the same time? That's completely unworkable.
  • xp84 3y ago
    > I don't need special software Technically correct (the best kind of correct!), but in my recent experience with 4 different password managers[1], there are some pretty big catches: It’s incredibly time consuming and error-prone to init and use good passwords correctly and to maintain them without any password manager, aka “special software” with deep hooks in your OSs and browsers that allow it to fill and save passwords efficiently. And it’s nearly as bad to do so if you don’t have a cross-platform one unless you’re all in on a single narrow ecosystem like Apple. Suddenly I would be on a different platform and I’m like, using telegram to shoot myself messages with passwords from my phone. And don’t forget the absurd password ‘rules’ (sorry, “/“ is not on our list of 5 ‘special characters’) that are differently-misguided on every site. This is a huge blow to “passwords are convenient.” And even if you do have one that’s cross-platform my experience recently has confirmed that if you’re not using the OS vendor’s own solution, you’re guaranteed a buggy, unreliable, slow, second-class experience on Apple devices because they don’t allow anyone else to work as efficiently, probably for some combination of “security” and “battery life” reasons. Similarly, even first party password managers are laggy or fail to trigger correctly in about 1/3 of “Apps” (they work fine on websites) This means with passwords I’m left completely without a solution already since I’m sure as hell: 1. Not using Safari. 2. Not limiting myself to Apple only. So I have to pick a 3rd party solution with its buggy trade offs. Anyway, if passkeys are implemented universally, at least I could ditch password managers and just have 1 passkey each in the Apple and a cross-platform storage location, and never have to deal with updating them. [1]: I tried, in order: iCloud (omg what a horrendous b—-h to “export” from!), Dashlane, 1Password, Microsoft.
    • deleted 3y ago
      [deleted]
• stavros 3y ago
  Can you elaborate a bit on how Passkeys differ from WebAuthn/FIDO2? I know they're an implementation of it, but I don't know how pluggable they are. Will I be able to use my soft- or hardware WebAuthn authenticator on any site that uses Passkeys? I tried to add a FIDO2 key to Google's passkey page and failed already, so it doesn't seem entirely compatible out of the box.
  • cmdli 3y ago
    Passkeys are just the product-facing name for WebAuthN, which FIDO2 devices should support. Theoretically, any FIDO2 device should support WebAuthN and therefore be used for websites, but right now there are a number of different implementations that each have their own quirks. I am surprised that the FIDO2 key doesn't work on Google, but it probably just means that there is a bug somewhere in the implementation.
    • stavros 3y ago
      Thanks, that's what I figured. Here's to a future where WebAuthn is everywhere and my password manager can finally only need to store one key.
    • crote 3y ago
      This is not true, Passkeys is the marketing term for Webauthn with resident keys.
      • sebk 3y ago
        It's surprisingly difficult to figure what what a passkey is, precisely. I think there's a bit of a terminology issue. FIDO marketing materials talk about passkeys in the same way you do, a resident key (now called discoverable credentials). Some other materials say that passkey with no other qualifier is a multi-device passkey, meaning it's backed up by a sync fabric. (e.g. the short version here https://passkeys.dev/docs/reference/terms/#passkey https://passkeys.dev/docs/reference/terms/#passkey). Others, like Google did in their blogpost last week and the long version of that link, say that a passkey is a multi-device passkey that also has user verification (so it can be used for passwordless and not just 2FA/2SV).
• crote 3y ago
  I believe the biggest issue is that they are functionally passwords when used in a user-friendy way, but security-wise they are still viewed as MFA. When I use a non-proprietary passkeys implementation, it is essentially just a file on my harddrive, just like my KeePass database containing my passwords is. It is still a huge single-point-of-failure, and unlike proper MFA should not be treated as if it provides any additional security. Switching to passkeys is a downgrade from password+2FA token and should be treated as such.
  • noahtallen 3y ago
    I don’t think it’s a complete downgrade. You get phishing protections, single-site super-strong “passwords”, if the public key is leaked, it doesn’t impact you, etc. If the only attack vector is someone having to crack into your encrypted hard drive, and then decrypt whatever stores the passkeys… that’s still both pretty strong and also probably not the biggest security issue most people face. The biggest issues most non-tech people face are 1. reusing simple passwords, and 2. getting phished through similar UIs/emails. It’d be much better for most people to use passkeys.
  • sebk 3y ago
    Passkeys are not quite passwords even if backed by software and stored in the same memory space as other applications running on the OS. They're still asymmetric, cryptographically secure, and domain-bound. It's true that being "just a file on your hard drive" changes the threat model as compared to a hardware security key, but that file is wrapped at rest, potentially with a hardware security key as well. Whether it's a downgrade or not depends on your specific threat model, and whether it's a downgrade for you or for the userbase at large.
    • manquer 3y ago
      All of that encryption at rest applies to any password manager too. In comparison with a password manger managed password +2FA , just software passkeys are a downgrade. Whether it is acceptable downgrade can depend on your threat model, the fact that it downgrade or not is not
• sebk 3y ago
  WebAuthn lets RPs reason about the strength and capabilities of the authenticator at registration time. With a mechanism like a shared file format and standard ways of transferring them, those mechanisms would be undermined. With hardware-backed multi-device Passkeys, the entire sync fabric becomes the authenticator. Apple and Google currently zero out attestation data, but you can imagine a scenario where attestation data matching the device is presented for single-device passkeys and DPK, but a different attestation key is used for multi-device passkeys that represents the entire sync fabric. Instead, with all these password manager vendors not wanting to be left out, and a good portion of the userbase either not being entirely in a single vendor's ecosystem and not wanting to deal with the hassle of QR codes and registering each fabric in each RP, or simply distrusting the big vendors like we see here in this thread, I can see cross-platform virtual authenticators like the one you're working on becoming more common, and I don't think it's unlikely that the OSs will offer APIs to back these keys with TPMs/Secure Enclaves, and will allow you to replacethe built-in passkey manager with a third-party, much like they do with password managers today. If software-based authenticators want to support import/export capabilities, they don't quite need an open standard, in the same way there isn't one for passwords but you can import/export passwords with any major password manager.
  • cmdli 3y ago
    This is something that I think is a bit of a security tradeoff. Hardware-based keys are absolutely more secure than software ones, but they come with significant usability limitations. I worry that if RPs restrict themselves to only hardware-based keys, then that will kill adoption of passkeys in general and we will be stuck with passwords. Software passkeys are already a significant security upgrade to passwords, and so I would like to see them gain adoption. In my ideal scenario, users would be able to use software passkeys for most websites, and then have hardware authenticators either for the vault of software passkeys or directly for a few key websites.
    • sebk 3y ago
      Yeah don't get me wrong, I wasn't disagreeing. I think the lack of interoperability is a major risk to adoption, but I also understand why we don't have interoperability today and why we likely never will. What I'd like to see password manager vendors like you do, though, is to push FIDO and the OS vendors to have richer APIs for interacting with the hardware components that can back keys. To be clear, I don't want to use Bulwark to manage or export passkeys in my iCloud Keychain (I'm confident that will never happen), but I want Bulwark to be able to create a passkey that is backed by a secure element in Mac OS, and then be able request a wrapped version of that key to be exported, and later imported into a TPM running on a Windows OS.