Passkey và WebAuthn: đăng nhập không cần mật khẩu, không cần phép thuật

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

1 
2Mật khẩu là một trong những thứ mà chúng ta đã bình thường hóa chỉ vì chúng ta đã sử dụng chúng trong nhiều năm. Người dùng quên chúng, sử dụng lại chúng, viết chúng vào những nơi không nên dùng. Các nhóm phải quản lý việc đặt lại, chính sách, băm, rò rỉ, lừa đảo và hỗ trợ.
3 
4passkey không giúp quá trình xác thực trở nên hoàn hảo nhưng chúng loại bỏ được một vấn đề lớn: máy chủ không còn phải giữ bí mật được chia sẻ với người dùng nữa.
5 
6## Điều gì thực sự xảy ra
7 
8passkey là thông tin xác thực dựa trên WebAuthn. Khi người dùng tạo, thiết bị sẽ tạo ra một cặp khóa:
9 
10- khóa riêng vẫn còn trên thiết bị hoặc trong trình quản lý mật khẩu;
11- một khóa công khai mà máy chủ có thể lưu.
12 
13Khi đăng nhập vào máy chủ không hỏi "cho tôi biết mật khẩu". Gửi một thử thách ngẫu nhiên. Thiết bị ký tên bằng khóa riêng. Máy chủ xác minh chữ ký bằng khóa chung.
14 
15Đó là phần hay: nếu cơ sở dữ liệu bị đánh cắp thì sẽ không có mật khẩu nào bên trong để bẻ khóa. Và nếu người dùng sử dụng một miền giả thì passkey sẽ không hợp lệ cho miền đó. Đó không chỉ là sự tiện lợi mà còn là sự bảo vệ cụ thể chống lại lừa đảo.
16 
17## Trình duyệt đóng vai trò là cầu nối
18 
19Trong trình duyệt, hai API chính là:
20 
21- `navigator.credentials.create()` để tạo passkey;
22- `navigator.credentials.get()` để sử dụng nó trong quá trình đăng nhập.
23 
24Nhưng logic quan trọng là trên máy chủ. Máy chủ phải tạo thử thách, lưu tạm thời, xác minh phản hồi, kiểm tra nguồn và Relying Party ID, sau đó tạo phiên.
25 
26Phần client sẽ gần như nhàm chán:
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 
42Nếu bạn thấy mình đang triển khai mã hóa WebAuthn bằng tay, hãy dừng lại. Sử dụng thư viện phía máy chủ mạnh mẽ. Lỗi ở đây không phải là "lỗi dễ thương" mà là lỗ hổng xác thực.
43 
44## Lưu gì vào cơ sở dữ liệu
45 
46Không cần thiết phải cứu một nửa thế giới. Thông thường là đủ:
47 
48- ID của giấy chứng nhận;
49- khóa công khai;
50- người dùng được kết nối;
51- bất kỳ bộ đếm xác minh hoặc siêu dữ liệu nào;
52- phương tiện vận chuyển, nếu hữu ích cho UX;
53- tên do người dùng chọn;
54- ngày tạo và lần sử dụng cuối cùng.
55 
56Một bảng tối thiểu có thể trông như thế này:
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 
70Sau đó, tôi sẽ thêm nhật ký kiểm tra và thông báo: nếu ai đó tạo passkey mới trên tài khoản của tôi, tôi muốn biết về điều đó.
71 
72## UX quan trọng hơn bản demo
73 
74Bản demo của passkey luôn đẹp: bạn nhấp vào, Face ID, bạn đã tham gia. Sản phẩm thực tế phức tạp hơn.
75 
76Có người thay đổi điện thoại của họ. Ai đó sử dụng máy tính công ty bị khóa. Một số người không hiểu tại sao trình duyệt lại gợi ý passkey. Ai đó mất quyền truy cập vào thiết bị của họ.
77 
78Đây là lý do tại sao tôi sẽ không bắt đầu với câu "từ hôm nay không còn mật khẩu nào cho mọi người nữa". Tôi sẽ bắt đầu như thế này:
79 
801. passkey tùy chọn đối với người dùng nội bộ;
812. đề xuất tạo một tài khoản sau khi đăng nhập thành công;
823. trang tài khoản để đổi tên và xóa passkey;
834. dự phòng rõ ràng;
845. triển khai dần dần trong lần đăng nhập chính.
85 
86Văn bản trong giao diện phải đơn giản. "Sử dụng màn hình khóa của thiết bị của bạn" tốt hơn là "xác thực bằng thông tin xác thực FIDO2 của cư dân."
87 
88## Những sai lầm tôi sẽ tránh
89 
90Không tạo ra thách thức cho khách hàng. Thử thách được tạo trên máy chủ và chỉ phải được xác minh một lần.
91 
92Đừng chỉ tin tưởng vào ID thông tin xác thực. Bạn cần xác minh chữ ký, thách thức, nguồn gốc và Relying Party ID.
93 
94Đừng xóa các bản dự phòng trước khi bạn có quy trình khôi phục tốt. Không cần mật khẩu không nhất thiết phải trở thành "nếu bạn mất điện thoại, bạn sẽ bị loại vĩnh viễn".
95 
96Đừng coi passkey như một nút giao diện người dùng thuần túy. Ẩn nút không phải là bảo mật: xác minh thực sự là phía máy chủ.
97 
98## Passkey-đầu tiên hay passkey-thân thiện?
99 
100Đối với một sản phẩm mới, bạn có thể nghĩ đến passkey-đầu tiên. Đối với ứng dụng hiện có, tôi thích passkey thân thiện hơn: thêm passkey làm phương pháp được đề xuất, đo lường mức độ thành công và vấn đề, sau đó bình tĩnh giảm trọng lượng mật khẩu.
101 
102Sự di cư lý tưởng không được cảm nhận. Người dùng phát hiện ra rằng việc đăng nhập dễ dàng hơn chứ không phải công ty đã thay đổi giao thức xác thực.
103 
104## Kết luận
105 
106passkey rất thú vị vì chúng cải thiện tính bảo mật và trải nghiệm người dùng cùng một lúc, điều này rất hiếm. Chúng không phải là cây đũa thần: khả năng phục hồi, khả năng tương thích, hỗ trợ và triển khai vẫn phải được thiết kế tốt.
107 
108Nhưng sự thay đổi cơ bản là mạnh mẽ. Hãy ngừng yêu cầu người dùng phát minh và bảo vệ bí mật. Bạn để thiết bị ký bằng chứng mật mã gắn liền với miền của bạn. Ít bộ nhớ con người hơn, ít lừa đảo hơn, ít đặt lại mật khẩu hơn. Tôi muốn nói rằng chúng đáng được xem xét nghiêm túc.
109 
110## Nguồn
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 và WebAuthn: đăng nhập không cần mật khẩu, không cần phép thuậtlines 1-116 (END) — press q to close

