Đăng nhập mà không có HTTPS, làm thế nào để bảo mật?

Đối với ứng dụng web, khi HTTPS không có sẵn như một biện pháp bảo mật, liệu có thể vẫn đảm bảo an toàn cho việc đăng nhập không? Ví dụ:

• Mã hóa thông tin đăng nhập, để thực hiện các cuộc tấn công lặp lại khó khăn?
• Bằng cách nào đó mã hóa mật khẩu đã gửi từ trường mật khẩu HTML?

Đặc biệt, tôi đang sử dụng CakePHP và cuộc gọi AJAX POST để kích hoạt xác thực (bao gồm tên người dùng và mật khẩu được cung cấp).

Cập nhật về sự cố:

• HTTPS không khả dụng. Giai đoạn = Stage. Nếu bạn không thích tình huống này, hãy coi đó là một câu hỏi lý thuyết.
• Không có yêu cầu rõ ràng, bạn có bất kỳ HTTP, PHP và trình duyệt nào (cookie, JavaScript, v.v.) cung cấp trong cuộc sống thực (không có mã nhị phân RSA kỳ diệu, plugin PGP).
• Câu hỏi đặt ra là, điều gì là tốt nhất, bạn có thể thoát khỏi tình huống này , điều đó tốt hơn là gửi bản rõ mật khẩu. Biết được nhược điểm của mỗi giải pháp như vậy là một điểm cộng.
• Mọi cải tiến tốt hơn mật khẩu thông thường đều được hoan nghênh. Chúng tôi không hướng đến giải pháp 100% l33tG0Dhx0r-proff. Khó bẻ khóa tốt hơn là khó hack, tốt hơn là đánh hơi tầm thường để lộ mật khẩu.

HTTPS hoàn toàn quan trọng trong việc duy trì kết nối an toàn giữa trang web và trình duyệt. Mạng wifi công cộng khiến người dùng gặp nhiều rủi ro , và khi được sử dụng đúng cách, HTTPS là công cụ duy nhất có thể bảo vệ tài khoản người dùng khỏi lỗ hổng này .

Nếu máy chủ của bạn không hỗ trợ HTTPS thì một dịch vụ như Cloudflare Universal SSL có thể được sử dụng để đảm bảo tất cả các trình duyệt kết nối với trang web của bạn bằng HTTPS, ngay cả khi máy chủ của bạn không hỗ trợ SSL / TLS . Kết nối giữa Cloudflare và trang web của bạn sẽ vẫn không được bảo vệ, nhưng dịch vụ Cloudflare này nhằm bảo vệ người dùng trước các mối đe dọa được tìm thấy trên mạng wifi công cộng. Từ quan điểm của một người kiểm tra thâm nhập, việc không cung cấp HTTPS rất đáng nghi ngờ, nếu bạn không cung cấp yêu cầu bảo mật cơ bản là phân phối lưu lượng truy cập, thì bạn còn thiếu những yêu cầu bảo mật nào khác? Chứng chỉ HTTPS có thể nhận được miễn phí bằng Let's Encrypt hoặc Start SSL , không có lý do chính đáng nào để không hỗ trợ HTTPS.

HTTPS quan trọng vì nó không chỉ là "mã hóa mật khẩu". Một vai trò quan trọng khác là nó phải ngăn người dùng đăng nhập vào một máy chủ độc hại đang mạo danh một máy chủ thực. Chỉ sử dụng một hệ thống để bảo vệ mật khẩu vẫn vi phạm OWASP A9 - Bảo vệ lớp truyền tải không đầy đủ vì bạn vẫn sẽ truyền thông tin đăng nhập phiên ở dạng văn bản thuần túy là tất cả những gì kẻ tấn công cần ( Firesheep ).

1. Không thể sử dụng mật mã dựa trên JavaScript để xây dựng một lớp truyền tải an toàn .

2. "Mã hóa thông tin đăng nhập": Nếu kẻ tấn công đánh hơi được lưu lượng truy cập, chúng sẽ có tên người dùng / mật khẩu văn bản thuần túy và sau đó chúng có thể đăng nhập bằng các thông tin đăng nhập mới này. (Phát lại tấn công)

3. "Bằng cách nào đó mã hóa mật khẩu được truyền": Sau khi người đó đăng nhập, kẻ tấn công có thể đánh hơi lưu lượng truy cập để lấy id phiên hợp lệ (cookie) và sau đó chỉ cần sử dụng điều này thay vì đăng nhập. Nếu toàn bộ phiên được bảo vệ bằng SSL / TLS thì Đây không phải là vấn đề.

