7 ms·

i think they could be great for websites i don't really care about and already use weaker passwords. but for important sites where security matters? nope

aseipp 3y ago
Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. For "important sites where security matters" they are literally better in every way than a password, it doesn't matter how weak or strong. You can use a pure software solution, and soon probably even your existing password manager, to handle them. Again, you should think of them as replacing passwords. You can still enforce post-authentication requirements like SMS or calls to known numbers, bank account deposits, magic follow-up links in a confirmed email, push notifications, etc. SSH keys are the best analogy. "SSH keys are great for useless servers, but for important servers? no way!" No! That's exactly where SSH keys are most useful. And you also happen to encrypt your SSH keys locally with a password, don't you? This is the exact same principle, but applied to arbitrary websites. Nobody goes around randomly generating login passwords for SSH'ing into each and every server they use, and then pats themselves on the back.
- Eduard 3y ago
  > Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. Let's assume a "passkey device emulator" written in software; quite realistic IMHO for someone to use, considering the cost of hardware authentication devices (phones, YubiKey etc.) If someone using such emulator gets hacked and has their passkey emulator data stolen, is there anything preventing a credential leak?
  - aseipp 3y ago
    The software you're describing is called a "Password Manager", and several do support passkeys already in newer versions. There's no real "emulation." 1Password 8 supports them just fine, your browser has APIs so third-party software can integrate exactly for that. So, the answer to your question is pretty much "exactly the same scenario as your password manager getting leaked", which is basically unsurprising and already well understood when you frame it this way, I think. The particular case I was referring to (and probably should have been clearer about) was when a website operator gets hacked; in that case the only information an attacker gains from your user account is a public key, which isn't of much use. But like, that's actually a major issue in practice, because the value of hacking a service operator is often far greater than just one user. That exact scenario was one of the motivations for using password managers in the first place, too, to mitigate operators getting hacked and common passwords getting reused between users, thus turning a single compromise for many users into multiple compromises for many users. So, it all has come full circle in a sense; now we've finally recognized that instead than shoehorning passwords into becoming psuedo-random strings that might as well be base64 encoded bytes from /dev/urandom, you might as well go "all the way" and just get those raw bytes from /dev/urandom directly and then use them as key material for a public key exchange. Again, the best analogy is to just imagine that you used SSH keys to log into a website. That's all this is. It's software. Then you remember: oh yeah, SSH key synchronization and enrollment across machines sucks ass, and normal people would hate doing it. Hey, you know what, we already use passwords to encrypt SSH keys -- so what if we added a storage synchronization layer between your machines to keep those SSH private keys synchronized, encrypted with that password, and stored using $FAVORITE_SERVICE_PROVIDER? That's pretty much it, in a nutshell. You just reinvented modern Passkeys. Most of the threat models at that point are well understood: what service provider or software to choose, how secure is the local encryption, should you use two-factor authentication to further improve unlock safety, etc.
    - autoexec 3y ago
      > when a website operator gets hacked; in that case the only information an attacker gains from your user account is a public key, which isn't of much use. How is that different from situations where a website gets hacked and all the attacker gets is a well-hashed version of a unique password? In either case it isn't doing the attacker any good.
      - aseipp 3y ago
        It isn't, if the website implements it correctly, and the user uses a strong password, and there's a salt -- then yes, probably, they aren't getting much information. But if you could always rely on all of those, a lot of these problems would not ever be problems; alas, here we are, in this particular world. And if passkeys were only equal to passwords in practice, it would still -- IMO -- be worth upgrading to passkeys because they're, for this case, a better foundational basis to work around (public key cryptographic authentication versus sharing symmetric keys), and less error prone for users and operators. But in practice they are aiming to actually be better, faster to use, and more secure since every Passkey implementation is basically designed around syncing (iOS 17 TBD) and device authentication, and they are phishing resistant, which seemingly nothing else can hope to solve so we just gave up on solving it and don't ever mention it because it's the users fault that they did it. (No, seriously, did we all just give up on that entirely?) I will keep invoking the SSH key analogy, here. Very few people are paranoid about SSH keys being some weird psychological "trick" to take Freedom Loving Passwords away from them or whatever (not referring to you), and most people aren't splitting hairs over "Well, you know, if /etc/shadow and /sbin/login the system is set up correctly, and the machine is secure, then there's no real point to using an SSH key, because my password is safe on disk, and you can just trust that." OK, and? It doesn't matter whether you're logging in as root or a normal user, on your VPS or a friends box. People just use SSH keys instead. Everything works around SSH keys today. People do not want to deal with your secret key material. Passkeys are in many ways just SSH keys for the browser. There really isn't much here to think about when you look at it like this, because the whole basic idea has been around for decades now.
      - dwaite 3y ago
        With passwords, the user choosing a unique password or the site choosing to use a recommended process for hashing passwords is proper hygiene, but requires knowledge and is a choice. With passkeys, there is no opportunity to have bad hygiene. The user does not pick a password. The site does not have secrets to store unprotected.
  - chlorion 3y ago
    If the device is exploited, they can also install a keylogger and steal regular passwords. I think this would be where hardware based authentication via TPM or similar would be useful. This would allow the device to be taken over and the private key material would still be safe.
    - dwaite 3y ago
      They could also look at your SMS and Email OTP. The secrets in the password vault can be used to authenticate and change settings in various trusted systems, like configuring call forwarding. Cloud-based backups or the local filesystem could theoretically be inspected for software TOTP secrets. Responding to the potential for bad user choices and full compromise quickly gets you to the point where your options are separate hardware or requiring in-person confirmation. NIST 800-63-3 AAL3 is probably most appropriate to look at if your risk profile mandates this.