2Mật khẩu là một trong những thứ mà chúng ta đã bình thường hóa chỉ vì chúng ta đã sử dụng chúng trong nhiều năm. Người dùng quên chúng, sử dụng lại chúng, viết chúng vào những nơi không nên dùng. Các nhóm phải quản lý việc đặt lại, chính sách, băm, rò rỉ, lừa đảo và hỗ trợ.

4passkey không giúp quá trình xác thực trở nên hoàn hảo nhưng chúng loại bỏ được một vấn đề lớn: máy chủ không còn phải giữ bí mật được chia sẻ với người dùng nữa.

6## Điều gì thực sự xảy ra

8passkey là thông tin xác thực dựa trên WebAuthn. Khi người dùng tạo, thiết bị sẽ tạo ra một cặp khóa:

10- khóa riêng vẫn còn trên thiết bị hoặc trong trình quản lý mật khẩu;

11- một khóa công khai mà máy chủ có thể lưu.

13Khi đăng nhập vào máy chủ không hỏi "cho tôi biết mật khẩu". Gửi một thử thách ngẫu nhiên. Thiết bị ký tên bằng khóa riêng. Máy chủ xác minh chữ ký bằng khóa chung.

15Đó là phần hay: nếu cơ sở dữ liệu bị đánh cắp thì sẽ không có mật khẩu nào bên trong để bẻ khóa. Và nếu người dùng sử dụng một miền giả thì passkey sẽ không hợp lệ cho miền đó. Đó không chỉ là sự tiện lợi mà còn là sự bảo vệ cụ thể chống lại lừa đảo.

17## Trình duyệt đóng vai trò là cầu nối

19Trong trình duyệt, hai API chính là:

21- `navigator.credentials.create()` để tạo passkey;

22- `navigator.credentials.get()` để sử dụng nó trong quá trình đăng nhập.

24Nhưng logic quan trọng là trên máy chủ. Máy chủ phải tạo thử thách, lưu tạm thời, xác minh phản hồi, kiểm tra nguồn và Relying Party ID, sau đó tạo phiên.

