it-swarm-vi.com

Xác thực dựa trên chứng chỉ so với xác thực tên người dùng và mật khẩu

Những lợi thế và hạn chế của xác thực dựa trên chứng chỉ so với xác thực tên người dùng và mật khẩu là gì? Tôi biết một số, nhưng tôi sẽ đánh giá cao một câu trả lời có cấu trúc và chi tiết.

CẬP NHẬT

Tôi cũng quan tâm đến việc biết những gì các cuộc tấn công mà họ có xu hướng, ví dụ: như đã đề cập đến lực lượng vũ phu, trong khi không có gì được đề cập cho chứng chỉ ... còn XSRF thì sao? Chứng chỉ dự kiến ​​sẽ có thời gian tồn tại ngắn hơn và có thể bị thu hồi trong khi mật khẩu sẽ tồn tại lâu hơn trước khi chính sách quản trị viên yêu cầu thay đổi ...

95
Stefany

1. Người dùng bị câm

Mật khẩu là thứ phù hợp với bộ nhớ của người dùng và người dùng chọn nó. Vì xác thực là về việc xác minh danh tính vật lý của người dùng từ xa (theo quan điểm của người xác minh), hành vi người dùng nhất thiết phải tham gia vào quá trình - tuy nhiên, mật khẩu phụ thuộc vào một phần của người dùng nổi tiếng nhất là tầm thường trong việc xử lý bảo mật, cụ thể là bộ não của anh ta. Người dùng chỉ đơn giản là không nắm bắt được mật khẩu entropy là gì. Tôi không đổ lỗi họ cho rằng: đây là một chủ đề kỹ thuật, chuyên môn hóa, không thể thực sự trở thành "lẽ thường" bất cứ lúc nào sớm. Mặt khác, bảo mật của mã thông báo vật lý "hữu hình" hơn nhiều và người dùng trung bình có thể trở nên khá giỏi về nó. Các nhà tiến hóa sẽ nói rằng con người đã được lựa chọn tích cực cho điều đó trong một triệu năm qua, bởi vì những người không thể nắm giữ các công cụ đá lửa của họ đã không sống sót đủ để sinh con.

Phim Hollywood có thể được sử dụng như một mô hình về cách người dùng nghĩ về mật khẩu - nếu chỉ vì những người dùng đó cũng đi xem phim. Lúc nào cũng vậy, Arch Enemy có một mật khẩu ngắn và chỉ thích khoe khoang về nó và phân phát manh mối bất cứ khi nào anh ta có thể. Và, luôn luôn, một đặc vụ bí mật của Anh đoán mật khẩu kịp thời để vô hiệu hóa quả bom nhiệt hạch được trồng dưới giường hoa yêu thích của Nữ hoàng. Phim chiếu một thực tế méo mó, cường điệu, nhưng chúng vẫn thể hiện cơ sở tinh thần mà người dùng trung bình hoạt động: họ hình dung mật khẩu là cung cấp bảo mật thông qua "dí dỏm" hơn kẻ tấn công. Và, luôn luôn thất bại, hầu hết đều thất bại ở đó.

"Độ mạnh mật khẩu" có thể được cải thiện phần nào bằng các quy tắc bắt buộc (ít nhất tám ký tự, ít nhất hai chữ số, ít nhất một chữ hoa và một chữ cái viết thường ...) nhưng những quy tắc đó được người dùng xem là gánh nặng và đôi khi là một ràng buộc không thể vượt qua đối với sự tự do bẩm sinh của họ - vì vậy người dùng trở nên chống lại các quy tắc, với sự sáng tạo tuyệt vời, bắt đầu bằng cách viết mật khẩu truyền thống trên một ghi chú dán. Thường xuyên hơn không, mật khẩu tăng cường quy tắc ngược lại theo cách đó.

Mặt khác, chứng chỉ người dùng ngụ ý một hệ thống lưu trữ và nếu hệ thống đó là thiết bị vật lý mà người dùng mang theo chìa khóa nhà hoặc xe hơi của họ, thì bảo mật phụ thuộc vào mức độ người dùng trung bình quản lý bảo mật của một đối tượng vật lý, và họ thường làm tốt công việc đó. Ít nhất là tốt hơn so với khi chọn mật khẩu tốt. Vì vậy, đó là một lợi thế lớn của chứng chỉ.