Có những cuộc tấn công khác phức tạp hơn ảnh hưởng đến cả hệ thống này và cơ sở hạ tầng SSL hiện tại của chúng tôi. Cuộc tấn công SSLStrip đi vào chi tiết hơn. Tôi thực sự khuyên bạn nên xem bài nói chuyện Blackhat 2009 của Moxie Marlinspike , dẫn đến tiêu chuẩn HTTP-Nghiêm ngặt-Giao thông-Bảo mật .

Câu trả lời ngắn gọn là không có mã hóa điểm cuối SSL đến điểm cuối, không thể thực hiện điều đó một cách an toàn ...

Một trong những lý do chính cho điều này là bạn không thể sử dụng tiền điện tử an toàn trong trình duyệt. Xem tài liệu tham khảo này - Mật mã Javascript được coi là có hại .

Ngoài ra, không có cách nào để bạn có thể chắc chắn rằng nguồn của thông tin đăng nhập thực sự là người bạn đang nói chuyện. Có nghĩa là hoàn toàn không có cách nào mà không có SSL để chắc chắn rằng không có Cuộc tấn công giữa người nào đang diễn ra.

Vì vậy, không, bạn không thể làm điều đó.

Ngoài ra, thậm chí không thử. Nhận SSL. Bạn có thể nhận được chứng chỉ miễn phí. Máy chủ thường sẽ cung cấp cho bạn một IP chuyên dụng với giá vài $$$ mỗi tháng. Và nếu bạn thực sự quan tâm đến bảo mật, bạn sẽ sử dụng ít nhất một máy ảo có địa chỉ IP chuyên dụng.

Thậm chí, nếu cố gắng điều này sẽ tốt nhất là Bảo mật thông qua sự che khuất , và không có gì tồi tệ nhất. SSL là một vấn đề đã được giải quyết. Tại sao không sử dụng giải pháp đó. An ninh không phải là thứ để đoán. Sử dụng các kỹ thuật thích hợp. Đừng cố gắng phát minh ra của riêng bạn. Nó sẽ không hoạt động ...

Vì bạn không thể thực hiện SSL tại máy chủ web và bạn không phải là chuyên gia bảo mật, hãy tìm một dịch vụ xác thực an toàn hiện có mà bạn có thể sử dụng và để họ xử lý cả SSL và sự phức tạp của việc xử lý thông tin đăng nhập cho bạn.

Đặc biệt, tôi khuyên bạn nên sử dụng dịch vụ xác thực miễn phí của bên thứ ba, chẳng hạn như OpenID . Họ có các thư viện cho PHP bao gồm một thư viện cho CakePHP .

Chỉnh sửa: (về rủi ro)

Mặc dù việc sử dụng dịch vụ xác thực bảo mật của bên thứ 3 (sử dụng chính HTTPS) có thể giảm thiểu sự cố khi tự xác thực mà không sử dụng HTTPS (trên máy chủ của bạn), nhưng nó không hoàn toàn loại bỏ khả năng bị tấn công.

Hai cuộc tấn công phổ biến nhất sẽ là tấn công phát lại và chiếm quyền điều khiển phiên trong đó kẻ tấn công có thể sử dụng lại mã thông báo phiên đăng nhập chính hãng sau đó hoặc sử dụng mã phiên hợp lệ cho mục đích độc hại của riêng chúng.

Cuộc tấn công phát lại có thể được giảm thiểu bằng cách mã thông báo phiên hết hạn và tốt hơn là bằng cách sử dụng nonce để ngăn phát lại phiên và để giảm nguy cơ chiếm đoạt phiên. Với một nonce, một phiên hợp pháp sẽ tạo ra lỗi nếu bị xâm nhập thành công, vì nonce đã hết hạn (đã được sử dụng), vì vậy phiên của chính chúng không còn hợp lệ.

Nếu bạn không thể sử dụng HTTPS để mã hóa mã thông báo phiên trong khi được truyền đến và từ máy chủ của mình, bạn không thể ngăn chặn hoàn toàn các cuộc tấn công đang hoạt động như chiếm quyền điều khiển phiên hoặc tấn công man-in-the-middle . Điều này có thể được chấp nhận trong một số trường hợp, chẳng hạn như các trang web có cơ sở người dùng nhỏ để sử dụng phi thương mại.

Như bạn đã đề xuất, bạn có thể tạo một mã thông báo duy nhất mỗi khi trang được tạo. Mã thông báo tương tự đó sẽ cần được gửi lại cùng với dữ liệu biểu mẫu và không thể được sử dụng lại. Bạn cũng có thể giữ mật khẩu an toàn bằng cách sử dụng JavaScript để băm mật khẩu, nếu bạn có thể tin rằng nó được người dùng của bạn kích hoạt.