- katbyte 3y ago
  for my important accounts the password is long, unique, and not recorded anywhere, that is one way that passkeys are not better. there is literally no credentials to leak until i go login and type it where passkeys are recorded somewhere? otherwise how would they work. someone gets my private SSH key that is a bad time (which is why we password protect them, or at least you really should be) to follow the ssh analogy, you (should) only use SSH keys to gain access to a unprivileged user account at which point you elevate permissions via sudo and another factor (password/MFA) and really theres an argument to be made the unprivileged account should have MFA for login as well. nobody puts their ssh public key in the root account of a server and pats them selves on the back that its secure so why would passkeys be any different for accounts you truly need to be secure?
  - aseipp 3y ago
    You seem to be making up a bunch of scenarios that aren't really relevant (what if someone did this and that with sudo, what if the bytes were stored here). You don't want to understand the actual security model, which is fine, but only on Hacker News can someone say with confidence "actually unphishable public keys that can't be leaked, are not good for security." Again, you might as well be arguing against SSH keys. That won't get topped for a while.
    - someplaceguy 3y ago
      I understood the parent poster to be saying that since his passwords are unique and are not stored anywhere, then if his device were to be compromised, the attacker could only steal a password once it is manually entered, in which case it wouldn't automatically compromise his other passwords. Conversely, if he were to use a password manager on his device to store passkeys, the attacker could compromise all his passkeys once one of them is used. Admittedly, it is an unusual use case (I mean, how do you generate and remember unique, sufficiently long and random passwords without storing them anywhere?) but I can see how passkeys could be worse for him if this is really what he does.
      - katbyte 3y ago

aseipp 3y ago

Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. For "important sites where security matters" they are literally better in every way than a password, it doesn't matter how weak or strong. You can use a pure software solution, and soon probably even your existing password manager, to handle them. Again, you should think of them as replacing passwords. You can still enforce post-authentication requirements like SMS or calls to known numbers, bank account deposits, magic follow-up links in a confirmed email, push notifications, etc. SSH keys are the best analogy. "SSH keys are great for useless servers, but for important servers? no way!" No! That's exactly where SSH keys are most useful. And you also happen to encrypt your SSH keys locally with a password, don't you? This is the exact same principle, but applied to arbitrary websites. Nobody goes around randomly generating login passwords for SSH'ing into each and every server they use, and then pats themselves on the back.

