Các lý do để có một đăng nhập hai bước là gì? (Tên người dùng trên một trang, mật khẩu trên trang thứ hai.)


8

Vì vậy, gần đây tôi đã gặp phải quá trình đăng nhập hai bước, trong đó tôi bắt buộc phải nhập tên người dùng của mình trên một trang và mật khẩu của tôi trong một giây. Tôi thực sự không thích mẫu này, vì nó yêu cầu tải thêm trang chỉ để đăng nhập.

Nhưng tôi đã được một vài người nói rằng nó an toàn hơn. Làm thế nào là nó an toàn hơn? Có những lý do khác để gây bất tiện cho người dùng với điều này?


1
Bảo mật và khả năng sử dụng sẽ luôn ở mức mâu thuẫn
John Conde

Nghe có vẻ như ai đó đã hiểu nhầm ý nghĩa của việc đăng nhập 2 bước
JamesRyan

Câu trả lời:


4

Bất hai yếu tố xác thực giới thiệu các mức độ an ninh bằng cách sử dụng để đăng nhập với tên truy cập và mật khẩu của họ và sau đó nói một mã được tạo trên điện thoại của họ hoặc thông qua một máy phát thẻ / mã (Ngân hàng Barclays gửi ra đọc thẻ mà tạo ra một sử dụng khi mã dựa trên quẹt thẻ của bạn.

Việc chia tên người dùng và mật khẩu thành hai trang khác nhau sẽ không thêm bất cứ điều gì về bảo mật bổ sung (AFAIK)


Yeah đó là những gì tôi nghĩ.
Daniel Bingham

Tôi ghét phải sử dụng đầu đọc thẻ của Barclay chỉ để đăng nhập - đến mức tôi đã đóng tài khoản.
ajcw

Tôi cảm thấy nỗi đau của bạn John. Tệ hơn khi họ khăng khăng bạn sử dụng một cái nhưng thực sự không gửi cho tôi. Thật tuyệt vời ...
Tinh chất kỹ thuật số

4

Lý do duy nhất mà tôi thấy đăng nhập hai bước khi bạn mô tả nó an toàn hơn là nếu tên người dùng được nhập trên trang đầu tiên được khớp với một loại hình ảnh hoặc cụm từ mà người dùng chọn khi họ đăng ký. Điều này giúp trang web tự xác minh.

Nếu ai đó đã sao chép trang web của bạn để sử dụng trong chiến dịch lừa đảo, họ sẽ không thể hiển thị hình ảnh hoặc cụm từ. Nó bảo vệ người dùng khi họ nhập mật khẩu của họ.

Nếu bạn không kéo thêm bất kỳ mục bảo mật tài khoản nào từ trang đầu tiên sang trang thứ hai, thì sẽ không có nhiều điểm để làm theo cách đó.


Đúng, nhưng điều này cũng có thể được thực hiện với một trang duy nhất và cách tiếp cận dựa trên cookie, như đã thấy với trang đăng nhập Yahoo.
Jacob Hume

1
Cách tiếp cận dựa trên cookie không xử lý đăng nhập trên một máy tính khác. Trang web như trang web của ngân hàng muốn được bảo vệ ngay cả khi bạn không đặt cookie. Đó là hơn giết cho hầu hết các trang web mặc dù. Nhưng đó là lý do đằng sau nó.
lovefaithswing

4

Lý do duy nhất tôi có thể đưa ra liên quan đến việc ngăn chặn các cuộc tấn công tự động.

Trong đó cả tên người dùng và mật khẩu đều được chấp nhận trên một trang, việc tạo ra một tập lệnh tự động sẽ kết hợp trang đó với sự kết hợp tên người dùng và mật khẩu cho đến khi có một cái gì đó được thực hiện - gọi là một cuộc tấn công "Brute force".

Có tên người dùng của bạn được nhập trên một trang và mật khẩu của bạn được nhập trên một trang khác sẽ làm cho loại tấn công này trở nên khó khăn hơn, nhưng không phải là không thể. Nó sẽ làm một công việc tốt để ngăn chặn những kẻ tấn công đơn giản, và đưa bạn lên trước phần lớn các trang web.

Mặc dù bạn không an toàn hơn về mặt kỹ thuật so với hàng xóm của mình, bạn không còn là một trong những loại trái cây treo thấp nữa.


2

Đây là một trường hợp kỳ lạ, nhưng nếu trang web chính được phục vụ không được mã hóa (vì lý do hiệu suất có thể), nhưng bạn muốn người dùng có thể bắt đầu quá trình đăng nhập từ trang đó, thay vì nhấp vào liên kết "đăng nhập". Gửi tên người dùng của bạn không được mã hóa không phải là một vấn đề lớn, và sau đó bạn có thể phục vụ phần thứ hai của trang đăng nhập (trường mật khẩu) qua HTTPS.

Tôi nghĩ rằng nó có thể không xứng đáng (công việc nhiều hơn cho lập trình viên, công việc nhiều hơn cho người dùng, giảm tải công việc bộ xử lý nhỏ), nhưng một số người có thể nghĩ rằng nó đáng giá.

Ví dụ: First National thực hiện điều này trên trang chủ của họ.


1

Tôi chỉ có thể tìm thấy tài liệu cũ hơn về nó, http://www.schneier.com/blog/archives/2005/10/us_regulators_r.html . Câu chuyện dài về các ngân hàng Mỹ và tôi tin rằng các công ty Thẻ tín dụng được yêu cầu sử dụng xác thực hai yếu tố cho các biểu mẫu đăng nhập trang web của họ.

Khi bài viết thảo luận về việc nó không thực sự giải quyết được vấn đề, nó chỉ khiến bọn tội phạm có thêm một cú hích để nhảy qua.


1
Câu hỏi không mô tả xác thực hai yếu tố ..
Brendan Long

@Brendan - Tài liệu đã cũ. Tôi ước tôi có thể tìm thấy phiên bản mới nhất. Tôi đã làm việc cho một công ty web vào 08/09 đã xử lý thẻ tín dụng và tôi không chắc quy tắc này đến từ đâu nhưng phát triển phải tạo xác thực hai yếu tố để tuân thủ hướng dẫn của liên bang. Tôi ước tôi có thể tìm thấy nguồn. Nếu tôi làm, tôi sẽ thêm một liên kết đến nó.
Ben Hoffman

1
Ý tôi là bạn đang nói về xác thực hai yếu tố, nhưng đó không phải là câu hỏi đang hỏi về điều gì. Câu hỏi là về một trang đăng nhập hai bước hỏi cùng thông tin như bình thường (tên người dùng trên trang đầu tiên, mật khẩu ở trang thứ hai).
Brendan Long

0

Chấp nhận tên người dùng và mật khẩu trên trang riêng biệt không làm cho ứng dụng an toàn hơn dưới bất kỳ hình thức nào. Tôi muốn biết trang web nào bạn gặp phải điều này?


0

Ngân hàng của tôi đã tìm thấy một lý do rất chính đáng để sử dụng xác thực hai bước: Họ đã có 3 phương pháp xác thực người dùng mà tôi biết:

  • Thẻ tiền điện tử cho các công ty
  • Thẻ tiền điện tử cho các tài khoản riêng tư (loại thẻ khác nhau!)
  • Xác thực chỉ mật khẩu

Họ sử dụng đăng nhập hai bước để họ biết loại tài khoản bạn đã có để họ có thể cung cấp một số trợ giúp khi nhập mật khẩu. Nếu bạn cần nhập mật khẩu, họ yêu cầu mật khẩu rõ ràng. Nếu bạn cần sử dụng thẻ tiền điện tử của mình để tạo mã xác thực duy nhất, họ sẽ yêu cầu mã và cung cấp liên kết trợ giúp cụ thể cho loại thẻ của bạn.


0

Tôi sẽ nói nó làm cho nó ít an toàn hơn. Bởi vì sau đó bạn có thể biết rằng user123 có một tài khoản trên trang web, và sau đó bạn có thể thực hiện một hành động vũ phu trên tài khoản đó.

Thực hành tiêu chuẩn là không bao giờ cho mọi người biết nếu tài khoản hoặc mật khẩu không chính xác .. "bạn đã nhập tên người dùng hoặc mật khẩu không chính xác"

làm cho nó khó khăn hơn rất nhiều để vũ phu.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.