293
Passkeys Explained: The End of Passwords (sentientrant.com)
submitted 10 months ago by to c/technology@lemmy.world
225 comments fedilink hide all child comments
 

Passkeys are built on the FIDO2 standard (CTAP2 + WebAuthn standards). They remove the shared secret, stop phishing at the source, and make credential-stuffing useless.

But adoption is still low, and interoperability between Apple, Google, and Microsoft isn’t seamless.

I broke down how passkeys work, their strengths, and what’s still missing

you are viewing a single comment's thread
view the rest of the comments
[–] 110 points 10 months ago (22 children)

The biggest disadvantage:

Disadvantages of Passkeys

Ecosystem Lock-In – Passkey pairs are synced through each vendor’s respective clouds via end-to-end encryption to facilitate seamless access multiple devices.

More eggs in the American megacorp basket for more people, yay

  • permalink
  • fedilink
  • source
  • hideshow 22 child comments
    •
  • [–] 39 points 10 months ago (6 children)

    Currently I use a FOSS (I think?) password manager, BitWarden, that supports passkeys. I use it across Mac, Windows and Android so I'm while my passkeys are locked yo the password manager, I am not locked to any of the aforementioned megacorps.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 22 points 10 months ago (2 children)

    While I use and love bitwarden, it's not exactly foss. Although there is a foss implementation of their server backend

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 5 points 10 months ago

    A cursory search lead to this thread from 2024 https://community.bitwarden.com/t/concerns-over-bitwarden-moving-away-from-open-source-what-does-our-future-hold/74800

    where an employee stated

    I’ll note that policy wise nothing changed. The referenced issue is a packaging bug, but the goal still is the dual licensing model, with the core being open source, and some (mostly enterprise) features being source-available.

    Both the client and server are mostly open source. Some server features are paywalled. The alternative Vaultwarden server is fully open source, and much lighter on system resources.

    Have there been any recent licensing shenanigans with BitWarden?

  • permalink
  • fedilink
  • source
  • parent
  • [–] 12 points 10 months ago

    KeePassXC has begun rollout of their own implementation, and I’m pretty sure they’re considered FOSS.

    From a quick scan of the white paper, it appears they’re currently using on-device passkey discovery and otherwise “intercepting” passkey registration workflows, which I take to mean they aren’t originating the request as a passkey registrar. This may be the easiest method to satisfy FIDO’s dID requirements.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 9 points 10 months ago

    I use BitWarden too. OS , device and browser agnostic is a win

    But I imagine the vast amount of people will use whatever their platform is pushing, so Apple Google or Microsoft. And in 5 years time "3rd party passkeys" are not "secure enough" and blocked by the OS. (Ok that's a bit tinfoil hat, but Google's recent Android app developer verification scheme is fresh in mind)

  • permalink
  • fedilink
  • source
  • parent
  • [–] 8 points 10 months ago* (last edited 10 months ago) (2 children)

    This is a big one. Lock-in and the threat of provider blacklisting means it will remain a shortcut like SSO (“sign in with ____”) until we’ve established federated providers.

    On further reading, this may not be as far off as I thought. Passkey registration providers can be OS-level but browser and password manager based solutions were intended (overview from FIDO alliance). And it looks like KeePassXC has begun rollout of their own. If I’m reading correctly they currently “piggyback” off of an OS-based provider in various ways, so it’s not yet an end-to-end implementation, but these are early days.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 10 months ago (1 child)

    And they can be hardware based as well. I have a cheap Yubikey USB dongle, which works as a passkey vault as well. Completely OS independent.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 7 points 10 months ago (1 child)

    That's not the biggest disadvantage "if used properly." Any account you have should get a passkey on every device you own. Each device has it's own passkey system. If you have an iPhone, yeah, you get an apple passkey, but then if you have a windows laptop, you have a microsoft passkey, a FLOSS system will have it's own, and so on. You are already on whatever system would contain the passkey and can easily add different ones each time you get a new device.

    The biggest issue is that most people use a small number of devices (including many who use 1). Passkeys work best if you have many devices, so if you lose one, you just use another to access your services. If you have 1, you need to use recovery codes (and people don't save them).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 11 points 10 months ago

    A key for each service for each device is too impractical in real life.

    Getting a new device would mean logging in to hundreds of services to link up the new device. Or somehow keep track of which services have keys with which devices. And signing up to a new service would mean having to remember to generate keys for a a handfull of devices, some of which might not be available at the time (like a desktop computer at home when you are out). Or you risk getting logged out if you loose the one device that had a key for that particular service.

    I agree passkeys can make sense with something like BitWarden or KeyPassX. Something that is FOSS, and is OS and device agnostic, and let's you sync keys across devices. And should have independent backups too. Sync is not backup.

  • permalink
  • fedilink
  • source
  • parent
  • [+] -6 points 10 months ago (8 children)

    Your password hashes (assuming they even hash them) already live on their servers...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 15 points 10 months ago (7 children)

    Cool, they know the hash to that one service I signed up with them. Not every account ever.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 5 points 10 months ago* (last edited 10 months ago) (2 children)

    Your passkeys aren't synced to anything, so the passkey is no different than your password hash. They're device locked unless you use something like bitwarden, so you're no more dependent on American mega corps than you are right this second.

    I'm wrong.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 10 months ago (1 child)

    Dont they all sync to the respective cloud services?
    iOS vault -> synced apple cloud Android vault -> synced with Google cloud?
    Windows Hello -> synced with Microsoft account?

    And if they're not synced, that's even worse. Loose your device and loose your account. Or keep track of which of your 5 devices are have keys for which of your 150 accounts

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 0 points 10 months ago (3 children)

    Say you don't understand passkeys without saying you don't understand them...

    A passkey uses public key cryptography to secure your account instead of a password, it only grants you access to the one account you set it up for, and the account provider only holds your public key, you control the private key. Your passkey is a secure alternative to passwords because you CANNOT reuse it across services, cannot reasonably remember it, and the method of using it isn't by copying and pasting into a field like a password, so it isn't susceptible to the same attacks.

    If the provider loses your public key, they can't give you a challenge to verify you have the private key, so you lose access. Just like if they lose your password hash. It's an identical scenario.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 10 months ago (1 child)

    The assumption is that the native passkey manager on the device (iPhone, android, windows) would sync the passkeys (to Apple , Google, Microsoft) for protection against device failure and easy of use across devices. Or you risk loosing your accounts if you loose your device.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 10 months ago

    That would happen if you store your passwords there too...

    If you're proactive enough with your passwords to manually store them in your own vault, you can be proactive enough to not use the corporate vaults that don't allow exporting. This isn't a "downside" of passkeys, it's a downside of using the built in managers.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 10 months ago

    Everything you said is correct, but you misunderstood my point. I was referring to the fact that Google/Apple/whatever would hold your private key. In practical terms, it is barely different from the existing "Sign in with Google/Apple/whatever".

  • permalink
  • fedilink
  • source
  • parent