TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

A Tour of WebAuthn

299 点作者 caust1c5 个月前

12 条评论

arianvanp5 个月前
There are some hairy edge cases during registration that many get wrong. (At least GitHub and google had this bug) that if create() returns but the passkey never reaches the server due to bad networking conditions that your password manager thinks it can log in but the server never recorded the passkey for the user. Basically there is no transactionality and you can get in a split brain situation where your password manager and your server don&#x27;t agree and it&#x27;s very confusing for end users.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;w3c&#x2F;webauthn&#x2F;issues&#x2F;2038">https:&#x2F;&#x2F;github.com&#x2F;w3c&#x2F;webauthn&#x2F;issues&#x2F;2038</a><p>They apparently came up with a fix for this using something called Signals API but I don&#x27;t think any browser implemented that yet.<p>Just wanted to highlight that this part of the UX is hairy and hard to get right
评论 #42519187 未加载
tgsovlerkhgsel5 个月前
This is an excellent write-up that finally motivated me to try to understand the mess that was left behind as new standards kept being layered on top of each other.<p>Given the requirement for discoverable credentials and sync, truly open&#x2F;independent passkey implementations seem impossible&#x2F;impractical. For example, you couldn&#x27;t just have a set of Trezor-style devices that you load with the same seed and use that as your passkey without syncing the &quot;discoverable&quot; part of the credentials through some kind of cloud service. (The cloud service wouldn&#x27;t need to be trusted with the actual keys, but you couldn&#x27;t operate without it.)<p>As a result, it looks like you can essentially choose which ecosystem you want to lock yourself into...<p>With authenticatorAttachment, sites have been given a convenient foot-gun to make sure no single setup actually works for all sites, and with both the discoverable and non-discoverable credentials supported, inconsistency in the login flow for maximum confusion is guaranteed.<p>Add to it that this is like the 4th or 5th iteration of a standard in the field in about 10 years, and there&#x27;s endless opportunity to get locked out because providers migrated from one standard (or buggy implementation) to another, or start setting things up only for the 6th standard to obsolete what you had (again, potentially locking you out).<p>And then people are surprised that users stick with passwords.
评论 #42520004 未加载
评论 #42520651 未加载
评论 #42520477 未加载
评论 #42521536 未加载
评论 #42519984 未加载
eadmund5 个月前
The very first sentence is:<p>&gt; Passwords are rubbish.<p>Hard, <i>hard</i> disagree. They’re really not. Password <i>reuse</i> is rubbish. Passwords human beings can remember are rubbish. But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish.<p>There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it.<p>The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) <i>and the relying party to has no ability to approve or disapprove</i>.<p>I do agree that WebAuthn offers very real improvements over passwords (principally due to no longer being a shared secret), but it makes things worse for the users in a few ways. For one, the ability of relying parties to blacklist or whitelist authenticators tramples on the user’s freedom to use the software he wants. Attestation keys and enterprise attestation are user-hostile: users and servers are no longer equal parties.<p>And finally, the user experience of passkeys with, say, a phone-based authenticator is miserable: one must interrupt one’s computer usage, pick up the phone, unlock the phone, open the notification and unlock the app, then put the phone down.<p>All in all, while WebAuthn does offer real advantages, I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
评论 #42522270 未加载
评论 #42521876 未加载
treve5 个月前
Looks like an amazing resource for webauthn. Currently diving into this so it comes at a nice time for me.<p>But it&#x27;s also great advertising against WebAuthn. Hard to believe that this kind of complexity is needed, but as with OpenID Connect it feels like enterprise interests are running the ship, not end-users. Ease of implementation seems like a non-goal.
_Algernon_5 个月前
Just like every other piece on passkeys it does not justify them, at all.<p>Passwords have problems, but less than putting all authentication secrets in a single basket or ecosystem is (which is what big tech fundamentally wants).<p>Passkeys are a solution to a manufactured problem, and keeps getting pushed because it is a useful big tech honey trap that solidifies their user&#x27;s captivity in their ecosystems.
评论 #42521514 未加载
评论 #42521730 未加载
评论 #42521268 未加载
Zamicol5 个月前
WebAuthn and passkeys are a disaster.<p>Much of the specs were created behind closed doors and never done in a way where we could have had outside input. They&#x27;re completely corporate driven and designed to control users not empower them.
评论 #42520423 未加载
评论 #42521850 未加载
xenophonf5 个月前
I&#x27;ve always wanted to write a serverless OIDC provider&#x2F;SAML IdP but got stymied by the WebAuthn standards, which don&#x27;t seem to be written for normal people. :( But this e-book looks like it might have enough actual code interleaved with exposition to serve as more than just a high-level intro.
评论 #42517301 未加载
评论 #42517939 未加载
评论 #42520633 未加载
ggm5 个月前
It interested me how quickly all of my auth methods started to include &quot;pick the right one of three presented numbers&quot; tests after TOTP got widespread. I&#x27;m guessing there is some replay method which they wanted to prevent? This is distinct from in protocol large random value challenges, it must be to ensure a Hooman, or very numerate dog is actually present.
评论 #42518587 未加载
评论 #42519184 未加载
1vuio0pswjnm75 个月前
No SNI: <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20241223150914if_&#x2F;https:&#x2F;&#x2F;www.imperialviolet.org&#x2F;tourofwebauthn&#x2F;tourofwebauthn.html" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20241223150914if_&#x2F;https:&#x2F;&#x2F;www.im...</a>
zcdziura5 个月前
Can anyone recommend a good dummy passkey provider to use when developing and testing RESTful authentication services that will rely on WebAuthn? Every example that I&#x27;ve seen online for interacting with a WebAuthn service assumes that you&#x27;re working within the context of the browser and can use the Navigator APIs.<p>I like to use regular ol&#x27; cURL when testing out API endpoints, and it would be great if there were some kind of dummy CLI program that I could use to generate the WebAuthn key agreements and materials.
评论 #42526483 未加载
评论 #42520048 未加载
jgalt2125 个月前
Credential stuffing would be a much less effective strategy is web apps went back to string-based usernames, and not email-based ones.<p>Also, I hit CTRL-F on this post for the term &quot;portable&quot;, and I got zero hits. Both passwords and SSH keys are trivially portable. Not so much with WebAuthn passkeys.
评论 #42522810 未加载
评论 #42522712 未加载
lapcat5 个月前
&gt; A passkey is a synced, discoverable WebAuthn credential.<p>This is my fundamental problem with passkeys: I don&#x27;t want to use any syncing service.<p>To be clear, I don&#x27;t want to deprive other people of the ability to sync their credentials; I simply want to opt out myself. I just want to be able to manually back up and restore my credentials, like I&#x27;ve always done with passwords, but the passkey vendors seem to want to refuse to give anyone this ability. The vendors claim that this is to make phishing impossible, but I abhor paternalism in all forms, and also it&#x27;s suspicious that this paternalism forces people to use the syncing systems of the passkey vendors, which are usually paid subscriptions. So passkeys become an endless supply of money for the vendors.<p>It&#x27;s very telling that passkeys were designed <i>and</i> shipped without any export&#x2F;import mechanism. You can plainly see the priority of the passkey vendors, which is to lock you in. Allegedly, export&#x2F;import is coming <i>sometime</i> in the future, but I strongly suspect that they&#x27;ll end up with some kind of &quot;approved provider&quot; system so that the big passkey vendors can retain absolute control and avoid giving power to the users.
评论 #42518750 未加载
评论 #42518581 未加载
评论 #42522369 未加载
评论 #42520027 未加载
评论 #42520352 未加载
评论 #42521055 未加载
评论 #42518797 未加载