2. Chứng chỉ sử dụng mật mã bất đối xứng

"Không đối xứng" là về việc tách các vai trò. Với mật khẩu, bất cứ ai xác minh mật khẩu đều biết mật khẩu hoặc dữ liệu tương đương với mật khẩu tại một số điểm (điều đó không hoàn toàn đúng trong trường hợp PAKE giao thức ). Với chứng chỉ người dùng, chứng chỉ là được cấp bởi cơ quan chứng nhận, người đảm bảo liên kết giữa danh tính thực và khóa công khai mật mã. Trình xác minh có thể là a differ thực thể và có thể xác minh một liên kết như vậy và sử dụng nó để xác thực người dùng, mà không có khả năng mạo danh người dùng.

Tóm lại, đây là điểm của chứng chỉ: tách những người xác định danh tính kỹ thuật số của người dùng (tức là thực thể ánh xạ từ nhận dạng vật lý sang thế giới máy tính) khỏi những người = xác thực người dùng.

Điều này mở đường đến chữ ký số mang lại sự không thoái thác. Điều này đặc biệt quan tâm đến các ngân hàng nhận đơn đặt hàng tài chính từ khách hàng trực tuyến: họ cần xác thực khách hàng (đó là tiền chúng ta đang nói đến, một vấn đề rất nghiêm trọng) nhưng họ rất muốn có một dấu vết thuyết phục của các đơn đặt hàng - theo nghĩa: thẩm phán sẽ bị thuyết phục. Với xác thực đơn thuần, ngân hàng đạt được một số đảm bảo rằng họ đang nói chuyện với đúng khách hàng, nhưng không thể chứng minh điều đó với các bên thứ ba; ngân hàng có thể xây dựng một bảng điểm kết nối giả, vì vậy nó là vũ khí chống lại một khách hàng tuyên bố là do chính ngân hàng đóng khung. Chữ ký kỹ thuật số không có sẵn ngay lập tức ngay cả khi người dùng có chứng chỉ; nhưng nếu người dùng có thể sử dụng chứng chỉ để xác thực thì hầu hết các công việc khó khăn đã được thực hiện.

Ngoài ra, mật khẩu vốn dễ bị tấn công lừa đảo, trong khi chứng chỉ người dùng thì không. Chính vì sự bất cân xứng: việc sử dụng chứng chỉ không bao giờ tiết lộ bất kỳ dữ liệu bí mật nào cho bạn bè, vì vậy kẻ tấn công mạo danh máy chủ không thể học được bất cứ điều gì có giá trị theo cách đó.

3. Chứng chỉ rất phức tạp

Triển khai chứng chỉ người dùng rất phức tạp, do đó tốn kém:

  • Cấp và quản lý chứng chỉ là một hộp sâu đầy đủ, vì bất kỳ nhà cung cấp PKI nào cũng có thể cho bạn biết (và thực sự, tôi có nói với bạn). Đặc biệt là quản lý thu hồi. PKI là khoảng 5% mật mã và 95% thủ tục. Nó có thể được thực hiện, nhưng không rẻ.

  • Chứng chỉ người dùng ngụ ý rằng người dùng lưu trữ khóa riêng của họ theo một cách nào đó, dưới "quyền truy cập độc quyền" của họ. Điều này được thực hiện trong phần mềm (hệ điều hành hiện tại và/hoặc trình duyệt Web có thể làm điều đó) hoặc sử dụng phần cứng chuyên dụng, nhưng cả hai giải pháp đều có các vấn đề về khả năng sử dụng riêng. Hai vấn đề chính sẽ phát sinh là 1) người dùng bị mất chìa khóa và 2) kẻ tấn công có được một bản sao của khóa. Lưu trữ phần mềm làm mất khóa là một vấn đề chính đáng (vì lỗi ổ cứng bị hỏng) và chia sẻ khóa giữa một số hệ thống (ví dụ: máy tính để bàn và iPad) ngụ ý một số thao tác thủ công không có khả năng được bảo vệ tốt trước kẻ tấn công. Mã thông báo phần cứng ngụ ý toàn bộ hoạt động kinh doanh lộn xộn của trình điều khiển thiết bị, điều này có thể còn tồi tệ hơn.

  • Chứng chỉ người dùng ngụ ý các hoạt động toán học tương đối phức tạp ở phía máy khách; đây không phải là vấn đề đối với Pentium II thiếu máu, nhưng bạn sẽ không thể sử dụng các chứng chỉ từ một số Javascript bị tát trong một trang web chung. Chứng chỉ yêu cầu hợp tác tích cực từ phần mềm phía khách hàng và phần mềm cho biết có xu hướng, giả sử, tối ưu hóa về mặt công thái học trong vấn đề đó. Người dùng trung bình thường có thể học cách sử dụng chứng chỉ ứng dụng khách cho kết nối HTTPS với trang web, nhưng với chi phí học cách bỏ qua cửa sổ bật lên cảnh báo không thường xuyên, khiến họ dễ bị tấn công hơn (ví dụ như các cuộc tấn công chủ động mà kẻ tấn công cố gắng cho chúng ăn chứng chỉ máy chủ giả của nó).

