Tương lai không mật khẩu: Xây dựng hướng tới các hệ thống xác thực an toàn hơn và có thể sử dụng hơn

Thay thế mật khẩu bằng khóa riêng theo cách ẩn dụ dễ hiểu

Với việc giới thiệu sáng kiến ​​của EOSIO Labs ™, chúng tôi đã bắt đầu đổi mới theo hướng mở về tương lai của các công nghệ blockchain được xây dựng trên EOSIO. Bản phát hành đầu tiên của chúng tôi theo sáng kiến ​​này khám phá tương lai của quản lý khóa riêng và ý nghĩa của nó đối với bảo mật và quản lý khóa - Thư viện Universal Authenticator (UAL). Điều làm nền tảng cho triết lý của phiên bản này là một cuộc thăm dò vào một vấn đề lớn hơn, một vấn đề tập trung vào cách thức mật khẩu và xác thực đã được thực hiện trên internet, blockchain hay cách khác. Mặc dù không có bản phát hành phần mềm đi kèm với bài đăng này, bài viết này nhằm mục đích thảo luận về các vấn đề gây khó khăn cho các hệ thống xác thực hiện có và các nỗ lực hiện đại để vượt ra ngoài mật khẩu đối với các vấn đề như vậy. Sau đó, chúng tôi sẽ đề xuất, một cách trừu tượng, một mô hình mới sử dụng phép ẩn dụ của một Pass pass, như vé máy bay hoặc thẻ thư viện, để giải quyết những vấn đề này một cách an toàn và có thể sử dụng được.

Vấn đề tin đồn

Các phương pháp xác thực người dùng hiện tại phải chịu đựng những gì chúng ta sẽ gọi là Vấn đề Hearsay. Hearsay là bất kỳ thông tin nào nhận được từ một bên về các tuyên bố hoặc hành động của bên thứ hai không thể được chứng minh đầy đủ. Quan điểm của chúng tôi là tất cả các thông tin có nguồn gốc từ các hệ thống dựa trên các phương pháp xác thực hiện đại của người dùng sẽ đủ điều kiện chỉ là tin đồn nếu bất kỳ bên nào liên quan sẽ gọi tính hợp lệ của thông tin.

Để minh họa, hãy tưởng tượng một bài đăng trên phương tiện truyền thông xã hội kém được cho là của một chính trị gia nổi tiếng có nguy cơ phá hủy sự nghiệp của chính trị gia nói. Làm thế nào để chúng ta biết chắc chắn rằng các chính trị gia đã làm, trên thực tế, tác giả bài viết gây hại? Mặc dù tác giả thực sự có thể là chính trị gia đang bị nghi ngờ, nhưng cũng có thể là bất kỳ ai có quyền truy cập vào tài khoản truyền thông xã hội của chính trị gia. Để mở rộng lý do này, nhóm các tác giả có thể có thể bao gồm bất kỳ số người nào gần gũi với chính trị gia hoặc tin tặc bất lợi trong một cuộc tấn công nhắm mục tiêu. Tuy nhiên, không ai, kể cả chính trị gia và nhà cung cấp dịch vụ truyền thông xã hội, có thể đưa ra bằng chứng thuyết phục, không hoàn cảnh rằng chính trị gia này hoặc không chắc chắn là tác giả của bài viết đang nghi vấn.

Để sử dụng thuật ngữ pháp lý và kỹ thuật, đặc điểm này được gọi là tính thoái thác và nó không phải là một đặc điểm mong muốn. Hai yếu tố chính dẫn đến đặc điểm này của sự từ chối trong ví dụ truyền thông xã hội của chúng tôi ở trên; yếu tố đầu tiên là một kế hoạch xác thực yêu cầu tiết lộ bí mật để xác thực việc sở hữu bí mật đó. Trong các chương trình bảo mật (như mật khẩu) tuân theo yếu tố này, không thể tạo nhật ký hoạt động của người dùng có thể kiểm chứng được bởi bất kỳ ai khác ngoài bên và đối tác. Yếu tố thứ hai là thiếu phương tiện để chứng minh rằng dữ liệu trong một hệ thống thực sự đại diện cho ý định của người dùng, điều này dẫn chúng ta đến một vấn đề khác mà chúng ta đang gọi, đó là kiểm tra trống.

