5 ms·

Unpopular opinion: These keys are about selling the idea that physical-based security is somehow magically better. If you have good password hygene (read: a de

Unpopular opinion: These keys are about selling the idea that physical-based security is somehow magically better. If you have good password hygene (read: a decent password manager) then I'll need to breach your host to obtain it - if you use a security key, I'll have to breach your host and hijack your session which is slightly more convenient but chances are you're royally screwed once you're breached anyway. Sure there's some edge cases where this might work (one-way keyloggers, etc) but these aren't realistic threats for a large majority of people. Somehow a sales team have taken a bullet hole, and attempted to use a square peg to band-aid it. Stop buying stupid products and just use a damn password manager.

bodhi 7y ago
How about phishing?
- datguacdoh 7y ago
  100% this. Phishing is incredibly common, really difficult for even sophisticated users to detect when done well, and the best password manager isn't going to help you. A security key will all but guarantee that this isn't an issue and is a pretty good UX too.
  - kadoban 7y ago
    Correct me if I'm wrong, but password managers can prevent quite a lot of phishing, because autofill can automatically check the domain. It would be abundantly obvious to me if I were going to put my paypal password into anything but paypal, for instance, because I wouldn't even have the option. I'd have to copy/paste if I wanted to, which would up my suspicion level to the extreme. (this is not to downplay security keys though, I think they're very important)
    - pvg 7y ago
      It would be abundantly obvious to me That's what people say but even security experts have fallen for phishing attacks. And since the autofill is not 100% reliable, it's not that unusual to go into the password store and manually get the password out of there.
      - kadoban 7y ago
        It's really quite unusual. I'm not sure what password managers these security experts are using, but there's no way it works like mine (bitwarden). I've never had it fail to recognize the domain, which is good because that seems like really obvious functionality. I have had it fail to autofill due to site implementation, and the couple of times it happened I was extremely on my guard and triple-checked everything before proceeding. I think that's the important part of this, the manager has to be reliable enough that the bypass mechanism stands out _a lot_, and the user has to be aware.
        deleted 7y ago
        [deleted]
        jessaustin 7y ago
        Sure it can handle logins to both "theircompany.com" and "service.theircompany.com", assuming the cert is set up correctly. It probably isn't going to figure out that those are related to "theircompany-service.net". This would arguably be a failure in domain setup, but I've certainly seen similar setups before. Example: "https://hbweb.incompass-solutions.com/" https://hbweb.incompass-solutions.com/" uses the same credentials as "http://www.equineline.com/" http://www.equineline.com/" since they're both owned by the Jockey Club.
        mceachen 7y ago
        Some password managers (like bitwarden) allow for N URL patterns for a given credential, for exactly this purpose.
        jessaustin 7y ago
    - burner589432 7y ago
      > since the autofill is not 100% reliable, it's not that unusual to go into the password store and manually get the password out of there. I imagine you can extract passwords out of security keys in some form without being on the correct domain, too. Do domain check fails that regularly? I'm sure enterprise configuration policies would provide functionality to prevent password extraction should you be inclined to enable it.
      - synotna 7y ago
        You can't
      - chowell 7y ago
        No, the whole point of U2F/FIDO is that phishing sites can't extract a usable credential from the key because everything is tied to the origin requesting the authentication.
      - tialaramex 7y ago
        WebAuthn doesn't have "passwords" it does public key crypto. So phishingsite.example gets a public key signed response saying "Yup, burner wants to sign into phishingsite.example" and the whole point of cryptographic signatures is that nobody can make it say mybank.example instead of phishingsite.example without invalidating the signature. So it's useless for breaking into your bank account. There's no UI. Even if you are 100% convinced this is really your bank, you desperately want to sign in, you keep tapping that button, trying again, it can't help the bad guys. There is no "Yes I'm really sure this is my bank" option that destroys your security.
        Bnshsysjab 7y ago
        What’s to stop a password manager behaving in the same way?
        tialaramex 7y ago
        Compatibility. Password managers have to be compatible with the reality of how passwords are used/ abused by site owners. When my preferred electricity supplier was bought by Shell (as part of an exercise in greenwashing the huge fossil fuel company) they rebranded and all their URLs changed overnight. My passwords still worked - but on these new URLs. This looks _exactly_ like a phishing attack, except for the huge advertising spend on a cynical rebranding exercise. If you sell a password manager that fails in this scenario you're getting customer feedback saying this product doesn't work, fix it. How can you fix it? Add an override, destroy the security value of the product. But WebAuthn comes out of the box enforcing this rule that the FQDN can't change. When Shell buys the electricity company and says "All your sites need to change" if they used WebAuthn the developer says "I tried that and it breaks login for all customers". "Tell them to override it, put up a banner saying so". "There is no override"... "OK, put the old site back". Done. Users saved from security lapses caused by corporate rebranding. The WebAuthn people put a bunch of effort into thinking about evil things that can go wrong and defending against them. Having a clean slate to start from helped enormously.
  - GoblinSlayer 7y ago
    >really difficult for even sophisticated users to detect when done well Hard to believe. Can you substantiate that claim? Also you don't need to detect it, you only need to not fall for it.