Mặt khác, xác thực dựa trên mật khẩu thực sự dễ dàng tích hợp ở mọi nơi. Nó cũng dễ dàng để gây rối, tất nhiên; nhưng ít nhất nó không nhất thiết liên quan đến một số chi phí phụ không thể nén được.

Tóm tắt

Chứng chỉ người dùng cho phép phân tách vai trò mà mật khẩu không thể thực hiện. Họ làm như vậy với chi phí thêm một loạt các vấn đề triển khai và triển khai, khiến chúng trở nên đắt đỏ. Tuy nhiên, mật khẩu vẫn rẻ bằng cách phù hợp với tâm trí con người, vốn dĩ ngụ ý bảo mật thấp. Các vấn đề bảo mật với mật khẩu có thể được giảm bớt phần nào bởi một số mánh khóe (tối đa là các giao thức PAKE) và, hầu hết, bằng cách đổ lỗi cho người dùng trong trường hợp có vấn đề (chúng tôi biết rằng người dùng trung bình không thể chọn mật khẩu an toàn, nhưng mọi sự cố sẽ xảy ra vẫn là lỗi của anh ấy - đó là cách các ngân hàng làm điều đó).

94
Thomas Pornin

Tên đăng nhập/Mật khẩ

  • Pro: Dễ triển khai - chỉ cần lấy một số mã và lưu trữ dữ liệu an toàn. Tùy thuộc vào chính sách bảo mật, có thể tự động tạo mật khẩu hoặc buộc người dùng mới tạo chúng.

  • Pro: Dễ quản trị - việc đặt lại mật khẩu có thể (đối với một số chính sách bảo mật) được thực hiện bằng các công cụ tự động

  • Con: Để bảo mật tốt, mật khẩu nên được đặt lại sớm và thường xuyên. Việc người dùng quên hoặc không thay đổi mật khẩu là một rủi ro bảo mật hoặc rắc rối về khả năng sử dụng.

  • Con: Mật khẩu tốt có thể khó nhớ, dẫn đến vấn đề người dùng sử dụng lại mật khẩu hoặc ghi lại chúng.

  • Con: Lưu trữ dữ liệu mật khẩu là một điểm yếu - nếu kẻ xâm nhập có được kho lưu trữ mật khẩu, anh ta sẽ nhận được tải mẹ.

  • Con: Tất cả các phần của việc truyền mật khẩu có thể dẫn đến phơi nhiễm - các trang web lưu trữ mật khẩu cục bộ để dễ sử dụng, các thành phần máy chủ nội bộ truyền tải rõ ràng, các tệp nhật ký trong các sản phẩm COTS lưu mật khẩu rõ ràng. Với bí mật là một phần của việc truyền tải, bạn chỉ mạnh bằng liên kết yếu nhất của mình - cần nỗ lực nghiêm túc để ngăn chặn việc tiếp xúc và yêu cầu là ở cả người dùng và nhà phát triển hệ thống.

