it-swarm-vi.com

"Tên người dùng và / hoặc mật khẩu không hợp lệ" - Tại sao các trang web hiển thị loại tin nhắn này thay vì thông báo cho người dùng biết cái nào sai?

Giả sử người dùng đang đăng nhập vào một trang web thông thường, nhập tên người dùng và mật khẩu của họ và họ nhập sai một trong những đầu vào của họ. Tôi đã nhận thấy rằng hầu hết, nếu không phải tất cả, các trang web hiển thị cùng một thông báo (một cái gì đó dọc theo dòng, "Tên người dùng hoặc mật khẩu không hợp lệ") mặc dù chỉ có một đầu vào bị sai.

Đối với tôi, dường như đủ dễ dàng để thông báo cho người dùng về việc nhập sai và điều này khiến tôi tự hỏi tại sao các trang web không làm điều đó. Vì vậy, có một lý do bảo mật cho điều này hay nó chỉ là một cái gì đó đã trở thành tiêu chuẩn?

103
bobble14988

Nếu người dùng độc hại bắt đầu tấn công trang web bằng cách đoán các kết hợp tên người dùng/mật khẩu phổ biến như admin/admin, kẻ tấn công sẽ biết rằng tên người dùng hợp lệ là nó trả về một thông báo "Mật khẩu không hợp lệ" thay vì "Tên người dùng hoặc mật khẩu không hợp lệ".

Nếu kẻ tấn công biết tên người dùng là hợp lệ, anh ta có thể tập trung nỗ lực vào tài khoản cụ thể đó bằng cách sử dụng các kỹ thuật như SQL tiêm hoặc xác nhận lại mật khẩu.

128
user10211

Như những người khác đã đề cập, chúng tôi không muốn bạn biết liệu đó có phải là tên người dùng hoặc mật khẩu sai hay không để chúng tôi không dễ bị brute-force hoặc dictionary tấn công ..

Nếu một số trang web muốn cho người dùng của họ biết cái nào bị lỗi trong khi vẫn ở trạng thái bảo mật xanh, họ có thể triển khai " honeypot " tên người dùng (như Quản trị viên, quản trị viên, v.v.) sẽ cảnh báo trang web quản trị viên rằng ai đó đang rình mò trên trang web của họ. Bạn thậm chí có thể thiết lập một số logic để cấm địa chỉ IP của họ nếu họ cố đăng nhập bằng một trong những tên người dùng "honeypot" đó. Tôi biết một người thực sự có một trang web và đặt mã nguồn của họ một nhận xét HTML, chẳng hạn như "Vì bạn đã quên Richard: Tên người dùng: pho mát Mật khẩu: Burger123" gần hộp đăng nhập với mục đích theo dõi bất kỳ địa chỉ IP nào đã cố sử dụng tên người dùng/mật khẩu. Thêm logic giám sát như thế rất thú vị khi bạn đang phát triển một trang web.

Tất nhiên, ghi nhật ký các lần thử đăng nhập không hợp lệ và thêm logic thích hợp để xử lý các địa chỉ IP đó cũng hoạt động. Tôi biết một số người sẽ không đồng ý với tôi, nhưng tùy thuộc vào loại trang web, tôi không nghĩ rằng đó là một thỏa thuận quá lớn để cho người dùng biết miễn là bạn thêm các biện pháp bảo mật bổ sung trong việc ngăn chặn các loại tấn công khác nhau.

24
ROFLwTIME

