Các nhận xét chỉ ra rằng SMTP không yêu cầu xác thực là chính xác. Điều đó nói rằng, cả ba của các tùy chọn bạn đã chỉ định là không an toàn, giả sử rằng máy chủ sử dụng phần cứng và phần mềm hàng hóa. Tôi sẽ chỉ ra lý do tại sao mỗi thứ không an toàn, mặc dù tôi sẽ không tuân theo thứ tự ban đầu của bạn.
Điều gì sẽ xảy ra nếu ai đó ăn cắp máy chủ? Sau đó, họ có thể chỉ cần mở tệp hoặc cơ sở dữ liệu, đọc mật khẩu và ngay lập tức có quyền truy cập vào tất cả các thông tin quan trọng trong công ty. Vì vậy, trừ khi bạn có bảo vệ vũ trang bao quanh máy chủ cả ngày lẫn đêm, điều này đã khá không an toàn.
Nhưng nó trở nên tồi tệ hơn. Không có hệ thống máy tính nào hoàn toàn không thể bị tấn công và một số cuộc tấn công được công bố rộng rãi (chẳng hạn như Mạng PlayStation của Sony) trong vài năm qua đã cho thấy kẻ tấn công có thể truy cập nội dung của tệp đĩa và cơ sở dữ liệu mà không cần truy cập vật lý. Hơn nữa, có vẻ như từ câu hỏi của bạn, máy chủ được đề cập có nghĩa là chấp nhận các gói (yêu cầu HTTP, email đến, v.v.) từ thế giới bên ngoài, điều này thúc đẩy bề mặt tấn công của bạn.
Điều này thật hấp dẫn, nhưng điều này thậm chí còn nguy hiểm hơn tùy chọn 2 hoặc tùy chọn 3. Đối với một điều, trường chuỗi cuối cùng riêng tư được lưu trữ trong tệp .class được tạo bởi trình biên dịch Java, vì vậy với tùy chọn này, bạn đã lưu trữ mật khẩu chưa được mã hóa. trên ổ cứng của máy chủ. Sau khi xâm nhập máy chủ như trong tùy chọn 2 hoặc 3, kẻ tấn công chỉ có thể chạy javap để lấy mật khẩu văn bản rõ ra khỏi tệp .class.
Tuy nhiên, cách tiếp cận này mở rộng bề mặt tấn công của bạn hơn nữa. Nếu mật khẩu được lưu trữ như một phần của mã nguồn, thì đột nhiên nó có sẵn cho tất cả các nhà phát triển đang làm việc trên mã. Theo nguyên tắc ít đặc quyền nhất, các nhà phát triển không nên biết thêm mật khẩu, và có một lý do rất chính đáng ở đây. Nếu bất kỳ nhà phát triển nào máy bị đánh cắp hoặc xâm nhập từ bên ngoài, kẻ tấn công có thể xem qua ổ cứng của máy bị xâm nhập và lấy mật khẩu văn bản rõ ràng. Sau đó, có kiểm soát nguồn. Một trong những lợi ích thực sự quan trọng của kiểm soát nguồn là nó cho phép bạn kiểm tra bất kỳ phiên bản mã nào trước đó của bạn. Vì vậy, ngay cả khi bạn chuyển sang một phương thức bảo mật trong tương lai, nếu mật khẩu đã từng nhập vào điều khiển nguồn thì máy chủ điều khiển nguồn sẽ là một điểm tấn công tiềm năng.
Tất cả các yếu tố này cộng lại để cho thấy rằng, ngay cả khi bảo mật của máy chủ HTTP / mail là hàng đầu, tùy chọn 1 làm tăng bề mặt tấn công đến mức bảo mật của máy chủ HTTP / mail không thực sự hữu ích.
Chi tiết bổ sung:Ở phần đầu, tôi đã chỉ định "giả sử rằng máy chủ sử dụng phần cứng và phần mềm hàng hóa." Nếu không sử dụng phần cứng và phần mềm hàng hóa, bạn có thể thực hiện những việc như khởi động từ bộ nhớ chỉ đọc và chỉ sử dụng cơ sở dữ liệu được mã hóa, yêu cầu một người cung cấp khóa giải mã mỗi lần khởi động. Sau đó, thông tin được giải mã chỉ tồn tại trong bộ nhớ và không bao giờ được ghi vào đĩa. Bằng cách này, nếu máy chủ bị đánh cắp, kẻ tấn công phải rút phích cắm của máy chủ và do đó, mất tất cả thông tin được giải mã mà trước đây chỉ có trong bộ nhớ. Loại thiết lập này đôi khi được sử dụng cho Kerberos KDC (với máy chủ trong một hộp khóa để tăng cường bảo mật), nhưng hiếm khi được sử dụng theo cách khác và thực sự là quá mức cần thiết khi có một cách dễ dàng để giải quyết vấn đề của bạn mà không cần phải làm gì thêm chi phí.