- burner589432 7y ago
  Browser based password managers solve this.
deleted 7y ago
[deleted]
judge2020 7y ago
> Unpopular opinion Yes, quite unpopular since keyloggers and clipboard watching malware are probably a threat model to many more people than someone stealing a security key off your keychain.
- burner589432 7y ago
  If malware is in a position to steal data from your clipboard or keylog your device, it's very likely to be in a position to hijack your session tokens.
  - blintz 7y ago
    Even if the malware hijacks your session tokens, using something like WebAuthn prevents silent theft of a password, which is much more powerful (allows creation of new sessions).
    - burner589432 7y ago
      If your host is infected with malware but it can't steal your passwords due to hardware boundaries, it still has access to your host at a pretty reasonable permission level. In most corporate environments that's far more damaging than getting persistence in a handful of webapps. Also, 2FA solves this exact issue.
  - tialaramex 7y ago
    Dubious. On a desktop device it's really common for there to be mechanisms that make it easy for software to steal the clipboard contents and intercept keypresses because these are things that some legitimate desktop software needs. There may often be a documented API that even a mediocre programmer can use to get this working in a few hours. On the other hand, stealing session tokens is typically going to require reaching inside the browser process, which is perhaps the most sophisticated software on a machine, and then groping around to find these tokens. It definitely is possible in some cases but it's likely to be pretty hard. I'd compare it to the difference between stealing a person's credit card from a bag they left under their seat versus reaching under somebody's shirt to take the money they've tucked into their bra. I don't doubt that somebody, somewhere, is good enough to get away with that second one unnoticed, but I know for sure the first one is easier.