Vấn đề kiểm tra trống

Vấn đề Kiểm tra trống có mặt trong bất kỳ hệ thống nào có thể thực hiện hành động thay mặt người dùng mà không cần người dùng có sự đồng ý rõ ràng về hành động cụ thể đó. Nó cũng có mặt nếu phương tiện chiếm được sự đồng ý của người dùng là bất cứ điều gì thiếu bản ghi bằng chứng cho thấy người dùng đã được thông báo về ý nghĩa của mọi hành động riêng lẻ và đồng ý rõ ràng với từng hành động.

Trong ví dụ trên, vấn đề này bổ sung chính dịch vụ truyền thông xã hội cũng như nhiều nhân viên của mình vào danh sách các bên có thể đã đăng bài gây thiệt hại. Làm thế nào chúng ta có thể chứng minh rằng dịch vụ truyền thông xã hội hoặc một trong những nhân viên của nó không có quyền truy cập vào bài đăng trên Thay mặt chính trị gia? Một ví dụ cổ phần cao hơn của vấn đề này thể hiện sự phù hợp cho tên gọi Vấn đề kiểm tra trống là một tài khoản ngân hàng. Về mặt công nghệ, không có gì ngăn cản ngân hàng của bạn thanh lý hoặc khóa tiền của bạn và sẽ không có cách nào để chứng minh bất kỳ hành vi sai trái nào, vì Ngân hàng có thể bịa đặt hồ sơ về các giao dịch dường như hợp pháp. Điều này chắc chắn sẽ gây ra hậu quả nghiêm trọng ảnh hưởng đến nhiều bên liên quan một cách vật chất.

‘Hai trở thành một

Một nhà quan sát sắc sảo có thể nhận thấy rằng những vấn đề này thực sự là hai kết quả của cùng một vấn đề tiềm ẩn: việc thiếu nhật ký kiểm toán có thể chứng minh được. Mặc dù có những công nghệ giải quyết được thiếu sót cơ bản này trong các hệ thống hiện tại của chúng tôi, như các hệ thống dựa trên chứng chỉ dựa trên mật mã bất đối xứng, chúng vẫn chưa đạt được mức độ thân thiện với người dùng để chúng có thể truy cập được cho công chúng. Bằng cách giải quyết thách thức này bằng các phép ẩn dụ dễ hiểu cho một giải pháp lý thuyết mà chúng tôi sẽ trình bày dưới đây, chúng tôi có cơ hội cải thiện tính bảo mật và khả năng sử dụng của tất cả các hệ thống của chúng tôi, cho mọi loại người dùng và cải thiện trải nghiệm của người dùng trong quá trình .

Mật khẩu

Khi thảo luận về an ninh mạng, cần xác định hai thuật ngữ cơ bản: ‘xác thực, đó là quá trình người dùng chứng minh rằng họ là người họ nói họ sở hữu thông tin xác thực cụ thể, thường là với tên người dùng và mật khẩu; và ‘ủy quyền, đó là quá trình người dùng hành động trên một nền tảng phần mềm được cho phép hoặc hạn chế theo danh tính của họ.

Kể từ những năm 1960, mật khẩu là phương pháp thực tế cho phép người dùng tự xác thực với thiết bị hoặc dịch vụ. Xác thực mật khẩu, cho đến nay, là một công nghệ được hiểu rõ cho các kỹ sư. Đối với người dùng, mật khẩu đã trở thành một khái niệm đơn giản để nắm bắt; chúng thoải mái và quen thuộc ngay cả đối với người dùng không có kỹ thuật. Nhưng trong khi sự đơn giản và quen thuộc của chúng là một thế mạnh, mật khẩu cũng bị nhiều điểm yếu.

