csuwldcat

Yes, this is true, however, that means an external actor is able to execute arbitrary code in your origin, so they could also trick the user into signing malicious payloads with even the native passkey itself. There's more downside to exfiltration here, but having arbitrary code from an external party executing in your page is a more general cause for concern you'd need to mitigate regardless.

Hmm, can you provide further details? I'm using it on Android in Chrome and Brave, and it works fine.

That would either mean you have arbitrary, malicious code executing in the bound origin (the origin was hacked and shipped malicious code), or you allowed random callers externally to take signatures out of the boundary - don't do either of these things, they are verboten. The whole point is that for the passkey you use as a PassSeed, you never do any signing other than locally for ECDSA recovery.

You can run the PassSeed code/mechanism on your own domain or localhost to ensure it's not subject to malicious host exfiltratuon. I agree that one should only trust a foreign host with low-security uses under this scheme.

A roaming authenticator does not have access to a CTAP mechanism to query the platform’s credential store. CTAP defines how the platform queries a roaming authenticator, in that direction. There is no CTAP command whereby an authenticator queries the platform for 'all passkeys you have' because the platform is the client in its protocol model. Platform / synced passkeys managed by the OS are not present on the roaming authenticator, so credential management APIs invoked from the roaming authenticator cannot enumerate them (it can only enumerate what it stores).

There's also the specific case of synced passkeys, which aren't exposed to CTAP management APIs for external parties, only to the OS/platform itself. You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device, but no such permissions/APIs exist for apps, and providing them would be in explicit violation of the fundamental security model. In reality, only the platform/OS and highly trusted actors/components that are already within the existing trust model have such access for internal purposes, and if that's not a safe assumption, it would have broader implications beyond this concern.

It's not just about the WebAuthn API, you're talking about passkeys as if their key bundles are freely accessible to random userland actors, which is absurd. If that were the case, many assurances the platform makes would be out the window. The reality is that you are obviously already trusting the platform, hardware, its software/firmware, and the implementation's use of core key management APIs, which it doesn't just offer up to random callers. If you think any of those components/actors are not adhering to fundamental boundaries/limitations, like exposure of sensitive credential material to random callers on the device, it's a more far reaching indictment of passkeys in general.

The underlying CTAP implementations are only used by the platform to facilitate core activities, they are not used to expose key pairs to external parties. Please link to where any API offers up public keys to external userland actors, and any use of said APIs beyond core credential management. If this is assumed insecure/exposed, it would mean the system and its guarantees cannot be trusted as advertised, given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time.

No need for the "oh dear"-ing before you provide evidence. I'm not aware of any command for fetch or enumeration of public keys in CTAP (was rather confident it doesn't provide any such thing). Care to link to what you were referring to?

It's a deliberate architectural decision that passkey authenticators not allow any retrieval or enumeration of key pairs - they don't even have internal APIs for it. This holds true for all known implementations, as it is a core principle of the system design.

The interesting thing about Passkeys is that they are only ever output in the client create() call, and the platform does not retain them for disclosure after that, so if you don't send them out of the origin boundary, they are treated like a virtually secret value by the platform. It's ironic, because the WebAuthn/Passkey authors (who I know some of) explicitly treat the public key as a sensitive value, and built system assumptions around that, which is what makes this possible. It's a rather gross hack, can't deny it that, but there are a group of use cases for which it is a better fit than any of the far more ugly flows many non-P-256 self-custodied key use cases are accomplished with today.

Saw your post above - I didn't "assert falsehoods", both are missing major browser support:

https://caniuse.com/mdn-api_credentialscontainer_get_publick...

https://caniuse.com/mdn-api_credentialscontainer_get_publick...

I addressed this in the post - neither is available across all major browsers: https://backalleycoder.com/posts/passseeds-an-experiment-in-...

Ironically, you could make a pollyfill for the PRF functionality with this.