Eduard 3y ago
> Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. Let's assume a "passkey device emulator" written in software; quite realistic IMHO for someone to use, considering the cost of hardware authentication devices (phones, YubiKey etc.) If someone using such emulator gets hacked and has their passkey emulator data stolen, is there anything preventing a credential leak?
- aseipp 3y ago
  The software you're describing is called a "Password Manager", and several do support passkeys already in newer versions. There's no real "emulation." 1Password 8 supports them just fine, your browser has APIs so third-party software can integrate exactly for that. So, the answer to your question is pretty much "exactly the same scenario as your password manager getting leaked", which is basically unsurprising and already well understood when you frame it this way, I think. The particular case I was referring to (and probably should have been clearer about) was when a website operator gets hacked; in that case the only information an attacker gains from your user account is a public key, which isn't of much use. But like, that's actually a major issue in practice, because the value of hacking a service operator is often far greater than just one user. That exact scenario was one of the motivations for using password managers in the first place, too, to mitigate operators getting hacked and common passwords getting reused between users, thus turning a single compromise for many users into multiple compromises for many users. So, it all has come full circle in a sense; now we've finally recognized that instead than shoehorning passwords into becoming psuedo-random strings that might as well be base64 encoded bytes from /dev/urandom, you might as well go "all the way" and just get those raw bytes from /dev/urandom directly and then use them as key material for a public key exchange. Again, the best analogy is to just imagine that you used SSH keys to log into a website. That's all this is. It's software. Then you remember: oh yeah, SSH key synchronization and enrollment across machines sucks ass, and normal people would hate doing it. Hey, you know what, we already use passwords to encrypt SSH keys -- so what if we added a storage synchronization layer between your machines to keep those SSH private keys synchronized, encrypted with that password, and stored using $FAVORITE_SERVICE_PROVIDER? That's pretty much it, in a nutshell. You just reinvented modern Passkeys. Most of the threat models at that point are well understood: what service provider or software to choose, how secure is the local encryption, should you use two-factor authentication to further improve unlock safety, etc.
  - autoexec 3y ago
    > when a website operator gets hacked; in that case the only information an attacker gains from your user account is a public key, which isn't of much use. How is that different from situations where a website gets hacked and all the attacker gets is a well-hashed version of a unique password? In either case it isn't doing the attacker any good.
    - aseipp 3y ago
      It isn't, if the website implements it correctly, and the user uses a strong password, and there's a salt -- then yes, probably, they aren't getting much information. But if you could always rely on all of those, a lot of these problems would not ever be problems; alas, here we are, in this particular world. And if passkeys were only equal to passwords in practice, it would still -- IMO -- be worth upgrading to passkeys because they're, for this case, a better foundational basis to work around (public key cryptographic authentication versus sharing symmetric keys), and less error prone for users and operators. But in practice they are aiming to actually be better, faster to use, and more secure since every Passkey implementation is basically designed around syncing (iOS 17 TBD) and device authentication, and they are phishing resistant, which seemingly nothing else can hope to solve so we just gave up on solving it and don't ever mention it because it's the users fault that they did it. (No, seriously, did we all just give up on that entirely?) I will keep invoking the SSH key analogy, here. Very few people are paranoid about SSH keys being some weird psychological "trick" to take Freedom Loving Passwords away from them or whatever (not referring to you), and most people aren't splitting hairs over "Well, you know, if /etc/shadow and /sbin/login the system is set up correctly, and the machine is secure, then there's no real point to using an SSH key, because my password is safe on disk, and you can just trust that." OK, and? It doesn't matter whether you're logging in as root or a normal user, on your VPS or a friends box. People just use SSH keys instead. Everything works around SSH keys today. People do not want to deal with your secret key material. Passkeys are in many ways just SSH keys for the browser. There really isn't much here to think about when you look at it like this, because the whole basic idea has been around for decades now.
    - dwaite 3y ago
      With passwords, the user choosing a unique password or the site choosing to use a recommended process for hashing passwords is proper hygiene, but requires knowledge and is a choice. With passkeys, there is no opportunity to have bad hygiene. The user does not pick a password. The site does not have secrets to store unprotected.
- chlorion 3y ago
  If the device is exploited, they can also install a keylogger and steal regular passwords. I think this would be where hardware based authentication via TPM or similar would be useful. This would allow the device to be taken over and the private key material would still be safe.
  - dwaite 3y ago
    They could also look at your SMS and Email OTP. The secrets in the password vault can be used to authenticate and change settings in various trusted systems, like configuring call forwarding. Cloud-based backups or the local filesystem could theoretically be inspected for software TOTP secrets. Responding to the potential for bad user choices and full compromise quickly gets you to the point where your options are separate hardware or requiring in-person confirmation. NIST 800-63-3 AAL3 is probably most appropriate to look at if your risk profile mandates this.
katbyte 3y ago
for my important accounts the password is long, unique, and not recorded anywhere, that is one way that passkeys are not better. there is literally no credentials to leak until i go login and type it where passkeys are recorded somewhere? otherwise how would they work. someone gets my private SSH key that is a bad time (which is why we password protect them, or at least you really should be) to follow the ssh analogy, you (should) only use SSH keys to gain access to a unprivileged user account at which point you elevate permissions via sudo and another factor (password/MFA) and really theres an argument to be made the unprivileged account should have MFA for login as well. nobody puts their ssh public key in the root account of a server and pats them selves on the back that its secure so why would passkeys be any different for accounts you truly need to be secure?
- aseipp 3y ago
  You seem to be making up a bunch of scenarios that aren't really relevant (what if someone did this and that with sudo, what if the bytes were stored here). You don't want to understand the actual security model, which is fine, but only on Hacker News can someone say with confidence "actually unphishable public keys that can't be leaked, are not good for security." Again, you might as well be arguing against SSH keys. That won't get topped for a while.
  - someplaceguy 3y ago
    I understood the parent poster to be saying that since his passwords are unique and are not stored anywhere, then if his device were to be compromised, the attacker could only steal a password once it is manually entered, in which case it wouldn't automatically compromise his other passwords. Conversely, if he were to use a password manager on his device to store passkeys, the attacker could compromise all his passkeys once one of them is used. Admittedly, it is an unusual use case (I mean, how do you generate and remember unique, sufficiently long and random passwords without storing them anywhere?) but I can see how passkeys could be worse for him if this is really what he does.
    - katbyte 3y ago