- Google cung cấp passkey làm tùy chọn mặc định cho Google Account cá nhân, giúp việc chuyển sang đăng nhập không cần mật khẩu trở nên dễ dàng hơn
- Từ lần đăng nhập tiếp theo, lời nhắc tạo và sử dụng passkey sẽ xuất hiện, và tùy chọn “Skip password when possible” trong phần cài đặt tài khoản sẽ hiển thị ở trạng thái bật
- Passkey cho phép đăng nhập bằng vân tay, quét khuôn mặt, PIN dùng để mở khóa thiết bị; Google cho rằng cách này nhanh hơn mật khẩu 40% và an toàn hơn nhờ cơ chế mã hóa
- Đăng nhập bằng mật khẩu sẽ tiếp tục được duy trì trong thời gian tới; người dùng không muốn sử dụng có thể tắt “Skip password when possible” để từ chối dùng passkey
- Passkey đã được dùng trong YouTube, Search, Maps; Uber và eBay cũng đang hỗ trợ, và khả năng tương thích với WhatsApp sẽ sớm được cung cấp
Thay đổi mặc định đăng nhập cho Google Account cá nhân
- Google cho biết phản hồi của người dùng là tích cực sau khi ra mắt hỗ trợ passkey hồi đầu năm nay
- Giờ đây, passkey được cung cấp làm tùy chọn đăng nhập mặc định trên toàn bộ Google Account cá nhân
- Khi đăng nhập tài khoản lần tiếp theo, lời nhắc tạo và sử dụng passkey sẽ xuất hiện
- Trong phần cài đặt Google Account, tùy chọn “Skip password when possible” sẽ hiển thị ở trạng thái bật
Cách sử dụng passkey và đặc tính bảo mật
- Passkey sử dụng vân tay, quét khuôn mặt, PIN giống như khi mở khóa thiết bị để đăng nhập tài khoản
- Theo Google, đăng nhập bằng passkey nhanh hơn 40% so với mật khẩu
- Passkey an toàn hơn nhờ dựa vào cơ chế mã hóa và cũng có khả năng chống phishing
- Người dùng có thể giảm bớt gánh nặng phải nhớ các con số và ký tự đặc biệt trong mật khẩu
Mật khẩu và quyền lựa chọn của người dùng vẫn được duy trì
- Google cho rằng công nghệ mới cần thời gian để phổ biến, nên mật khẩu có thể vẫn tồn tại thêm một thời gian
- Người dùng vẫn có thể đăng nhập bằng mật khẩu
- Người dùng không muốn dùng passkey có thể tắt tùy chọn “Skip password when possible”
Hỗ trợ passkey lan rộng ra ngoài Google
- Kể từ khi passkey ra mắt, người dùng đã sử dụng passkey trong các ứng dụng Google như YouTube, Search, Maps
- Google đánh giá tích cực xu hướng ngày càng nhiều doanh nghiệp trong ngành áp dụng passkey
- Uber và eBay cung cấp lựa chọn đăng nhập nền tảng không cần dùng mật khẩu
- Khả năng tương thích với WhatsApp cũng sẽ sớm được cung cấp
Bước tiếp theo hướng tới đăng nhập không cần mật khẩu
- Google sẽ tiếp tục thông báo những nơi có thể sử dụng passkey cho các tài khoản trực tuyến khác
- Google thúc đẩy ngành chuyển sang passkey để giảm việc sử dụng mật khẩu, và cuối cùng biến mật khẩu thành thứ hiếm khi cần dùng
- Có thể xem thông tin liên quan đến bảo mật tài khoản Google tại myaccount.google.com/safer
1 bình luận
Ý kiến trên Hacker News
Như nhiều người đã nói, nếu mất thiết bị thì việc bắt đầu lại xác thực bằng mật mã học là cực kỳ khó
Tháng trước vợ tôi làm vỡ kính iPhone và đem sửa qua AppleCare, nhưng Apple không hề cho biết rằng “sửa kính” trên thực tế bao gồm cả việc thay linh kiện bên trong và khôi phục cài đặt gốc
Bản sao lưu Apple iPhone không chứa các bí mật mật mã học như eSIM
Cuối cùng rơi vào vòng lặp: để kích hoạt eSIM thì cần email, email cần MS Authenticator, còn MS Authenticator thì không thể kích hoạt nếu không có SMS
Chúng tôi phải mang theo một đống giấy tờ tùy thân có ảnh đến tận cửa hàng của nhà mạng để được cấp lại eSIM, và dù mật khẩu đúng, tài khoản ngân hàng cũng bị khóa vì một dạng khóa phần cứng điện thoại nào đó
Mất vài ngày mới giải quyết xong và phải trực tiếp đến nhiều tổ chức. Nếu đang đi du lịch nước ngoài thì chắc chắn đã bị kẹt hoàn toàn
Thời thế đã thay đổi, và giờ đây toàn bộ danh tính số đã trở thành một smart card nằm trong điện thoại. Smart card đó, dù là SIM hay chip TPM tích hợp, nếu mất đi thì trong mắt người khác bạn chẳng khác nào người đã chết
Passkey làm vấn đề này tệ hơn rất nhiều. Nếu còn SIM vật lý thì ít nhất có thể chuyển từ điện thoại này sang điện thoại khác, nhưng Passkey thì không thể chuyển giữa các nhà cung cấp
Nên vừa la hét vừa bỏ chạy. Đừng tin những lời thổi phồng, hãy đợi đến khi các nhà cung cấp đưa ra giải pháp chuyển đổi và khôi phục cho tử tế
Mọi người ghét mật khẩu, nhưng trên thực tế trong nhiều tình huống và mô hình đe dọa, mật khẩu là thỏa hiệp tốt nhất. Nếu lấy 32 byte trở lên từ
/dev/randomrồi mã hóa theo cách bạn muốn, thì trong vũ trụ này không ai có thể brute-force được, và trình quản lý mật khẩu cũng giải quyết vấn đề tái sử dụngHơn nữa, nó còn có lợi thế là tôi có thể kiểm soát cách lưu trữ và áp dụng sao lưu dự phòng nhiều đến mức đủ yên tâm
Bản sao lưu iPhone bao gồm cả bản sao lưu các mục được lưu trong iCloud Keychain, và nếu có một thiết bị Apple khác hoặc khóa khôi phục thì có thể truy cập lại. Chỉ cần mật mã thiết bị hoặc khóa khôi phục là có thể bootstrap lại mọi thứ
eSIM là thứ của nhà mạng nên khá đặc thù; những thứ như vậy vốn đã và sẽ vẫn phiền phức vì bị gắn với cửa hàng và cuộc gọi điện thoại
Tôi gần như dùng 3 cái: Yubikey cho workstation, Yubikey mang theo, và điện thoại. Cả 3 thứ này đều có thể khởi động lại Google cho email và Apple cho điện thoại. Phần còn lại nằm trong 1Password và có thể truy cập thông qua các phương tiện này
Ngay cả trong tình huống khẩn cấp tệ nhất của tệ nhất, tôi nghĩ email cũng có thể lấy lại bằng cách nào đó. Nếu xác minh danh tính với nhà cung cấp DNS và đổi bản ghi MX thì có thể tiếp tục xử lý công việc. Dù vậy, tôi không nghĩ nó đến mức thiết yếu cho sinh hoạt hằng ngày. Mất quyền truy cập sẽ cực kỳ bất tiện, nhưng có lẽ không phải án tử
Danh bạ SMS và Signal cũng có ở nơi khác, còn tiền trong tài khoản ngân hàng thì có thể dùng bằng cách viết séc. Các tài khoản liên quan đến công ty thì nếu trực tiếp xuất hiện ở văn phòng là vào được
Tuy nhiên tôi cho rằng Passkey rất có thể quá phức tạp với người dùng máy tính phổ thông. Đáng tiếc là cách “mỗi lần đăng nhập chúng tôi sẽ gửi link qua email cho bạn” có vẻ là kiểu xác thực không mật khẩu thân thiện với người dùng nhất
Tôi cũng không thật sự yên tâm với thói quen đưa Passkey vào 1Password. Vì tôi biết mình sẽ bị buộc chặt vào đó mãi mãi. Dù vậy tôi thích dịch vụ này, và khi nào muốn chuyển đi thì ít nhất tôi có danh sách các tài khoản cần tạo lại
Điều tôi sợ nhất là tình huống quên mật mã điện thoại. Có lần tôi vừa thức dậy và đúng lúc rất không may bị xao nhãng, hoàn toàn không thể nhớ nổi mã 6 chữ số. Tôi cũng dùng cùng mã đó để mở khóa workstation. Sau khi chuyển sự chú ý sang việc khác một lúc, tôi mới nhờ trí nhớ cơ bắp mà nhớ ra
Đó thật sự là khoảnh khắc kiểu “mình vừa bị đột quỵ hay sao vậy”. Giờ tôi lưu mật mã đó trong 1Password, nên nếu còn một thiết bị đã mở khóa thì có thể khơi lại trí nhớ. Chuyện đó đã khá lâu rồi, và tôi không nghĩ là sa sút trí tuệ, chỉ là một hiện tượng nhất thời kỳ lạ
Ngược lại, tôi nhớ hoàn hảo tất cả các mật khẩu dùng ở nơi làm việc với thời hạn tối đa 1 năm. Dù nếu không nhớ nổi 6 chữ số kia thì cũng chẳng ích gì mấy
Vậy nên có lẽ chẳng bao lâu nữa mật khẩu cũng sẽ vào danh sách “Killed by Google”, và tài khoản của tôi cũng vào theo. Tôi không để bất kỳ thiết bị nào đăng nhập sẵn
Đã quá lâu rồi mới đến lúc chuyển nốt vài mục đích sử dụng còn lại. Tôi tự hỏi khi tình huống không thể tránh khỏi xảy ra, công ty có thể đặt lại Passkey tài khoản công việc của tôi hay không
Tôi thấy đây là hướng đi đúng, nhưng đã thấy quá nhiều câu chuyện kinh hoàng về việc bị khóa khỏi tài khoản Google hoặc iCloud mà thực tế không có cách nào lấy lại được
Chắc không chỉ mình tôi nghĩ vậy, nhưng có lẽ một ngày nào đó, có thể do lỗi của chính tôi, tôi sẽ bị Google khóa và đời sống số của tôi coi như chấm hết
Nếu có một công ty tư nhân cung cấp phương thức đăng nhập kiểu login.gov, và khi bị khóa vẫn cho phép nói chuyện với người thật như USPS, tôi sẵn sàng trả tiền
https://mastodon.laurenweinstein.org/@lauren/111103819626952...
https://mastodon.laurenweinstein.org/@lauren/111211366080459...
Không phải là nếu, mà là khi nào. Với những ai coi dữ liệu là quan trọng, sao lưu và một kế hoạch khôi phục sau thảm họa kỹ lưỡng là bắt buộc. Một công ty nào đó sẽ làm hỏng chuyện dù không phải lỗi của bạn, và điều đó là không thể tránh khỏi
Đáng tiếc là với một số khía cạnh của tài khoản bị mất, không có lựa chọn khôi phục sau thảm họa nào tốt, nhưng có nhiều tài khoản và tránh điểm lỗi đơn lẻ cũng giúp được phần nào
Bạn cần có nhiều phương thức độc lập để có thể đăng nhập. Ví dụ như in mã dự phòng và cất cùng các giấy tờ quan trọng
Nhưng điều này cũng không ngăn được tình huống bị khóa tài khoản do thay đổi chính sách của Google, nên lý tưởng nhất là cũng nên luyện tập sống sót mà không cần tài khoản Google
Lauren Weinstein đang cảnh báo rằng Passkey có khiếm khuyết và sẽ trở thành một rắc rối khổng lồ, đặc biệt với người dùng phổ thông
https://mastodon.laurenweinstein.org/@lauren/111103819626952...
https://mastodon.laurenweinstein.org/@lauren/111211366080459...
Tạm gác vấn đề quyền riêng tư và bị khóa trong hệ sinh thái nhà cung cấp sang một bên, Passkey không phải là một lựa chọn quá tệ cho những người tái sử dụng cùng một mật khẩu cơ bản trên mọi website mà không dùng xác thực hai bước
Nhưng ngay khi bắt đầu dựa vào nó để thực sự bảo vệ thứ gì đó, nó nhanh chóng trở thành một cơn ác mộng lớn. Tệ hơn nữa là nó bị đối xử như thể tương đương với mật khẩu + xác thực hai bước
Nói là “dễ tìm”, nhưng có vẻ lại không thực sự tìm được
https://mastodon.laurenweinstein.org/@lauren/111211489395997...
Nếu người dùng đằng nào cũng có khả năng dùng mật khẩu dịch vụ yếu, thì tôi không hiểu vì sao mật khẩu thiết bị yếu lại là lý do để tránh Passkey
Trong trường hợp đó, nếu xác thực thiết bị bị vượt qua thì dù sao tài khoản cũng đã bị xâm phạm
Đặc biệt, hiện tại Google không có cấu trúc bắt buộc phải chọn chỉ một trong hai: mật khẩu hoặc Passkey. Nếu thiết bị không có Passkey thì vẫn có thể quay lại luồng đăng nhập bằng mật khẩu
Để so sánh rủi ro và lợi ích, cần biết thực tế mọi người tái sử dụng mật khẩu nhiều đến mức nào, có dùng xác thực hai bước hay không, có phụ thuộc toàn bộ việc truy cập tài khoản vào khóa màn hình điện thoại hay không, có dùng xác thực sinh trắc học hay không, việc khôi phục tài khoản cần thiết đến mức nào, v.v.
Chỉ dữ liệu đó mới có thể làm rõ cuộc tranh luận, và cũng cho phép mỗi người đi đến kết luận khác nhau tùy hoàn cảnh của mình
Google có phần lớn các dữ liệu này. Nếu muốn củng cố lập luận của mình thì họ nên công bố
1Password gần đây đã bật hỗ trợ Passkey, và tôi đã “ngạc nhiên” khi biết rằng không có cách nào xuất chúng ra khỏi 1Password
Chúng không được đưa vào khi xuất định dạng 1PUX, cũng không có trong CSV
Nói cách khác, đúng nghĩa là không thể sao lưu. Nếu 1Password bị sập, công ty đóng cửa, hoặc có chuyện tương tự xảy ra, Passkey sẽ cứ thế biến mất. Hoàn toàn không có cách khôi phục
Tham khảo bài AMA gần đây của 1Password về Passkey liên quan đến chủ đề này:
https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd...
Còn về trường hợp 1Password ngừng hoạt động, cả mật khẩu lẫn Passkey đều được lưu cục bộ khi đồng bộ xuống thiết bị. Dù vì lý do nào đó bạn không thể truy cập 1Password, bạn vẫn tiếp tục truy cập được mọi mục trong kho, chỉ là không thể đồng bộ giữa các thiết bị nữa
Thay vì chuyển Passkey giữa các thiết bị, nên xem mô hình này giống SSH key: tạo Passkey khác nhau cho từng thiết bị và đăng ký tất cả với dịch vụ liên quan
Tất nhiên người dùng vẫn có thể bị lừa thêm Passkey của kẻ tấn công vào tài khoản của mình
Trên di động, vấn đề này đã được giải quyết từ nhiều năm trước, nhưng email thì đến giờ vẫn là một mớ hỗn độn. Bài học là tuyệt đối đừng để bị phụ thuộc
Nó chặn các lệnh gọi
window.credentials, và nếu muốn dùng 1Password cùng với một phương thức xác minh khác như Yubikey, bạn phải vào cài đặt và tắt toàn bộ tính năng PasskeyCách này cũng giống việc chặn prompt Google One Tap, vô hiệu hóa nó trên toàn cục rồi hiển thị prompt OAuth của riêng mình. Tôi chỉ dùng extension Chrome nên không biết trải nghiệm app native có khác nhiều không
Từ góc nhìn người dùng, tôi vẫn chưa hiểu
Nếu nhà bị cháy hoặc chuyện tương tự khiến mọi thiết bị đang đăng nhập Google đều hỏng thì sao? Làm thế nào đăng nhập lại vào tài khoản?
Tôi đưa cho họ một chiếc điện thoại cũ, chuyển SIM thì ổn, nhưng không thể nào đăng nhập tài khoản Google. Vì Google cứ kiên quyết hướng dẫn “hãy dùng điện thoại”. Laptop cũng đã bị đăng xuất khỏi email
May là do một sự cố trước đó tôi có token dự phòng, nên đã giải quyết được. Không biết những người khác sẽ làm thế nào
Chia khóa thành M mảnh, và cần N mảnh trong số đó để tái tạo. Ví dụ 3/8 nghĩa là chỉ cần 3 trong 8 mảnh là có thể khôi phục khóa. Gửi từng mảnh cho những người bạn tin tưởng, và khi cần khôi phục thì lấy mảnh từ ít nhất 3 người trong số họ để phục hồi khóa
Khi tôi triển khai trong một demo YC tên multipasskey, tôi cho người dùng chọn các liên hệ tin cậy, rồi gửi các mảnh khóa cho họ ở nền. Khi cần khôi phục, người dùng yêu cầu họ gửi lại, và nếu nhận đủ mảnh thì tái tạo khóa thiết bị. Khi có khóa thiết bị, hệ thống tải bản sao lưu khóa đã mã hóa từ máy chủ từ xa xuống và khôi phục như mới
Năm 2017/2018, tôi gọi dự án này là multipasskey và nộp đơn vào YC với một demo hoạt động được, nhưng bị từ chối. Tôi nghĩ chắc là do mình giải thích chưa tốt
Với tư cách người làm kỹ thuật, tôi đoán điều đó có nghĩa là nên gửi một thiết bị dự phòng cho bạn bè giữ hộ, hoặc cũng phải lưu Passkey trong tài khoản Apple/Microsoft/trình quản lý mật khẩu
Nhưng Google cần giải thích chi tiết hơn
Và tuyệt đối không được để mất số điện thoại. Dù có tên người dùng, mật khẩu, email khôi phục, bạn vẫn không thể vào lại tài khoản Google nếu không nhận được mã SMS
Trong giai đoạn chuyển tiếp này, cách được khuyến nghị là cung cấp Passkey như một lựa chọn thay thế cho các phương thức hiện có. Google và nhiều nhà cung cấp dịch vụ đang làm như vậy
Tuy nhiên câu hỏi nêu ra ở đây là vấn đề khôi phục tài khoản mà mọi người đều nên đặt ra, kể cả khi không có Passkey. Bạn cần có kế hoạch đăng nhập khi quên mật khẩu, không truy cập được trình quản lý mật khẩu, hoặc mất thiết bị xác thực thứ hai. Việc áp dụng Passkey không khiến nỗi lo khôi phục tài khoản biến mất hoàn toàn
Dù vậy, có một số trường hợp đặc biệt mà Passkey giúp khôi phục tài khoản tốt hơn. Nếu bạn tạo Passkey cho tài khoản Google trên thiết bị Apple dùng iCloud Keychain, Passkey đó sẽ được đồng bộ lên iCloud. Khi đó, ngay cả khi nhà cháy và mất toàn bộ thiết bị, miễn là bạn vẫn truy cập được tài khoản iCloud, bạn có thể lấy lại Passkey cho tài khoản Google và các website khác
Tất nhiên câu hỏi “nếu mất quyền truy cập tài khoản Apple iCloud thì sao?” là chính đáng. Vì vậy vấn đề khôi phục tài khoản không biến mất hoàn toàn, nhưng trong nhiều trường hợp Passkey có thể giảm đáng kể rủi ro đó
Ở đây có nghịch lý Simpson
Trung bình thì có thể nâng cao bảo mật. Vì đa số người dùng dùng mật khẩu rất tệ
Nhưng với những người dùng thành thạo sử dụng mật khẩu an toàn, nếu bị ép buộc thì bảo mật sẽ giảm mạnh
Xác thực 2 bước bắt buộc bằng số điện thoại cũng có hiệu ứng tương tự. Với Big G, xác thực 2 bước bắt buộc bằng số điện thoại là một chính sách chống ẩn danh được khoác áo bảo mật. Trường hợp lần này trông giống như một nỗ lực thu thập dữ liệu sinh trắc học
Số điện thoại là định danh dài hạn tốt nhất mà hầu hết mọi người có, và Google phải hỗ trợ khôi phục tài khoản cho hàng tỷ người dùng ở quy mô phi lý
Nhiều người làm mất mật khẩu và thiết bị, nhưng rất ít người mất số điện thoại
Vì vậy việc Google dùng số điện thoại để gán và ủy quyền danh tính trên nền tảng của mình là hợp logic. Điều này không tốt cho quyền riêng tư, nhưng lại rất tốt cho bảo mật vì nó cho phép kiểm soát dữ liệu bằng một “chứng danh” xác thực bên thứ ba mà người dùng không cần tự quản lý
Và phần này tôi không chắc, nên nếu ai biết thì xin sửa giúp. Ngay cả khi giả định là người dùng thành thạo miễn nhiễm với mật khẩu yếu, tái sử dụng mật khẩu và phishing, tôi hiểu rằng vẫn có một lợi thế bảo mật. Ngay cả khi Google Passkey bị rò rỉ, thứ bị lộ chỉ là khóa công khai, và vì không thể đăng nhập bằng khóa công khai nên vụ rò rỉ gần như vô dụng
Nếu Google đã thu thập dữ liệu sinh trắc học thì họ đã làm từ trước rồi, và điều đó không liên quan đến tính năng này
Những chi tiết rất cơ bản của mô hình bảo mật này đã đúng từ lâu, từ thời iPhone bắt đầu dùng Secure Enclave. Tôi không hiểu vì sao trên trang này mọi người lại nói chắc như đinh đóng cột về những thứ họ hoàn toàn không hiểu, và thành thật mà nói tôi thấy ngạc nhiên
Passkey về mặt đạo lý tương đương với việc dùng khóa SSH thay vì mật khẩu SSH khi đăng nhập vào máy chủ, chỉ là áp dụng nó cho website. Hơn nữa còn có một sự thật đơn giản, khách quan, không thể thay thế bằng ý tưởng “dùng mật khẩu an toàn”: Passkey đúng nghĩa là chống phishing
Tôi ngạc nhiên là họ đã thúc đẩy cái này rồi. Tính đến tuần trước, phần triển khai vẫn còn đủ thô nên tôi đã tắt nó trong tenant Workspace của mình
Hai điểm khó chịu nhất là Advanced Protection vẫn chưa hỗ trợ Passkey nên trước mắt phải giữ U2F, và nếu tài khoản đã thiết lập khóa U2F thì Google trước tiên sẽ hướng dẫn dùng nó như Passkey, rồi sau đó vì nó không phải Passkey nên lại bảo đăng nhập bằng mật khẩu
Kết quả là những người dùng xác thực đa yếu tố chống phishing mất khả năng cho thiết bị “ghi nhớ” bước xác thực đa yếu tố. Vì Google luôn yêu cầu yếu tố xác thực U2F trước mật khẩu
Riêng phần này, trong lúc chuẩn bị triển khai đăng nhập không mật khẩu dựa trên Okta cho vài khách hàng nhỏ, tôi đã thử nghiệm khá nhiều luồng FIDO2 dùng khóa bảo mật và Passkey trên nhiều loại thiết bị và nền tảng. Nhìn chung tôi thích bản thân luồng xác thực, nhưng có nhiều cái bẫy cần chú ý
Tôi đã mất khá nhiều thời gian để sắp xếp luồng chuẩn, tạo tài liệu onboarding và ghi lại các kịch bản duy trì hoạt động kinh doanh. Trường hợp sử dụng cá nhân theo vài cách còn khó hơn, vì phải nghĩ đến từng dịch vụ chứ không phải một IdP duy nhất
Nếu phải hỗ trợ nhiều môi trường, con đường dễ nhất hiện nay là đầu tư vào 1Password hoặc một trình quản lý mật khẩu khác hỗ trợ Passkey. Nó mang lại trải nghiệm người dùng nhất quán nhất và hoạt động trên hầu hết nền tảng, nhưng trên Android 14 vẫn còn vấn đề
Với các tài khoản đặc quyền cao, tôi sẽ tiếp tục dùng khóa phần cứng nên quản trị viên sẽ nhận một cặp khóa FIDO2. Những người còn lại nhận một Yubikey, đóng vai trò dự phòng khi mất quyền truy cập thiết bị hoặc phải đăng nhập từ thiết bị không đáng tin cậy. Android cũng là vấn đề ở đây. Ngay cả bản 14 dường như cũng không hỗ trợ luồng FIDO2 không mật khẩu
Đây là một hướng đi thú vị. Tuy nhiên cũng đáng chỉ ra rằng dữ liệu sinh trắc học như vân tay hay nhận diện khuôn mặt thực ra không phải là “bí mật”
Nó có thể bị quan sát hoặc khai thác mà người dùng không biết hoặc không đồng ý, và về nhiều mặt nó hoạt động giống tên người dùng hơn là mật khẩu
Vân tay chỉ mở khóa cặp khóa mật mã sẽ được dùng để xác thực
Tôi đang dùng Yubico Security Key làm Passkey, được bảo vệ bằng PIN 6 chữ số. PIN đó chỉ nằm cục bộ trên thiết bị, dùng để ngăn người có thiết bị vật lý đăng nhập ngay lập tức. Nhập sai PIN 10 lần liên tiếp thì khóa sẽ bị xóa
Khi nhập PIN, khóa được mở ra, và chính khóa đó là thứ cho phép vào tài khoản Google
Hầu hết tài khoản có mật khẩu đều có cơ chế an toàn kiểu “nếu chứng minh danh tính với công ty thì họ sẽ đặt lại cho bạn”. Chẳng hạn nếu không nhớ mật khẩu ngân hàng thì ngân hàng có đường để đặt lại
Với những thứ do Google kiểm soát, hoàn toàn không có cách liên hệ để giải quyết vấn đề. Đây đã là vấn đề trên mọi sản phẩm của Google
Khóa mọi quyền truy cập sau cánh cửa do Google kiểm soát là tự chuẩn bị một cơn ác mộng trong tương lai
Tiếc là hiện vẫn chưa thể lưu Passkey trong Bitwarden. Dù vậy, theo thông báo ở đầu trang này thì có vẻ tính năng đó sẽ có trong tháng 10
https://bitwarden.com/blog/bitwarden-passkey-management/