Chứng chỉ :

  • Pro: Không yêu cầu truyền bí mật. Bằng chứng về khóa riêng không chứa thông tin bí mật - giảm thiểu tất cả các loại điểm yếu lưu trữ/truyền tải.

  • Pro: Do một bên đáng tin cậy (CA) cấp cho phép hệ thống quản lý tập trung cho trạng thái trên nhiều ứng dụng. Nếu một chứng chỉ xấu đi, nó có thể bị thu hồi. Việc sửa lỗi ngắt mật khẩu phải được thực hiện riêng cho từng hệ thống trừ khi sử dụng ID chung.

  • Pro: Trường hợp không thoái thác mạnh hơn - trong hầu hết các hệ thống mật khẩu, cách người dùng được xác thực ban đầu trước khi tạo tài khoản khá yếu và các cơ chế đặt lại mật khẩu có thể cung cấp một yếu tố khác cho việc từ chối hợp lý. Với nhiều hình thức cấp chứng chỉ, người dùng khó có thể nói rằng đó không phải là chúng. Hãy cẩn thận - bạn vẫn chỉ tốt như các chính sách phát hành của CA.

  • Pro: Phục vụ nhiều mục đích hơn là chỉ xác thực - cũng có thể cung cấp tính toàn vẹn và bảo mật.

  • Con: Vẫn yêu cầu mật khẩu/mã pin - gần như mọi cơ chế lưu trữ cặp khóa riêng tư sau đó được mở khóa bằng mã PIN. SmartCards có thể có khả năng bảo vệ và khóa giả mạo để ngăn chặn lực lượng vũ phu, nhưng điều đó không khắc phục được thực tế người dùng đã viết PIN trên một ghi chú dán bên cạnh máy tính nơi thẻ được gắn. vấn đề mật khẩu xuất hiện trở lại ở quy mô nhỏ hơn với PKI.

  • Con: Sự phức tạp của cơ sở hạ tầng - thiết lập PKI không phải là nhiệm vụ dễ dàng và thường rất tốn kém trong cả việc triển khai và bảo trì đến mức nó chỉ có thể được sử dụng cho các hệ thống lớn/đắt tiền.

  • Con: Báo cáo và cập nhật trạng thái chứng chỉ không dễ dàng - việc thu hồi thông tin xác thực người dùng đã bị hỏng là rất khó khăn do quy mô và độ phức tạp của cơ sở hạ tầng. Thông thường, CA tạo CRL có thể được cung cấp hoặc không được cung cấp trong máy chủ OCSP. Sau đó, mọi ứng dụng nên kiểm tra mọi thông tin đăng nhập để biết trạng thái CRL hoặc OCSP. Điều này đưa ra nhiều sự chậm trễ về thời gian vào hệ thống giữa thời điểm thông tin PKI được báo cáo là bị xâm phạm và thời điểm các hệ thống dựa trên thông tin đó thực sự bắt đầu từ chối truy cập. Tốc độ cập nhật trạng thái có thể được tăng tốc - nhưng với chi phí phức tạp hệ thống lớn hơn.

Một vài lưu ý khác:

Chứng chỉ dự kiến ​​sẽ có thời gian tồn tại ngắn hơn và có thể bị thu hồi trong khi mật khẩu sẽ tồn tại lâu hơn trước khi chính sách quản trị viên yêu cầu thay đổi ...

Tôi không đồng ý với tiền đề. Trên các hệ thống tôi đã làm việc trên đó hỗ trợ cả mật khẩu và PKI, chính sách cho các yêu cầu cập nhật mật khẩu ngắn hơn NHIỀU so với chính sách cấp chứng chỉ. Thu hồi là một loại giun khác nhau - nó dành cho sự kiện ít có khả năng thỏa hiệp khóa riêng. Do dữ liệu khóa riêng không được truyền qua hệ thống, nên rủi ro tiếp xúc với dữ liệu này thường được coi là thấp hơn nhiều so với rủi ro tiếp xúc với mật khẩu. Đối với các mục đích thực tế, mật khẩu được coi là có tuổi thọ ngắn hơn.

Tôi cũng quan tâm đến việc biết những gì các cuộc tấn công mà họ có xu hướng, ví dụ: như đã đề cập đến lực lượng vũ phu, trong khi không có gì được đề cập cho chứng chỉ ... còn XSRF thì sao?

Bạn đang trộn táo và cam ở đây. Brute force có thể là một cuộc tấn công khả thi đối với một trong hai loại thông tin xác thực - nhưng XSRF là một cuộc tấn công vào một loại ứng dụng cơ bản có thể xảy ra bất kể cơ chế xác thực. Trừ khi bạn có nghĩa là vì tên người dùng/mật khẩu sẽ được nhập với một loại giao diện văn bản nào đó, nên họ có thể dễ bị kịch bản chéo trang trên giao diện đó.