Những điểm yếu như vậy là cả công nghệ và con người trong tự nhiên. Một số trong số chúng đã được thảo luận rộng rãi, bao gồm chi tiết đầy đủ trong Nguyên tắc nhận dạng kỹ thuật số của NIST, vì vậy chúng tôi sẽ không nhắc lại chúng ở đây. Tuy nhiên, điều quan trọng cần nhớ là mật khẩu không cho phép nhật ký kiểm toán đáng tin cậy về các hành động mà người dùng đã ủy quyền. Để xác thực bằng mật khẩu, nó phải được tiết lộ và để kiểm tra tính hợp lệ của mật khẩu người dùng, các nhà cung cấp dịch vụ phải lưu trữ chúng trong một số dạng cơ sở hạ tầng tập trung. Điều này có nghĩa là không ai ngoài nhà cung cấp dịch vụ có thể tin tưởng rằng bất kỳ nhật ký kiểm toán nào họ giữ là đại diện chính xác cho hành động của người dùng. Vì lý do này, các hệ thống dựa vào mật khẩu để xác thực phải tuân theo cả Vấn đề Nghe và Vấn đề Kiểm tra Trống như được mô tả ở trên.

Những nỗ lực hiện đại để cải thiện hoặc thay thế mật khẩu

Đã có một số nỗ lực trong những năm qua để tăng dần hoặc thay thế mật khẩu. Dưới đây chúng tôi sẽ xem xét một vài trường hợp thành công nhất cùng với điểm mạnh và điểm yếu của họ.

Quản lý mật khẩu

Sự tồn tại của Trình quản lý mật khẩu thể hiện sự thừa nhận một số lỗ hổng cơ bản của mật khẩu. Họ cố gắng cải thiện tình hình bằng cách giải phóng người dùng khỏi phải tạo và ghi nhớ mật khẩu đủ phức tạp, do đó cho phép mật khẩu đơn mục đích đáp ứng mức độ bảo mật cao hơn nhiều.

Được sử dụng một cách chính xác, Trình quản lý mật khẩu giúp cải thiện bảo mật và trong một phạm vi hạn chế, khả năng sử dụng của các hệ thống có xác thực dựa trên mật khẩu. Tuy nhiên, bất cứ ai đã cố gắng dạy cho cha mẹ, con cái hoặc những người bạn không có kỹ thuật của mình sử dụng phần mềm quản lý mật khẩu ngày nay đều biết rằng chúng không được chấp nhận rộng rãi cũng như không thể sử dụng đủ để trở thành như vậy.

Từ góc độ kỹ thuật, không có tiêu chuẩn cho người quản lý mật khẩu. Họ cố gắng đoán khi người dùng tạo tài khoản, đăng nhập hoặc cập nhật mật khẩu để thuận tiện hơn, nhưng họ thường thất bại. Chúng cung cấp cơ sở cho một giải pháp cải tiến, nhưng cuối cùng, chúng vẫn chỉ là mật khẩu và vẫn phải chịu cả Vấn đề Nghe và Vấn đề Kiểm tra Trống.

Xác thực hai yếu tố

Để nhận ra sự yếu kém của mật khẩu, các nỗ lực đã được thực hiện để tăng cường bảo mật bổ sung để đảm bảo rằng mật khẩu không phải là điểm thất bại duy nhất. Cách tiếp cận này thường được gọi là yếu tố thứ hai hoặc xác thực hai yếu tố (2FA). Có nhiều cách triển khai 2FA và trong khi tất cả chúng đều bổ sung các mức độ bảo mật gia tăng khác nhau cho các hệ thống xác thực dựa trên mật khẩu, chúng bù lại bằng sự phức tạp hơn về mặt thiết lập và hoạt động của người dùng cuối. Một giải pháp 2FA phổ biến dựa trên các tin nhắn SMS để cung cấp mật khẩu một lần dựa trên thời gian (OTP). Giống như mật khẩu, các giải pháp hai yếu tố gặp phải vấn đề là chúng không thể nghe được và dễ bị tổn thương trước các hoạt động bảo mật của các nhà mạng điện thoại gửi tin nhắn SMS đến thiết bị của bạn.

Sự thiếu kiểm toán có thể chứng minh này có nghĩa là 2FA vẫn không giải quyết được vấn đề Hearsay hoặc Vấn đề kiểm tra trống.

