Tôi hiện đang làm việc trên một nhà cung cấp PHP OpenID sẽ hoạt động qua HTTPS (do đó được mã hóa SSL).
Tôi có sai khi truyền mật khẩu dưới dạng văn bản thuần túy không? Về lý thuyết thì HTTPS không thể bị đánh chặn nên tôi không thấy có gì sai. Hay điều này không an toàn ở một mức độ nào đó và tôi không thấy điều này?
Câu trả lời:
An toàn rồi. Đó là cách toàn bộ web hoạt động. Tất cả mật khẩu trong các biểu mẫu luôn được gửi ở dạng văn bản thuần túy, vì vậy, nó cần đến HTTPS để bảo mật.
Bạn vẫn cần đảm bảo rằng bạn gửi nó qua yêu cầu POST chứ không phải GET. Nếu bạn gửi nó qua yêu cầu GET, nó có thể được lưu ở dạng bản rõ trong nhật ký lịch sử trình duyệt của người dùng hoặc nhật ký truy cập của máy chủ web.
Nếu HTTP bị vô hiệu hóa và bạn chỉ sử dụng HTTPS, thì bạn vẫn chưa thực sự truyền mật khẩu dưới dạng văn bản thuần túy.
Hash phía khách hàng. Tại sao? Hãy để tôi kể cho bạn nghe về một thử nghiệm nhỏ. Đi bộ đến máy tính trong nhà ăn của công ty. Mở trình duyệt đến trang đăng nhập trang web của công ty (https). Nhấn F12, nhấp vào tab mạng, kiểm tra nhật ký liên tục, thu nhỏ bảng điều khiển nhưng để trang web mở trang đăng nhập. Ngồi xuống và ăn trưa. Hãy quan sát nhân viên sau khi nhân viên đăng nhập vào trang web của công ty và là một nhân viên giỏi đăng xuất khi hoàn thành. Ăn trưa xong, ngồi xuống máy tính, mở tab mạng và xem từng tên người dùng và mật khẩu ở dạng văn bản thuần túy trong phần nội dung biểu mẫu.
Không có công cụ đặc biệt, không có kiến thức đặc biệt, không có phần cứng hack ưa thích, không có keylogger chỉ là F12 cũ tốt.
Nhưng này, hãy nghĩ tất cả những gì bạn cần là SSL. Những kẻ xấu sẽ yêu bạn vì nó.
Hãy thực hiện một số ghi chú cho các câu trả lời trước.
Đầu tiên, có lẽ không phải là ý tưởng tốt nhất khi sử dụng thuật toán băm phía máy khách. Nếu mật khẩu của bạn bị nhiễm mặn ở phía máy chủ, bạn sẽ không thể so sánh các hàm băm (ít nhất là không nếu bạn không lưu trữ hàm băm của ứng dụng khách trong cơ sở dữ liệu ở một trong các lớp băm từ mật khẩu, giống hoặc tệ hơn). Và bạn không muốn triển khai thuật toán băm được sử dụng bởi cơ sở dữ liệu ở phía máy khách, điều đó sẽ thật ngớ ngẩn.
Thứ hai, giao dịch các khóa mật mã cũng không phải là lý tưởng. Về mặt lý thuyết, MITM có thể (coi như anh ta đã cài đặt chứng chỉ gốc trên máy khách) thay đổi các khóa mật mã và thay đổi bằng các khóa của chính mình:
Kết nối ban đầu (không tính đến tls) từ một máy chủ lý thuyết trao đổi khóa:
Ứng dụng khách yêu cầu khóa công khai> máy chủ giữ khóa cá nhân, tạo khóa công khai cho máy khách> máy chủ gửi khóa công khai cho máy khách
Bây giờ, trong trạng thái MITM lý thuyết:
Ứng dụng khách yêu cầu khóa công khai> MITM tạo khóa cá nhân giả mạo > Máy chủ giữ khóa cá nhân, tạo khóa công khai cho ứng dụng khách> MITM nhận khóa công khai từ máy chủ ban đầu, hiện tại, chúng tôi có thể tự do gửi khóa công khai giả của mình cho khách hàng và bất cứ khi nào có yêu cầu từ khách hàng, chúng tôi sẽ giải mã dữ liệu khách hàng bằng các khóa giả, thay đổi tải trọng (hoặc đọc nó) và mã hóa bằng các khóa công khai gốc > MITM gửi các khóa công khai giả cho khách hàng.
Đó là điểm của việc có chứng chỉ CA đáng tin cậy trong TLS và đó là cách bạn nhận được thông báo từ cảnh báo của trình duyệt nếu chứng chỉ không hợp lệ.
Trả lời OP: theo ý kiến khiêm tốn của tôi, bạn không thể làm điều đó, bởi vì sớm hay muộn, ai đó sẽ muốn tấn công người dùng từ dịch vụ của bạn và sẽ cố gắng phá vỡ giao thức của bạn.
Tuy nhiên, những gì bạn có thể làm là triển khai 2FA để ngăn mọi người cố gắng đăng nhập bằng cùng một mật khẩu. Mặc dù vậy, dấu hiệu của các cuộc tấn công phát lại.
Tôi không giỏi về mật mã, vui lòng sửa cho tôi nếu tôi sai.
Các áp phích khác là chính xác. Bây giờ bạn đang sử dụng SSL để mã hóa việc truyền mật khẩu, hãy đảm bảo rằng bạn đang băm mật khẩu đó bằng một thuật toán tốt và muối để nó cũng được bảo vệ khi nó ở trạng thái nghỉ ...
Ví dụ về @CodeDog có vấn đề ..
Có, tôi có thể tin rằng người dùng sẽ đăng nhập vào một hộp caffeteria. Nếu bạn đang ghi lại nhật ký từ một caffeteria của công ty, thì bạn là người vi phạm an ninh. Các hộp caffeterias của công ty nên được vô hiệu hóa, ví dụ như không có điều khoản, không có trình ghi nhật ký, không có quyền truy cập từ xa, v.v. Để ngăn chặn bạn, kẻ tấn công bên trong.
Ví dụ này là một ví dụ tốt về bảo mật truy cập máy tính, và không thực sự liên quan đến an ninh mạng. Nó được cung cấp để biện minh cho việc băm phía máy khách, nhưng nếu bạn có quyền truy cập máy tính, bạn có thể chỉ cần sử dụng trình ghi nhật ký tổ hợp phím và bỏ qua điều đó. Hàm băm phía máy khách một lần nữa không liên quan. Ví dụ của @CodeDog là một cuộc tấn công truy cập máy tính và yêu cầu các kỹ thuật khác với các cuộc tấn công lớp mạng.
Ngoài ra, một vụ hack máy tính công cộng được bảo vệ bằng cách làm tê liệt hệ thống khỏi các mối đe dọa, như đã đề cập ở trên. ví dụ: sử dụng chromebook cho một máy tính caffeteria công cộng. Nhưng điều đó đã bị bỏ qua bởi một cuộc tấn công vật lý . Trong giờ nghỉ, hãy đến caffeteria và thiết lập một camera bí mật để ghi lại những lần nhấn bàn phím của người dùng. Sau đó, không quan trọng nếu máy tính caffeteria bị tê liệt, HOẶC loại mã hóa nào được sử dụng.
lớp vật lý -> lớp máy tính -> lớp khách -> lớp mạng -> lớp máy chủ
Đối với mạng, không thành vấn đề nếu bạn băm ở phía máy khách vì lớp https / ssl sẽ mã hóa mật khẩu thuần túy. Vì vậy, như những người khác đề cập, băm máy khách là dư thừa nếu TLS được bảo mật.