How it's better: automatically synced across all a user's devices, not subject to manual interactions with input fields (you can't programmatically request/regen passwords the same way you can with this).

I did use AI for the ECDSA public key recovery diagram, because I wasn't about to spend hours hand rolling that in Lunacy. It's correct in broad strokes, and anyone who wants to understand it more deeply can just look at the code, imo.

Just sounded cooler , and I was on the team that worked on Passkeys at Microsoft, so I wanted to poke them a bit (in a friendly way).

Passkeys can be hijacked to serve as cryptographic seed material that is securely synced across all of a user’s devices, enabling the generation of a wide range of cryptographic keys. This allows Passkeys to power use cases far beyond what they have traditionally been constrained to. I’ve been calling this mechanism PassSeeds.

I’ll leave the details to the blog post, but here’s a short list of what PassSeeds enable:

- Need a user-custodied BLS12-381 key to engage in more advanced ZKP Verifiable Credential / proofing flows? Say less, you're covered.

- Want to create a petty cash Web wallet for Bitcoin transactions that relies on a secp256k1 key? Ask and ye shall receive.

- How about keys for decentralized social media identifiers and post signing that are of a type other than P-256? No problem, I got you!

Also take a look at DIF's Identity Hub - a large-scale initiative that goes far beyond a social server/mailbox, and incorporates solutions for the identity issues people here have flagged: https://github.com/decentralized-identity/identity-hub/blob/...

This is unrelated to any previous demo/work Accenture has shown. (I work on this @ MSFT)

Other way around: the sat system supports Bitcoin, not BCash.

Correct - you can increase the units in circulation without destroying the purchasing power of those who currently hold the asset, which is a huge advantage over traditional fiat currency.

Property is subject to bubbles, and in almost any economic recession prices of real estate tend to fall (demand drops, and sellers/supply grows). Bitcoin is a far better asset hedge, as it possesses almost every property of commodities, like gold, without almost all of their negatives.

False - mining in Bitcoin (which is really just transaction processing) is based on a math/crypto difficulty algo, and the system automatically adjusts itself every ~two weeks to fit the load/prevalence of miners and their block-finding success rates.

Bitcoin is a store of value that will long-term net-increase as true monetary bubbles, like this: http://imgur.com/a/0ZoDu, pop and cause their base currencies to long-term net-decrease.

I went to a Cal State university - it was a joke.

Drug purchasing sites have actually helped reduce violence and crime associated with prohibited items/activities. I'm more nervous about where authoritarian government is taking us.

You forgot to account for two significant factors: that 40% of Californians pay no state income tax, and that California dramatically skews toward higher brackets paying for the state's expenditures - the top 1% already pay an absurdly massive 48% of state income tax.

Per person numbers like the ones you included are basically meaningless, given they bear almost no reflection of the actual fiscal implementation and unique issues it would create.

Alexander Tyler nailed the broader issue of 'democracy' long ago:

“A democracy cannot exist as a permanent form of government. It can only exist until the voters discover that they can vote themselves money from the public treasure. From that moment on the majority always votes for the candidates promising the most money from the public treasury, with the result that a democracy always collapses over loose fiscal policy followed by a dictatorship."

He should have just flown to Oklahoma instead: http://reason.com/blog/2017/01/27/what-happens-when-doctors-...

Sometimes, more so in my early-mid 20s, I would dream about code/architecture issues I was having, and bizarrely, wake up with the solution. It was a trip when I realized what had happened, so I started napping when I got stuck and it actually worked a decent amount of the time.

I just wanted to take a moment to thank Capitalism - an overwhelmingly positive system of resource optimization that's oft-maligned by the econ-shallow, which drives creativity and human advancement through entrepreneurship and the desire to succeed.

I'll describe democracy, and you tell me how comical it sounds:

"A group of people, within a geographic region marked by invisible lines drawn by human aggression, all gather once every 2nd rotation of the Earth around the Sun to put papers in a magic box. The people believe once an arbitrarily large number of papers are put into the box, it grants the owners of those papers the right to force their will and ideas on others within the invisible lines. The box does amazing things, for instance: the very minute before all the papers are counted, it could be immoral theft to take something from others without their explicit, individual permission, but just after counting the papers, magically, if by some form of mobtastic incantation, it becomes 'legal' and totally accessible to take that thing from others via harm and violence."

Holy shit folks, if you don't find that to be magical comedy gold, I don't know what is. It's like a bad M. Night Shyamalan script, except humans actually do it.