Làm cách nào để gửi mật khẩu thuần văn bản bằng AJAX?

Question

Có thể tiêu đề bị phân tán kém nhưng không thể nghĩ ra cách tốt hơn để nói nó.

Tôi đang làm việc trên hệ thống đăng nhập vào lúc này (không có gì chính thức, chỉ thử nghiệm) và đang lên kế hoạch sử dụng PHPLiveX (thư viện AJAX) cho một số tính năng. Về cơ bản bạn tạo ra một số hàm PHP mà sau đó được gọi thông qua JavaScript. Bạn có thể thêm các tham số (getElementById) vào JavaScript được chuyển giao cho hàm PHP. Điều tôi thực sự muốn biết là liệu có an toàn khi chỉ gọi hàm từ JavaScript mà không mã hóa mật khẩu trước, sau đó cho phép hàm PHP mã hóa nó (SHA256 trong trường hợp này). Dữ liệu được chuyển qua AJAX có bị chặn không? Nếu vậy thì khả năng này là như thế nào?

Answer 1

Không hơn hoặc ít an toàn hơn so với một yêu cầu HTTP POST bình thường do một trình duyệt (như trong từ một <form>)

Các "sửa chữa" cho việc này là như nhau "sửa chữa" cho phi AJAX yêu cầu - sử dụng SSL.

Answer 2

Cuộc gọi AJAX chỉ là yêu cầu HTTP đơn giản.

Nó hoạt động như yêu cầu HTTP thông thường và cũng đi kèm với tất cả lợi thế và bất lợi của nó. Nó không an toàn hơn.

Để làm cho AJAX của bạn gọi an toàn, có một số cách bạn có thể thử:

1. Sử dụng SSL. SSL sẽ mã hóa tin nhắn giữa người dùng và máy chủ của bạn. Điểm bất lợi của SSL là bạn sẽ phải trả thêm phí cho các chứng chỉ SSL hợp lệ. Chứng chỉ SSL không hợp lệ trong khi sử dụng được, không cung cấp cùng một mức độ bảo đảm bảo mật cho người dùng.
2. Mã hóa các yêu cầu trước khi được gửi, phía máy khách. Ví dụ: mật khẩu của người dùng băm trước khi được gửi qua mạng. Hầu hết thời gian, bạn không cần mật khẩu văn bản thuần túy của người dùng. Điều này không thể sử dụng được khi người dùng không cho phép chạy tập lệnh phía máy khách.
3. Ngoài các thông tin gây hiểu lầm phổ biến mà POST an toàn hơn GET, nó không phải là. Cả hai đều đều mở cho kẻ tấn công để xem.

Answer 3

Cho dù bạn gửi mật khẩu qua AJAX hay thông qua biểu mẫu thông thường, nó vẫn được gửi qua yêu cầu HTTP POST (hy vọng). Vì vậy, bạn không thêm hoặc loại bỏ bất cứ điều gì bảo mật khôn ngoan.

Cách duy nhất để ngăn người khác chặn mật khẩu của bạn là sử dụng SSL (thông qua AJAX hay không).

Answer 4

Mật khẩu văn bản thuần được truyền qua AJAX sẽ an toàn như mật khẩu được truyền qua một bài đăng HTTP bình thường. Đó là để nói AJAX sử dụng HTTP và do đó có thể bị chặn và đánh hơi. Đặt cược tốt nhất của bạn là sử dụng HTTPS (SSL).

Để đọc thêm về AJAX và an ninh tôi khuyên bạn nên các bài đọc sau

• Top 10 Ajax Security Holes and Driving Factors
• Ajax security holes and how to fill them

Answer 5

Đây chỉ là an toàn như có một hình thức đăng nhập mà không được bảo đảm SSL được gửi qua dây, giống như hầu hết các diễn đàn ở đó!

Answer 6

Nó không an toàn. Không gửi mật khẩu không được mã hóa. Rất có khả năng chúng sẽ bị chặn tại một thời điểm nào đó bạn sẽ gặp phải một vấn đề lớn.

Dưới đây là ví dụ về video chụp mật khẩu telnet. Telnet gửi trong văn bản thuần túy và điều này minh họa độc đáo vấn đề chính bạn có nếu bạn thậm chí nghĩ đến việc này. Bất kỳ kiddie kịch bản hai bit nào cũng có thể lấy một mật khẩu văn bản thuần túy nhanh hơn bạn có thể "Ôi Chúa ơi, cơ sở dữ liệu của tôi đi đâu?"

Answer 7

Đảm bảo mục tiêu cuộc gọi AJAX của bạn là một trang HTTPS: // đáng tin cậy và bạn đã bảo đảm an toàn như mọi thông tin gửi khác của cùng một thông tin mà phần còn lại của ứng dụng đang thực hiện. Hầu hết các thư viện/khung công tác không giới hạn bạn chỉ với HTTP: // cho các cuộc gọi AJAX của bạn.

Answer 8

