2011-11-18 27 views
5

Từ nhiều bài đăng tôi đã xem trên trang web, thông tin đăng nhập được thực hiện bởi AJAX hoặc các biểu mẫu truyền thống cũng an toàn như nhau. (Lại: Login/session cookies, Ajax and securityAjax login and javascript cookies, is this secure?)Nhúng băm trong cuộc gọi đăng nhập AJAX, bảo mật hơn?

Câu hỏi của tôi (s) là/là:

  1. Nếu tôi băm mật khẩu của người dùng (thông qua client-side/javascript băm thư viện) trước khi tôi gửi nó đến máy chủ , tôi có tăng cường an ninh từ những người nới lỏng?

  2. Nếu tôi đặt mã thông báo biểu mẫu (dựa trên ngẫu nhiên, dựa trên thời gian khác), có bao gồm các cuộc tấn công CSRF không?

  3. Tôi có tất cả các căn cứ của mình được bao trả sau tất cả những điều này không? Biểu mẫu này có an toàn không?
+1

Sử dụng SSL nếu bạn cần gửi mật khẩu (và nếu có thể cho mọi thứ khác ngoài cookie có phiên đăng nhập). – Thilo

Trả lời

5

Thực ra đây có thể là vấn đề bảo mật lớn. Lý do tại sao mật khẩu được băm là một phương tiện lập kế hoạch thất bại. Kẻ tấn công có thể truy cập vào kho dữ liệu (tiêm sql) và sau đó lấy băm. Nếu bạn chỉ đăng nhập bằng băm, thì kẻ tấn công sẽ không phải bẻ khóa băm đã được phục hồi để truy cập vào ứng dụng.

Tấn công phát lại cũng là một vấn đề. Nếu tôi sniff băm trong quá trình xác thực, những gì ngăn tôi từ chỉ phát lại yêu cầu đó để xác thực?

Các giao thức sử dụng chức năng thông báo xác thực cung cấp cho khách hàng một nonce, được sử dụng làm muối một lần. Xác thực NTLM SMB của Microsoft là một ví dụ tốt, nhưng nó đã có a lot of problems.

SỬ DỤNG SSL và không chỉ để đăng nhập. OWASP A9 nói rằng id phiên không bao giờ bị rò rỉ trên kênh không an toàn. Sau khi tất cả những người quan tâm về mật khẩu nếu bạn chỉ cần tràn các thông tin xác thực thực một vài phần nghìn giây sau đó.

Hầu hết mọi người không thực hiện bảo vệ CSRF để đăng nhập. Sau khi tất cả những kẻ tấn công sẽ phải biết mật khẩu ngay từ đầu, vì vậy "phiên cưỡi" là một điểm tranh luận.

+0

Chỉ vì tò mò, nếu bạn sử dụng mã hóa khóa công khai trên mật khẩu trước khi gửi, và sau đó giải mã mật khẩu trên máy chủ bằng khóa riêng phù hợp, điều đó có tốt hơn không? – Esailija

+0

@Esailija Mật mã không đối xứng có vấn đề riêng của nó, chẳng hạn như các cuộc tấn công phát lại và thiếu IV. Nhưng quan trọng hơn nếu bạn không bảo vệ id phiên, thì bạn không bảo vệ được gì cả. Bất kỳ kẻ tấn công nào đánh hơi dây sẽ có toàn quyền truy cập. – rook

+0

Ah yeah, nên đọc câu trả lời của bạn với nhiều suy nghĩ hơn. Tôi hoàn toàn bỏ lỡ phần cuối của đoạn thứ ba ... cảm ơn vì đã trả lời. – Esailija

0

Nếu kẻ tấn công biết bạn đang sử dụng băm gì thì có thể bẻ khóa. Và nếu bạn muốn thêm muối, bạn phải gửi nó cho trình duyệt và kẻ tấn công có thể chặn nó. Sử dụng thời gian như muối cũng sẽ không hiệu quả vì chỉ có một lượng thời gian tương đối ngắn để họ có thể giải quyết điều đó.

+0

"Hashing" (trái với mã hóa) thường không thể đảo ngược. –

+0

@DavidGelhar Cảm ơn, tôi đã thay đổi từ ngữ đó là một sự lựa chọn nghèo nàn của các từ về phía tôi. – qw3n

+1

@ David Gelhar anh ta có nghĩa là một cuộc tấn công tầm thường. John the ripper, hoặc rainbowcrack nên làm các trick. – rook

1

Một chút sang một bên, nhưng trong câu trả lời cho câu hỏi 3. KHÔNG! Cũng nên nhớ rằng AJAX và các biểu mẫu chuẩn cũng chỉ là không an toàn với nhau.

Triển khai xác thực bảo mật là khó. Trừ khi bạn đang làm nó như là một bài tập học thuật, tôi sẽ khuyên bạn nên sử dụng thư viện được cung cấp bởi khuôn khổ của bạn, nếu bạn đủ may mắn để có một tốt nhất.

Bạn cũng sẽ cần xem xét những thứ như sau, v.v.

  • Triển khai id phiên ngẫu nhiên và không phù hợp để sử dụng trong cookie phiên.
  • Không cho phép sử dụng id phiên.
  • Khi quyền hoặc thông tin xác thực được thay đổi (ví dụ: do người dùng hiện đã đăng nhập hoặc đăng xuất) thì sẽ làm mất hiệu lực ngay lập tức phiên và bắt đầu phiên mới.
  • Cung cấp tính năng đăng xuất và đảm bảo làm mất hiệu lực phiên khi đăng xuất.
  • Đặt cookie thành HttpOnly -Preferably HTTPS và alo đặt cookie để chỉ bảo mật.
  • Cân nhắc việc hạn chế hiệu lực của phiên để bao gồm việc kiểm tra một số thông tin khác giúp phù hợp với người dùng, ví dụ: đại lý người dùng.
  • Luôn hết hạn phiên sau khi không sử dụng và không triển khai "giữ cho tôi đăng nhập" bằng cách kết nối lại người dùng với phiên http cũ của họ.
  • Đảm bảo 2 phiên không thể có cùng một id phiên tại cùng một thời điểm
  • Đảm bảo rằng tất cả dữ liệu phiên bị hủy khi phiên không hợp lệ. Một người dùng mới sắp ra mắt, có thể xảy ra khi được gán một id phiên đã được sử dụng trước đó. Phiên mới này không được có quyền truy cập vào dữ liệu phiên đã được đặt trước đó đối với id phiên đó.
+0

Điều này thật tuyệt! "Đảm bảo 2 phiên không thể có cùng một id phiên cùng một lúc" được tích hợp trong hàm session_start() của PHP không? –

+1

@JosephSzymborski yes. Bạn có thể thấy điều này thú vị lại php http://phpsec.org/projects/guide/4.html – Cheekysoft

Các vấn đề liên quan