Tuy nhiên, chương trình này vẫn không an toàn. Kẻ tấn công vẫn có thể nhìn thấy mọi thứ đi qua dây. Họ có thể chặn mã thông báo và gửi phản hồi lại cho bạn trước khi người dùng thực hiện. Hoặc họ có thể chỉ đợi ai đó đăng nhập, lấy cắp thông tin đăng nhập của người đó (khi họ được gửi qua đường dây) và chỉ cần thực hiện yêu cầu đăng nhập của riêng họ sau này.

Điểm mấu chốt - bạn cần sử dụng HTTPS để đảm bảo trang web được an toàn.

Bạn có thể mã hóa mật khẩu bằng Javascript và giải mã nó trên máy chủ.

Tôi khuyên bạn nên tạo cặp khóa RSA trên máy chủ, gửi khóa công khai cùng với muối định thời đến trình duyệt, sau đó mã hóa mật khẩu, kết hợp với muối, sử dụng khóa công khai trong Javascript.

Bạn có thể tìm thấy một triển khai RSA trong Javascript tại đây

Bạn nên bao gồm cả địa chỉ IP và toàn bộ hedaer X-FORWARDED-FOR trong cookie xác thực để ngăn chặn hành vi trộm cắp cookie đằng sau proxy.

Nếu bạn đang xử lý dữ liệu nhạy cảm, bạn có thể tạo khóa AES ngẫu nhiên trong Javascript , sau đó gửi nó đến máy chủ cùng với mật khẩu được mã hóa bằng RSA.
Sau đó, bạn có thể làm cho toàn bộ ứng dụng sử dụng các yêu cầu AJAX được mã hóa từ một trang duy nhất và hoàn toàn không sử dụng cookie xác thực.

Lưu ý rằng không thể bảo vệ khỏi một cuộc tấn công man-in-the-middle đang hoạt động mà không có SSL. Kẻ tấn công đang hoạt động có thể thay thế hoàn toàn trang web của bạn bằng proxy của riêng mình và không có bất kỳ cách nào để chống lại điều đó. (Vì không thể có bất kỳ mã tốt nào được biết đến)

Bạn có thể sử dụng xác thực Thông báo HTTP , được hầu hết các trình duyệt hỗ trợ và không gửi mật khẩu rõ ràng qua dây.

Nhược điểm là hộp đăng nhập xấu xí được hiển thị bởi broswer. Nếu bạn thích gắn bó với các biểu mẫu, thì bạn có thể triển khai chính xác giao thức giống như HTTP Digest trong cách xác thực biểu mẫu của mình: gửi các trường ẩn có chứa lĩnh vực và thử thách, đồng thời yêu cầu khách hàng thêm JavaScript từ đầu vào và tính toán thông báo. Bằng cách này, bạn sẽ sử dụng một giao thức hoàn thiện nổi tiếng và đã được chứng minh, thay vì tự cuộn.

HTTP Digest chỉ yêu cầu các hoạt động băm.

Điều gì về Xác thực Thông báo HTTP ? Nó cung cấp bảo mật bằng tên người dùng băm MD5, mật khẩu và một nonce (trong số những thứ khác) trước khi gửi đến máy chủ. MD5 không thực sự an toàn, nhưng đó là một cách tốt để bảo mật đơn giản với HTTP.

Tất nhiên điều này không ngăn được tin tặc thay đổi tin nhắn ... nhưng nó bảo mật mật khẩu của bạn.

HTTPS có rất nhiều trường hợp sử dụng, hầu hết trong số đó được thiết kế để bảo vệ chống lại các cuộc tấn công của Người ở giữa. Bất cứ ai có tư duy của một hacker sẽ rùng mình khi nói với bạn rằng không có cách nào khác ngoài cách đã được thiết lập để đạt được điều gì đó. Thực tế là chỉ vì bạn sử dụng TLS (tiêu chuẩn mà HTTPS hiện đại sử dụng), không có nghĩa là bạn đang sử dụng nó tốt. Ngoài ra, chỉ sử dụng TLS không ngăn ai đó khai thác các điểm yếu đã biết. Cũng như bạn có thể đang tìm cách sáng tạo để bảo mật dữ liệu của mình, có những người đang tìm cách sáng tạo để khai thác các biện pháp bảo mật của bạn.

Vậy lam gi?

Trước hết, nếu bạn định bỏ qua TLS, sẽ rất hữu ích nếu bạn hiểu cách hoạt động của nó. Và đó là tất cả về một cái bắt tay.

Sau khi máy khách và máy chủ đã đồng ý sử dụng TLS, họ sẽ thương lượng kết nối trạng thái bằng cách sử dụng quy trình bắt tay. [7] Trong quá trình bắt tay này, máy khách và máy chủ đồng ý về các thông số khác nhau được sử dụng để thiết lập bảo mật của kết nối:

