it-swarm-vi.com

Quên mật khẩu hoặc đặt lại liên kết, cái nào an toàn hơn cho email?

Ban đầu tôi đã đăng bài này dưới dạng trả lời ở đây trong chủ đề này nhưng không nhận được nhiều phản hồi về nó, và bây giờ tôi tò mò về những gì người khác nghĩ là cách tiếp cận tốt nhất, hoặc nếu có bất kỳ sự khác biệt nào giữa hai cách tiếp cận.

Điểm ban đầu là liệu có an toàn hơn khi gửi liên kết đặt lại mật khẩu khi người dùng quên mật khẩu của họ đến trang web hoặc gửi mật khẩu gốc không được mã hóa trong email.

Bây giờ không muối và mã hóa mật khẩu là xấu vì khi cơ sở dữ liệu cuối cùng bị đánh cắp khỏi trang web, kẻ tấn công sẽ có tất cả các mật khẩu rõ ràng như ngày. Được rồi, tôi hiểu rồi.

Nhưng nếu chúng ta bỏ qua khả năng cơ sở dữ liệu bị đánh cắp và chỉ nhìn vào người dùng quên mật khẩu của họ và trải qua "các bước mật khẩu bị quên"; Là nhiều hơn, cùng hoặc ít an toàn hơn để gửi một liên kết đặt lại qua mật khẩu văn bản đơn giản trong một email?

Suy nghĩ của tôi là nó giống nhau. Bởi vì nếu kẻ tấn công có quyền truy cập vào email của bạn bằng bất kỳ phương tiện nào (anh ta biết chi tiết đăng nhập email của bạn hoặc anh ta đang theo dõi lưu lượng truy cập ở đâu đó) thì anh ta có quyền truy cập vào mật khẩu văn bản đơn giản được gửi hoặc liên kết đặt lại - ngay cả khi đó là thời gian giới hạn liên kết.

Kẻ tấn công có thể đặt lại mật khẩu của bạn trước khi bạn biết bạn có email.

Là suy nghĩ của tôi ở đây thiếu sót?

23
fwgx

Việc truy cập vào kho email hiện tại đơn giản hơn nhiều so với việc truy cập vào luồng đến. Ví dụ: nhận được một vài phút truy cập vào hệ thống của ai đó cho phép dễ dàng tìm kiếm qua email của họ. Vì vậy, đối với trường hợp kẻ tấn công có quyền truy cập vào thư cũ, nhưng không truy cập vào luồng thư mới, thư đến:

Bạn đang dựa vào người dùng thay đổi mật khẩu của họ sau khi họ nhận được mật khẩu (không chắc, do bạn đã nói với họ đó là gì) hoặc xóa (vĩnh viễn, không lưu trữ hoặc chuyển sang thư mục 'thùng rác', cũng không chắc) thông điệp.

Nếu điều này không xảy ra, thì nếu tôi có quyền truy cập vào tài khoản email của người dùng một thời gian sau đó, thì (sử dụng hạn chế/thời gian có hạn, thậm chí có thể giới hạn để kẻ tấn công có thể dễ dàng sử dụng) liên kết đặt lại sẽ không được sử dụng cho tôi, nhưng có mật khẩu (rất có thể vẫn còn hiệu lực) chắc chắn là có.

Ngoài ra, bằng cách gửi cho tôi mật khẩu văn bản đơn giản, bạn đang chứng minh rằng bạn có lưu trữ này ở nơi nào đó có thể truy cập được. Trong hầu hết các trường hợp, không cần điều này, vì bạn không cần mã hóa mật khẩu (và muối/hạt tiêu), bạn chỉ cần băm nó. Nếu được mã hóa, thì bất kỳ ai có quyền truy cập vào cơ sở dữ liệu và khóa giải mã (ví dụ: có thể là hầu hết nhân viên hoặc bất kỳ ai đánh cắp mã cùng với cơ sở dữ liệu) đều có thể lấy mật khẩu văn bản đơn giản. Nếu nó được băm, thì bạn phải lấy nó trước khi quá trình băm diễn ra (ví dụ: trong một phiên đăng nhập).

Hơn nữa, mặc dù mọi người không nên, việc sử dụng cùng một mật khẩu (hoặc mật khẩu rất giống nhau) trên nhiều trang web là rất phổ biến. Điều đó có nghĩa là thay vì chỉ cung cấp một cách để vào một tài khoản, bạn đang cung cấp một cách để truy cập vào nhiều tài khoản.

Trong trường hợp khác, nơi kẻ tấn công có quyền truy cập vào tất cả thư đến (thậm chí có khả năng loại bỏ thư đến trước khi người dùng nhìn thấy), cả hai thư này đều không an toàn. Tài khoản email là rủi ro cao , vì nếu bạn có loại quyền truy cập đó, thì bạn có thể đến mọi trang web mà người dùng có tài khoản và tạo lại mật khẩu. Để tránh điều này, bạn cần sử dụng một cái gì đó ngoài (hoặc cũng như) tài khoản email của bạn để có quyền truy cập, chẳng hạn như xác thực hai yếu tố.

Lưu ý rằng ngay cả trong trường hợp sau, liên kết đặt lại vẫn vượt trội: nếu kẻ tấn công thay đổi mật khẩu của người dùng thông qua liên kết đặt lại, thì khi người dùng cố gắng đăng nhập, họ sẽ phát hiện ra có gì đó không đúng (quá muộn, nhưng ít nhất là họ biết). Nếu bạn chỉ cung cấp mật khẩu, thì người dùng không biết rằng kẻ tấn công đã âm thầm truy cập.

40
Tony Meyer