Tiêu chuẩn WebAuthn

WebAuthn là một tiêu chuẩn xác thực mới được đề xuất bởi World Wide Web Consortium (W3C), một cộng đồng quốc tế của các tổ chức thành viên, một nhân viên toàn thời gian và cộng đồng làm việc cùng nhau để phát triển các tiêu chuẩn Web. WebAuthn đã tiến gần đến việc giải quyết tất cả các vấn đề này cho các giao dịch dựa trên Web bằng cách sử dụng mật mã bất đối xứng, thay vì mật khẩu, cung cấp một trong những thành phần cần thiết để khắc phục các vấn đề chúng tôi đã nêu. Tuy nhiên, để ngăn người dùng bị mất thiết bị khỏi bị khóa khỏi mọi dịch vụ, WebAuthn được thiết kế để được sử dụng cùng với mật khẩu, thay vì thay thế.

Một hạn chế quan trọng quan trọng khác của WebAuthn là nó được thiết kế như một bằng chứng về sự hiện diện, không phải là bằng chứng của sự đồng ý. Nó không được xác định để cho phép các yêu cầu ủy quyền trên mỗi giao dịch có thể được kiểm tra bởi các đồng nghiệp. Vì vậy, một lần nữa, các hệ thống dựa trên WebAuthn don sắt có nhật ký kiểm toán có thể chứng minh được và phải chịu cả vấn đề Hearsay và The Check Check.

Blockchain là một giải pháp tiềm năng

Blockchains đã phổ biến ý tưởng xác thực người dùng cho mọi hành động mà họ ủy quyền, sử dụng ký mã hóa giao dịch khóa công khai để thực hiện mục tiêu này. Đây là một cải tiến lớn về mật khẩu và một bước vượt xa những gì WebAuthn có thể cung cấp. Nó cũng thỏa mãn yếu tố đầu tiên cần thiết để giải quyết vấn đề Hearsay: khả năng kiểm toán có thể chứng minh được.

Thật không may, ngày nay các giao diện người dùng blockchain cũng không xác định một tiêu chuẩn để mô tả các yêu cầu ủy quyền theo cách thân thiện với con người để người dùng có thể được hiển thị trong bối cảnh đáng tin cậy để người dùng chấp thuận. Nếu không có tiêu chuẩn kết xuất yêu cầu thân thiện với con người này, người dùng không thể biết họ đồng ý với điều gì. Điều này có nghĩa là mặc dù các blockchains tạo ra một bản ghi có thể kiểm tra được, chúng vẫn thiếu phương tiện để chứng minh rằng dữ liệu trong một hệ thống thực sự thể hiện ý định của người dùng. Vì vậy, họ vẫn phải chịu các vấn đề về Hearsay và Blank Check.

Quay lại ví dụ về phương tiện truyền thông xã hội của chúng tôi, nếu một nền tảng truyền thông xã hội được xây dựng trên blockchain, họ sẽ có thể chứng minh rằng chính trị gia đang nghi vấn đã thực sự ký vào hành động dẫn đến bài đăng, nhưng họ sẽ không thể chứng minh rằng họ (hoặc một đảng khác) đã không lừa chính trị gia ký hành động bằng cách trình bày sai.

Một giải pháp lý thuyết: Pass vượt qua Thay vì khóa hoặc mật khẩu

Để nâng cao tính bảo mật của hệ thống của chúng tôi, chúng tôi cần bằng chứng về sự đồng ý của người dùng, kết hợp với mức độ đơn giản và khả năng sử dụng vượt quá cả mật khẩu. Điều này có nghĩa là chúng ta phải giao tiếp các công nghệ phức tạp như mật mã bất đối xứng thông qua một phép ẩn dụ có thể hiểu được ngay lập tức đối với mọi loại người dùng, không chỉ các nhà công nghệ. Một khái niệm đáp ứng các tiêu chí này là về một pass Pass. Khi mô tả khái niệm về pass, chúng tôi sẽ chỉ ra cách giải pháp lý thuyết này của pass được sử dụng trong Ứng dụng Trình quản lý Pass có thể đáp ứng cả Vấn đề Hearsay và Vấn đề Kiểm tra Trống mà chúng tôi đã nêu.