• Quá trình bắt tay bắt đầu khi khách hàng kết nối với máy chủ hỗ trợ TLS yêu cầu kết nối an toàn và trình bày danh sách các bộ mật mã được hỗ trợ (mật mã và hàm băm).
• Từ danh sách này, máy chủ chọn một mật mã và hàm băm mà nó cũng hỗ trợ và thông báo cho khách hàng về quyết định.
• Máy chủ sẽ gửi lại nhận dạng của nó dưới dạng chứng chỉ kỹ thuật số. [Mâu thuẫn] Chứng chỉ thường chứa tên máy chủ, tổ chức phát hành chứng chỉ đáng tin cậy (CA) và khóa mã hóa công khai của máy chủ.
• Máy khách có thể liên hệ với máy chủ đã cấp chứng chỉ (CA đáng tin cậy như trên) và xác nhận tính hợp lệ của chứng chỉ trước khi tiếp tục.
• Để tạo các khóa phiên được sử dụng cho kết nối an toàn, máy khách mã hóa một số ngẫu nhiên bằng khóa công khai của máy chủ và gửi kết quả đến máy chủ. Chỉ máy chủ mới có thể giải mã nó bằng khóa riêng của nó.
• Từ số ngẫu nhiên, cả hai bên tạo ra tài liệu chính để mã hóa và giải mã. [Mâu thuẫn] Điều này kết thúc quá trình bắt tay và bắt đầu kết nối an toàn, được mã hóa và giải mã bằng tài liệu chính cho đến khi kết nối đóng.

Nếu bất kỳ một trong các bước trên không thành công, bắt tay TLS không thành công và kết nối không được tạo.

Nguồn: Wikipedia

Vì vậy, nó có thể? Đúng. Tôi đã được dạy rằng bất cứ điều gì đều có thể. Nó có thể tốn kém, nhưng nó luôn luôn có thể.

Tôi muốn hoàn toàn tiết lộ rằng tôi KHÔNG phải là một chuyên gia bảo mật, chỉ là một người đam mê. Tôi không khuyên bạn nên thử điều này cho một dự án cấp sản xuất hoặc bất kỳ thứ gì khác ngoài bản chỉnh sửa của chính bạn. Bạn nên CHẮC CHẮN xem bài đăng này SẼ đưa ra lời giải thích tuyệt vời về những rào cản trong việc thiết lập giao thức bảo mật của riêng bạn.

Tuy nhiên, nếu bạn muốn tiếp tục, đây là một số suy nghĩ xuất hiện trong đầu bạn. Đây là những thực tế sẽ tồn tại bất kể bạn đã trực tiếp thực hiện dự án này.

• HTTPS được hỗ trợ bởi tất cả các trình duyệt hiện đại chính. Ngay cả với thực tế này, thời gian tải HTTPS chậm hơn HTTP thông thường. Nếu không có sản xuất rộng rãi, rất có thể việc triển khai thay thế của bạn sẽ an toàn hơn một chút trong khi chậm hơn đáng kể. Đây sẽ là một hạn chế của bất kỳ cách triển khai cây nhà lá vườn nào trừ khi bạn đang sử dụng các tính năng của trình duyệt, điều này giúp chúng ta quay trở lại việc sử dụng TLS, vốn là thứ mà HTTPS hiện đại sử dụng.

• Nếu bạn quản lý để mã hóa mật khẩu của mình mà không có TLS ở phía trình duyệt bằng cách sử dụng Javascript theo cách không thể đoán trước đến mức một cuộc tấn công MiTM sẽ khó xảy ra, đừng nghỉ ở đó. Bạn cũng nên bảo mật dữ liệu bạn gửi qua lại. Nếu không, mật khẩu được mã hóa thực sự không liên quan. Chắc chắn, kẻ tấn công có thể không biết mật khẩu của bobsmith109, nhưng anh ta không cần nó, bởi vì anh ta có thể đánh hơi mọi hoạt động trên mạng. Anh ấy biết bobsmith109 đăng nhập vào thời gian nào, có thể theo dõi IP của anh ấy và bất kỳ phần dữ liệu nhạy cảm nào khác mà bạn gửi qua lại.

• Bất kể bạn thực hiện các biện pháp bảo mật nào, đều có bảo mật theo chiều sâu. Vì vậy, một điều bạn có thể làm ngay là đảm bảo rằng bạn mã hóa dữ liệu của mình trong cơ sở dữ liệu đồng thời yêu cầu mật khẩu mạnh.