Việc thực hiện an toàn yêu thích của tôi về việc này được thực hiện bởi một ngân hàng tôi sử dụng. Nếu tôi nhập đúng tên người dùng của mình, nó sẽ hiện "Chào mừng Jimbob!" và sau đó nhắc tôi trả lời các câu hỏi bảo mật (nếu tôi chưa bao giờ đăng nhập từ trình duyệt này trên máy tính này), hãy đợi tôi trả lời chính xác các câu hỏi bảo mật và sau đó sẽ cho tôi xem hình ảnh/chú thích bảo mật và nhập mật khẩu của tôi. Nếu tôi nhập sai tên người dùng, tôi sẽ thấy một cái gì đó như "Chào mừng Bessie/Kareem/Randal!" trong đó tên hiển thị rất không phổ biến - mặc dù bạn sẽ luôn là cùng tên cho cùng một tên người dùng (tôi thường không chắc chắn giữa một hoặc hai tên người dùng; và tên sai luôn gọi tôi là Frenshelia). Tôi giả sử nó được triển khai như một loại băm không mật mã được áp dụng cho bất kỳ tên người dùng nào được nhập mà ánh xạ duy nhất đến một tên người dùng trong một danh sách dài các tên khá phổ biến. Điều này cho phép người dùng hợp pháp biết nếu họ nhập sai tên người dùng (vì ngay cả khi bạn có một tên không phổ biến như Bessie; rất có thể tên người dùng sai bạn đã đoán ngẫu nhiên bản đồ trở lại tên không phổ biến cụ thể của bạn), mà không làm cho mọi người cố gắng rõ ràng để tìm tài khoản ngẫu nhiên mà tên người dùng không tồn tại.

Bên cạnh: Tôi không đặc biệt thích phần câu hỏi bảo mật/phần hình ảnh bảo mật, dường như giáp với nhà hát an ninh. Kẻ tấn công tinh vi thực hiện một cuộc tấn công trung gian (MITM) (ví dụ: sau khi cài đặt chứng chỉ giả trong trình duyệt web của bạn và giả mạo DNS/ARP để trỏ yourbank.com đến địa chỉ IP của chúng) có thể đợi cho đến khi bạn thử đăng nhập vào trang web, sau đó đăng nhập tập lệnh tự động trên máy tính của họ vào trang thật, nhận câu hỏi bảo mật, hiển thị lại câu hỏi bảo mật đã chọn cho bạn, gửi lại câu trả lời cho trang web từ trình duyệt của họ, chờ để nhận được bảo mật hình ảnh, phục vụ lại hình ảnh bảo mật cho bạn và sau đó đợi bạn nhập mật khẩu từ đầu của họ tại thời điểm họ sử dụng mật khẩu để đăng nhập như bạn và làm những việc độc hại. Việc đưa ra các câu hỏi + hình ảnh làm cho quá trình trở nên khó khăn hơn việc thu thập tất cả các hình ảnh bảo mật cho nhiều tên người dùng bị tấn công bằng cách biến nó thành một cuộc tấn công phải được thực hiện trong thời gian thực và có thể để lại một chữ ký đáng ngờ .

18
dr jimbob

Các câu trả lời khác cung cấp cái nhìn sâu sắc về lý do bảo mật đằng sau hành vi này. Mặc dù chúng là chính xác, tôi khá chắc chắn rằng ít nhất một số trang web chỉ có thói quen ủy quyền được lập trình theo cách không thể biết điều gì sai - đăng nhập hoặc mật khẩu.

Truy vấn mẫu:

SELECT COUNT(*) FROM users WHERE login = 'john' AND hash = '2bbfcdf3f09ae8d700402f36913515cd'

Điều này sẽ trả về 1 khi thử ghi nhật ký thành công và nếu không có người dùng nào có tên đó hoặc người dùng này có mật khẩu khác nhau. Không có cách nào để nói phần nào của điều kiện thất bại. Vì vậy, khi nói đến việc hiển thị thông báo lỗi, lập trình viên chỉ cần thành thật nói với bạn rằng có gì đó không ổn và anh ta không thực sự chắc chắn chính xác đó là gì.

Cá nhân tôi đã thấy các truy vấn tương tự trong một số trang web dựa trên PHP vì vậy tôi khá chắc chắn rằng một phần lý do xuất phát từ cách quá trình xác thực được mã hóa, thực sự.

13
Dyppl

