Tại sao cách tiếp cận thách thức-phản ứng lại là giải pháp kém cho mật khẩu bị quên?

Question

Công ty của tôi đang phát triển một ứng dụng Nhân sự và Biên chế trực tuyến, nơi đảm bảo quyền truy cập là rất quan trọng. Tôi rõ ràng về cách khóa hầu hết các quy trình xác thực/ủy quyền, ngoại trừ trang 'Quên mật khẩu'.

Kế hoạch ban đầu của tôi là yêu cầu người dùng nhập cả địa chỉ email và câu trả lời cho câu hỏi thách thức đã chọn/nhập trước đó, với mật khẩu tạm thời được gửi tới e-mail được liệt kê (giả định e-mail là hợp lệ). Nhưng tôi đã đọc here và here (cả trên SO) rằng cách tiếp cận thách thức-phản ứng là không an toàn.

Nếu chúng tôi chỉ gửi thư điện tử mật khẩu tạm thời, có thực sự không an toàn không? Lựa chọn duy nhất an toàn hơn tôi có thể nghĩ đến là yêu cầu người dùng gọi cho Đại diện dịch vụ khách hàng của họ, điều này sẽ gây khó khăn cho nhân viên của chúng tôi.

Tôi đang thiếu gì ... có cách tiếp cận tốt hơn không? Cảm ơn!

Answer 1

Đừng gửi mật khẩu tạm thời qua email, gửi email cho người dùng URL + mã thông báo tới trang đặt lại mật khẩu. Bằng cách đó, không có mật khẩu nào thay đổi tay không được mã hóa. Nó cũng ngay lập tức hiển nhiên đối với người dùng cuối rằng tài khoản của họ đã bị xâm phạm nếu họ cố truy cập trang đó và mã thông báo đặt lại đã được sử dụng.

gia tăng từ các ý kiến:

Tôi nghĩ thử thách phản ứng ("bí mật câu hỏi") các khía cạnh thực sự làm cho mọi việc kém an toàn, bởi vì họ nói chung là những thứ có thể được phát hiện bằng cách nghiên cứu thông tin công khai về mục tiêu. Tổng số bước ít hơn, ít hơn có thể bị phá vỡ mà không ai biết. Để các email đặt lại hoạt động sớm và thường là một cách hay để cho một người biết được nỗ lực đang được thực hiện.

Answer 2

Như đã giải thích trong tài khoản này article, tài khoản e-mail Thống đốc Palin gần đây đã bị tấn công bằng câu trả lời cho các câu hỏi được hỏi trước đó. Từ bài viết:

Như chi tiết trong bài đăng, bản hack của Palin không yêu cầu bất kỳ kỹ năng thực sự nào. Thay vào đó, hacker chỉ cần đặt lại mật khẩu của Palin bằng cách sử dụng ngày sinh, mã ZIP và thông tin về nơi cô gặp vợ/chồng - câu hỏi bảo mật trên tài khoản Yahoo của cô, được trả lời (Wasilla High) bằng một tìm kiếm đơn giản trên Google.

Answer 3

Sẽ không dễ dàng/khả thi để thuê ngoài toàn bộ quản lý mật khẩu giống như SO đã làm và sử dụng OpenId hoặc tương tự? Tất nhiên điều này sẽ thêm một sự phụ thuộc khác, nhưng bạn muốn giao dịch đó chống lại sự cần thiết phải lưu (và bảo mật) mật khẩu và đối phó với chúng như bạn đã mô tả.

Answer 4

Bạn cho biết đây là ứng dụng nhân sự trực tuyến và bảng lương. Bạn có tùy chọn của người dùng cho biết anh/cô ấy đã quên mật khẩu của mình và tạo thông báo cho đại diện nhân sự hoặc một số quan chức trong tổ chức có thể xác nhận danh tính rồi đặt lại mật khẩu không?

Answer 5

Có một vài cách phổ biến để quản lý mật khẩu bị mất:

• Các câu hỏi bí mật: Nó thực sự là một hình thức yếu xác thực, giống như người ở trên được đăng. Người dùng có thể chọn một cái gì đó thực sự đơn giản và dễ đoán. Tôi khuyên chống lại điều này, bởi vì nó không yêu cầu bất kỳ kỹ thuật "hack"

• Gửi mật khẩu mới.Để tránh sự kiểm soát này, cần truy cập vào tài khoản e-mail hoặc yêu cầu vị trí Người ở Giữa (MITM): Bạn đọc mật khẩu tạm thời từ hộp thư đến của người dùng hoặc chặn ở giữa. Cách tiếp cận này là chín muồi vì lạm dụng, bởi vì ai cũng có thể đặt lại mật khẩu và buộc người dùng ra khỏi hệ thống, nếu anh ta không thể đọc e-mail bằng mật khẩu mới.

• Gửi băm đặt lại mật khẩu, để phá vỡ điều này, bạn cần truy cập vào hộp thư đến hoặc MITM, giống như trong trường hợp trước đó, nhưng không có mật khẩu nào thực sự được đặt lại cho đến khi xác nhận hoàn tất. Vì vậy, người dùng không thể bị khóa khỏi hệ thống, ngay cả khi anh ta không đọc e-mail. Thêm một bộ đếm thời gian cooldown cho một thiết lập lại mỗi 8 giờ để ngăn chặn hệ thống của bạn từ lũ lụt hộp thư của người dùng.

• Cân nhắc một số liên lạc ngoài băng thông, ví dụ: trong hợp đồng đã in, ghi lại mã PIN. Sau đó yêu cầu người sử dụng gọi đến Quầy trợ giúp của bạn từ một số điện thoại đã biết (kiểm tra bằng ID người gọi) và cung cấp tên người dùng và mã PIN của họ.

Answer 6

Trong ngắn hạn, câu hỏi thách thức thường là liên kết yếu nhất. Chúng dễ đoán hơn mật khẩu và hoạt động hiệu quả như một proxy cho mật khẩu, vì vậy chúng thực sự làm giảm bảo mật hơn là tăng cường bảo mật bằng cách cung cấp một vector tấn công khác thực sự dễ dàng hơn để phá vỡ. Web Application Hacker's Handbook có một số thông tin tuyệt vời về lĩnh vực này.