Đối với người dùng, thẻ đại diện cho một phương tiện hữu hình và hữu hình để chứng minh quyền sở hữu chứng chỉ. Mỗi ngày chúng ta tương tác với các đường chuyền vật lý như một phần của thói quen hàng ngày. Là người dùng thư viện, bạn chỉ cần xuất hiện và xuất trình thẻ thư viện của mình. Là một hành khách hàng không, bạn chỉ cần xuất hiện và xuất trình vé của bạn. Đây là những ví dụ về thẻ vượt qua một mục đích, đối với các dịch vụ không cung cấp thẻ đơn mục đích, bạn có thể xuất trình Giấy phép Lái ​​xe để chứng minh danh tính của mình.

Để hỗ trợ các trường hợp sử dụng xác thực và ủy quyền, chúng tôi giới thiệu khái niệm về Trình quản lý kỹ thuật số Pass Pass kỹ thuật số. Pass Manager là một mô hình không mật khẩu cho các trường hợp sử dụng đăng ký, xác thực và ủy quyền.

Bạn có thể làm gì với Pass Manager?

Phát hành và thu hồi

  • Nhà cung cấp dịch vụ có thể yêu cầu Trình quản lý thẻ phát hành thẻ mới cho người dùng.
  • Người dùng có thể tổ chức các lượt đi của họ thành các nhóm. (ví dụ: công việc của tôi vượt qua và thông qua cá nhân của tôi)
  • Người dùng có thể ủy quyền và hủy cấp phép trên nhiều thiết bị.

Xác thực

  • Nhà cung cấp dịch vụ có thể yêu cầu bằng chứng về việc người dùng sở hữu thẻ Pass.
  • Người dùng có thể cung cấp bằng chứng về việc họ sở hữu thẻ.

Ủy quyền

  • Nhà cung cấp dịch vụ có thể yêu cầu bằng chứng về ủy quyền của người dùng để thực hiện một hành động cụ thể, dựa trên quyền vượt qua mà người dùng sở hữu.
  • Người dùng có thể thấy các yêu cầu ủy quyền được hiển thị rõ ràng theo cách thân thiện với con người và chọn có cho phép hành động hay không, dựa trên thẩm quyền của thẻ mà họ sở hữu.

Trình quản lý Pass sẽ hoạt động như thế nào?

Trình quản lý thẻ thực hiện một giao thức được chuẩn hóa (chưa được xác định) để ban hành và hủy bỏ các lượt, xác thực và ủy quyền với các lượt. Pass là một khái niệm trừu tượng, đóng gói thông tin xác thực (khóa).

Trải nghiệm sử dụng Trình quản lý thẻ kỹ thuật số phải rất giống với thẻ tương tự vật lý của thẻ qua. Người dùng chỉ cần đến một dịch vụ (cho dù đó là ứng dụng web, ứng dụng gốc, hệ thống điểm bán hàng hay ki ốt) và đưa ra một thông báo để đăng nhập hoặc ủy quyền cho một hành động. Điều này giống như một sinh viên đại học sử dụng ID trường đại học của họ để được nhận vào một sự kiện thể thao của trường đại học, sau đó một lần vào bên trong, sử dụng nó để mua thức ăn tại quầy với số dư ăn uống trong khuôn viên trường của họ, được trình bày xác nhận đơn hàng trước khi thực hiện giao dịch.

Dưới vỏ bọc, sự pha trộn của các công nghệ có thể hoạt động song song để tạo ra tính bảo mật và khả năng sử dụng vượt trội cho người dùng, bao gồm ký mã hóa, khóa phần cứng và sinh trắc học để bảo mật thông tin, cũng như giao thức không thể truyền tải cho tính di động.

