Tại sao có một độ trễ lớn sau khi nhập sai mật khẩu?

Tôi nhận thấy một điều kỳ lạ (tốt, theo tôi) về mật khẩu. Ví dụ: nếu tôi nhập mật khẩu không chính xác trong khi đăng nhập, sẽ có một vài giây chậm trễ trước khi hệ thống cho tôi biết như vậy. Khi tôi cố gắng nhập sudosai mật khẩu, tôi cũng sẽ phải đợi trước khi shell nói "Xin lỗi, hãy thử lại".

Tôi tự hỏi tại sao phải mất quá lâu để "nhận ra" một mật khẩu không chính xác? Điều này đã được nhìn thấy trên một số bản phân phối tôi sử dụng (và thậm chí cả OSX), vì vậy tôi nghĩ rằng đó không phải là một điều cụ thể về phân phối.

Đây là một điều bảo mật, nó không thực sự mất nhiều thời gian để nhận ra nó. 2 lỗ hổng này giải quyết:

1. điều này đăng nhập các nỗ lực đăng nhập, có nghĩa là ai đó không thể đập hệ thống nhanh như nó có thể cố gắng bẻ khóa nó (1 triệu lần thử một giây? Tôi không biết).

2. Nếu nó đã làm điều đó ngay khi nó xác minh thông tin đăng nhập của bạn không chính xác, bạn có thể sử dụng lượng thời gian cần thiết để xác thực thông tin đăng nhập của mình để giúp đoán xem một phần thông tin của bạn có chính xác hay không, giảm đáng kể thời gian đoán.

để ngăn chặn 2 điều này, hệ thống chỉ mất một khoảng thời gian nhất định để thực hiện, tôi nghĩ bạn có thể định cấu hình thời gian chờ với PAM ( Xem câu trả lời của Michaels ).

Kỹ thuật bảo mật ( 2ed, amazon | 1ed, miễn phí ) đưa ra lời giải thích tốt hơn nhiều về những vấn đề này.

Đây là cố ý, để cố gắng và hạn chế vũ phu. Bạn thường có thể sửa đổi nó bằng cách tìm FAIL_DELAYmục nhập cấu hình /etc/login.defsvà thay đổi giá trị của nó ( 3theo mặc định là giây), mặc dù nhận xét trong tệp đó có vẻ như PAM sẽ thực thi ít nhất một 2giây chậm trễ bất kể là gì

Trên các hệ thống linux hiện đại, lý do là pam_unix.so áp đặt độ trễ như vậy. Như đã đưa tin, điều này có thể được cấu hình xuống để hai giây bằng cách thay đổi FAIL_DELAYtrong /etc/login.defs. Nếu bạn muốn giảm độ trễ hơn nữa, bạn phải cung cấp cho pam_unix.so tùy chọn "gật đầu". Ví dụ: trên hệ thống của tôi, nếu bạn theo dõi bao gồm bắt đầu từ /etc/pam.d/sudo, bạn thấy bạn phải chỉnh sửa dòng sau /etc/pam.d/system-auth:

auth      required  pam_unix.so     try_first_pass nullok

và thay đổi nó thành này:

auth      required  pam_unix.so     try_first_pass nullok nodelay

Thật không may, cách distro linux (arch) của tôi cấu hình mọi thứ, cùng một system-authtệp được bao gồm bởi system-remote-login, được sử dụng bởi sshd.

Mặc dù an toàn để loại bỏ độ trễ trên sudo, vì nó được ghi lại, chỉ được sử dụng bởi người dùng cục bộ và có thể bỏ qua bởi những kẻ tấn công cục bộ, nhưng có lẽ bạn không muốn loại bỏ sự chậm trễ này cho đăng nhập từ xa. Tất nhiên bạn có thể sửa nó bằng cách viết một sudo tùy chỉnh không bao gồm các tệp auth hệ thống được chia sẻ.

Cá nhân, tôi nghĩ rằng sự chậm trễ trên sudo (và bỏ qua SIGINT) là một sai lầm lớn. Điều đó có nghĩa là người dùng biết họ nhập sai mật khẩu không thể giết quá trình và bị thất vọng. Tất nhiên, bạn vẫn có thể dừng sudo bằng Ctrl-Z, vì sudo không bắt được SIGTSTP và sau khi dừng, bạn có thể giết nó bằng kill -9 (SIGKILL). Nó chỉ gây phiền nhiễu để làm. Vì vậy, điều đó có nghĩa là một cuộc tấn công tự động có thể bắn sudos vào các thiết bị đầu cuối giả với tốc độ siêu cao. Nhưng sự chậm trễ làm nản lòng người dùng hợp pháp và khuyến khích họ tạm ngưng vỏ gốc thay vì thoát khỏi chúng để tránh phải sudo lại.