Nói chung (xin lỗi vì tôi không có thuật ngữ chính thức - tôi thường xem các thuật ngữ tấn công điển hình nhưng tôi không có nhiều thời gian):

  • Lực lượng vũ phu - vì không gian khóa của mật khẩu trung bình của bạn nhỏ hơn không gian khóa của khóa không đối xứng, nên mật khẩu dễ dàng hơn để tạo ra lực lượng vũ trang. Tuy nhiên, kích thước khóa đủ nhỏ trên chứng chỉ cũng có khả năng vũ lực và khả năng vũ phu tấn công các phím tấn công với khả năng của CPU buộc một cuộc đua chuột với kích thước khóa tăng lên.

  • Việc đoán có giáo dục - thu hẹp không gian khóa thành một bộ đoán hợp lý sẽ dễ dàng hơn với mật khẩu và không rõ ràng đối với hầu hết các thuật toán khóa bất đối xứng, mặc dù có thuật toán yếu trong thuật toán RSA, do đó, có một số phụ thuộc vào cách mã hóa lớn Kẻ tấn công là.

  • Kỹ thuật xã hội - có thể thực hiện được, mặc dù với chứng chỉ được lưu trữ trong phần cứng, bạn không chỉ phải kiểm soát người dùng PIN mà còn cả phần cứng lưu trữ khóa của họ.

  • Tấn công bên trong - nhận thông tin đăng nhập từ bên trong hệ thống và sau đó sử dụng chúng để mô phỏng người dùng hợp pháp - phụ thuộc. Nếu mật khẩu được lưu trữ không an toàn thì điều này dễ thực hiện hơn đối với hệ thống dựa trên mật khẩu. Nhưng nếu bạn có thể kiểm soát CA, bạn có thể cấp cho mình một chứng chỉ hợp pháp và sau đó tùy thuộc vào cách kiểm soát truy cập.

  • Người đàn ông ở giữa - phụ thuộc - một người đàn ông ở giữa có thể chặn mật khẩu nếu mật khẩu không được mã hóa trong quá trình vận chuyển bằng cơ chế mã hóa bỏ qua anh ta. Điều đó có thể thực hiện được với SSL/TLS. Tuy nhiên, một người đàn ông ở giữa cũng có thể chặn các phần của chuyển PKI, tùy thuộc vào cách sử dụng PKI. Chữ ký PKI không có dấu thời gian hoặc dấu thời gian được mở cho các cuộc tấn công sao chép bởi một người đàn ông ở giữa - anh ta có thể gửi lại một tin nhắn bị chặn miễn là không có cách nào để biết tin nhắn đó là kịp thời hay duy nhất.

32
bethlakshmi
  1. Tên người dùng và mật khẩu
    • Đó là tất cả về những gì bạn biết. Bạn đang cung cấp một mã bí mật Word để xác thực với dịch vụ.
    • Điều này có nghĩa là nếu nó bị chặn trong luồng, nó có thể được sử dụng. Sử dụng mã hóa làm cho điều đó không thể nhưng vẫn có thể. Ai đó có thể làm một người đàn ông ở giữa để lấy mật khẩu của bạn hoặc chiếm lấy máy tính nhận xác thực.
    • Tên người dùng và mật khẩu có thể được sử dụng trên bất kỳ máy tính nào vào bất kỳ lúc nào. Đây là một điều xấu nếu vấn đề bảo mật và một điều tốt nếu khả năng tiếp cận có vấn đề. Đối với một ngân hàng ... điều này là xấu. Đối với facebook, nó thực sự không quan trọng.
  2. Chứng chỉ [.__.]
    • Chứng chỉ phức tạp hơn một chút. Máy chủ gửi dữ liệu đến máy khách và máy khách ký dữ liệu và gửi lại. Điều này có nghĩa là máy chủ không biết khóa riêng bất cứ lúc nào vì vậy trong khi một người đàn ông ở giữa hoặc tiếp quản máy chủ sẽ dẫn đến việc họ có quyền truy cập, họ không có khóa của bạn.
    • Giấy chứng nhận là một nỗi đau để sử dụng. Bạn không thể nhớ chúng và chúng có thể bị đánh cắp.

Hệ thống tốt nhất là sự kết hợp. Bạn đặt mật khẩu trên khóa để bạn có xác thực hai yếu tố. Một cái gì đó bạn biết (mật khẩu), và một cái gì đó bạn có (khóa). Tuy nhiên, càng nhiều lớp bảo mật thì càng đau. Đó là sự đánh đổi lớn trong tất cả an ninh.

