it-swarm-vi.com

Có phải là thông lệ để đăng nhập mật khẩu bị từ chối?

Mặc dù lựa chọn mật khẩu duy nhất cho từng mục đích là một ý tưởng tuyệt vời, nhưng trong thực tế, điều này hiếm khi xảy ra. Do đó, nhiều người chọn mật khẩu từ nhóm mật khẩu cá nhân dễ nhớ. Khi xác thực vào các hệ thống được sử dụng không thường xuyên, rất có thể một số mật khẩu từ nhóm như vậy được thử tuần tự. Ngoài ra, mật khẩu thất bại rất gần với mật khẩu thực tế trong trường hợp lỗi chính tả.

Vì hầu như không ai mô tả chính sách mật khẩu có hiệu lực, bao gồm cả cách xử lý mật khẩu bị từ chối, nên bắt đầu giả định rằng chúng được thu thập trong cơ sở dữ liệu được bán cho người trả giá cao nhất?

Có hướng dẫn thực hiện không? Điều gì thường xảy ra với mật khẩu ứng viên khi điều này bị từ chối? Họ có đang đăng nhập, ngay lập tức bị loại bỏ hoặc để lại xung quanh cho đến khi rác được thu thập? Là các thủ tục xử lý mật khẩu không thành công của bất kỳ kiểm soát kiểm toán? Có vẻ như có rất nhiều yêu cầu triển khai và đề xuất về cách xử lý mật khẩu hợp lệ, nhưng mơ hồ về các giá trị mật khẩu bị từ chối.