Bất cứ khi nào người dùng Pass Manager tìm kiếm sự đồng ý của người dùng, các mô tả hành động thân thiện với con người sẽ được hiển thị cho người dùng và mô tả đó (hoặc một dẫn xuất có thể kiểm chứng bằng mật mã của nó) nên được đưa vào phản hồi đã ký từ Trình quản lý Pass. Việc sử dụng các khóa có nghĩa là các bản ghi không thể từ chối và có thể được xác minh bởi các bên thứ ba và việc đưa mô tả thân thiện với con người vào phản hồi đã ký có thể đóng vai trò là bằng chứng về ý định của người dùng. Những đặc điểm này giải quyết cả hai vấn đề Hearsay và Blank Check.

Mô hình này có thể hỗ trợ cả công nghệ web hiện tại và các trường hợp sử dụng công nghệ blockchain trong tương lai. Nó cũng có khả năng cung cấp trải nghiệm người dùng rõ ràng cho cả trường hợp sử dụng đăng nhập và ủy quyền.

Điều gì là cần thiết để làm cho người quản lý Pass thành công?

Khả năng tương tác

Trước hết, cần xây dựng giao thức Pass Manager để cho phép người dùng tự do chọn Trình quản lý Pass phù hợp nhất với nhu cầu của họ. Điều này rất quan trọng vì nó ngăn chặn sự khóa của nhà cung cấp, tạo ra thị trường tự do cần thiết để thúc đẩy sự đổi mới trong cả bảo mật và trải nghiệm người dùng. Bằng cách này, trải nghiệm người dùng tốt nhất với bảo mật chấp nhận được sẽ giành chiến thắng.

Để cung cấp quyền tự do lựa chọn này, cần có các giao thức chuẩn để đăng ký, đăng nhập và ủy quyền. Ủy quyền, đặc biệt, là một thách thức thú vị, bởi vì nó đòi hỏi định nghĩa của một tiêu chuẩn để mô tả các yêu cầu ủy quyền cho người dùng theo cách dễ hiểu, có thể nghe được, có thể chứng minh được và có thể mang theo được.

Tính di động

Thứ hai, giao thức Pass Manager nên được xây dựng cho tính di động; nghĩa là: 1) hỗ trợ cho mọi loại ứng dụng hoặc dịch vụ chạy trên mọi nền tảng, 2) hỗ trợ cho kết nối mạng bị giới hạn hoặc không có, 3) hỗ trợ cho nhiều thiết bị và 4) hỗ trợ cho giao tiếp giữa các thiết bị.

Người dùng có máy tính để bàn, máy tính xách tay, điện thoại, máy tính bảng, đồng hồ thông minh và phím USB. Vì vậy, trải nghiệm đơn giản và liền mạch để cấp và thu hồi quyền truy cập qua nhiều thiết bị là rất quan trọng. Người dùng cũng tương tác với các hệ thống điểm bán, máy tính công cộng không tin cậy, máy bán hàng tự động và kiốt. Vì vậy, khả năng tương tác từ thiết bị này sang thiết bị khác, có hoặc không có kết nối mạng, mà không cần các thiết bị tin tưởng lẫn nhau là cần thiết.

Những yêu cầu này có thể được đáp ứng bằng cách xác định giao thức Pass Manager là vận chuyển bất khả tri. Điều này có nghĩa là giao thức nên tập trung vào việc xác định các danh từ và động từ mà các hệ thống triển khai phải có khả năng nói trôi chảy và cho phép các phương tiện vận chuyển qua đó chúng được nói thay đổi. Ví dụ về vận chuyển có thể bao gồm URL giao thức tùy chỉnh, Liên kết phổ quát của Apple, Ý định của máy chủ, yêu cầu máy chủ, mã QR, Bluetooth, NFC và API JavaScript. Với tính linh hoạt này, Trình quản lý Pass có thể thực sự di động.

Khả năng sử dụng

Người dùng không cần phải xem xét tác động của việc họ đang sử dụng dịch vụ web với phụ trợ cơ sở dữ liệu hay hệ thống blockchain. Trong trường hợp của blockchain, họ không cần phải biết nền tảng blockchain hoặc mạng mà ứng dụng họ đang sử dụng được xây dựng trên nền tảng nào. Họ chỉ cần xem xét trường hợp sử dụng của họ. Những thứ như…