8
Stephen

Tôi đồng ý với quan điểm của Stephen. Bạn đưa ra một câu hỏi khó để nghiên cứu vì vấn đề thường không phải là so sánh cái này với cái kia. Một cách tốt để hiểu tại sao cả hai tồn tại và thường không được đánh giá với nhau là tập trung vào việc sử dụng. Chứng chỉ được gắn với các kho khóa cấp độ máy và do đó rất phù hợp để xác thực máy giữa các máy cụ thể được lên kế hoạch trước. Mật khẩu rất phù hợp với mọi người vì chúng tôi là điện thoại di động và có xu hướng xác thực từ nhiều hệ thống theo cách khó dự đoán trước. Vì vậy, chứng chỉ là điển hình trong thiết kế trước xác thực dựa trên phần cứng và mật khẩu là tốt cho xác thực dựa trên di động. Thẻ thông minh là một cách tuyệt vời để thêm xác thực dựa trên chứng chỉ cho người di động và một yếu tố khác vào quy trình.

8
zedman9991

Một mật khẩu thường có thể bị ép buộc và nó có thể được thiết kế xã hội, bởi vì, vì chủ sở hữu của nó phải ghi nhớ nó, nó thường đơn giản hơn nhiều so với một khóa bí mật.

Khóa riêng (có đủ cường độ - đối với RSA, 2048 hoặc 4096 bit) không thể bị ép buộc. Cách duy nhất để xác thực hệ thống yêu cầu xác thực dựa trên khóa chung là trước tiên phải có quyền truy cập vào một số máy tính khác để lấy khóa riêng. Điều này giới thiệu một mức độ phức tạp bổ sung cho bất kỳ cuộc tấn công nào. Kỹ thuật xã hội để khiến một người tiết lộ mật khẩu của mình sẽ không giúp ích gì, vì mật khẩu chỉ giải mã khóa riêng của anh ta, thay vì cấp cho anh ta quyền truy cập trực tiếp vào hệ thống đích. Kỹ thuật xã hội để khiến một người tiết lộ khóa riêng của mình cùng với mật khẩu của anh ta có thể sẽ khó khăn hơn nhiều.

Ngoài ra, mật khẩu được truyền qua mạng từ máy của người dùng đến hệ thống mà người dùng muốn sử dụng. Khóa riêng không được truyền qua mạng, không rõ ràng cũng như ở định dạng được mã hóa; thay vì chỉ có khóa công khai được truyền đi.

3
yfeldblum

Bạn dường như quên rằng một trang web có thể sử dụng cả chứng chỉ và mật khẩu. Nếu người dùng có chứng chỉ đến, cửa sẽ mở. Và nếu anh ta không có chứng chỉ, anh ta phải đăng nhập bằng tên và mật khẩu như mọi khi.

Theo cách này, những người dùng quan tâm có được chứng chỉ của họ, tất cả những người khác làm theo cách cũ.

1
Martin

Tôi muốn thêm một tùy chọn - Thiết bị mật khẩu một lần. Tôi đồng ý với những gì người khác đã nói về ưu và nhược điểm của chứng chỉ và mật khẩu - Thiết bị OTP yêu cầu một số thành phần phụ trợ để hoạt động, nhưng theo tôi có thể được tích hợp mà không gặp nhiều rắc rối (Active Directory hơi khác một chút, nhưng khác hệ thống không quá khó).

Một sự kết hợp của mật khẩu và mật khẩu một lần hoạt động rất tốt. Bạn có thể sử dụng một giải pháp đơn giản hơn như Yubikey bằng mật khẩu (USB hoặc NFC) hoặc mã fob được hiển thị.

Cả hai tùy chọn đều dễ dàng để thêm vào các hoạt động dựa trên Linux. Nếu bạn muốn làm điều đó trong Active Directory, bạn sẽ cần mua phần mềm để xử lý mã và cài đặt nó trên mọi máy chủ AD. Sau đó, người dùng nhập OTP vào đầu trường mật khẩu, sau đó là mật khẩu thông thường của họ. Có thể phát triển mô-đun của riêng bạn cho nó, nhưng chi phí rất cao so với những gì tôi đã thấy.

1
Mat Carlson