4 ms·

Sure, but then you still need a protocol between user agent and website. If you just do this in Javascript, you're not protected against phishing sites just for

by lxgr 8mo ago

Sure, but then you still need a protocol between user agent and website. If you just do this in Javascript, you're not protected against phishing sites just forwarding the password entered directly. Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain https://github.com/lxgr/brainchain

valenterry 8mo ago
> Sure, but then you still need a protocol between user agent and website. Yes of course. Just like you do for passkeys. > Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain https://github.com/lxgr/brainchain No, not quite. It's written on there: > "Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...) That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.
- lxgr 8mo ago
  But attestation for passkeys is dead. Neither Apple's, nor Google's implementation (with negligible exceptions) support it anymore, so any site demanding attestation will immediately disqualify > 99% of all potential users. Some still might, e.g. for corporate or high security contexts, but I don't think it'll become a mass-adopted thing if things don't somehow drastically change course.
  - valenterry 8mo ago
    It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.
    - lxgr 8mo ago
      > It's still in the standard. Yes, because hardware authenticators (like Yubikeys) still commonly support it, and it makes sense there. I guess they could add an explicit remark like "synchronized credentials must not support attestation", and given the amount of FUD this regularly seems to generate I'd appreciate that. But attestation semantics seem to be governed more by FIDO than the W3C, so putting that in the WebAuthN spec would be a bit awkward, I think.
      - valenterry 8mo ago
        Hm, I disagree. I prefer if the user has the freedom to choose how they want to do things. At the cost of some users choosing the wrong way and then getting problems. It's a question of balance, but when I look at recent tech/internet history, I tend to not want to give central authorities any more power than they already have.
        lxgr 8mo ago
        Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers. In other words, you have a principal-agent problem: Users doing custom software passkey acrobatics and the banks liable for any funds lost. Preferably, use of attestation should be limited to these (and enterprise) scenarios, and I do share the concern of others starting to use them as weak proofs of humanity etc.
        valenterry 8mo ago
        > Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers. Seems like an absolutely rare edge case to me. Or maybe even just a misunderstanding. I doubt there is a law that says that. If anything, I could imagine a law saying that a company has to take "sufficient precautions". But even if what you say were to be true - that's not something to solve with tech. That means the law should be changed.

by lxgr 8mo ago

valenterry 8mo ago

> Sure, but then you still need a protocol between user agent and website. Yes of course. Just like you do for passkeys. > Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain https://github.com/lxgr/brainchain No, not quite. It's written on there: > "Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...) That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.

lxgr 8mo ago
But attestation for passkeys is dead. Neither Apple's, nor Google's implementation (with negligible exceptions) support it anymore, so any site demanding attestation will immediately disqualify > 99% of all potential users. Some still might, e.g. for corporate or high security contexts, but I don't think it'll become a mass-adopted thing if things don't somehow drastically change course.
- valenterry 8mo ago
  It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.
  - lxgr 8mo ago
    > It's still in the standard. Yes, because hardware authenticators (like Yubikeys) still commonly support it, and it makes sense there. I guess they could add an explicit remark like "synchronized credentials must not support attestation", and given the amount of FUD this regularly seems to generate I'd appreciate that. But attestation semantics seem to be governed more by FIDO than the W3C, so putting that in the WebAuthN spec would be a bit awkward, I think.
    - valenterry 8mo ago
      Hm, I disagree. I prefer if the user has the freedom to choose how they want to do things. At the cost of some users choosing the wrong way and then getting problems. It's a question of balance, but when I look at recent tech/internet history, I tend to not want to give central authorities any more power than they already have.
      - lxgr 8mo ago
        Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers. In other words, you have a principal-agent problem: Users doing custom software passkey acrobatics and the banks liable for any funds lost. Preferably, use of attestation should be limited to these (and enterprise) scenarios, and I do share the concern of others starting to use them as weak proofs of humanity etc.
        valenterry 8mo ago
        > Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers. Seems like an absolutely rare edge case to me. Or maybe even just a misunderstanding. I doubt there is a law that says that. If anything, I could imagine a law saying that a company has to take "sufficient precautions". But even if what you say were to be true - that's not something to solve with tech. That means the law should be changed.