Bạn có thể rút tiền từ ATM.

Tôi đã đăng nhập vào email của mình.

Mùi tôi thích một bài đăng trên phương tiện truyền thông xã hội.

Tôi đã mua chip từ máy bán hàng tự động.

Tôi đã chuyển 100 mã thông báo từ Dan sang Brian.

Không bao giờ những thứ như Lọ

Sau đó, tôi đang ký một giao dịch, với khóa R1, được ủy quyền cho tài khoản blockchain11 của tôi, trên dapp example.com, được xây dựng trên blockchain Telos, được xây dựng trên nền tảng EOSIO.

Sự an toàn

Việc triển khai hiện tại của cả mật khẩu và hệ thống khóa công khai đều không an toàn vì nhiều lý do. Quản lý vượt qua phải làm tốt hơn.

Để bảo vệ người dùng khỏi các cuộc tấn công vào mật ong tập trung thông tin đăng nhập, dữ liệu thông tin bí mật không bao giờ được lưu trữ trên cơ sở hạ tầng tập trung dưới mọi hình thức (băm và muối là không đủ tốt). Để bảo vệ người dùng khỏi bị đánh cắp thông tin đăng nhập của họ thông qua lừa đảo, phần mềm độc hại và tấn công trung gian, người dùng không bao giờ nên thực sự biết thông tin đăng nhập của mình là gì và không bao giờ nên nhập thủ công hoặc tự động vào bất kỳ dịch vụ nào. Để bảo vệ người dùng khỏi bị lừa thêm các đường chuyền độc hại, người dùng không thể tự thêm hoặc xóa các đường chuyền. Thay vào đó, Trình quản lý Pass đáng tin cậy sẽ tự động xử lý việc này thay mặt người dùng để phản hồi người dùng truy cập các dịch vụ mới hoặc nhận thiết bị mới.

Tương lai rộng mở cho những người quản lý Pass

Trong bài viết này, chúng tôi đã đặt ra các vấn đề cần giải quyết để giải quyết các mối lo ngại về bảo mật và khả năng sử dụng với các phương pháp hiện đại để bảo mật tài khoản người dùng. Chúng tôi đã trình bày khái niệm về Pass thay thế mật khẩu và Trình quản lý Pass kỹ thuật số như một phương tiện để giải quyết những vấn đề này. Chúng tôi đã thảo luận về các thuộc tính cần thiết để giao thức Pass Manager thành công, nhưng chúng tôi chưa xác định rõ ràng giao thức. Chúng tôi khuyến khích các nhà phát triển dám nghĩ dám làm để giải quyết các vấn đề gây khó chịu cho cả hệ thống bảo mật dựa trên mật khẩu và khóa và coi phép ẩn dụ Pass là một cách để thực hiện mục tiêu đó.

