Đăng nhập thất bại đăng nhập cố gắng lộ mật khẩu

38

Tôi đã bắt đầu đăng nhập thất bại khi đăng nhập vào trang web của mình bằng một thông báo như

Failed login attempt by qntmfred

Tôi đã nhận thấy một số các bản ghi này trông giống như

Failed login attempt by qntmfredmypassword

Tôi đoán một số người đã đăng nhập thất bại vì họ đã nhập tên người dùng và mật khẩu của họ trong trường tên người dùng. Mật khẩu được băm trong cơ sở dữ liệu, nhưng nếu bằng cách nào đó db bị xâm phạm, những thông điệp tường trình này có thể là một cách để kẻ tấn công tìm ra mật khẩu cho bất kỳ tỷ lệ nhỏ nào mọi người kết thúc việc đăng nhập thất bại như thế này.

Có cách nào tốt hơn để xử lý việc này? Tôi thậm chí có nên lo lắng về khả năng này?

web-development security

— kenwarner
nguồn

14

Có bạn nên lo lắng về nó.

— FoolishSeth

9

Liên quan: Mật khẩu được gửi trong văn bản rõ ràng do sai lầm của người dùng khi nhập nó vào trường tên người dùng và việc đăng nhập mật khẩu bị từ chối có phải là thông lệ không? .

— một CVn

4

Câu hỏi thú vị vì nó vượt qua UX và bảo mật. Như đã lưu ý trong một trong các liên kết của Michael, bạn có thể ngăn hầu hết các trường hợp sử dụng Javascript (phía máy khách). Vô hiệu hóa nút Đăng nhập trong khi trường mật khẩu trống. Người dùng không có Javascript vẫn có thể sử dụng màn hình đăng nhập theo cách đó, vì nút này sẽ không bị tắt trong trường hợp đó.

— MSalters

65

Hãy thử nó như thế này:

Nếu tên người dùng tồn tại, đăng nhập "thất bại đăng nhập bằng cách username". Nếu không, hãy đăng nhập "thất bại đăng nhập bằng IP 123.45.67.89". Điều đó sẽ quan tâm đến vấn đề có mật khẩu xuất hiện trong nhật ký.

— Bánh xe Mason
nguồn

14

Bạn cũng có thể kiểm tra mật khẩu trống và không có lỗi thích hợp trong trường hợp đó.

— Mike Weller

In tên người dùng là vấn đề mà OP đã mô tả. Đôi khi đăng nhập thất bại là do người dùng thiếu phím [tab] và nhanh chóng nhập cả tên người dùng và mật khẩu vào trường tên người dùng và nhấn enter. Đề nghị của bạn không xử lý này.

— BZink

7

@BZink: Có chứ. Nếu tên người dùng tồn tại , đăng nhập nó như vậy. Nếu những gì người dùng làm là vô tình thêm mật khẩu vào tên người dùng, chuỗi kết quả gần như chắc chắn sẽ không phải là tên người dùng hợp lệ.

— Mason Wheeler

12

Tại sao không chỉ đơn giản là kiểm tra nếu tên người dùng như vậy tồn tại trong cơ sở dữ liệu? Điều này sẽ để lại cho bạn 2 kết quả có thể.

Người dùng đã nhập đúng tên người dùng. Sau đó bạn có thể chỉ cần đăng nhập những gì bạn đăng nhập bây giờ.
Người dùng đã nhập mật khẩu của mình vào trường tên người dùng, do đó tên người dùng không hợp lệ. Chỉ cần nhập một mục nhật ký nói rằng đã có thất bại trong nỗ lực đăng nhập của người dùng không xác định?

Và tất nhiên bạn có thể có thêm một trường để đăng nhập ip, ngày và những gì không?

— galdikas
nguồn

3

Tại sao không nối băm tên người dùng vào mục nhật ký ở # 2. Điều này sẽ ẩn mật khẩu, nhưng đồng thời cho phép ai đó nhìn vào nhật ký để xác định xem có nhiều lần thử bởi cùng một người dùng không xác định.

— emory

Nếu không có bản ghi chứa tên người dùng, rõ ràng họ đã nhầm, vì vậy điều này vẫn hữu ích cho việc xử lý sự cố.

— JeffO

2

@emory, nếu người dùng nhập nhầm mật khẩu của họ cùng với tên người dùng thì không có cách nào khả thi để trích xuất chỉ phần tên người dùng của chuỗi. Và ai đó liên tục nhập mật khẩu của họ vào trường tên người dùng là điều rất khó xảy ra. Đây là một lỗi "một lần tắt" mà bạn làm. Xảy ra với những điều tốt nhất của chúng ta, nhưng tôi nghi ngờ có ai đó đủ ngu ngốc để tiếp tục làm điều đó mà không nhận ra điều đó: D

— galdikas

@galdikas Không cần trích xuất bất cứ thứ gì từ tên người dùng. Ví dụ: tôi là người dùng 'người dùng' với mật khẩu 'mật khẩu'. Tôi đăng nhập bằng 'mật khẩu người dùng' và hàm băm của bạn ánh xạ 'mật khẩu người dùng' thành 17. Nhật ký sẽ thông báo "Lỗi đăng nhập thất bại của người dùng không xác định 17".

— emory

1

@galdikas Có lẽ không có ai ngu ngốc hay đủ kiên trì để tiếp tục làm điều đó hơn một vài lần, nhưng có những kịch bản đủ ngu ngốc và đủ kiên trì để thực hiện hàng ngàn lần. Bạn có muốn biết sự khác biệt không?

— emory

1

Cân nhắc:

