Làm thế nào để gửi mật khẩu một cách an toàn qua HTTP?

Nếu trên màn hình đăng nhập, người dùng gửi biểu mẫu có tên người dùng và mật khẩu của mình, mật khẩu sẽ được gửi ở dạng văn bản thuần túy (ngay cả với POST, hãy sửa cho tôi nếu tôi sai).

Vì vậy, câu hỏi đặt ra là đâu là cách phù hợp để bảo vệ người dùng và mật khẩu của mình trước bên thứ ba, những người có thể đang nghe trộm dữ liệu liên lạc?

Tôi biết rằng HTTPS là cách giải quyết vấn đề, nhưng có cách nào để đảm bảo ít nhất một mức độ bảo mật nào đó bằng giao thức HTTP tiêu chuẩn (yêu cầu POST) không? (có thể sử dụng javascript theo một cách nào đó)

CHỈNH SỬA Tôi có thể đã bỏ sót một số điều quan trọng.

Những gì tôi đã nói về một trang - đó là trang đăng nhập do PHP tạo ra, tất nhiên được gửi đến người dùng trong yêu cầu HTTP GET dưới dạng tệp HTML. Không có kết nối (@Jeremy Powel) nào được thiết lập giữa máy chủ và máy khách nên tôi không thể tạo giao thức bắt tay như vậy. Và tôi muốn toàn bộ quá trình minh bạch với người dùng - anh ta muốn gửi mật khẩu chứ không phải xử lý mật mã.

Cảm ơn.

Sử dụng HTTP với SSL sẽ làm cho cuộc sống của bạn dễ dàng hơn nhiều và bạn có thể yên tâm, những người rất thông minh (ít nhất cũng thông minh hơn tôi!) Đã xem xét kỹ lưỡng phương pháp giao tiếp bí mật này trong nhiều năm.

Xác thực an toàn là một chủ đề rộng lớn. Tóm lại, như @ jeremy-powell đã đề cập, luôn ưu tiên gửi thông tin đăng nhập qua HTTPS thay vì HTTP. Nó sẽ làm mất đi rất nhiều vấn đề đau đầu liên quan đến bảo mật.

Ngày nay, chứng chỉ TSL / SSL khá rẻ. Trên thực tế, nếu bạn không muốn tốn tiền thì có letsencrypt.org - Cơ quan cấp chứng chỉ tự động miễn phí .

Bạn có thể tiến thêm một bước nữa và sử dụng caddyserver.com gọi letsencrypt trong nền.

Bây giờ, khi chúng ta đã sử dụng được HTTPS ...

Bạn không nên gửi thông tin đăng nhập và mật khẩu qua tải trọng ĐĂNG hoặc tham số GET. Thay vào đó, hãy sử dụng tiêu đề Ủy quyền (Lược đồ xác thực quyền truy cập cơ bản), được xây dựng như sau:

• Tên người dùng và mật khẩu được kết hợp thành một chuỗi được phân tách bằng dấu hai chấm, ví dụ: tên người dùng: mật khẩu
• Chuỗi kết quả được mã hóa bằng biến thể RFC2045-MIME của Base64, ngoại trừ không giới hạn ở 76 ký tự / dòng.
• Sau đó, phương thức ủy quyền và một khoảng trắng tức là "Cơ bản" được đặt trước chuỗi được mã hóa.

nguồn: Wikipedia: Tiêu đề ủy quyền

Nó có vẻ hơi phức tạp, nhưng không phải vậy. Có rất nhiều thư viện tốt sẽ cung cấp chức năng này cho bạn.

Có một vài lý do chính đáng để bạn nên sử dụng tiêu đề Ủy quyền

1. Đó là một tiêu chuẩn
2. Nó rất đơn giản (sau khi bạn học cách sử dụng chúng)
3. Nó sẽ cho phép bạn đăng nhập ở cấp URL, như thế này: https://user:password@your.domain.com/login(Ví dụ : Chrome sẽ tự động chuyển nó thành Authorizationtiêu đề)

QUAN TRỌNG:
Như @zaph đã chỉ ra trong nhận xét của anh ấy bên dưới, việc gửi thông tin nhạy cảm dưới dạng truy vấn GET không phải là ý kiến ​​hay vì rất có thể nó sẽ xuất hiện trong nhật ký máy chủ.

Bạn có thể sử dụng sơ đồ phản hồi thách thức. Giả sử cả máy khách và máy chủ đều biết một bí mật S. Sau đó, máy chủ có thể chắc chắn rằng máy khách biết mật khẩu (mà không cho nó đi) bằng cách:

1. Máy chủ gửi một số ngẫu nhiên, R, cho máy khách.
2. Máy khách gửi H (R, S) trở lại máy chủ (trong đó H là một hàm băm mật mã, như SHA-256)
3. Máy chủ tính toán H (R, S) và so sánh nó với phản hồi của máy khách. Nếu chúng khớp, máy chủ biết máy khách biết mật khẩu.

Biên tập:

Có một vấn đề ở đây với sự mới mẻ của R và thực tế là HTTP không trạng thái. Điều này có thể được xử lý bằng cách yêu cầu máy chủ tạo một bí mật, gọi là Q, mà chỉ máy chủ biết . Sau đó, giao thức diễn ra như thế này:

Cần lưu ý, vì máy khách không thể giả mạo H (R, Q) nên H (R, Q) hoạt động như một cookie (và do đó có thể được triển khai thực sự như một cookie).

Chỉnh sửa khác:

Chỉnh sửa trước đó đối với giao thức không chính xác vì bất kỳ ai đã quan sát H (R, Q) dường như có thể phát lại nó với hàm băm chính xác. Máy chủ phải nhớ R không còn mới. Tôi đang xem câu trả lời này nên các bạn có thể chỉnh sửa câu trả lời này và tìm ra điều gì đó tốt.