Tôi nhắc lại rằng tôi không phải là một chuyên gia bảo mật và thực sự không khuyến khích điều này như bất cứ điều gì khác ngoài việc thỏa mãn sự tò mò của bạn. Thật không thể tránh khỏi khi bạn có thể tạo ra một giải pháp thay thế khả thi cho TLS mà không cần một nhóm cực kỳ lớn các chuyên gia bảo mật đóng góp cho một dự án trong nhiều năm, nếu không muốn nói là nhiều thập kỷ, đó là những gì SSL / TLS có thể tự hào. Điều đó đang được nói, một điểm khởi đầu tốt nếu bạn chọn tiếp tục là xem xét mô hình bắt tay ở trên và xem cách bạn có thể triển khai phiên bản này mà không có TLS.

Tôi rất tiếc nếu không chia sẻ trong bài đăng của mình rằng hầu hết các rào cản trong đời thực đối với việc sử dụng HTTPS đang được tích cực chống lại. Một trong những chi phí lớn nhất - rất gần với việc trở thành vấn đề không phải vấn đề. Một tổ chức phát hành chứng chỉ miễn phí sẽ ra mắt vào Quý 2 năm 2015 được hỗ trợ bởi một số công ty lớn, bao gồm cả Mozilla và Akamai, để kể tên một số. Đây là một bài báo .

Đăng nhập mà không có HTTPS, làm thế nào để bảo mật?

Vì không có kênh an toàn nào giữa máy chủ và máy khách của bạn:

• bởi vì không có kênh an toàn, bất kỳ ai cũng có thể rình mò lưu lượng truy cập của bạn.
• bởi vì bất kỳ ai cũng có thể rình mò lưu lượng truy cập, bạn đang sẵn sàng cho một cuộc tấn công MITM.
• bởi vì bạn đang mở cuộc tấn công MITM, không có gì đảm bảo rằng khách hàng của bạn sẽ thấy một trang hợp pháp.
• bởi vì các trang không hợp pháp và trang của bạn có hiệu lực không được phục vụ (người ở giữa đang phân phát các trang), tất cả các thủ thuật được sử dụng phía máy chủ đều vô dụng.

Bạn có thể làm gì? Về mặt lý thuyết?

• cả máy khách và máy chủ đều cần sử dụng mã hóa để làm cho việc dò tìm / MITM ít bị ảnh hưởng hơn.
• giả sử bạn không thể bắt tay,
• giả sử khách hàng của bạn đã có khóa của bạn và biết cách nói những thứ vô nghĩa giống như máy chủ của bạn.
• làm thế nào về một số SSL qua HTTP nhưng được gói trong thông báo mã hóa base64 cho một số ngôn ngữ vô nghĩa?

Nhưng chờ đã ... Vì bạn đã nói không có nhị phân kỳ diệu hoặc plugin, thậm chí không phải RSA, tôi không biết liệu bất kỳ điều nào trong số này có thể lưu cho (một số khả năng rất yếu) mã hóa nội bộ hay không.

-

Bạn có thể cố gắng sao chép nó đến một thời điểm nào đó, bằng cách sử dụng mã hóa khóa công khai (có thể là GPG) và sử dụng bộ nhớ đệm của trình duyệt.

Đây không phải là thứ gì đó an toàn, thậm chí chỉ thiết lập SSL sẽ không đủ đối với những kẻ tấn công tinh vi, bạn cần phải sử dụng HSTS, ghim khóa công khai, v.v. để xem xét một trang web ngày nay an toàn .

Phần còn lại của câu trả lời chỉ là thức ăn cho suy nghĩ.

1. Tạo một cặp khóa công khai-riêng tư. Giữ riêng tư một cách an toàn.
2. Tạo tệp js chứa khóa công khai và một encrypthàm, tìm thuật toán mã hóa an toàn. Hàm này nên mã hóa một chuỗi nhất định (dạng tuần tự hóa) với một dấu thời gian bổ sung, để tránh bị tấn công sao chép.
3. Cung cấp tệp này với Cache-Control:public, max-age=31536000tiêu đề HTTP. Chúng tôi cố gắng giảm thiểu khi kẻ tấn công cố gắng thay thế tập lệnh. Tệp sẽ luôn được cung cấp từ bộ nhớ cache của trình duyệt.
4. Gửi tất cả các biểu mẫu qua Javascript, sử dụng encrypthàm. Cung cấp những thứ này với cùng một tiêu đề như trên.
5. Ở phía máy chủ, decryptdữ liệu, hãy kiểm tra dấu thời gian, nếu nó vẫn hợp lệ. Bạn có điều gì không, nếu không, hãy loại bỏ nó.
6. Tạo mã thông báo cookie chỉ có thể được sử dụng một lần trong một khoảng thời gian rất ngắn. Nếu kẻ tấn công chụp được một cookie, anh ta sẽ không có nhiều thời gian để thực hiện công việc. Tuy nhiên, nếu kẻ tấn công đủ nhanh, thì hắn có thể đăng xuất người dùng ban đầu.
7. Thay đổi cookie với mọi phản hồi. Nhưng sau đó bạn sẽ làm gì khi người dùng gửi nhiều yêu cầu cùng một lúc và sau đó họ đến theo thứ tự ngược lại? Cookie nào hợp lệ? Điều này tạo ra rất nhiều vấn đề với cái giá là cảm giác an toàn sai lầm.

