5 ms·

I've had so many of my non-tech relatives get hacked. Folks who don't live/breath/shit tech just kind of suck at p/w management. This is a huge improvement for

I've had so many of my non-tech relatives get hacked. Folks who don't live/breath/shit tech just kind of suck at p/w management. This is a huge improvement for them. BUT, I absolutely think we should continue to demand the right to interact with services on our own terms: Even accepting the compromise of "less security" (debatable if you know what you're doing). I think the only way forward is a Free/Libre implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want. Even a fully-software one.

car_analogy 4y ago
> implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want Is this not possible with current designs?
- Freak_NL 4y ago
  It pretty much is as far as I know. There are even open source hardware key specs.
- vanburen 4y ago
  At least as I understand it, in implementations like yubikey the FIDO2 secret is baked-in to the yubikey for security, which is good as it shouldn't be possible to remove the private key. However the main issue I have is that the user cannot import their own secret into the yubikey, so you cannot choose to use your own secret vs the factory generated one, or choose to have multiple yubikeys using the same secret, which would be useful as you wouldnt need to enrol multiple secrets with each service.
  - magicalhippo 4y ago
    > However the main issue I have is that the user cannot import their own secret into the yubikey Where would you get this secret from in a secure way? How would you prevent a nefarious actor from exporting it and importing it into their own yubikey or similar?
    - eikenberry 4y ago
      Secrets are easy to securely generate and it would allow importing, not exporting. If you allow importing then the user can generate the secret, store it somewhere safe and import it into the device. Then if they lose that device they can just write the saved secret to a new key.
      - magicalhippo 4y ago
        > store it somewhere safe That's what I meant. How exactly would one safely store this secret? How would you prevent an adversary from extracting the secret from the storage?
        vanburen 4y ago
        Personally I would store it in a Keepass DB stored offline on a USB drive, in a safe location.
        eikenberry 4y ago
        Various strategies that trade off security vs. convenience. Most secure is probably something simple like printing it out and putting that in a fire-proof safe. But there are lots of options. For the non-tech parents or some such, a nice pass-phrase would probably work well as the secret.
        magicalhippo 4y ago
        How do you get this pass-phrase from paper onto the yubikey without an adversary getting hold of it? I'm not trying to be pedantic here, I'm just failing to see how this can be realistically implemented without significantly lowing the overall security. But this is also not my domain, so I'd like to learn.
- eikenberry 4y ago
  It is possible under FIDO L1 certification, but Yubikey and most other players are focusing on L2 and L3 certification as that will be what enterprise customers want.
  - TacticalCoder 4y ago
    Wait: what about these higher certification? Is there going to be some kind of "master key", controlled by the FIDO alliance (?), that would somehow sign the keys produced by "complying" company X or Y? Making it impossible to come with a software implementation allowing to users to backup their keys? Or are you saying that a software implementation would be totally doable but just wouldn't be officially certified?
jtcasper 4y ago
My Solokey is hackable and firmware available under Apache/MIT (https://github.com/solokeys/solo1 https://github.com/solokeys/solo1). Unfortunately the easiest way to "export" is likely to rely on the RP, as if they effectively use the sign_counter they may flag such a key as cloned. They should ideally just let you register multiple (and that's an RFC 'SHOULD'). Not a shill by the way, just a happy solokey owner.
akira2501 4y ago
> just kind of suck at p/w management. The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk." In my experience, solutions balanced on this type of ratio always fail to solve the fundamental problem. Which is why we have to have commercials that tell people "medicare will _never_ call you. If anyone calls and says they're from medicare, hang up immediately!" So, I'm assuming we can now look forward to "no one will ever call and ask for information from your key, if they do, hang up!" I also expect a similar outcome.
- moduspol 4y ago
  > The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk." Eh, my non-tech savvy friends/relatives find themselves guessing at and then finally resetting their password surprisingly frequently. There's some room for "reward" there.
- ChadNauseam 4y ago
  > So, I'm assuming we can now look forward to "no one will ever call and ask for information from your key, if they do, hang up!" There's usually no way to take your key off your device, so don't worry about that :P
  - tialaramex 4y ago
    I guess it's possible that particularly vulnerable people might be persuaded to physically send the actual device to bad guys. I'd like to hope that existing advice to such people warns them not to send stuff to bad guys, we don't want them sending their credit cards, house keys, etc. to bad guys either.
    - supertrope 4y ago
      Mailing keys away would only be economical for targeted attacks. Trojans are more scalable. Even that is a big improvement as malware distribution is harder than credential stuffing, email hijacking, or SIM swap attacks.

car_analogy 4y ago

> implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want Is this not possible with current designs?

Freak_NL 4y ago
It pretty much is as far as I know. There are even open source hardware key specs.
vanburen 4y ago
At least as I understand it, in implementations like yubikey the FIDO2 secret is baked-in to the yubikey for security, which is good as it shouldn't be possible to remove the private key. However the main issue I have is that the user cannot import their own secret into the yubikey, so you cannot choose to use your own secret vs the factory generated one, or choose to have multiple yubikeys using the same secret, which would be useful as you wouldnt need to enrol multiple secrets with each service.
- magicalhippo 4y ago
  > However the main issue I have is that the user cannot import their own secret into the yubikey Where would you get this secret from in a secure way? How would you prevent a nefarious actor from exporting it and importing it into their own yubikey or similar?
  - eikenberry 4y ago
    Secrets are easy to securely generate and it would allow importing, not exporting. If you allow importing then the user can generate the secret, store it somewhere safe and import it into the device. Then if they lose that device they can just write the saved secret to a new key.
    - magicalhippo 4y ago
      > store it somewhere safe That's what I meant. How exactly would one safely store this secret? How would you prevent an adversary from extracting the secret from the storage?
      - vanburen 4y ago
        Personally I would store it in a Keepass DB stored offline on a USB drive, in a safe location.
      - eikenberry 4y ago
        Various strategies that trade off security vs. convenience. Most secure is probably something simple like printing it out and putting that in a fire-proof safe. But there are lots of options. For the non-tech parents or some such, a nice pass-phrase would probably work well as the secret.
        magicalhippo 4y ago
        How do you get this pass-phrase from paper onto the yubikey without an adversary getting hold of it? I'm not trying to be pedantic here, I'm just failing to see how this can be realistically implemented without significantly lowing the overall security. But this is also not my domain, so I'd like to learn.
eikenberry 4y ago
It is possible under FIDO L1 certification, but Yubikey and most other players are focusing on L2 and L3 certification as that will be what enterprise customers want.
- TacticalCoder 4y ago
  Wait: what about these higher certification? Is there going to be some kind of "master key", controlled by the FIDO alliance (?), that would somehow sign the keys produced by "complying" company X or Y? Making it impossible to come with a software implementation allowing to users to backup their keys? Or are you saying that a software implementation would be totally doable but just wouldn't be officially certified?

jtcasper 4y ago

My Solokey is hackable and firmware available under Apache/MIT (https://github.com/solokeys/solo1 https://github.com/solokeys/solo1). Unfortunately the easiest way to "export" is likely to rely on the RP, as if they effectively use the sign_counter they may flag such a key as cloned. They should ideally just let you register multiple (and that's an RFC 'SHOULD'). Not a shill by the way, just a happy solokey owner.

akira2501 4y ago

> just kind of suck at p/w management. The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk." In my experience, solutions balanced on this type of ratio always fail to solve the fundamental problem. Which is why we have to have commercials that tell people "medicare will _never_ call you. If anyone calls and says they're from medicare, hang up immediately!" So, I'm assuming we can now look forward to "no one will ever call and ask for information from your key, if they do, hang up!" I also expect a similar outcome.

moduspol 4y ago
> The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk." Eh, my non-tech savvy friends/relatives find themselves guessing at and then finally resetting their password surprisingly frequently. There's some room for "reward" there.
ChadNauseam 4y ago
> So, I'm assuming we can now look forward to "no one will ever call and ask for information from your key, if they do, hang up!" There's usually no way to take your key off your device, so don't worry about that :P
- tialaramex 4y ago
  I guess it's possible that particularly vulnerable people might be persuaded to physically send the actual device to bad guys. I'd like to hope that existing advice to such people warns them not to send stuff to bad guys, we don't want them sending their credit cards, house keys, etc. to bad guys either.
  - supertrope 4y ago
    Mailing keys away would only be economical for targeted attacks. Trojans are more scalable. Even that is a big improvement as malware distribution is harder than credential stuffing, email hijacking, or SIM swap attacks.