From 29bb3d8ef64e661e1c0bbcffd2e615bbfa4e5723 Mon Sep 17 00:00:00 2001 From: Noman Date: Sat, 30 Nov 2024 00:51:32 -0500 Subject: [PATCH 1/3] fix: thrust -> trust --- docs/faq.md | 4 ++-- docs/registration.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/faq.md b/docs/faq.md index 1e90c4b..240875e 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -61,14 +61,14 @@ Not by default. Passkeys are a single step 2FA only if: When using synced "multi-device" passkeys, the "cloud" has the key, your devices have the key, and the key is in-transit over the wire. While vendors go to great length to secure every aspect, it is still exposed to more risk. All security guarantees are hereby delegated to the software authenticator, whether it's built-in in the platform or a password manager. At best, these passkeys are as safe as the main account itself. If the account is hacked, whether it's by a stolen password, temporary access to your device or a lax recovery procedure, all the passkeys would come along with the hacked account. While it offers convenience, the security guarantees are not as strong as with hardware bound authenticators. -The privacy concerns are similar. It is a matter of thrust with the vendor. +The privacy concerns are similar. It is a matter of trust with the vendor. ## How to deal with recovery when using hardware-bound credentials? A device can be lost, broken, or stolen. You must deal with it. The most straightforward way is to offer the user a way to register multiple passkeys, so that losing one device does not imply locking oneself out. -Another alternative is to provide a recovery procedure per SMS or some other thrusted means. +Another alternative is to provide a recovery procedure per SMS or some other trusted means. Relying on solely a password as recovery is discouraged, since the recovery per password then becomes the "weakest link" of the authentication system. diff --git a/docs/registration.md b/docs/registration.md index 1fcf7d2..8622489 100644 --- a/docs/registration.md +++ b/docs/registration.md @@ -102,7 +102,7 @@ Then simply send this object as JSON to the server. 4️⃣ Verifying the registration on the server ------------------------------------------- -To verify it server side, call the `verifyRegistration(...)` function. While registration is basically "thrust on first use", some basic checks are necessary. The most important one is to check if it matches the expected `challenge` used when initiating the registration procedure, and if the `origin` is the expected one. +To verify it server side, call the `verifyRegistration(...)` function. While registration is basically "trust on first use", some basic checks are necessary. The most important one is to check if it matches the expected `challenge` used when initiating the registration procedure, and if the `origin` is the expected one. ```js import { server } from '@passwordless-id/webauthn' From 02b4d0601131ba1a60092df2ea56b9b07459214d Mon Sep 17 00:00:00 2001 From: Noman Date: Sat, 30 Nov 2024 02:48:21 -0500 Subject: [PATCH 2/3] Couple more typos --- docs/registration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/registration.md b/docs/registration.md index 8622489..ee3dd04 100644 --- a/docs/registration.md +++ b/docs/registration.md @@ -114,7 +114,7 @@ const expected = { const registrationParsed = await server.verifyRegistration(registration, expected) ``` -While this is the minial verification, further verifications are possilbe. +While this is the minimal verification, further verifications are possible. | Verification options | Description | |-------|-------------| From 55bee13a7ab70958cfc212e737406237c274e666 Mon Sep 17 00:00:00 2001 From: Noman Date: Sat, 30 Nov 2024 19:00:39 -0500 Subject: [PATCH 3/3] Fix typo --- docs/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/authentication.md b/docs/authentication.md index 33e60ad..880e704 100644 --- a/docs/authentication.md +++ b/docs/authentication.md @@ -166,4 +166,4 @@ Sadly, there are a few things you cannot do. The specification is complex, areas like UX are left to platform's discretion and browser vendors have their own quirks. As such, I would highly recommend one thing: **test it out with a variety of browsers/platforms**. It's far from a consitent experience. -Moreover, otpions like `hints`, `allowCredentials`, `userVerification` and `discoverable` may interact with each other and provide different UX depending on their combination and the time of the year. The protocol evolved dramatically in the last years, with changes to the UX every couple of months. +Moreover, options like `hints`, `allowCredentials`, `userVerification` and `discoverable` may interact with each other and provide different UX depending on their combination and the time of the year. The protocol evolved dramatically in the last years, with changes to the UX every couple of months.