_jal 7y ago
Other folks have mentioned things you missed, here's another: insider threats. A authentication event requiring a hardware token is significantly harder to deny, especially if used again by the legitimate user after the questionable event. So any insider attacks that are not last-hurrahs or one-shots plausibly explained by theft are significantly riskier.
- burner589432 7y ago
  If you're trying to prevent credential theft: Educate users on password managers, deploying 2FA, or tokens like this would also make sense. MFA deployments are probably significantly cheaper though (And yes, ActiveDirectory OTP and smartcard based MFA tools exist). Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many people that forget their mobile phone. If you're trying to have rock solid audit trails that will stand up in court: This, or 2FA won't have a huge functional difference, but chances are unless you have NSA/Google tier security, your money would be better spent hardening infrastructure - your logs won't be worth jack if a pentest rips your network apart in two hours. I regularly see $1m+ SEIM deployments on MS17-010 vulnerable networks, I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security.
  - ti_ranger 7y ago
    > Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many people that forget their mobile phone. (Your terminology is weird. What do you mean by MFA where USB tokens aren't in-scope? I guess you mean an authenticator app on a mobile device). Where I work, we use Yubikeys, which are used as 2FA for almost everything: * SSO on all web internal web sites, the SSO implementation supports U2F * short-lived (less than a day) ssh certs signed by Yubikey OTP * VPN access authenticated by Yubikey OTP Enrolling of yubikeys is self-service, and supports up to 2, and employees in critical positions can have 2. Re-setting the Yubikey OTP pin is mostly self-service, but you need to enter it any time you VPN or get a new ssh cert, so you are more likely to forget your phone at home than your Yubikey OTP pin. > I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security. Many banks (especially in my country) rely on SMS OTPs. Some banks have OTP authentication for their websites on their mobile apps (but then if you uninstall the app, you have to re-enroll, which is quite tedious). I would much prefer all banking sites to support U2F/WebAuthn, and hopefully that would also sufficiently motivate good support on phones for U2F/WebAuthn. If they allowed you to turn off any SMS-based OTPs (e.g. if they support recovery codes and 2 tokens), I think it would be possible to eliminate SIM-swap fraud (which is quite rife here ...). And to be clear, I don't mean this in place of good password managers, I mean in addition to password managers. Defense-in-depth and all.

bodhi 7y ago

How about phishing?

datguacdoh 7y ago
100% this. Phishing is incredibly common, really difficult for even sophisticated users to detect when done well, and the best password manager isn't going to help you. A security key will all but guarantee that this isn't an issue and is a pretty good UX too.
- kadoban 7y ago
  Correct me if I'm wrong, but password managers can prevent quite a lot of phishing, because autofill can automatically check the domain. It would be abundantly obvious to me if I were going to put my paypal password into anything but paypal, for instance, because I wouldn't even have the option. I'd have to copy/paste if I wanted to, which would up my suspicion level to the extreme. (this is not to downplay security keys though, I think they're very important)
  - pvg 7y ago
    It would be abundantly obvious to me That's what people say but even security experts have fallen for phishing attacks. And since the autofill is not 100% reliable, it's not that unusual to go into the password store and manually get the password out of there.
    - kadoban 7y ago
      It's really quite unusual. I'm not sure what password managers these security experts are using, but there's no way it works like mine (bitwarden). I've never had it fail to recognize the domain, which is good because that seems like really obvious functionality. I have had it fail to autofill due to site implementation, and the couple of times it happened I was extremely on my guard and triple-checked everything before proceeding. I think that's the important part of this, the manager has to be reliable enough that the bypass mechanism stands out _a lot_, and the user has to be aware.
      - deleted 7y ago
        [deleted]
      - jessaustin 7y ago
        Sure it can handle logins to both "theircompany.com" and "service.theircompany.com", assuming the cert is set up correctly. It probably isn't going to figure out that those are related to "theircompany-service.net". This would arguably be a failure in domain setup, but I've certainly seen similar setups before. Example: "https://hbweb.incompass-solutions.com/" https://hbweb.incompass-solutions.com/" uses the same credentials as "http://www.equineline.com/" http://www.equineline.com/" since they're both owned by the Jockey Club.
        mceachen 7y ago
        Some password managers (like bitwarden) allow for N URL patterns for a given credential, for exactly this purpose.
        jessaustin 7y ago
  - burner589432 7y ago
    > since the autofill is not 100% reliable, it's not that unusual to go into the password store and manually get the password out of there. I imagine you can extract passwords out of security keys in some form without being on the correct domain, too. Do domain check fails that regularly? I'm sure enterprise configuration policies would provide functionality to prevent password extraction should you be inclined to enable it.
    - synotna 7y ago
      You can't
    - chowell 7y ago
      No, the whole point of U2F/FIDO is that phishing sites can't extract a usable credential from the key because everything is tied to the origin requesting the authentication.
    - tialaramex 7y ago
      WebAuthn doesn't have "passwords" it does public key crypto. So phishingsite.example gets a public key signed response saying "Yup, burner wants to sign into phishingsite.example" and the whole point of cryptographic signatures is that nobody can make it say mybank.example instead of phishingsite.example without invalidating the signature. So it's useless for breaking into your bank account. There's no UI. Even if you are 100% convinced this is really your bank, you desperately want to sign in, you keep tapping that button, trying again, it can't help the bad guys. There is no "Yes I'm really sure this is my bank" option that destroys your security.
      - Bnshsysjab 7y ago
        What’s to stop a password manager behaving in the same way?
        tialaramex 7y ago
        Compatibility. Password managers have to be compatible with the reality of how passwords are used/ abused by site owners. When my preferred electricity supplier was bought by Shell (as part of an exercise in greenwashing the huge fossil fuel company) they rebranded and all their URLs changed overnight. My passwords still worked - but on these new URLs. This looks _exactly_ like a phishing attack, except for the huge advertising spend on a cynical rebranding exercise. If you sell a password manager that fails in this scenario you're getting customer feedback saying this product doesn't work, fix it. How can you fix it? Add an override, destroy the security value of the product. But WebAuthn comes out of the box enforcing this rule that the FQDN can't change. When Shell buys the electricity company and says "All your sites need to change" if they used WebAuthn the developer says "I tried that and it breaks login for all customers". "Tell them to override it, put up a banner saying so". "There is no override"... "OK, put the old site back". Done. Users saved from security lapses caused by corporate rebranding. The WebAuthn people put a bunch of effort into thinking about evil things that can go wrong and defending against them. Having a clean slate to start from helped enormously.
