3 ms·

Interesting, but the PRF / LargeBlob extensions already enable just such functionality (and more) without relying on the secrecy of a public key. Why not just

Interesting, but the PRF / LargeBlob extensions already enable just such functionality (and more) without relying on the secrecy of a public key. Why not just use those? Edit: that's what I get for not reading far enough -- the article addresses this, though I would quibble with the confident assertion that the extensions are not available in major browsers, given I worked for a startup literal years ago which built major functionality on top of these extensions, which were available in (at least) all relevant mobile browsers.

deleted 9mo ago
[deleted]
csuwldcat 9mo ago
I addressed this in the post - neither is available across all major browsers: https://backalleycoder.com/posts/passseeds-an-experiment-in-hijacking-passkeys-to-unlock-cryptographic-use-cases/#why-not-use-the-webauthns-prf-or-large-blob-features https://backalleycoder.com/posts/passseeds-an-experiment-in-... Ironically, you could make a pollyfill for the PRF functionality with this.
- csuwldcat 9mo ago
  Saw your post above - I didn't "assert falsehoods", both are missing major browser support: https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_prf https://caniuse.com/mdn-api_credentialscontainer_get_publick... https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_largeblob https://caniuse.com/mdn-api_credentialscontainer_get_publick...
  - notorious_pgb 9mo ago
    You're right and I was misremembering (we had only developed against modern mobile browsers), though I am 100% certain we made use of these extensions on iOS Safari, so I honestly don't believe caniuse when they assert that it supports _neither_ extension. Per my recollection, iOS Safari supported the large blob extension quite early on. Apologies for the brash statement earlier; that was wrong of me.
- notorious_pgb 9mo ago
  Very fair (see my edit), though I would submit to you that this isn't a sufficient polyfill for PRF, since PRF allows for a _secondary secret_ alongside the public key, allowing the server to safely store the public key without storing the cryptographic seed material itself. The inability to use a passkey for the purposes of both authentication and secret storage (at least, without building non-trivial additional cryptographic plumbing) seems to me a reason to just use and push for the continued adoption and acceleration of the purpose-built extensions, instead of reusing a _public_ key as private material.

deleted 9mo ago

[deleted]

csuwldcat 9mo ago

I addressed this in the post - neither is available across all major browsers: https://backalleycoder.com/posts/passseeds-an-experiment-in-hijacking-passkeys-to-unlock-cryptographic-use-cases/#why-not-use-the-webauthns-prf-or-large-blob-features https://backalleycoder.com/posts/passseeds-an-experiment-in-... Ironically, you could make a pollyfill for the PRF functionality with this.

csuwldcat 9mo ago
Saw your post above - I didn't "assert falsehoods", both are missing major browser support: https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_prf https://caniuse.com/mdn-api_credentialscontainer_get_publick... https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_largeblob https://caniuse.com/mdn-api_credentialscontainer_get_publick...
- notorious_pgb 9mo ago
  You're right and I was misremembering (we had only developed against modern mobile browsers), though I am 100% certain we made use of these extensions on iOS Safari, so I honestly don't believe caniuse when they assert that it supports _neither_ extension. Per my recollection, iOS Safari supported the large blob extension quite early on. Apologies for the brash statement earlier; that was wrong of me.
notorious_pgb 9mo ago
Very fair (see my edit), though I would submit to you that this isn't a sufficient polyfill for PRF, since PRF allows for a _secondary secret_ alongside the public key, allowing the server to safely store the public key without storing the cryptographic seed material itself. The inability to use a passkey for the purposes of both authentication and secret storage (at least, without building non-trivial additional cryptographic plumbing) seems to me a reason to just use and push for the continued adoption and acceleration of the purpose-built extensions, instead of reusing a _public_ key as private material.