Komentarze wskazujące, że SMTP nie wymaga uwierzytelniania, są poprawne. To powiedziawszy, wszystkie trzy określonych opcji jest niezabezpieczonych, przy założeniu, że serwer używa zwykłego sprzętu i oprogramowania. Pokażę, dlaczego każdy z nich jest niepewny, chociaż nie zastosuję się do Twojego pierwotnego zamówienia.
A gdyby ktoś ukradł serwer? Wtedy mogliby po prostu otworzyć plik lub bazę danych, odczytać hasło i od razu uzyskać dostęp do wszystkich ważnych informacji w firmie. Więc jeśli nie masz uzbrojonych strażników otaczających serwer dzień i noc, jest to już dość niepewne.
Ale jest coraz gorzej. Żaden system komputerowy nie jest całkowicie odporny na ataki, a kilka dobrze nagłośnionych ataków (na przykład PlayStation Network firmy Sony) w ciągu ostatnich kilku lat pokazało, że atakujący może dostać się do zawartości plików dyskowych i baz danych bez fizycznego dostępu. Co więcej, z twojego pytania wynika, że dany serwer ma akceptować pakiety (żądania HTTP, przychodzące wiadomości e-mail itp.) ze świata zewnętrznego, co zwiększa powierzchnię ataku.
To kuszące, ale jest jeszcze bardziej szkodliwe niż opcja 2 lub opcja 3. Po pierwsze, prywatne pole ciągu końcowego jest przechowywane w pliku .class wygenerowanym przez kompilator Java, więc dzięki tej opcji przechowujesz już niezaszyfrowane hasło na dysku twardym serwera. Po zhakowaniu serwera, jak w opcji 2 lub 3, atakujący może po prostu uruchomić javap w celu uzyskania hasła w postaci zwykłego tekstu z pliku .class.
Takie podejście jeszcze bardziej poszerza pole ataku. Jeśli hasło jest przechowywane jako część kodu źródłowego, nagle staje się dostępne dla wszystkich programistów, którzy pracują nad kodem. Zgodnie z zasadą najmniejszych uprawnień programiści nie powinni znać dodatkowych haseł i jest tutaj bardzo dobry powód. Jeśli któryś z programistów komputery zostaną skradzione lub zhakowane z zewnątrz, osoba atakująca może przejrzeć dysk twardy zaatakowanej maszyny i uzyskać hasło w postaci zwykłego tekstu. Następnie jest kontrola źródła. Jedną z naprawdę ważnych zalet kontroli źródła jest to, że pozwala ona na sprawdzenie dowolnej wcześniejszej wersji kodu. Więc nawet jeśli przełączysz się na bezpieczną metodę w przyszłości, jeśli hasło kiedykolwiek weszło do kontroli źródła, serwer kontroli źródła jest potencjalnym punktem ataku.
Wszystkie te czynniki sumują się, aby pokazać, że nawet jeśli zabezpieczenia serwera HTTP/poczty są na najwyższym poziomie, opcja 1 zwiększa powierzchnię ataku tak bardzo, że bezpieczeństwo serwera HTTP/poczty tak naprawdę nie pomaga.
Dodatkowy szczegół:Na początku określiłem "zakładając, że serwer używa zwykłego sprzętu i oprogramowania". Jeśli nie korzystasz ze zwykłego sprzętu i oprogramowania, możesz wykonywać takie czynności, jak uruchamianie z pamięci masowej tylko do odczytu i używać tylko zaszyfrowanej bazy danych, co wymaga od osoby podania klucza deszyfrującego przy każdym uruchomieniu. Następnie odszyfrowane informacje pozostają tylko w pamięci i nigdy nie są zapisywane na dysku. W ten sposób, jeśli serwer zostanie skradziony, atakujący musi odłączyć serwer i w ten sposób stracić wszystkie odszyfrowane informacje, które znajdowały się tylko w pamięci. Ten rodzaj konfiguracji jest czasami używany w Kerberos KDC (z serwerem w zamkniętym pudełku dla dodatkowego bezpieczeństwa), ale rzadko jest używany w inny sposób i jest szczerze mówiąc przesadą, gdy istnieje łatwy sposób rozwiązania problemu bez wchodzenia w te wszystkie dodatkowe koszt.