Mọi người nghe sẽ không thể sử dụng dữ liệu qua lại và họ sẽ không thể thay đổi / chèn các tệp hiện có JS cho đến khi bộ nhớ cache hết hạn / người dùng xóa bộ nhớ cache. Tuy nhiên, bất kỳ kẻ tấn công tinh vi nào cũng có thể thay thế toàn bộ HTMLtệp sẽ loại bỏ tất cả các phép đo bảo mật mà tôi vừa đề cập. Nếu ít nhất bạn có thể phục vụ tệp / biểu mẫu này HTTPS, bạn có thể bỏ nó đi, đưa chúng lên trang github hoặc bất cứ thứ gì. Tuy nhiên, nếu bạn đặt tệp ở một số miền khác, thì bạn cần thiết lập CORSmiền nhận để miền này hoạt động.

Một lần thử khác

Mật khẩu một lần được gửi đến email.

1. Người dùng điền vào email của họ, nhấp vào một liên kết, sau đó sẽ gửi một liên kết đến email của họ cùng với một mã thông báo cho phép họ đăng nhập.
2. Người dùng nhấp vào liên kết
3. Máy chủ kiểm tra mã thông báo, đăng nhập người dùng.
4. Cuộn các cookie như ví dụ trước.

Nói chung, bất cứ điều gì bạn làm, nó không được bảo mật . Với một kẻ tấn công nhanh, tinh vi, không gì có thể cản đường.

Nhận SSL, nếu cơ sở hạ tầng không hỗ trợ, hãy thay đổi nó. Nếu người quản lý của bạn không tin vào SSL, hãy thuyết phục họ. Đừng tạo ra cảm giác an toàn giả tạo. Bảo vệ dữ liệu của người dùng, tùy thuộc vào vị trí của bạn, về mặt pháp lý, bạn được yêu cầu bảo vệ dữ liệu của người dùng.

Sau đó, hãy nói về cách làm cho một trang web an toàn với SSL.

Tạo một cặp khóa công khai / riêng tư bằng cách sử dụng mật mã không đối xứng.

Tạo khóa đối xứng trên máy chủ.

Gửi khóa công khai xuống phía máy khách.

Tạo một khóa ngẫu nhiên cho phía máy khách mật mã đối xứng.

Mã hóa khóa ngẫu nhiên đó bằng cách sử dụng phía máy khách khóa công khai.

Gửi khóa đã mã hóa đến máy chủ.

Máy chủ thực hiện như sau:

a. Giải mã khóa đối xứng ngẫu nhiên bằng khóa riêng.

b. Tạo mã thông báo có chứa khóa ứng dụng đã tạo.

c. Ký mã thông báo.

d. Mã hóa mã thông báo bằng khóa đối xứng của máy chủ.

e. Mã hóa mã thông báo đã được mã hóa bằng khóa do khách hàng tạo.

f. Gửi mã thông báo đã mã hóa xuống.

Khách hàng nhận được mã thông báo này và thực hiện những việc sau:

a. Giải mã mã thông báo bằng khóa mà nó đã tạo.

b. Lưu trữ mã thông báo đã giải mã.

c. Tại thời điểm này, mã thông báo được lưu trữ chỉ được mã hóa bằng khóa đối xứng của máy chủ.

Trên mọi từ máy khách đến máy chủ:

a. Mã hóa dữ liệu gửi đi bằng khóa do khách hàng tạo.

b. Gửi mã thông báo + dữ liệu được mã hóa

Trên mọi yêu cầu máy chủ nhận được:

a. Giải mã mã thông báo bằng khóa đối xứng của máy chủ.

b. Xác minh chữ ký.

c. Giải mã dữ liệu bằng cách sử dụng khóa do khách hàng tạo được lưu trữ trong mã thông báo.

Hãy xem "Giao thức mật khẩu từ xa an toàn" .

Thay vì tự mình lập công thức, hãy để tôi trích dẫn từ trang web của họ:

Giao thức Mật khẩu Từ xa An toàn thực hiện xác thực từ xa an toàn các mật khẩu ngắn mà con người có thể ghi nhớ và chống lại cả các cuộc tấn công mạng thụ động và chủ động.

và:

Giao thức [The] kết hợp các kỹ thuật của các bằng chứng không có kiến ​​thức với các giao thức trao đổi khóa không đối xứng và cung cấp hiệu suất được cải thiện đáng kể so với các phương pháp mở rộng tương đối mạnh để chống lại các cuộc tấn công của trình xác minh bị đánh cắp như Augmented EKE hoặc B-SPEKE.