Tuy nhiên, có một kỹ thuật thú vị khác có thể được áp dụng để thực hiện user enumeration attack (và hơn thế nữa). Nó được gọi là Timing attack. Kẻ tấn công chỉ đơn giản là đo thời gian phản hồi cho yêu cầu xác thực và mức độ khác nhau giữa thông tin đăng nhập hợp lệ và không hợp lệ.

  1. Tấn công thời gian từ xa quy mô Nanosecond trên PHP Ứng dụng: Thời gian để thực hiện chúng một cách nghiêm túc?
    [.__.] http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-timing-attacks-on-php-appluggest-time-to-take-them-seriously/

  2. Một bài học về các cuộc tấn công thời gian
    [.__.] http://codahale.com/a-lesson-in-timing-attacks/

  3. So sánh chuỗi thời gian không đổi trong PHP để ngăn chặn các cuộc tấn công thời gian
    [.__.] https://codereview.stackexchange.com/questions/13512/constant-time-opes-comparision-in-php-to-prevent-timing-attacks

Quan điểm của tôi là một tin nhắn như vậy là không đủ nếu bạn muốn bảo mật ứng dụng của mình trước mối đe dọa này.

8
Charlie Rudenstål

Lý do bảo mật đằng sau nó là nếu không, việc tìm tên người dùng hợp lệ trở nên dễ dàng hơn rất nhiều.

5
Lucas Kauffman

Ngoài tất cả các câu trả lời tuyệt vời đã được đưa ra, có một nguyên tắc bảo mật chung nói rằng bạn không nên cung cấp thông tin không mong muốn cho người dùng trái phép. I E. nếu bạn có lựa chọn trả lời "dữ liệu xác thực của bạn không hợp lệ" hoặc giải thích phần nào không hợp lệ - bạn nên luôn luôn chọn phần trước. Một số cuộc tấn công mật mã rất khó chịu dựa trên lượng thông tin lỗi nhỏ nhất do việc triển khai cố gắng là "hữu ích" - xem Cuộc tấn công của Padding Oracle . Vì vậy, tốt nhất là bạn luôn luôn chọn một chút thông tin có thể được tiết lộ cho thực thể trái phép - nghĩa là, nếu kết hợp tên người dùng/mật khẩu của anh ta không tốt, bạn luôn trả lời "tên người dùng/mật khẩu không tốt" và không bao giờ tiết lộ nữa dữ liệu. Ngay cả trong trường hợp cụ thể (như gmail nơi tên người dùng là công khai) thì điều đó không quan trọng, đó là một cách tốt để áp dụng theo mặc định.

5
StasM

Giả sử bạn nhập tên người dùng ngẫu nhiên và mật khẩu ngẫu nhiên như nhau (chỉ cần lưu ý mật khẩu bạn nhập). Bây giờ mật khẩu có thể phổ biến trong số n người dùng. Vì vậy, nếu trang web nói mật khẩu là chính xác ... thì bạn sẽ biết điều gì tiếp theo .. tình trạng lộn xộn giữa những người dùng chính hãng vì việc lấy tên đăng nhập khá dễ dàng.

4
aayush anand

Cung cấp câu trả lời mơ hồ rất hữu ích để ngăn chặn liệt kê người dùng tấn công.

Trong một số trường hợp, kẻ tấn công không cần phải thỏa hiệp tài khoản người dùng. Thông tin mà người dùng có tài khoản là đủ mà không có hành động nào khác. Ví dụ: thông tin có giá trị cho thương mại mà khách hàng của họ có tài khoản trên cửa hàng web cạnh tranh.

4
Jakub Šturc

Tôi đánh giá cao các câu trả lời khác nhau ở trên vì họ nói nhiều nhất nhưng đôi khi Ứng dụng cũng không biết UserName hoặc Mật khẩu sai là gì. Trong trường hợp xác thực dựa trên mã thông báo đặc biệt để triển khai SSO (Đăng nhập một lần), ví dụ: Trình quản lý truy cập IBM Tivoli ứng dụng của bạn nhận được mã thông báo thành công hoặc bị lỗi trở lại.

4
Niks

nếu thông tin đăng nhập là một địa chỉ email, thật dễ dàng để biết rằng một người đã đăng ký tại một trang web - Tôi có thể không muốn điều đó >> Đôi khi mọi người sử dụng mật khẩu thực của tài khoản email cho các trang web mà họ đăng ký khi họ sử dụng id email làm tài khoản đăng nhập :)

3
Verena Haunschmid