Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
sebk
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
1.
▲
by
sebk
1y ago
I agree with this. One way to keep changes small but still compose them into a coherent PR is to make each commit in the final PR independently meaningful, rather than what actually transpired during local development. TFA touches on this s
2.
▲
by
sebk
1y ago
Counter-anecdotally, I reported two WebAuthn issues to Apple in separate instances and both were immediately fixed in the next patch version of iOS/Mac OS. In both cases first line support had little understanding of the issue but were
3.
▲
by
sebk
3y ago
There's a standard for this using NFC and UWB, Digital Car Key; BMW has support for either 2.0 (NFC) or 3.0 (UWB) across their entire range. The Hyundai Motor Company group (Hyundai/Kia/Genesis) is starting to add support as
4.
▲
by
sebk
3y ago
Professor Daniel Abadi makes a similar point in his paper [1], where he improves on CAP with PACELC -- if there is a partition (P) how does the system tradeoff between availability and consistency (A and C); else (E) when the system is run
5.
▲
by
sebk
3y ago
Have a look at https://mitxela.com/projects/shamirs_password_store for an explanation of a suitable algorithm for this use case.
6.
▲
by
sebk
3y ago
Beazley's Concurrency From the Ground Up is one of my favorite tech talks ever: In about 45 minutes he builds an async framework using generators, while live coding in an emacs screen that shows only about 20 lines and without syntax h
7.
▲
by
sebk
3y ago
UWB is augmenting Bluetooth for car keys solving this exact issue; The Car Connectivity Consortium came up with the Digital Key 3.0 standard that's available today, as implemented by some makes like BMW and the Hyundai/Kia group a
8.
▲
by
sebk
3y ago
I think we both have exhausted our arguments regarding attestation. I understand why you don't want attestation to exist, and I believe you understand why I think it needed to exist in order for WebAuthn itself to exist. Like you, I ho
9.
▲
by
sebk
3y ago
> but this is blocking authentication based on attributes of the device, correct? Not precisely. It's requesting capabilities that the Yubikey is not configured to deliver so the browser doesn't show it as an option. There is n
10.
▲
by
sebk
3y ago
let me restate, they're not "blocking the description of a Yubikey" either. You can register one, and in fact I just did to try it out. The Yubikey needs to be configured with a PIN which you do through Yubikey manager. They&
11.
▲
by
sebk
3y ago
Attestation doesn't carry that information. Also consider that Apple zeroes out attestation for its devices and works just fine with Google as passkeys. What's happening here is that when an RP is registering an authenticator, it
12.
▲
by
sebk
3y ago
100k devices is the minimum. Also I already agreed that this is an expansion of information, were it to be requested in practice and the user chose to provide it. And I don't believe the use case for attestation in enterprise settings
13.
▲
by
sebk
3y ago
WebAuthn goes to great lengths to preserve user privacy, much more so than past alternatives, so I don't think there's a expansion of information, especially when the device is probed for capabilities which is extremely pervasive
14.
▲
by
sebk
3y ago
I don't think FIDO saying importing/exporting keys is important and them having to standardize it is the same thing. The first and most straightforward reason is that we have no standard for importing/exporting passwords in o
15.
▲
by
sebk
3y ago
The entire sync fabric would become the authenticator. Apple and Google could (but don't currently) issue attestation that the passkey ecosystem you're using is theirs for multi-device passkeys, and continue to use attestation for
16.
▲
by
sebk
3y ago
Please read the comment again, because that wasn't the argument I was making. I'll restate in case I wasn't clear -- the fact that it's wrapped addresses the "just a file"; meaning it's not sufficient to a
17.
▲
by
sebk
3y ago
It's surprisingly difficult to figure what what a passkey is, precisely. I think there's a bit of a terminology issue. FIDO marketing materials talk about passkeys in the same way you do, a resident key (now called discoverable cr
18.
▲
by
sebk
3y ago
Yeah don't get me wrong, I wasn't disagreeing. I think the lack of interoperability is a major risk to adoption, but I also understand why we don't have interoperability today and why we likely never will. What I'd like
19.
▲
by
sebk
3y ago
Passkeys are not quite passwords even if backed by software and stored in the same memory space as other applications running on the OS. They're still asymmetric, cryptographically secure, and domain-bound. It's true that being &q
20.
▲
by
sebk
3y ago
WebAuthn lets RPs reason about the strength and capabilities of the authenticator at registration time. With a mechanism like a shared file format and standard ways of transferring them, those mechanisms would be undermined. With hardware-b
21.
▲
by
sebk
3y ago
Fortunately you can undo these steps for $BANK1 and use your TOTP authenticator of choice: https://github.com/dlenski/python-vipaccess e: I think you added a reference to this as I was writing my comment :)
22.
▲
by
sebk
3y ago
It's called hybrid transport, and the old name for it was caBLE. Yubico has a nice explainer here: https://developers.yubico.com/WebAuthn/Concepts/Hybrid_Flows... It's not fundamentally different than ot
23.
▲
by
sebk
3y ago
For the client-side, the spec is comprehensive in allowing the authenticator to decide whether backups are allowed. In this case it's iOS not exposing that to you as a user. I get why you'd want this, but trusting Apple to store y
24.
▲
by
sebk
3y ago
Sure but this currently means a virtual authenticator that puts unwrapped passkeys in the same memory as other applications, leaving only the OS and no other physical measures to protect a direct-memory read. That might be acceptable for yo
25.
▲
by
sebk
3y ago
Talking about Apple here because it's what I'm more familiar with, and their security whitepapers are more widely available. The PIN and key derivation wraps the actual encryption key that's stored locally in the device or se
26.
▲
by
sebk
3y ago
I'm glad to have an answer to the question I asked you 7 months ago: https://news.ycombinator.com/item?id=32472443 ( What's Neon's point of view about transient state in nodes? Is there a world where serverle
27.
▲
by
sebk
4y ago
I don't disagree at all. I like that WebAuthn prioritized security and privacy over usability, and they have made improvements in usability later on (like Passkeys or hybrid transport). Bolting on security is undoubtedly worse than bol
28.
▲
by
sebk
4y ago
This is a totally valid concern. A mitigation is to have some other device or mechanism to generate a device that's part of sync fabric in escrow somewhere else. Of course, this introduces two new problems: Where do you keep it in escr
29.
▲
by
sebk
4y ago
1Password's and Dashlane's implementation keeps the key material and does crypto in software, meaning it's less isolated from the operating system than hardware-backed implementations. That might be an acceptable tradeoff for
30.
▲
by
sebk
4y ago
Even if they are broken you have the option, and you can decide which trade offs suit your use case.
More ›