Mặc dù Đại học Stanford không cung cấp các triển khai cho PHP và JavaScript, nhưng chúng liên kết với một số triển khai của bên thứ ba.

Một trong những liên kết đó dẫn đến "Clipperz" , là một trình quản lý mật khẩu trực tuyến. Nó cũng có sẵn dưới dạng phiên bản cộng đồng trên GitHub. Ở đó, họ lưu trữ "javascript-crypto-library" của họ , thực hiện giao thức và "trình quản lý mật khẩu" , chứa các phụ trợ được viết bằng PHP và Python.

Tôi không thể nói sẽ khó khăn như thế nào để trích xuất các phần mã liên quan, nhưng có thể bạn có thể sử dụng lại cách triển khai của chúng (nó được cấp phép theo AGPL).

Chỉnh sửa 2014/10/24:

Bài viết trên Wikipedia về SRP liệt kê thêm một số cách triển khai. Có liên quan cho PHP / JS:

• srp-client (JS)
• srp-6a-demo (PHP / JS)

Giải pháp tốt nhất mà tôi đã thấy cho các kết nối HTTP hơi an toàn là sử dụng triển khai Javascript của md5sum (hoặc một số hàm băm khác) để tránh truyền mật khẩu ở dạng bản rõ. Bạn có thể tạo một trình xử lý gửi kèm biểu mẫu trong Javascript để thay thế trường mật khẩu bằng một băm có giá trị ban đầu. Điều này bổ sung một lượng bảo mật khiêm tốn cho một kết nối không an toàn, nhưng dựa vào Javascript chạy trong trình duyệt để hoạt động bình thường.

Tôi đoán bạn quan tâm đến việc truyền mật khẩu an toàn đến máy chủ? Câu trả lời của tôi là: không truyền mật khẩu đến máy chủ :)

Trong thực tế, bạn không thể truyền bất cứ thứ gì từ trình duyệt (người dùng) đến máy chủ để xác thực người dùng, vì kẻ tấn công đang theo dõi lưu lượng truy cập http cũng sẽ có thể truyền lại dữ liệu và xác thực.

Đề nghị:

Giải pháp rõ ràng sẽ là sử dụng xác thực giao dịch một chiều, một lần bắt nguồn từ máy chủ; như một số giao dịch chỉ có thể được sử dụng một lần. Cuối cùng, bạn vẫn cần một kênh bảo mật để đồng bộ danh sách số giao dịch với người dùng.

Bạn có thể sử dụng trình xác thực nào đó của google , nhưng bạn cần một kênh an toàn để thiết lập các thông số ở cả hai bên. Nếu bạn coi email là an toàn, đó sẽ là một cách để thực hiện.

Tôi có cùng một vấn đề trên một hệ thống của tôi. Tôi đã thực hiện các bước để thử và tăng cường bảo mật mà không ảnh hưởng đến trải nghiệm người dùng với các cơ chế phức tạp. Điều tôi nhận thấy là đại đa số người dùng đã đăng nhập từ cùng một máy bằng cùng một trình duyệt, (nhưng không nhất thiết phải cùng một địa chỉ IP) hoặc từ một vài trình duyệt (ví dụ: máy tính để bàn hoặc thiết bị di động). Tôi quyết định có thể sử dụng cái này để xác định một mẫu.

1) Trong quá trình đăng ký, người dùng được yêu cầu có mật khẩu mạnh (để ngăn chặn các cuộc tấn công từ điển), câu hỏi / câu trả lời bảo mật và xác minh email tiêu chuẩn (bằng chứng là người thật)

2) Trong khi đăng nhập, sau 5 lần đăng nhập không thành công (không phải trước đó), hình ảnh xác thực được hiển thị để ngăn chặn các cuộc tấn công vũ phu.

3) Cuối cùng, tôi đã tạo một hàm băm các phần của chuỗi tác nhân người dùng sau khi đăng nhập thành công, chứa hệ điều hành, trình duyệt (nói chung không phải phiên bản) và ngôn ngữ của người dùng - tạo thành một loại mật khẩu phụ. Nếu băm useragent khác đáng kể trong lần đăng nhập tiếp theo, người dùng được yêu cầu trả lời câu hỏi bảo mật. Sau đó, nếu điều này được trả lời thỏa đáng, chuỗi UA mới sẽ được băm và thêm vào danh sách "máy an toàn" của chúng, để chúng sẽ không bị hỏi lại từ máy này. Điều này tương tự như cơ chế được sử dụng bởi hệ thống chơi game Steam.

