it-swarm-vi.com

Bất cứ ai cũng có thể cung cấp tài liệu tham khảo để thực hiện các cơ chế tự đặt lại mật khẩu ứng dụng web đúng cách?

Chúng tôi đang thực hiện tự đặt lại mật khẩu trên một ứng dụng web và tôi biết tôi muốn làm như thế nào (URL đặt lại mật khẩu giới hạn thời gian email cho người dùng đăng ký trước địa chỉ email).

Vấn đề của tôi là tôi không thể tìm thấy bất kỳ tài liệu tham khảo nào để chỉ ra các nhà phát triển xung quanh bằng cách sử dụng kỹ thuật đó. Bất cứ ai có thể chỉ cho tôi theo hướng của một số tài liệu tham khảo tốt về kỹ thuật này?

96
bdg

Một số gợi ý:

Không đặt lại mật khẩu của người dùng cho đến khi được xác nhận. Đừng ngay lập tức đặt lại mật khẩu của người dùng. Chỉ đặt lại khi người dùng nhấp vào liên kết xác nhận được gửi đến địa chỉ email đã đăng ký trước của họ.

Yêu cầu CAPTCHA. Khi người dùng yêu cầu đặt lại mật khẩu, hãy buộc họ giải quyết CAPTCHA trước khi tiếp tục. Điều này là để ngăn các công cụ tự động cố gắng làm cho nhiều người dùng đau buồn và buộc người dùng phải chứng minh họ là một con người (không phải là robot).

Tính ngẫu nhiên. URL đặt lại mật khẩu giới hạn thời gian phải bao gồm một thành phần ngẫu nhiên, không thể truy cập được. Hãy chắc chắn rằng bạn sử dụng tính ngẫu nhiên chất lượng của tiền điện tử. Đầu ra từ /dev/urandom Hoặc System.Security.Cryptography.RNGCryptoServiceProvider Sẽ là một lựa chọn tốt. Đầu ra từ Rand() hoặc random() hoặc System.Random Không đủ ngẫu nhiên và sẽ là một lựa chọn tồi. A GUID hoặc dấu thời gian không đủ ngẫu nhiên và sẽ không phải là một lựa chọn tốt.

Bao gồm giới hạn thời gian. Liên kết xác nhận đặt lại sẽ hết hạn sau một khoảng thời gian hợp lý: giả sử, 24 giờ. Liên kết chỉ có thể được sử dụng một lần và ngay lập tức hết hạn ngay khi được sử dụng.

Bao gồm văn bản giải thích trong email. Bạn có thể muốn thêm một số văn bản giải thích vào email, để giải thích lý do email được gửi, trong trường hợp ai đó yêu cầu đặt lại cho một tài khoản không phải của riêng bạn. Bạn có thể bao gồm một số văn bản như "Ai đó đã yêu cầu đặt lại mật khẩu cho tài khoản của bạn username on site. Nếu bạn đã thực hiện yêu cầu này, hãy nhấp vào đây để thay đổi mật khẩu của bạn. Nếu bạn không thực hiện yêu cầu này, bấm vào đây để hủy yêu cầu. "

Gửi email sau khi mật khẩu được đặt lại. Sau khi mật khẩu được đặt lại thành công, hãy gửi email cho người dùng để cho họ biết rằng mật khẩu đã được thay đổi. Không bao gồm mật khẩu mới trong email đó.

Theo dõi việc hủy. Bạn có thể cân nhắc bao gồm một số logic để theo dõi tần suất người dùng nhấp vào liên kết hủy cho biết họ không yêu cầu đặt lại. Nếu điều này vượt quá một ngưỡng nhất định, có thể hữu ích để gửi cảnh báo đến các nhà khai thác hệ thống. Ngoài ra, nếu liên kết hủy đối với một số yêu cầu được truy cập sau liên kết xác nhận được truy cập, đó là dấu hiệu tiềm năng của một cuộc tấn công chống lại người dùng đó - bạn có thể muốn thực hiện hành động tại thời điểm đó, ví dụ: , làm mất hiệu lực mật khẩu của người dùng và yêu cầu họ đặt lại mật khẩu. (Đây là một biện pháp bảo vệ chống lại cuộc tấn công sau: kẻ tấn công giành quyền truy cập vào hộp thư của người dùng, sau đó yêu cầu mật khẩu của họ trên trang web của bạn được đặt lại, sau đó truy cập vào liên kết xác nhận. sau đó khi người dùng thực đọc email của họ, họ có thể nhấp vào liên kết hủy, cung cấp cho bạn dấu hiệu của sự cố có thể xảy ra.)

