Komentáře poukazující na to, že SMTP nevyžaduje ověření, jsou správné. Tedy všechny tři z možností, které jste zadali, jsou nejisté, za předpokladu, že server používá komoditní hardware a software. Ukážu, proč je každý z nich nejistý, i když nebudu dodržovat váš původní příkaz.
Co kdyby někdo ukradl server? Pak už mohli jen otevřít soubor nebo databázi, přečíst si heslo a okamžitě mít přístup ke všem důležitým informacím ve firmě. Takže pokud nemáte kolem serveru ve dne i v noci ozbrojené stráže, je to už dost nejisté.
Ale je to horší. Žádný počítačový systém není zcela nezranitelný vůči útoku a několik dobře propagovaných útoků (například PlayStation Network společnosti Sony) v posledních několika letech ukázalo, že útočník se může dostat k obsahu souborů na disku a databází bez fyzického přístupu. Z vaší otázky se navíc zdá, že daný server má přijímat pakety (požadavky HTTP, příchozí e-maily atd.) z vnějšího světa, což zvyšuje vaši útočnou plochu.
To je lákavé, ale je to ještě zhoubnější než možnost 2 nebo možnost 3. Za prvé, soukromé pole konečného řetězce je uloženo v souboru .class generovaném kompilátorem Java, takže s touto možností již ukládáte nezašifrované heslo na pevném disku serveru. Po kompromitaci serveru jako ve variantě 2 nebo 3 může útočník jednoduše spustit javap za účelem získání hesla ve formátu prostého textu ze souboru .class.
Tento přístup však ještě více rozšiřuje vaši útočnou plochu. Pokud je heslo uloženo jako součást zdrojového kódu, je najednou k dispozici všem vývojářům, kteří na kódu pracují. Podle zásady nejmenšího privilegia by vývojáři neměli znát další hesla, a je zde velmi dobrý důvod. Pokud některý z vývojářů Pokud je počítač odcizen nebo kompromitován zvenčí, může útočník prozkoumat pevný disk napadeného počítače a získat heslo v prostém textu. Pak je tu ovládání zdroje. Jednou z opravdu důležitých výhod ovládání zdroje je to, že vám umožňuje kontrolovat jakoukoli předchozí verzi vašeho kódu. Takže i když v budoucnu přejdete na zabezpečenou metodu, pokud heslo někdy vstoupilo do kontroly zdroje, pak je server kontroly zdroje potenciálním bodem útoku.
Všechny tyto faktory se sčítají a ukazují, že i když je zabezpečení HTTP/mail serveru prvotřídní, možnost 1 zvyšuje plochu útoku natolik, že zabezpečení HTTP/mail serveru ve skutečnosti nepomáhá.
Další podrobnosti:Na začátku jsem specifikoval "za předpokladu, že server používá komoditní hardware a software." Pokud nepoužíváte komoditní hardware a software, můžete například spouštět z úložiště pouze pro čtení a používat pouze šifrovanou databázi, což vyžaduje, aby osoba poskytla dešifrovací klíč při každém spuštění. Poté jsou dešifrované informace uloženy pouze v paměti a nikdy se nezapisují na disk. Tímto způsobem, pokud je server odcizen, musí útočník odpojit server a tak ztratí všechny dešifrované informace, které byly kdy pouze v paměti. Tento druh nastavení se někdy používá pro Kerberos KDC (se serverem v uzamčeném boxu pro extra zabezpečení), ale jinak se používá jen zřídka a je upřímně řečeno přehnaný, když existuje snadný způsob, jak vyřešit váš problém, aniž byste museli jít do toho všeho navíc. výdaje.