Tuyên bố miễn trừ trách nhiệm: Block.one đóng góp trên cơ sở tự nguyện với tư cách là thành viên của cộng đồng EOSIO và không chịu trách nhiệm đảm bảo hiệu suất chung của phần mềm hoặc bất kỳ ứng dụng liên quan nào. Chúng tôi không tuyên bố, bảo hành, bảo đảm hoặc cam kết đối với các bản phát hành được mô tả ở đây, bản phát hành GitHub có liên quan, phần mềm EOSIO hoặc bất kỳ tài liệu liên quan nào, dù được thể hiện hay ngụ ý, bao gồm nhưng không giới hạn ở bảo hành hoặc tính thương mại, cụ thể mục đích và không tiêm nhiễm. Trong mọi trường hợp, chúng tôi sẽ không chịu trách nhiệm cho bất kỳ khiếu nại, thiệt hại hoặc trách nhiệm pháp lý nào khác, cho dù là trong hành động của hợp đồng, tra tấn hay nói cách khác, phát sinh từ, liên quan đến phần mềm hoặc tài liệu hoặc việc sử dụng hoặc giao dịch khác trong phần mềm hoặc tài liệu. Bất kỳ kết quả kiểm tra hoặc số liệu hiệu suất là chỉ định và sẽ không phản ánh hiệu suất trong mọi điều kiện. Mọi tham chiếu đến bất kỳ sản phẩm, tài nguyên hoặc dịch vụ của bên thứ ba hoặc bên thứ ba nào không phải là sự chứng thực hoặc khuyến nghị của Block.one. Chúng tôi không chịu trách nhiệm và từ chối mọi trách nhiệm và trách nhiệm pháp lý đối với việc bạn sử dụng hoặc phụ thuộc vào bất kỳ tài nguyên nào trong số này. Tài nguyên của bên thứ ba có thể được cập nhật, thay đổi hoặc chấm dứt bất cứ lúc nào, vì vậy thông tin ở đây có thể bị lỗi thời hoặc không chính xác. Bất kỳ ai sử dụng hoặc cung cấp phần mềm này liên quan đến việc cung cấp phần mềm, hàng hóa hoặc dịch vụ cho bên thứ ba sẽ thông báo cho các bên thứ ba về các điều khoản cấp phép này, từ chối trách nhiệm và loại trừ trách nhiệm pháp lý. Block.one, EOSIO, EOSIO Labs, EOS, heptahedron và các logo liên quan là thương hiệu của Block.one. Các nhãn hiệu khác được tham chiếu ở đây là tài sản của chủ sở hữu tương ứng của họ. Xin lưu ý rằng các tuyên bố trong tài liệu này là một biểu hiện của tầm nhìn Block.one, không phải là sự đảm bảo cho bất cứ điều gì và tất cả các khía cạnh của nó có thể thay đổi trong tất cả các khía cạnh theo quyết định riêng của Block.one. Chúng tôi gọi những tuyên bố này về phía trước, bao gồm các tuyên bố trong tài liệu này, ngoài các tuyên bố về các sự kiện lịch sử, chẳng hạn như các tuyên bố về sự phát triển của EOSIO, hiệu suất dự kiến ​​và các tính năng trong tương lai, hoặc chiến lược kinh doanh, kế hoạch, triển vọng, phát triển và mục tiêu của chúng tôi. Những tuyên bố này chỉ là dự đoán và phản ánh niềm tin và kỳ vọng hiện tại của Block.one đối với các sự kiện trong tương lai; chúng dựa trên các giả định và có thể gặp rủi ro, không chắc chắn và thay đổi bất cứ lúc nào. Chúng tôi hoạt động trong một môi trường thay đổi nhanh chóng. Rủi ro mới xuất hiện theo thời gian. Với những rủi ro và sự không chắc chắn này, bạn nên thận trọng không dựa vào những tuyên bố hướng tới tương lai này. Kết quả thực tế, hiệu suất hoặc sự kiện có thể khác về mặt vật chất so với những gì được dự đoán trong các tuyên bố hướng tới. Một số yếu tố có thể khiến kết quả, hiệu suất hoặc sự kiện thực tế khác biệt về mặt vật chất với các tuyên bố hướng tới bao gồm, nhưng không giới hạn: biến động thị trường; tiếp tục có sẵn vốn, tài chính và nhân sự; chấp nhận sản phẩm; sự thành công thương mại của bất kỳ sản phẩm hoặc công nghệ mới; cuộc thi; quy định của chính phủ và pháp luật; và điều kiện kinh tế, thị trường hoặc kinh doanh nói chung. Tất cả các tuyên bố chỉ có giá trị kể từ ngày đăng đầu tiên và Block.one không có nghĩa vụ và từ chối rõ ràng mọi nghĩa vụ, cập nhật hoặc thay đổi bất kỳ tuyên bố nào, cho dù là kết quả của thông tin mới, sự kiện tiếp theo hay nói cách khác. Không có gì ở đây cấu thành công nghệ, tài chính, đầu tư, pháp lý hoặc tư vấn khác, nói chung hoặc liên quan đến bất kỳ tình huống cụ thể hoặc thực hiện. Vui lòng tham khảo ý kiến ​​các chuyên gia trong các lĩnh vực thích hợp trước khi thực hiện hoặc sử dụng bất cứ điều gì có trong tài liệu này.