Sử dụng HTTPS. Liên kết nên sử dụng https (không phải http :), để bảo vệ chống lại các cuộc tấn công khác nhau (ví dụ: Firesheep tấn công người dùng lướt web từ Internet quán cà phê).

Ghi nhật ký các thao tác này. Tôi đề nghị đăng nhập tất cả các yêu cầu như vậy. Ngoài việc đăng nhập tên người dùng, bạn có thể muốn đăng nhập địa chỉ IP của khách hàng yêu cầu liên kết đặt lại được gửi qua email cho người dùng, cũng như địa chỉ IP của khách hàng đã truy cập liên kết đặt lại.

Đọc thêm. Bạn cũng có thể muốn đọc bài đăng blog tuyệt vời của Troy Hunt, Mọi thứ bạn từng muốn biết về việc xây dựng tính năng đặt lại mật khẩu an toàn . Cảm ơn @coryT cho một liên kết đến tài nguyên này.

Cuối cùng, xem xét xác thực không phải mật khẩu. Mật khẩu có nhiều vấn đề như một cơ chế xác thực và bạn có thể xem xét các phương pháp xác thực người dùng khác, chẳng hạn như lưu trữ bảo mật cookie liên tục trên máy của họ với một bí mật không thể tin được để xác thực chúng. Bằng cách này, không có mật khẩu để quên và không có cách nào để người dùng bị lừa đảo, mặc dù bạn cần cung cấp một cách để người dùng cho phép truy cập từ một máy mới hoặc một trình duyệt mới (có thể qua email cho người dùng trước địa chỉ email đã đăng ký). Tài liệu khảo sát này có một khảo sát tuyệt vời về nhiều phương pháp xác thực dự phòng cũng như điểm mạnh và điểm yếu của chúng.

93
D.W.

Troy Hunt có một bài viết rất hay về câu hỏi chính xác này. Mọi thứ bạn từng muốn biết về việc xây dựng tính năng đặt lại mật khẩu an toàn

15
coryT

Bất cứ nơi nào có thể gửi cho bạn mật khẩu có nghĩa là họ không băm mật khẩu, nhưng lưu trữ nó ở nơi nào đó có thể giải mã thành 'văn bản gốc'. Điều này tự nó là xấu.

Có lẽ không "an toàn" nhất, nhưng an toàn hơn sẽ là:

Theo yêu cầu mật khẩu, gửi liên kết đặt lại mật khẩu cho người dùng với GUID được nhúng. Phiên trong GUID hết hạn sau, hmm, giờ hoặc lâu hơn.

9
Rich Homolka

OK, vậy câu hỏi của bạn là, bạn nên cấu trúc quy trình khôi phục mật khẩu/tài khoản như thế nào? Điều đó sẽ phụ thuộc vào những gì bạn muốn tối ưu hóa cho: trải nghiệm người dùng không gặp rắc rối hoặc bảo mật tốt.

Nếu bạn muốn bảo mật tốt:

  • Trong quá trình đăng ký, người dùng phải nhập địa chỉ email của mình.
  • Trong quá trình đăng ký, người dùng phải nhập kênh phụ để xác thực - số điện thoại di động hoặc câu hỏi và câu trả lời thách thức (tức là " tên thời con gái của mẹ bạn " hoặc tốt hơn).

  • Trong quá trình khôi phục, trước tiên, hệ thống của bạn sẽ nhận được một xác minh sơ bộ về danh tính bằng kênh thứ cấp ở trên - câu hỏi thách thức hoặc bằng cách SMS gửi mã đến điện thoại di động hoặc tương tự.

  • Khi kiểm tra danh tính đầu tiên ở trên bị xóa, hệ thống sẽ gửi email đặt lại mật khẩu đến địa chỉ email đã nhập trước đó. Đây là một biện pháp bổ sung, quan trọng để ngăn chặn f.x. Khai thác kiểu Sarah Palin .

  • Email không được chứa mật khẩu mới hoặc tương tự. Nó phải có liên kết có thể nhấp đến trang web được mã hóa HTTPS trên trang web của bạn mà a) được liên kết với tài khoản thông qua giá trị bí mật không thể đoán được được cung cấp trong URL, b ) bị giới hạn thời gian, do đó, việc khôi phục tài khoản chỉ hoạt động trong x giờ sau khi được yêu cầu, c) cung cấp cách cho người dùng cuối tạo a mới mật khẩu.

  • Đăng nhập tốt vào tất cả các giao dịch đặt lại tài khoản và có một con người thực sự giám sát chúng và hành động nếu chúng có vẻ đáng ngờ (nhìn vào nhật ký máy chủ cho các địa chỉ IP fx, có nhiều yêu cầu đến từ cùng một địa chỉ IP không, có trường hợp nào không người dùng đang cố gắng đặt lại mật khẩu từ một quốc gia khác với chủ tài khoản đã đăng ký, v.v.).