- GoblinSlayer 7y ago
  >really difficult for even sophisticated users to detect when done well Hard to believe. Can you substantiate that claim? Also you don't need to detect it, you only need to not fall for it.
burner589432 7y ago
Browser based password managers solve this.

deleted 7y ago

[deleted]

judge2020 7y ago

> Unpopular opinion Yes, quite unpopular since keyloggers and clipboard watching malware are probably a threat model to many more people than someone stealing a security key off your keychain.

burner589432 7y ago
If malware is in a position to steal data from your clipboard or keylog your device, it's very likely to be in a position to hijack your session tokens.
- blintz 7y ago
  Even if the malware hijacks your session tokens, using something like WebAuthn prevents silent theft of a password, which is much more powerful (allows creation of new sessions).
  - burner589432 7y ago
    If your host is infected with malware but it can't steal your passwords due to hardware boundaries, it still has access to your host at a pretty reasonable permission level. In most corporate environments that's far more damaging than getting persistence in a handful of webapps. Also, 2FA solves this exact issue.
- tialaramex 7y ago
  Dubious. On a desktop device it's really common for there to be mechanisms that make it easy for software to steal the clipboard contents and intercept keypresses because these are things that some legitimate desktop software needs. There may often be a documented API that even a mediocre programmer can use to get this working in a few hours. On the other hand, stealing session tokens is typically going to require reaching inside the browser process, which is perhaps the most sophisticated software on a machine, and then groping around to find these tokens. It definitely is possible in some cases but it's likely to be pretty hard. I'd compare it to the difference between stealing a person's credit card from a bag they left under their seat versus reaching under somebody's shirt to take the money they've tucked into their bra. I don't doubt that somebody, somewhere, is good enough to get away with that second one unnoticed, but I know for sure the first one is easier.

_jal 7y ago

Other folks have mentioned things you missed, here's another: insider threats. A authentication event requiring a hardware token is significantly harder to deny, especially if used again by the legitimate user after the questionable event. So any insider attacks that are not last-hurrahs or one-shots plausibly explained by theft are significantly riskier.

burner589432 7y ago
If you're trying to prevent credential theft: Educate users on password managers, deploying 2FA, or tokens like this would also make sense. MFA deployments are probably significantly cheaper though (And yes, ActiveDirectory OTP and smartcard based MFA tools exist). Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many people that forget their mobile phone. If you're trying to have rock solid audit trails that will stand up in court: This, or 2FA won't have a huge functional difference, but chances are unless you have NSA/Google tier security, your money would be better spent hardening infrastructure - your logs won't be worth jack if a pentest rips your network apart in two hours. I regularly see $1m+ SEIM deployments on MS17-010 vulnerable networks, I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security.
- ti_ranger 7y ago
  > Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many people that forget their mobile phone. (Your terminology is weird. What do you mean by MFA where USB tokens aren't in-scope? I guess you mean an authenticator app on a mobile device). Where I work, we use Yubikeys, which are used as 2FA for almost everything: * SSO on all web internal web sites, the SSO implementation supports U2F * short-lived (less than a day) ssh certs signed by Yubikey OTP * VPN access authenticated by Yubikey OTP Enrolling of yubikeys is self-service, and supports up to 2, and employees in critical positions can have 2. Re-setting the Yubikey OTP pin is mostly self-service, but you need to enter it any time you VPN or get a new ssh cert, so you are more likely to forget your phone at home than your Yubikey OTP pin. > I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security. Many banks (especially in my country) rely on SMS OTPs. Some banks have OTP authentication for their websites on their mobile apps (but then if you uninstall the app, you have to re-enroll, which is quite tedious). I would much prefer all banking sites to support U2F/WebAuthn, and hopefully that would also sufficiently motivate good support on phones for U2F/WebAuthn. If they allowed you to turn off any SMS-based OTPs (e.g. if they support recovery codes and 2 tokens), I think it would be possible to eliminate SIM-swap fraud (which is quite rife here ...). And to be clear, I don't mean this in place of good password managers, I mean in addition to password managers. Defense-in-depth and all.