Nếu máy chủ web của bạn cho phép hoặc bạn sẽ cần xử lý dữ liệu nhạy cảm, thì hãy sử dụng HTTPS. (Nó thường được yêu cầu bởi luật pháp afaik).

Ngược lại nếu bạn muốn thực hiện điều gì đó qua HTTP. Tôi sẽ làm một cái gì đó như thế này.

1. Máy chủ nhúng khóa công khai của nó vào trang đăng nhập.
2. Khách hàng điền biểu mẫu đăng nhập và bấm gửi.
3. Một yêu cầu AJAX lấy dấu thời gian hiện tại từ máy chủ.
4. Tập lệnh phía máy khách nối các thông tin xác thực, dấu thời gian và một muối (được băm từ dữ liệu tương tự, ví dụ: chuyển động chuột, sự kiện nhấn phím), mã hóa nó bằng khóa công khai.
5. Gửi kết quả băm.
6. Máy chủ giải mã hàm băm
7. Kiểm tra xem dấu thời gian có đủ gần đây không (chỉ cho phép cửa sổ ngắn 5-10 giây). Từ chối đăng nhập nếu dấu thời gian quá cũ.
8. Lưu trữ băm trong 20 giây. Từ chối cùng một băm để đăng nhập trong khoảng thời gian này.
9. Xác thực người dùng.

Vì vậy, theo cách này, mật khẩu được bảo vệ và không thể phát lại cùng một băm xác thực.

Về tính bảo mật của mã thông báo phiên. Khó hơn một chút. Nhưng có thể khiến việc sử dụng lại mã thông báo phiên bị đánh cắp khó hơn một chút.

1. Máy chủ đặt một cookie phiên bổ sung chứa một chuỗi ngẫu nhiên.
2. Trình duyệt sẽ gửi lại cookie này vào yêu cầu tiếp theo.
3. Máy chủ kiểm tra giá trị trong cookie, nếu nó khác thì nó sẽ hủy phiên, nếu không thì tất cả đều ổn.
4. Máy chủ đặt lại cookie với văn bản khác.

Vì vậy, nếu mã thông báo phiên bị đánh cắp và một yêu cầu được gửi bởi người khác, thì theo yêu cầu tiếp theo của người dùng ban đầu, phiên sẽ bị hủy. Vì vậy, nếu người dùng tích cực duyệt trang web, nhấp vào các liên kết thường xuyên, thì kẻ trộm sẽ không đi xa với mã thông báo bị đánh cắp. Lược đồ này có thể được củng cố bằng cách yêu cầu một xác thực khác cho các hoạt động nhạy cảm (như xóa tài khoản).

CHỈNH SỬA: Xin lưu ý rằng điều này không ngăn chặn các cuộc tấn công MITM nếu kẻ tấn công thiết lập trang riêng của họ với khóa công khai khác và các yêu cầu proxy đến máy chủ. Để bảo vệ khỏi điều này, khóa công khai phải được ghim trong bộ nhớ cục bộ của trình duyệt hoặc trong ứng dụng để phát hiện các loại thủ thuật này.

Về cách triển khai: RSA có lẽ là thuật toán được biết đến nhiều nhất, nhưng nó khá chậm đối với các khóa dài. Tôi không biết việc triển khai PHP hoặc Javascript sẽ nhanh như thế nào. Nhưng có lẽ có một thuật toán nhanh hơn.

Tôi sẽ sử dụng hệ thống trao đổi khóa Diffie-Hellman phía máy chủ và phía máy khách với AJAX hoặc gửi nhiều biểu mẫu (tôi khuyên bạn nên gửi trước), mặc dù tôi không thấy bất kỳ triển khai tốt nào của hệ thống đó trên internet. Hãy nhớ rằng thư viện JS luôn có thể bị hỏng hoặc bị thay đổi bởi MITM. Lưu trữ cục bộ có thể được sử dụng để giúp chống lại điều này, ở một mức độ nào đó.

Bạn có thể sử dụng SRP để sử dụng mật khẩu an toàn qua một kênh không an toàn. Ưu điểm là ngay cả khi kẻ tấn công đánh hơi thấy lưu lượng truy cập hoặc xâm phạm máy chủ, chúng không thể sử dụng mật khẩu trên một máy chủ khác. https://github.com/alax/jsrp là một thư viện javascript hỗ trợ mật khẩu bảo mật qua HTTP trong trình duyệt hoặc phía máy chủ (thông qua nút).

HTTPS rất mạnh vì nó sử dụng mật mã không đối xứng. Loại mật mã này không chỉ cho phép bạn tạo một đường hầm được mã hóa mà còn có thể xác minh rằng bạn đang nói chuyện với đúng người chứ không phải tin tặc.

Đây là mã nguồn Java sử dụng mật mã không đối xứng RSA (được PGP sử dụng) để giao tiếp: http://www.hushmail.com/services/downloads/

bạn có thể sử dụng ssl cho máy chủ của mình, có dự án miễn phí cho ssl như letsencrypt https://letsencrypt.org/

Sử dụng https có vẻ là lựa chọn tốt nhất ở đây (hiện nay chứng chỉ không đắt như vậy). Tuy nhiên, nếu http là một yêu cầu, bạn có thể sử dụng một số mã hóa - mã hóa nó ở phía máy chủ và giải mã trong trình duyệt của người dùng (gửi khóa riêng).

Chúng tôi đã sử dụng điều đó trong khi triển khai safevia.net - mã hóa được thực hiện ở phía máy khách (người gửi / người nhận), vì vậy dữ liệu người dùng không có sẵn trên mạng cũng như lớp máy chủ.