Bạn cũng có thể vượt qua sự phức tạp này hoàn toàn: Vẫn còn sớm, nhưng OAuth/OpenID/đăng nhập qua Facebook, Google v.v ... loại bỏ hoàn toàn sự phức tạp này khỏi các hệ thống của bạn, nhưng với một có lẽ khả năng sử dụng kém hơn .

9
Jesper M

Cách an toàn nhất để thực hiện đặt lại mật khẩu là tạo mã thông báo đặt lại một lần duy nhất ngẫu nhiên lớn, có thời hạn sử dụng, được gắn với ID người dùng. Mã thông báo nên được băm trong cơ sở dữ liệu, vì kẻ tấn công có quyền truy cập SQL có thể sử dụng nó để đặt lại mật khẩu người dùng tùy ý.

Liên kết đặt lại phải được gửi đến địa chỉ email, chứa mã thông báo đặt lại. Khi người dùng nhấp vào liên kết, hàm băm của mã thông báo sẽ được tìm thấy trong cơ sở dữ liệu và ngày hết hạn được xác minh là trong tương lai. Nếu các điều kiện này được đáp ứng, người dùng sẽ được trình bày với một màn hình cho phép họ nhập mật khẩu mới.

Toàn bộ quá trình này phải được thực hiện qua SSL, nếu không, kẻ tấn công có thể đánh hơi URL và đặt lại mật khẩu trước khi người dùng thực hiện.

Một vài lời khuyên khác:

  1. Bí mật đặt câu hỏi về một sự phiền toái nhỏ đối với những kẻ tấn công và một sự phiền toái lớn đối với người dùng. Tránh chúng hoàn toàn.
  2. Đưa ra cho người dùng một thử thách xác minh con người (ví dụ: CAPTCHA) trước khi gửi lại mật khẩu. Điều này ngăn chặn các yêu cầu thiết lập lại tự động.
  3. Kiểm tra xem địa chỉ IP thực hiện đặt lại có phải là địa chỉ đã đăng nhập thành công vào tài khoản trước đó không. Nếu không, hãy hỏi thêm một số chi tiết về tài khoản/người dùng, ví dụ: năm tạo tài khoản, ngày sinh, dòng địa chỉ đầu tiên.
  4. Thêm liên kết "Tôi không yêu cầu email này" để người dùng có thể báo cáo các yêu cầu đặt lại mật khẩu sai.
6
Polynomial

Một cách khác có thể phù hợp hoặc không phù hợp với ứng dụng của bạn, nhưng được sử dụng trong các ứng dụng ngân hàng trực tuyến và các loại điều tương tự là gửi một nửa mã đặt lại bằng cách SMS nhắn tin đến điện thoại di động đã đăng ký. Từ quan điểm của kẻ tấn công, đây là một PITA hoàn chỉnh vì nó đòi hỏi sự thỏa hiệp của một vài kênh để phá vỡ.

6
Rory Alsop

Xác thực 2 yếu tố qua SMS! 1 bạn biết khách hàng và số điện thoại di động của họ, SMS cho họ một mã duy nhất để thêm vào trang web để xác thực đó là họ: )

0
frank

Làm cho nó một vài bước thủ tục. Ví dụ như một cái gì đó như thế này:

  1. Người dùng tha thứ cho mật khẩu của mình. Anh bấm vào nút "Tôi quên mật khẩu gửi cho tôi một email phải làm gì tiếp theo" (nhãn nút có thể khác nhau;))
  2. Máy chủ của bạn gửi cho anh ấy một liên kết www.yourdomain.com/lostpassword?param_1=x;param_2=y
  3. Anh ta nhấp vào liên kết và có thể tạo cho mình một mật khẩu mới
  4. Anh bấm gửi. Mọi thứ đã xong. Tất cả mọi người vui vẻ

Một và chỉ bắt được ở điểm 3). Giá trị X và Y phải ngẫu nhiên, không thể đoán trước và được kết nối với một tài khoản cụ thể này. Họ cũng chỉ nên sử dụng một lần và sẽ trở nên cũ kỹ sau một khoảng thời gian ngắn (24 giờ?). Lưu trữ cả hai giá trị trong một bảng chuyên dụng với các cột tương ứng:

| some_id | user_id | X | Y | expire_time

Nếu người dùng cố gắng sử dụng liên kết thích hợp, hãy kiểm tra xem thời gian hết hạn có được đáp ứng hay không và nếu không, hãy cho phép anh ta thay đổi mật khẩu.

0
Andrzej Bobak