26Phần client sẽ gần như nhàm chán:

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```

42Nếu bạn thấy mình đang triển khai mã hóa WebAuthn bằng tay, hãy dừng lại. Sử dụng thư viện phía máy chủ mạnh mẽ. Lỗi ở đây không phải là "lỗi dễ thương" mà là lỗ hổng xác thực.

44## Lưu gì vào cơ sở dữ liệu

46Không cần thiết phải cứu một nửa thế giới. Thông thường là đủ:

48- ID của giấy chứng nhận;

49- khóa công khai;

50- người dùng được kết nối;

51- bất kỳ bộ đếm xác minh hoặc siêu dữ liệu nào;

52- phương tiện vận chuyển, nếu hữu ích cho UX;

53- tên do người dùng chọn;

54- ngày tạo và lần sử dụng cuối cùng.

56Một bảng tối thiểu có thể trông như thế này:

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```

70Sau đó, tôi sẽ thêm nhật ký kiểm tra và thông báo: nếu ai đó tạo passkey mới trên tài khoản của tôi, tôi muốn biết về điều đó.

72## UX quan trọng hơn bản demo

74Bản demo của passkey luôn đẹp: bạn nhấp vào, Face ID, bạn đã tham gia. Sản phẩm thực tế phức tạp hơn.

76Có người thay đổi điện thoại của họ. Ai đó sử dụng máy tính công ty bị khóa. Một số người không hiểu tại sao trình duyệt lại gợi ý passkey. Ai đó mất quyền truy cập vào thiết bị của họ.

78Đây là lý do tại sao tôi sẽ không bắt đầu với câu "từ hôm nay không còn mật khẩu nào cho mọi người nữa". Tôi sẽ bắt đầu như thế này:

801. passkey tùy chọn đối với người dùng nội bộ;

812. đề xuất tạo một tài khoản sau khi đăng nhập thành công;

823. trang tài khoản để đổi tên và xóa passkey;

834. dự phòng rõ ràng;

845. triển khai dần dần trong lần đăng nhập chính.

86Văn bản trong giao diện phải đơn giản. "Sử dụng màn hình khóa của thiết bị của bạn" tốt hơn là "xác thực bằng thông tin xác thực FIDO2 của cư dân."

88## Những sai lầm tôi sẽ tránh

90Không tạo ra thách thức cho khách hàng. Thử thách được tạo trên máy chủ và chỉ phải được xác minh một lần.

92Đừng chỉ tin tưởng vào ID thông tin xác thực. Bạn cần xác minh chữ ký, thách thức, nguồn gốc và Relying Party ID.

94Đừng xóa các bản dự phòng trước khi bạn có quy trình khôi phục tốt. Không cần mật khẩu không nhất thiết phải trở thành "nếu bạn mất điện thoại, bạn sẽ bị loại vĩnh viễn".

96Đừng coi passkey như một nút giao diện người dùng thuần túy. Ẩn nút không phải là bảo mật: xác minh thực sự là phía máy chủ.

98## Passkey-đầu tiên hay passkey-thân thiện?

100Đối với một sản phẩm mới, bạn có thể nghĩ đến passkey-đầu tiên. Đối với ứng dụng hiện có, tôi thích passkey thân thiện hơn: thêm passkey làm phương pháp được đề xuất, đo lường mức độ thành công và vấn đề, sau đó bình tĩnh giảm trọng lượng mật khẩu.

101

102Sự di cư lý tưởng không được cảm nhận. Người dùng phát hiện ra rằng việc đăng nhập dễ dàng hơn chứ không phải công ty đã thay đổi giao thức xác thực.

103

104## Kết luận

105

106passkey rất thú vị vì chúng cải thiện tính bảo mật và trải nghiệm người dùng cùng một lúc, điều này rất hiếm. Chúng không phải là cây đũa thần: khả năng phục hồi, khả năng tương thích, hỗ trợ và triển khai vẫn phải được thiết kế tốt.

107

108Nhưng sự thay đổi cơ bản là mạnh mẽ. Hãy ngừng yêu cầu người dùng phát minh và bảo vệ bí mật. Bạn để thiết bị ký bằng chứng mật mã gắn liền với miền của bạn. Ít bộ nhớ con người hơn, ít lừa đảo hơn, ít đặt lại mật khẩu hơn. Tôi muốn nói rằng chúng đáng được xem xét nghiêm túc.

109

110## Nguồn

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