4 ms·

To restate, I think your argument is that by making authn more complex, standards like WebAuthn will push towards "Identity as a Service" platforms like Firebas

by md_ 5y ago

To restate, I think your argument is that by making authn more complex, standards like WebAuthn will push towards "Identity as a Service" platforms like Firebase, Okta, etc, and that this concentrates power in the hands of those providers. To an extent I think this is a fair argument, but it strikes me as somewhat of a Luddite one as well: yes, the better technology is also more complex, but most of the time users are simply more secure by developers choosing IaaS providers! At the limit, you could argue against developer guidelines to use SSL or salted password storage, because those are "complex" and "encourage adoption of common providers." I don't think these security mechanisms are significant drivers of tech consolidation, and of all the things to complain about, the payoff for users--increased security--is hard to oppose!

mindslight 5y ago
When it comes to surveillance companies developing software, I am a Luddite by default. They can't help but incorporate biases that destroy end user autonomy, because they're only concerned about advancing their own perspective. In general, I don't view "security" under the wing of a company as a goal worth striving for, because companies are the long-term attackers we need to worry about! If it was guaranteed that say FIDO would stop sites demanding phone numbers to do snake oil "2FA", then I'd be fully supportive. But from what I've witnessed surveillace companies won't take steps that don't benefit them - why would they ever stop demanding phone numbers now that they can? And so whatever it turns out being, I can only imagine that "passwordless" will be similarly abused ("never let a good crisis go to waste"). At the very least it will create another configuration speed bump that interrupts workflows based around trying to compartmentalize the surveillance industry (eg I only run web browsers in VMs). If you really want to drive adoption of FIDO, then instead of pushing hardware tokens (and corresponding heavyweight process), Mozilla should create a software FIDO key within the browser. That is something that I can see evolving features that help users rather than restrict them. It would then be up to an end user whether to use a hardware token in place of that, iff they determine that a given account is that important.
- md_ 5y ago
  There's nothing that stands in the way of anyone implementing a software FIDO2 key (though some RPs can reject self-signed attestation certs if they want to, but it's not common AFAIK). See https://github.blog/2017-07-20-soft-u2f/ https://github.blog/2017-07-20-soft-u2f/ for an example.
  - mindslight 5y ago
    I didn't say there was, and I figured there had to be, given the amount of open implementations. I was speaking more to adoption path and resulting customs rather than what is technically possible. Like for example to use "FIDO authentication", if I have to plug in a specific USB key, pass it through to a VM, etc, then that extra effort isn't worth it for 90% of my accounts (although that won't stop them from insisting that it is!). Whereas if Firefox can handle it in software by default, and I can easily backup/restore its keying material with standard shell scripts, then I'm much more likely to see it as a benefit. FWIW do you know if the server can reliably determine what brand of authenticator is being used (eg through a pubkey signature)? I haven't studied the protocol enough to know if it contains those kind of anti-features.
    - md_ 5y ago
      There's a concept of "batch attestation", by which the manufacturer builds in a key that attests to a batch (with a minimum batch size, to avoid identifying a single USB key--either 10k or 100k but I forget offhand which). This is (AFAICT) intended to be used by, say, an enterprise who wants to restrict their employees to some trusted brand, but some banks and similar have also used it. This is somewhat discouraged and annoying. In general, most places you can use a "self-signed" authenticator, which could be software and nobody would know.
      - mindslight 5y ago
        Damn. That's the exactly the type of long-term security vulnerability that I'm concerned about. What you're describing is only today's present conditions. They're allowed to continue because adoption is low, and so businesses aren't trying to add even more "security". This is like IP before DPI, or when people considered Bitcoin anonymous. Once FIDO keys become popular, and especially if software-only keys become popular, companies will most certainly restrict their services to only work with trusted brands.

by md_ 5y ago

mindslight 5y ago

When it comes to surveillance companies developing software, I am a Luddite by default. They can't help but incorporate biases that destroy end user autonomy, because they're only concerned about advancing their own perspective. In general, I don't view "security" under the wing of a company as a goal worth striving for, because companies are the long-term attackers we need to worry about! If it was guaranteed that say FIDO would stop sites demanding phone numbers to do snake oil "2FA", then I'd be fully supportive. But from what I've witnessed surveillace companies won't take steps that don't benefit them - why would they ever stop demanding phone numbers now that they can? And so whatever it turns out being, I can only imagine that "passwordless" will be similarly abused ("never let a good crisis go to waste"). At the very least it will create another configuration speed bump that interrupts workflows based around trying to compartmentalize the surveillance industry (eg I only run web browsers in VMs). If you really want to drive adoption of FIDO, then instead of pushing hardware tokens (and corresponding heavyweight process), Mozilla should create a software FIDO key within the browser. That is something that I can see evolving features that help users rather than restrict them. It would then be up to an end user whether to use a hardware token in place of that, iff they determine that a given account is that important.

md_ 5y ago
There's nothing that stands in the way of anyone implementing a software FIDO2 key (though some RPs can reject self-signed attestation certs if they want to, but it's not common AFAIK). See https://github.blog/2017-07-20-soft-u2f/ https://github.blog/2017-07-20-soft-u2f/ for an example.
- mindslight 5y ago
  I didn't say there was, and I figured there had to be, given the amount of open implementations. I was speaking more to adoption path and resulting customs rather than what is technically possible. Like for example to use "FIDO authentication", if I have to plug in a specific USB key, pass it through to a VM, etc, then that extra effort isn't worth it for 90% of my accounts (although that won't stop them from insisting that it is!). Whereas if Firefox can handle it in software by default, and I can easily backup/restore its keying material with standard shell scripts, then I'm much more likely to see it as a benefit. FWIW do you know if the server can reliably determine what brand of authenticator is being used (eg through a pubkey signature)? I haven't studied the protocol enough to know if it contains those kind of anti-features.
  - md_ 5y ago
    There's a concept of "batch attestation", by which the manufacturer builds in a key that attests to a batch (with a minimum batch size, to avoid identifying a single USB key--either 10k or 100k but I forget offhand which). This is (AFAICT) intended to be used by, say, an enterprise who wants to restrict their employees to some trusted brand, but some banks and similar have also used it. This is somewhat discouraged and annoying. In general, most places you can use a "self-signed" authenticator, which could be software and nobody would know.
    - mindslight 5y ago
      Damn. That's the exactly the type of long-term security vulnerability that I'm concerned about. What you're describing is only today's present conditions. They're allowed to continue because adoption is low, and so businesses aren't trying to add even more "security". This is like IP before DPI, or when people considered Bitcoin anonymous. Once FIDO keys become popular, and especially if software-only keys become popular, companies will most certainly restrict their services to only work with trusted brands.