Bạn đang gửi nó rõ ràng, vì vậy bất kỳ ai có đánh hơi/nghe/etc mạng của khách hàng sẽ có thể dễ dàng nhìn thấy mật khẩu. Cuộc gọi AJAX chỉ là một tin nhắn HTTP cũ đơn giản. Nếu bạn muốn thấy điều này trong hành động, hãy sao chép wireshark và tự yêu cầu. Bạn sẽ có thể thấy mật khẩu trong gói HTTP.

Answer 9

Có thể đọc được. Giống như mọi thứ khác mà không có loại bảo mật nào đó (Xem SSL)

Để tự mình xem một công cụ như WireShark khi thực hiện các lệnh AJAX.

Có khả năng như thế nào? Không phải rất, nhưng mật khẩu của người dùng có thể sẽ được lưu trong các tệp nhật ký của một ai đó bằng văn bản thuần túy. Nếu ai đó cuối cùng tìm thấy nó, thì đó có thể là tin xấu. Trở lại trường đại học, lớp mạng của tôi có quyền truy cập vào một số bộ định tuyến (bán) ưa thích. Chúng tôi đã có bài tập nơi chúng tôi đăng ký tài khoản trên các trang web ngẫu nhiên. Như chúng tôi đã làm điều này, chúng tôi nhận thấy một số điều rất đáng sợ trên các tệp nhật ký trong các bộ định tuyến. Đây là một công cụ mở mắt để tôi suy nghĩ về cách mọi giao tiếp được theo dõi và hầu như có thể đăng nhập ở đâu đó.

Answer 10

Như những người khác đã đề cập, không còn nguy hiểm hơn việc gửi một bài đăng HTTP từ một biểu mẫu. Trong thực tế, đó là điều rất giống nhau.

Nhưng nếu HTTPS không phải là tùy chọn, bạn luôn có thể sử dụng lược đồ thách thức/phản hồi qua kết nối không được mã hóa. Về cơ bản, nó hoạt động như sau:

• Máy chủ có một SHA (hoặc bất kỳ thuật toán băm nào bạn thích) băm mật khẩu của người dùng.
• Khách hàng có mật khẩu.
• yêu cầu khách hàng (sử dụng mã hóa AJAX) mà máy chủ gửi một thách thức (một chuỗi ngẫu nhiên của byte; nhân vật cũng tốt.)
  
• Server tạo ra một thách thức và là một thách thức ID, và lưu nó với thời hạn.
• Khách hàng sẽ nhận được ID thách thức và thách thức.
• Khách hàng băm mật khẩu bằng SHA.
• Khách hàng băm băm kết quả với thử thách được thêm vào theo một cách nào đó.
• Khách hàng gửi ID thử thách (không phải là bản thân thử thách) và mã băm kết quả thứ hai.
• Máy chủ tra cứu thử thách bằng ID nếu nó tồn tại và chưa hết hạn.
• Máy chủ gắn thêm thách thức vào băm mật khẩu được lưu trữ và tạo một băm bằng cách sử dụng cùng một lược đồ như ứng dụng khách.
• Máy chủ so sánh giá trị băm của nó với ứng dụng khách.Nếu nó giống nhau, người dùng được xác thực.

Nó thực sự khá đơn giản để thiết lập khi bạn có ý tưởng. Wikipedia có một số thông tin bổ sung về nó.

EDIT: Tôi nhận thấy rằng tôi đã quên đề cập đến việc xác thực có thành công hay không. Việc cung cấp cho khách hàng nhiều nỗ lực trên một thử thách có thể dẫn đến các vấn đề về bảo mật.

Answer 11

Như đã đề cập, SSL là giải pháp tốt nhất ở đây. Tuy nhiên, bạn có thể băm mật khẩu ở phía máy khách. Nếu bạn google cho nó, bạn sẽ tìm thấy nhiều triển khai javascript của md5.

Answer 12

các bạn lo lắng cho tôi. SSL không bảo vệ chống lại cuộc tấn công MITM nhiễm độc ARP. Nó sẽ gây tử vong khi tôn thờ SSL như các bạn. Bạn phải có một cách để mã hóa mật khẩu ở phía máy khách trước khi nó làm cho thậm chí một hop hoặc thậm chí một hacker mới làm quen sẽ có thể chặn mật khẩu trong văn bản thuần túy

Answer 13

Người ta cũng phải rất ý thức về các lỗ hổng bảo mật tiềm ẩn khi xây dựng một ứng dụng sử dụng Ajax.

Trang web sau có một số thông tin thực sự tốt liên quan đến Ajax và XSS hay XSRF tấn công http://www.isecpartners.com/files/isec-attacking_ajax_applications.bh2006.pdf

Đừng quên rằng khi bạn thực hiện một chức năng từ xa truy cập đến một cuộc gọi javascript, người dùng chỉ có thể đoán chức năng gọi và sửa đổi nó để thực hiện đấu thầu của mình.