Điều này đã được sử dụng trong hơn một năm rất thành công với khoảng 700 người dùng và nó có thêm lợi ích là ngăn chặn "chia sẻ đăng nhập" - một vấn đề trong đó nhiều người dùng đang sử dụng cùng một thông tin đăng nhập để thuận tiện!

Câu trả lời ngắn hơn, và nếu bạn thực sự quan trọng về bảo mật, bạn luôn có các lựa chọn mà các cấp độ văn phòng khác nhau.

Bảo mật tuyệt đối không tồn tại. Số một lỗ hổng luôn luôn là về phía khách hàng, với trojan ans keyloggers . SSL không giúp được điều đó.

1) Máy tạo mã thông báo : các ngân hàng sử dụng chúng, sau đó sử dụng bão tuyết. Nó có thể là một thiết bị hoặc một ứng dụng. Chà .. nó đắt.

2) Chân SMS . giải pháp thú vị và giá cả phải chăng. Có rất nhiều giá tốt từ sms trnasactional trên thị trường và mọi người có một điện thoại có khả năng nhận được nó.

3) Nếu bạn phải sử dụng HTTP, bạn có thể buộc dịch vụ oauth của bên thứ ba, như google hoặc facebook . Đó là điều tốt nhất bạn có thể làm mà không có trình tạo mã thông báo.

Sử dụng cơ chế băm để lưu trữ mật khẩu và luôn so sánh mật khẩu đã băm thì không ai biết mật khẩu thực ngay cả bạn. Nó rất đơn giản nhưng hiệu quả, tuy nhiên, không có gì là hoàn toàn an toàn và có một số cách để phá vỡ các lớp tinh khiết.

Nếu bạn không thể sử dụng HTTPS hoặc bạn không muốn sử dụng HTTPS, hãy xem xét sử dụng jCryption . jCryption cung cấp mã hóa cho dữ liệu được gửi qua các yêu cầu HTTP (POST, GET, v.v.).

Bạn có thể kiểm tra kỹ thuật này tại đây: http://www.jcryption.org/#examples

Nếu đang sử dụng Firebug, bạn sẽ thấy rằng tất cả dữ liệu đã được mã hóa.

Nó có thư viện jQuery để mã hóa dữ liệu trên front-end và một thư viện PHP để giải mã dữ liệu trong back-end.

Hãy thử điều này: Trên mỗi yêu cầu của trang đăng nhập, hãy gửi qua một nonce và một dấu thời gian. Trong khi đăng lên máy chủ, hãy gửi bốn thông tin chi tiết sau:

Tên người dùng, nonce và dấu thời gian trong bản rõ. Sau đó, nối phần trên với dấu phân tách (Ví dụ: dòng mới) và mã hóa bằng mật khẩu của người dùng làm mã hóa trong chế độ mã hóa chuỗi khối.

Trên máy chủ cuối, sử dụng tên người dùng để tra cứu mật khẩu và xác minh chuỗi được mã hóa.

Vì mật khẩu không bao giờ được gửi một cách rõ ràng, nó an toàn và có thể sử dụng dấu thời gian để tránh gửi lại cùng một dữ liệu.

Để tránh chiếm quyền điều khiển phiên bằng cách lấy khóa phiên thông qua tấn công trung gian, mật khẩu hoặc hàm băm của mật khẩu có thể được ứng dụng ở phía cuối máy khách lưu trữ trong bộ nhớ và được sử dụng để tạo khóa phiên duy nhất để xác thực bởi máy chủ.

Xem qua OAuth 1.0 cũng là một ý tưởng không tồi.

Thật khó để bảo mật thông tin liên lạc mà không có một trusted third party, tuy nhiên, có một số thủ thuật bảo mật dành cho bạn:

KHÔNG để lộ thông tin nhạy cảm của người dùng lên mạng công cộng.

Mọi thông tin nhạy cảm phải được băm tốt hoặc mã hóa khóa công khai. Chú ý: Nếu bạn chọn mã hóa thông tin nhạy cảm của người dùng bằng khóa công khai, hãy đảm bảo rằng người dùng có thể xác minh khóa công khai. Ví dụ: bạn có thể gửi một số loại vân tay khóa công khai cho người dùng qua SMS hoặc thậm chí là cuộc gọi tự động.

Tạo BÍ MẬT ĐƯỢC CHIA SẺ sau khi đăng nhập thành công

Sau khi ghi nhật ký giao dịch an toàn, một bí mật được chia sẻ sẽ được tạo. Quy trình tạo có thể tham khảo SSL Handshake. Chú ý: Khi bí mật được chia sẻ được tạo, nó phải được vận chuyển nữa. Chức năng duy nhất của nó là mã hóa / giải mã dữ liệu giữa ServervàBroswer

NÊN có xác minh hai bước để tránh bị tấn công lặp lại

Mong những thủ thuật này sẽ giúp bạn