[~ # ~] chỉnh sửa [~ # ~]

Tôi sẽ cố gắng liệt kê ở đây các triển khai khác nhau để đăng nhập thông tin đăng nhập bảo mật không thành công để có được cảm giác về quy trình này phổ biến như thế nào:

Hệ thống quản lý nội dung :

Joomla thông qua Đăng nhập thất bại đăng nhập plugin

Plug-in nhỏ này thu thập nhật ký về mỗi lần đăng nhập thất bại của quản trị viên trang Joomla của bạn và gửi email về từng người cho quản trị viên siêu của trang web với tên người dùng, mật khẩu, địa chỉ ip và lỗi.

KPlaylist v1.3 và v1.4 - một hệ thống PHP miễn phí bộ sưu tập nhạc có sẵn thông qua Internet.

đang ghi nhật ký tên người dùng và mật khẩu của các lần đăng nhập thất bại trong nhật ký lỗi Apache

Drupal 5.x trước phiên bản 5.19 và Drupal 6.x trước phiên bản 6.1 .

Khi người dùng ẩn danh không đăng nhập được do nhập nhầm tên người dùng hoặc mật khẩu của anh ta và trang anh ta đang ở có chứa một bảng có thể sắp xếp, tên người dùng và mật khẩu (không chính xác) được bao gồm trong các liên kết trên bảng. Nếu người dùng truy cập các liên kết này, mật khẩu có thể bị rò rỉ ra các trang web bên ngoài thông qua trình giới thiệu HTTP.

Phần mềm độc lập

Máy chủ báo cáo đi kèm với Symantec Client Security 3.1 và SAV CE 10.1

Mật khẩu quản trị viên cho Máy chủ báo cáo Symantec có thể được tiết lộ sau khi đăng nhập thất bại.

Linux :

OpenSSH thông qua sửa đổi auth-passwd.c ; sử dụng PAM thông qua chức năng nạp chồng pam_sm_authenticate

EDIT # 2

Dường như có sự đồng thuận và ghi lại mật khẩu hoặc mã PIN bị lỗi được coi là rủi ro bảo mật nghiêm trọng/nghiêm trọng, tuy nhiên theo như tôi biết, các tiêu chuẩn sau đây không cung cấp hướng dẫn, quy trình kiểm toán hoặc kiểm soát nào giải quyết cụ thể rủi ro này:

  • PCI-DSS : Thủ tục mật khẩu được giải quyết trong 8.4. và 8,5. (mật khẩu thất bại chỉ được bảo vệ trong quá trình truyền; sau khi xác thực không được coi là mật khẩu, do đó không bắt buộc phải bảo vệ)

  • Trin140-2 : Xác thực được xử lý trong 4.3 (vòng đời của dữ liệu xác thực không thành công chỉ được giải quyết một phần)

61
Drew Lex

Ghi nhật ký giá trị của một lần thử mật khẩu thất bại (Cleartext hoặc cách khác) có vẻ như là một mô hình chống bảo mật. Tôi chưa bao giờ thấy một ứng dụng web nào thực hiện điều này và tôi không biết bất kỳ dịch vụ hệ thống mặc định nào như SSH cũng làm như vậy. Như được chỉ ra bởi @tylerl bên dưới, hầu hết các hệ thống chỉ cần ghi thông tin meta về một lần truy cập (ví dụ: tên người dùng, thời gian, có lẽ là địa chỉ IP, v.v.).

Tại sao điều này nên là một mô hình chống bảo mật

Chính thức, tôi có thể nghĩ ra ba lý do tại sao việc ghi lại giá trị của một lần thử mật khẩu thất bại là một ý tưởng tồi:

1. Typose người dùng

Việc mọi người gõ nhầm mật khẩu bằng một hoặc hai ký tự là cực kỳ phổ biến. Kiểm tra tệp nhật ký của các lần thử thất bại sẽ giúp nhiều người trong số này dễ dàng tìm ra, đặc biệt là nếu bạn có thể đối chiếu chuỗi các lần thử thất bại với xác thực thành công.

2. Đoán và kiểm tra

Nhiều người có hai hoặc ba mật khẩu họ chuyển qua cho tất cả mọi thứ. Do đó, khi họ quên mật khẩu họ đã sử dụng trên một trang web nhất định, họ chỉ quay vòng qua tất cả chúng cho đến khi tìm thấy kết quả khớp. Điều này sẽ khiến việc hack tài khoản của họ trên các trang web khác trở nên tầm thường.

. Đăng nhập Bloat

Lưu trữ mật khẩu thất bại không phục vụ mục đích hữu ích cho phần lớn các dịch vụ xác thực trong sản xuất hiện nay. Mặc dù có thể có một số trường hợp Edge, nhưng đối với hầu hết mọi người, việc lưu trữ dữ liệu này chỉ đơn giản là vứt bỏ không gian đĩa.

Về Pháp lý/Tiêu chuẩn có liên quan

Tôi không biết về bất kỳ tiêu chuẩn nào (PCI, HIPAA, v.v.) giải quyết cụ thể các quy trình lưu trữ các lần đăng nhập thất bại, nhưng tôi nghĩ rằng việc cấp các sự kiện trên có thể đưa ra một lý lẽ pháp lý tốt cho lý do tại sao các tiêu chuẩn tương tự áp dụng cho việc lưu trữ mật khẩu nói chung cũng nên áp dụng cho các lần thử mật khẩu không thành công. Nói cách khác, bạn có thể đưa ra một lập luận pháp lý rằng mật khẩu không thành công vẫn là mật khẩu và do đó nó phải tuân theo cùng tiêu chuẩn.

Mặc dù tôi chắc chắn không phải là luật sư, tôi sẽ không muốn một thẩm phán quyết định liệu tôi có sơ suất hay vi phạm các tiêu chuẩn ngành hay không vì mật khẩu không được lưu trữ trong văn bản rõ ràng và người tiêu dùng phải chịu hậu quả. Tôi không nghĩ rằng điều đó sẽ kết thúc với một quyết định thuận lợi.

Tôi đồng ý với OP rằng nó có thể hữu ích cho các cơ quan tiêu chuẩn khác nhau để giải quyết vấn đề này một cách cụ thể (nếu họ thực sự chưa có). Cuối cùng, đề xuất của tôi sẽ là tạo ra một tiêu chuẩn tuân thủ không lưu trữ giá trị của các lần thử mật khẩu thất bại.

68
Mark

Không có mục đích hợp pháp để ghi lại mật khẩu văn bản gốc cho bất kỳ ứng dụng nào; đặc biệt là cho một đăng nhập không chính xác. Nó có thể được ghi lại một cách tình cờ - Tôi tình cờ nhìn vào auth.log cho các mục đích khác và thấy một người dùng vô tình nhập mật khẩu của họ vào trường đăng nhập (và tôi ghi lại các trường đăng nhập để xem tài khoản nào đang cố đăng nhập) - tuy nhiên tôi đã thông báo cho người dùng về nó và họ đã thay đổi mật khẩu.

Mặt khác, với tư cách là một người dùng, giả định thận trọng là nói rằng mọi ứng dụng ngẫu nhiên bạn sử dụng đều ghi lại mọi mật khẩu của các lần thử sai. Đây là lý do tại sao nên có một (ba) mật khẩu ngẫu nhiên nhỏ mà bạn chuyển qua, so với mật khẩu duy nhất cho mỗi trang web được quản lý trong danh sách mật khẩu được mã hóa (có thể sử dụng một công cụ như keepass).

Về lưu ý này, Mark Zuckerberg (người sáng lập facebook) đã bị businessinsider.com cáo buộc sử dụng nhật ký kết hợp đăng nhập/mật khẩu (thậm chí từ các mục nhập không chính xác) từ thefacebook.com (một phiên bản đầu của facebook) để hack vào tài khoản email của các nhà báo Harvard Crimson đang điều tra anh ta. Từ thư hàng ngày : :

Tuy nhiên, sau khi những tuyên bố tiếp theo xuất hiện, Zuckerberg rõ ràng đã trở nên lo lắng rằng rốt cuộc tờ báo sẽ viết một câu chuyện về anh ta.

Business Insider tuyên bố anh ta sau đó nói với một người bạn rằng anh ta đã xâm nhập vào tài khoản của nhân viên Crimson như thế nào.

Anh ta bị cáo buộc nói với người bạn rằng anh ta đã sử dụng TheFacebook.com để tìm kiếm các thành viên nói rằng họ là nhân viên của Crimson.

Sau đó, anh ta bị cáo buộc đã kiểm tra một báo cáo về các lần đăng nhập thất bại để xem liệu có thành viên nào của Crimson đã nhập mật khẩu không chính xác vào TheFacebook.com hay không.

Cũng có phần liên quan xkcd (hãy tưởng tượng rằng các tài khoản tà ác cũng đã đăng nhập đã thử mật khẩu để tăng tỷ lệ thành công của chúng).

17
dr jimbob

Có một số câu trả lời tuyệt vời ở trên, vì vậy đây chỉ là một viễn cảnh nhanh chóng và đơn giản từ chính sách của chính phủ Hoa Kỳ về việc quản lý các hệ thống máy tính xử lý thông tin được phân loại.

(1) Toàn bộ hệ thống máy tính phải được bảo vệ theo tiêu chuẩn cao nhất theo yêu cầu của mọi dữ liệ trên máy đó. Điều này bao gồm các bản ghi được lưu trữ trên hoặc ngoài máy.

Ví dụ: nếu bạn vô tình hoặc vô tình đưa dữ liệu "bí mật" vào máy tính, thì MỌI phần của máy tính đó giờ phải được bảo vệ dưới dạng thông tin "bí mật". Đây là trường hợp ngay cả khi bạn có một máy tính chưa được phân loại (ví dụ như ở nhà) đã nhận được email có thông tin được phân loại. Toàn bộ máy tính, và mọi thứ trên đó hiện được phân loại là "bí mật".

(2) mật khẩ cho máy đó cũng được phân loại ở mức bảo vệ cao nhất theo yêu cầu của bất kỳ dữ liệu nào trên máy đó.

Ví dụ: nếu bạn có bất kỳ dữ liệu "bí mật" nào trên máy đó, bất cứ nơi nào bạn lưu mật khẩu, nó cũng yêu cầu mức độ bảo vệ tương tự.

Khi áp dụng cho câu hỏi của bạn, bất kể tiêu chuẩn bạn đang áp dụng, chẳng hạn như PCI-DSS, NISPOM, v.v., bạn không thể có mật khẩu bằng văn bản rõ ràng trong nhật ký nếu yêu cầu là chúng phải được bảo vệ (chẳng hạn như băm và muối) .

Vì vậy, tóm lại, nếu bất kỳ lược đồ quy định được áp dụng cho hệ thống máy tính của bạn được đề cập và quy định đó nói rằng bạn không thể có mật khẩu văn bản rõ ràng, thì bạn không thể có mật khẩu văn bản rõ ràng trong nhật ký của mình.

6
OnTheShelf

Không có gì lạ khi ghi lại sự thật rằng một nỗ lực xác thực đã thất bại và người dùng đó đã làm gì. Điều này có thể chứng minh rất hữu ích trong việc khắc phục sự cố pháp y. Điều này là cực kỳ không phổ biến và vô trách nhiệm từ góc độ bảo mật để ghi lại mật khẩu đã bị từ chối. Thông tin này không phục vụ mục đích hữu ích và có thể được sử dụng để chống lại bạn.

CHỈNH SỬA
[.__.] Bạn nên hy vọng có thể hy vọng rằng một công ty có uy tín và được tổ chức tốt sẽ không bán thông tin mật khẩu của bạn vì điều này thực sự có hại cho họ nếu bị phát hiện. Nhưng vì lợi ích bảo mật của chính bạn, bạn nên luôn chuẩn bị sẵn sàng cho thông tin bạn đưa ra để sử dụng chống lại bạn vì đó luôn là một khả năng. Điều này tăng gấp đôi cho bất kỳ tổ chức nào có uy tín mà bạn không thể thiết lập đáng tin cậy.

6
tylerl

Không. Thông thường người dùng có một nhóm mật khẩu và chuyển qua chúng cố gắng tìm ra cái nào đang được sử dụng cho một trang web nhất định. Ghi nhật ký chỉ có nghĩa là khi bạn bị xâm phạm, những người thay thế của họ sẽ được thêm vào nhóm cracker của bất cứ ai đánh bạn.

2
John Haugeland