Ok, bỏ qua thực tế là các mật khẩu được lưu trữ trong văn bản đơn giản và đi thẳng vào câu hỏi :. Mật khẩu là một thông tin có giá trị lâu dài, trong khi liên kết đặt lại mật khẩu có thể được xác định theo các cách khác nhau:

  1. Chỉ có hiệu lực trong một khoảng thời gian ngắn
  2. Chỉ hợp lệ từ một ip nhất định [.__.]
    • Tốt nhất là cùng một IP yêu cầu mật khẩu đã được gửi từ.
  3. Chỉ có hiệu lực trong phiên người dùng [.__.]
    • Khi người dùng nhập chi tiết trong biểu mẫu web để yêu cầu mật khẩu mới, người dùng sẽ được cấp cookie (bắt đầu một phiên). Việc xác thực url đặt lại mật khẩu phụ thuộc vào nội dung nào đó trong phiên này, do đó chức năng xác thực sẽ thất bại nếu yêu cầu được thực hiện mà không có cookie.

Cũng cần lưu ý rằng một mật khẩu cũ, có thể không còn hiệu lực tại trang web của bạn, vẫn có thể rất nhạy cảm đối với khách hàng, vì mọi người sử dụng lại mật khẩu trên tất cả các loại dịch vụ.

Từ khía cạnh đó, việc đặt mật khẩu vào hộp thư điện tử của mọi người có thể được coi là loại thô lỗ.

22
mhswende

Đáng nói thêm là nếu bạn gửi mật khẩu của người dùng một cách đơn giản, bạn có thể đang gửi mật khẩu mà họ cũng sử dụng trên các trang web khác - ngay cả khi bạn buộc người dùng thay đổi mật khẩu trên trang web của bạn vào lần đăng nhập tiếp theo, bạn đã không ủng hộ họ ở tất cả.

9
Tom Newton

Việc lưu trữ mật khẩu trong bản rõ là không hợp lý nếu bạn có chút lo lắng nhất cho người dùng của mình. Bạn nên lưu trữ băm muối an toàn. Gửi mật khẩu văn bản gốc có thể khiến người dùng có ý thức bảo mật ngừng sử dụng dịch vụ của bạn (mặc dù người dùng có ý thức bảo mật không sử dụng lại mật khẩu; họ chỉ không muốn hỗ trợ các dịch vụ không có ý thức bảo mật rõ ràng).

Làm thế nào để thực hiện thiết lập lại mật khẩu; nói chung đối với một trang web bảo mật vừa phải (giả sử thẻ tín dụng), bạn yêu cầu họ trả lời một số câu hỏi bảo mật cơ bản (ví dụ: tên thời con gái của mẹ) và xác minh rằng họ có quyền kiểm soát tài khoản email hoặc số điện thoại của họ, như một hình thức xác thực hai yếu tố. Liên kết chỉ có giá trị trong một cửa sổ thời gian ngắn (vài giờ đến vài ngày) và chỉ có hiệu lực một lần (ví dụ: bao gồm mã thông báo được tạo ngẫu nhiên hết hạn sau lần sử dụng đầu tiên và sau một khoảng thời gian).

Bạn cũng thông báo cho họ rằng mật khẩu đã được đặt lại (và ngay cả khi email của họ bị xâm phạm; họ sẽ tìm thấy bằng chứng của kẻ tấn công khi họ không thể đăng nhập bằng mật khẩu cũ nữa). Gửi mật khẩu (không thay đổi mật khẩu) có nghĩa là cuộc tấn công này có thể được thực hiện một cách lén lút mà người dùng không bao giờ biết (nếu nói rằng các email đã bị xóa).

9
dr jimbob

Tốt hơn là gửi một liên kết đặt lại mật khẩu.

Một số trang web có dạng mật khẩu bị quên ngay lập tức đặt lại mật khẩu thành giá trị ngẫu nhiên và được gửi qua email cho người dùng. Điều này có một lỗ hổng từ chối dịch vụ - ai đó không phải là chủ tài khoản có thể khiến mật khẩu của họ được đặt lại. Liên kết đặt lại mật khẩu tránh điều này, vì mật khẩu chỉ được đặt lại sau khi người dùng nhấp vào liên kết - và họ phải có quyền truy cập vào địa chỉ email để thực hiện việc này.

Nếu bạn muốn có một chút bảo mật chống lại kẻ tấn công có quyền truy cập vào email của người dùng, cách tiếp cận thông thường là cũng có câu hỏi bảo mật. Đây là những câu hỏi như "Tên thú cưng của bạn là gì". Và thời gian để hỏi những điều này là sau khi người dùng đã nhấp vào liên kết đặt lại mật khẩu trong email.

Một số lời khuyên tốt ở đây: https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

3
paj28

Nó là tốt hơn để gửi một liên kết thiết lập lại.

Ngoài các lý do được đưa ra bởi @Tony Meyer và @mhswende, trang tại liên kết đặt lại có thể yêu cầu xác thực bổ sung. Nhiều trang web yêu cầu người dùng trả lời "câu hỏi bảo mật" cho chính xác mục đích này (tiêu chuẩn trước khi sử dụng máy tính cũ là yêu cầu tên thời con gái của mẹ bạn). Các trang web có số điện thoại của bạn có thể, trên trang đặt lại mật khẩu của họ, yêu cầu bạn nhập mã họ gửi bằng SMS. Các tổ chức tài chính có thể đặt câu hỏi về hồ sơ tài chính cũ (nhà xác trước đây, v.v.).

Sẽ không tầm thường khi đưa ra một cơ chế xác thực thứ cấp tốt, nhưng bất kỳ quy trình đặt lại mật khẩu (hoặc khôi phục) nào không đủ dễ bị tổn thương đến mức tôi gọi đó là sơ suất.

2
ShadSterling