Passkey at WebAuthn: mag-login nang walang password, walang magic

spinny:~/writing $ less passkeys-webauthn-passwordless-authentication.md

1 
2Ang mga password ay isa sa mga bagay na na-normalize namin dahil nakasama namin sila sa loob ng maraming taon. Ang mga gumagamit ay nakakalimutan ang mga ito, muling ginagamit ang mga ito, isulat ang mga ito kung saan hindi nila dapat. Dapat pamahalaan ng mga koponan ang mga pag-reset, patakaran, hash, leaks, phishing at suporta.
3 
4Hindi ginagawang perpekto ng passkey ang pagpapatunay, ngunit inaalis nila ang isang malaking problema: hindi na kailangang magtago ng lihim na ibinahagi sa user ang server.
5 
6## Ano ba talaga ang nangyayari
7 
8Ang passkey ay isang kredensyal batay sa WebAuthn. Kapag ginawa ito ng user, bubuo ang device ng key pair:
9 
10- isang pribadong key, na nananatili sa device o sa password manager;
11- isang pampublikong key, na maaaring i-save ng server.
12 
13Kapag nag-log in ang server ay hindi nagtatanong ng "sabihin sa akin ang password". Magpadala ng random na hamon. Pipirmahan ito ng device gamit ang pribadong key. Bine-verify ng server ang lagda gamit ang pampublikong susi.
14 
15Iyan ang magandang bahagi: kung ang database ay ninakaw, walang mga password sa loob upang i-crack. At kung ang isang user ay napunta sa isang pekeng domain, ang passkey ay hindi wasto para sa domain na iyon. Ito ay hindi lamang kaginhawaan, ito ay konkretong proteksyon laban sa phishing.
16 
17## Ang browser ay gumaganap bilang isang tulay
18 
19Sa browser ang dalawang pangunahing API ay:
20 
21- `navigator.credentials.create()` upang lumikha ng passkey;
22- `navigator.credentials.get()` upang gamitin ito sa panahon ng pag-login.
23 
24Ngunit ang mahalagang lohika ay nasa server. Dapat buuin ng server ang hamon, pansamantalang i-save ito, i-verify ang tugon, suriin ang pinagmulan at Relying Party ID, pagkatapos ay gawin ang session.
25 
26Ang bahagi ng kliyente ay dapat na halos mayamot:
27 
28```typescript
29const options = await fetch('/api/passkeys/login/options').then((r) => r.json());
30 
31const credential = await navigator.credentials.get({
32  publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),
33});
34 
35await fetch('/api/passkeys/login/verify', {
36  method: 'POST',
37  headers: { 'Content-Type': 'application/json' },
38  body: JSON.stringify(credential?.toJSON()),
39});
40```
41 
42Kung nakita mo ang iyong sarili na nagpapatupad ng WebAuthn encryption sa pamamagitan ng kamay, huminto. Gumamit ng isang mahusay na library sa panig ng server. Ang mga error dito ay hindi "cute na mga bug", sila ay mga butas sa pagpapatunay.
43 
44## Ano ang ise-save sa database
45 
46Hindi na kailangang iligtas ang kalahati ng mundo. Karaniwan sapat:
47 
48- ID ng kredensyal;
49- pampublikong susi;
50- konektadong gumagamit;
51- anumang verification counter o metadata;
52- transports, kung kapaki-pakinabang para sa UX;
53- pangalan na pinili ng gumagamit;
54- petsa ng paglikha at huling paggamit.
55 
56Ang isang minimal na talahanayan ay maaaring magmukhang ganito:
57 
58```sql
59create table passkey_credentials (
60  id uuid primary key default gen_random_uuid(),
61  user_id uuid not null references users(id),
62  credential_id text not null unique,
63  public_key text not null,
64  name text,
65  created_at timestamptz not null default now(),
66  last_used_at timestamptz
67);
68```
69 
70Pagkatapos ay magdaragdag ako ng mga audit log at notification: kung may gumawa ng bagong passkey sa aking account, gusto kong malaman ang tungkol dito.
71 
72## Mas mahalaga ang UX kaysa sa demo
73 
74Ang demo ng isang passkey ay palaging maganda: mag-click ka, Face ID, pasok ka na. Ang aktwal na produkto ay mas kumplikado.
75 
76May nagpalit ng phone. May gumagamit ng naka-lock na computer ng kumpanya. Hindi maintindihan ng ilang tao kung bakit nagmumungkahi ang browser ng passkey. May nawalan ng access sa kanilang device.
77 
78Ito ang dahilan kung bakit hindi ako magsisimula sa "mula ngayon wala nang mga password para sa lahat". Magsisimula ako ng ganito:
79 
801. passkey opsyonal para sa mga panloob na user;
812. mungkahi na lumikha ng isa pagkatapos ng matagumpay na pag-login;
823. pahina ng account upang palitan ang pangalan at alisin ang passkey;
834. malinaw na fallback;
845. unti-unting paglulunsad sa pangunahing pag-login.
85 
86Ang teksto sa interface ay dapat na simple. "Gamitin ang lock screen ng iyong device" ay mas mahusay kaysa sa "patotohanan gamit ang isang residente FIDO2 kredensyal."
87 
88## Mga pagkakamaling iiwasan ko
89 
90Huwag bumuo ng mga hamon sa kliyente. Ang hamon ay nilikha sa server at dapat na ma-verify nang isang beses lamang.
91 
92Huwag basta basta magtitiwala sa credential ID. Kailangan mong i-verify ang lagda, hamon, pinagmulan at Relying Party ID.
93 
94Huwag tanggalin ang mga fallback bago ka magkaroon ng magandang daloy ng pagbawi. Ang passwordless ay hindi kailangang maging "kung mawala mo ang iyong telepono ay wala ka nang tuluyan".
95 
96Huwag ituring ang passkey bilang purong frontend na button. Ang pagtatago ng button ay hindi seguridad: ang tunay na verification ay server-side.
97 
98## Passkey-una o passkey-friendly?
99 
100Para sa isang bagong produkto maaari mong isipin ang passkey-una. Para sa isang umiiral na app mas gusto ko ang passkey-friendly: idagdag ang passkey bilang isang inirerekomendang paraan, sukatin ang tagumpay at mga problema, pagkatapos ay mahinahong bawasan ang bigat ng password.
101 
102Ang perpektong migration ay hindi nararamdaman. Natuklasan ng user na mas madali ang pag-log in, hindi na binago ng kumpanya ang protocol ng pagpapatunay nito.
103 
104## Konklusyon
105 
106Ang passkey ay kawili-wili dahil pinapahusay nila ang seguridad at UX sa parehong oras, na bihira. Ang mga ito ay hindi isang magic wand: ang pagbawi, pagiging tugma, suporta at paglulunsad ay nananatiling maayos na idinisenyo.
107 
108Ngunit ang pangunahing pagbabago ay malakas. Itigil ang pagtatanong sa mga user na mag-imbento at magprotekta ng mga lihim. Hinayaan mong lumagda ang device sa isang cryptographic na patunay na nakatali sa iyong domain. Mas kaunting memorya ng tao, mas kaunting phishing, mas kaunting pag-reset ng password. Masasabi kong sulit silang seryosohin.
109 
110## Mga Pinagmulan
111 
112- [MDN: Passkeys](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Passkeys)
113- [MDN: Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)
114- [W3C: Web Authentication](https://www.w3.org/TR/webauthn-3/)
115- [passkeys.dev](https://passkeys.dev/)
116

:Passkey at WebAuthn: mag-login nang walang password, walang magiclines 1-116 (END) — press q to close

2Ang mga password ay isa sa mga bagay na na-normalize namin dahil nakasama namin sila sa loob ng maraming taon. Ang mga gumagamit ay nakakalimutan ang mga ito, muling ginagamit ang mga ito, isulat ang mga ito kung saan hindi nila dapat. Dapat pamahalaan ng mga koponan ang mga pag-reset, patakaran, hash, leaks, phishing at suporta.

4Hindi ginagawang perpekto ng passkey ang pagpapatunay, ngunit inaalis nila ang isang malaking problema: hindi na kailangang magtago ng lihim na ibinahagi sa user ang server.

6## Ano ba talaga ang nangyayari

8Ang passkey ay isang kredensyal batay sa WebAuthn. Kapag ginawa ito ng user, bubuo ang device ng key pair:

10- isang pribadong key, na nananatili sa device o sa password manager;

11- isang pampublikong key, na maaaring i-save ng server.

13Kapag nag-log in ang server ay hindi nagtatanong ng "sabihin sa akin ang password". Magpadala ng random na hamon. Pipirmahan ito ng device gamit ang pribadong key. Bine-verify ng server ang lagda gamit ang pampublikong susi.

15Iyan ang magandang bahagi: kung ang database ay ninakaw, walang mga password sa loob upang i-crack. At kung ang isang user ay napunta sa isang pekeng domain, ang passkey ay hindi wasto para sa domain na iyon. Ito ay hindi lamang kaginhawaan, ito ay konkretong proteksyon laban sa phishing.

17## Ang browser ay gumaganap bilang isang tulay

19Sa browser ang dalawang pangunahing API ay:

21- `navigator.credentials.create()` upang lumikha ng passkey;

22- `navigator.credentials.get()` upang gamitin ito sa panahon ng pag-login.

24Ngunit ang mahalagang lohika ay nasa server. Dapat buuin ng server ang hamon, pansamantalang i-save ito, i-verify ang tugon, suriin ang pinagmulan at Relying Party ID, pagkatapos ay gawin ang session.

26Ang bahagi ng kliyente ay dapat na halos mayamot:

28```typescript

29const options = await fetch('/api/passkeys/login/options').then((r) => r.json());

31const credential = await navigator.credentials.get({

32 publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),

33});

35await fetch('/api/passkeys/login/verify', {

36 method: 'POST',

37 headers: { 'Content-Type': 'application/json' },

38 body: JSON.stringify(credential?.toJSON()),

39});

40```

42Kung nakita mo ang iyong sarili na nagpapatupad ng WebAuthn encryption sa pamamagitan ng kamay, huminto. Gumamit ng isang mahusay na library sa panig ng server. Ang mga error dito ay hindi "cute na mga bug", sila ay mga butas sa pagpapatunay.

44## Ano ang ise-save sa database

46Hindi na kailangang iligtas ang kalahati ng mundo. Karaniwan sapat:

48- ID ng kredensyal;

49- pampublikong susi;

50- konektadong gumagamit;

51- anumang verification counter o metadata;

52- transports, kung kapaki-pakinabang para sa UX;

53- pangalan na pinili ng gumagamit;

54- petsa ng paglikha at huling paggamit.

56Ang isang minimal na talahanayan ay maaaring magmukhang ganito:

58```sql

59create table passkey_credentials (

60 id uuid primary key default gen_random_uuid(),

61 user_id uuid not null references users(id),

62 credential_id text not null unique,

63 public_key text not null,

64 name text,

65 created_at timestamptz not null default now(),

66 last_used_at timestamptz

67);

68```

70Pagkatapos ay magdaragdag ako ng mga audit log at notification: kung may gumawa ng bagong passkey sa aking account, gusto kong malaman ang tungkol dito.

72## Mas mahalaga ang UX kaysa sa demo

74Ang demo ng isang passkey ay palaging maganda: mag-click ka, Face ID, pasok ka na. Ang aktwal na produkto ay mas kumplikado.

76May nagpalit ng phone. May gumagamit ng naka-lock na computer ng kumpanya. Hindi maintindihan ng ilang tao kung bakit nagmumungkahi ang browser ng passkey. May nawalan ng access sa kanilang device.

78Ito ang dahilan kung bakit hindi ako magsisimula sa "mula ngayon wala nang mga password para sa lahat". Magsisimula ako ng ganito:

801. passkey opsyonal para sa mga panloob na user;

812. mungkahi na lumikha ng isa pagkatapos ng matagumpay na pag-login;

823. pahina ng account upang palitan ang pangalan at alisin ang passkey;

834. malinaw na fallback;

845. unti-unting paglulunsad sa pangunahing pag-login.

86Ang teksto sa interface ay dapat na simple. "Gamitin ang lock screen ng iyong device" ay mas mahusay kaysa sa "patotohanan gamit ang isang residente FIDO2 kredensyal."

88## Mga pagkakamaling iiwasan ko

90Huwag bumuo ng mga hamon sa kliyente. Ang hamon ay nilikha sa server at dapat na ma-verify nang isang beses lamang.

92Huwag basta basta magtitiwala sa credential ID. Kailangan mong i-verify ang lagda, hamon, pinagmulan at Relying Party ID.

94Huwag tanggalin ang mga fallback bago ka magkaroon ng magandang daloy ng pagbawi. Ang passwordless ay hindi kailangang maging "kung mawala mo ang iyong telepono ay wala ka nang tuluyan".

96Huwag ituring ang passkey bilang purong frontend na button. Ang pagtatago ng button ay hindi seguridad: ang tunay na verification ay server-side.

98## Passkey-una o passkey-friendly?

100Para sa isang bagong produkto maaari mong isipin ang passkey-una. Para sa isang umiiral na app mas gusto ko ang passkey-friendly: idagdag ang passkey bilang isang inirerekomendang paraan, sukatin ang tagumpay at mga problema, pagkatapos ay mahinahong bawasan ang bigat ng password.

101

102Ang perpektong migration ay hindi nararamdaman. Natuklasan ng user na mas madali ang pag-log in, hindi na binago ng kumpanya ang protocol ng pagpapatunay nito.

103

104## Konklusyon

105

106Ang passkey ay kawili-wili dahil pinapahusay nila ang seguridad at UX sa parehong oras, na bihira. Ang mga ito ay hindi isang magic wand: ang pagbawi, pagiging tugma, suporta at paglulunsad ay nananatiling maayos na idinisenyo.

107

108Ngunit ang pangunahing pagbabago ay malakas. Itigil ang pagtatanong sa mga user na mag-imbento at magprotekta ng mga lihim. Hinayaan mong lumagda ang device sa isang cryptographic na patunay na nakatali sa iyong domain. Mas kaunting memorya ng tao, mas kaunting phishing, mas kaunting pag-reset ng password. Masasabi kong sulit silang seryosohin.

109

110## Mga Pinagmulan

111

112- [MDN: Passkeys](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Passkeys)

113- [MDN: Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)

114- [W3C: Web Authentication](https://www.w3.org/TR/webauthn-3/)

115- [passkeys.dev](https://passkeys.dev/)

116