Bạn có thể phát hiện khi điều này xảy ra, trái ngược với việc ai đó nhập nhầm tên người dùng của họ không? Ghi nhật ký tên người dùng sai có thể hữu ích cho mục đích hỗ trợ, tức là trả lời câu hỏi "tại sao tôi không thể đăng nhập" bằng câu trả lời "Bạn đã nhập nhầm tên người dùng của mình, đó phải là dấu gạch ngang không phải là dấu chấm" hoặc "Bạn có dấu hai chấm sau đó khoảng trắng - bạn đã cắt và dán nó ". Nếu bạn có một số lượng nhỏ người dùng trả tiền giá trị cao (nghĩa là chưa phải là một trang mạng xã hội khác) thì có lẽ bạn sẽ phải cung cấp loại hỗ trợ này.
Hành động thích hợp ai đó nên làm điều này là gì? Tên người dùng có thể là chỉ số của các nỗ lực hack. Việc tên người dùng không xuất hiện trong danh sách của bạn không có nghĩa là bạn không cần biết nó là gì. Tuy nhiên nếu bạn tin rằng đây là một mối quan tâm nghiêm trọng và bạn có thể phát hiện ra mật khẩu của ai, bạn có thể yêu cầu người dùng thay đổi mật khẩu của họ sau khi điều này xảy ra.
Thực hành công nghiệp là gì? Thực hành công nghiệp là đăng nhập trường tên người dùng nhưng không phải trường mật khẩu. Bạn không có khả năng bị sa thải vì làm điều này.

Trừ khi bạn có những cân nhắc khác thường, tôi sẽ đề nghị theo dõi thực tiễn ngành và đăng nhập trường tên người dùng, bất kể. Xem xét thay đổi mật khẩu bắt buộc như đề xuất 2 nếu bạn cho rằng điều này không thỏa đáng.

— Bến
nguồn

1

Để an toàn, việc đăng nhập trong ứng dụng hiện tại của tôi không lưu trữ các tham số được truyền cho các phương thức đăng nhập hoặc đặt lại mật khẩu. Cuộc gọi nhật ký có một tham số tùy chọn điều khiển điều này, khi được đặt thành true, sẽ thay thế đối tượng tham số được lưu trữ bằng [Redacted]. Chắc chắn, vì vậy tôi bỏ lỡ một ít dữ liệu, nhưng tôi có địa chỉ IP của họ và tôi không muốn mạo hiểm nhận được thứ gì đó nhạy cảm trong bản rõ.

Nếu bạn thực sự muốn đăng nhập loại điều này, tôi khuyên bạn nên đăng nhập một lần thử đăng nhập, bạn kiểm tra cơ sở dữ liệu cho người dùng có tên khớp với những gì bạn có trong trường tên người dùng và chỉ lưu trữ nếu bạn khớp. Nếu không, bạn chỉ cần lưu trữ nó dưới dạng "người dùng không xác định". Bạn có thể thích, kiểm tra xem giá trị này có chứa giá trị đó hay không, nhưng luôn có nguy cơ bạn nhận được các kết hợp như [Người dùng] [Mật khẩu] và [UserPas] [kiếm], trong trường hợp đó bạn có thể kiểm tra IP và suy luận rằng bạn đã vô tình lưu trữ bắt đầu mật khẩu của ai đó rõ ràng. Bạn có thể mở rộng nó thành [Người dùng] [Mật khẩu] và [UserPassword] [??], trong trường hợp đó bạn có thể thấy "đăng nhập không thành công bởi UserPassword" theo sau là "Đăng nhập thành công bởi người dùng" và suy luận tất cảmật khẩu của người dùng. Nói chung, để an toàn, tôi nói không đăng nhập tên người dùng trừ khi đăng nhập thành công.

Chỉnh sửa để thêm:

Hầu hết các đối số mà mọi người đang đăng để đăng nhập tên người dùng cho các lần đăng nhập thất bại, theo tôi, được xử lý tốt hơn thông qua các phương pháp khác.

Ví dụ, người ta nói rằng khi khách hàng hỏi "tại sao tôi không thể đăng nhập?", Tên người dùng đã đăng nhập sẽ cho phép bạn chỉ ra lỗi chính tả. Điều này là đúng, nhưng nó không đáng để mạo hiểm khi bắt mật khẩu; Tôi sẽ làm điều này bằng cách thay vào đó chuyển hướng người dùng trở lại biểu mẫu đăng nhập khi thất bại, làm nổi bật trường tên người dùng và sao chép lại bằng bất cứ điều gì họ đã nhập để họ có thể tự nhìn thấy.

Một lập luận khác là nó cho phép bạn xác định các nỗ lực hack; một chuỗi các lỗi đối với một tên người dùng cũng có thể là một nỗ lực để đánh cắp mật khẩu. Tôi sẽ làm điều này bằng cách có cột "BadLogins" trên bảng Người dùng, được tăng lên mỗi lần đăng nhập thất bại với tên người dùng khớp với người dùng này và được đặt lại về 0 khi đăng nhập thành công, sau khi nói với người dùng "đã có x những lần đăng nhập không thành công kể từ lần đăng nhập cuối cùng của bạn "và tư vấn cho họ phải làm gì nếu họ không nghĩ rằng những nỗ lực đó là từ họ. Nếu bạn muốn thực sự kỹ lưỡng, bạn có thể có một cột khác lưu trữ giá trị cuối cùng của cột BadLogins ngay cả sau khi đăng nhập thành công và / hoặc một cột lưu trữ giá trị cao nhất từ trước đến nay của cột này và / hoặc một cột có lưu trữ tổng số lần đăng nhập thất bại mà tài khoản này đã từng có.

— anaximander
nguồn