Коментарите, посочващи, че SMTP не изисква удостоверяване, са правилни. Това каза, и тримата от посочените от вас опции са несигурни, ако се приеме, че сървърът използва стандартен хардуер и софтуер. Ще покажа защо всеки е несигурен, въпреки че няма да следвам първоначалната ви поръчка.
Ами ако някой открадне сървъра? След това те биха могли просто да отворят файла или базата данни, да прочетат паролата и веднага да имат достъп до цялата важна информация в компанията. Така че освен ако нямате въоръжена охрана, обграждаща сървъра ден и нощ, това вече е доста несигурно.
Но става по-зле. Никоя компютърна система не е напълно неуязвима за атака и няколко добре рекламирани атаки (например PlayStation Network на Sony) през последните няколко години показаха, че нападателят може да стигне до съдържанието на дискови файлове и бази данни без физически достъп. Освен това от въпроса ви изглежда, че въпросният сървър е предназначен да приема пакети (HTTP заявки, входящи имейли и т.н.) от външния свят, което увеличава повърхността на вашата атака.
Това е примамливо, но това е още по-пагубно от опция 2 или опция 3. От една страна, частно поле за финален низ се съхранява във файла .class, генериран от компилатора на Java, така че с тази опция вие вече съхранявате нешифрованата парола на твърдия диск на сървъра. След компрометиране на сървъра, както е във вариант 2 или 3, нападателят може просто да стартира javap за да извадите паролата за обикновен текст от .class файла.
Този подход обаче разширява още повече повърхността ви за атака. Ако паролата се съхранява като част от изходния код, изведнъж тя е достъпна за всички разработчици, които работят върху кода. Съгласно принципа на най-малко привилегии, разработчиците не трябва да знаят допълнителни пароли и тук има много добра причина. Ако някой от разработчиците машините са откраднати или компрометирани отвън, нападателят може да погледне през твърдия диск на компрометираната машина и да получи паролата в обикновен текст. След това има контрол на източника. Едно от наистина важните предимства на контрола на източника е, че ви позволява да проверявате всяка предходна версия на вашия код. Така че дори ако преминете към защитен метод в бъдеще, ако паролата някога е влизала в контрола на източника, сървърът за контрол на източника е потенциална точка за атака.
Всички тези фактори показват, че дори ако сигурността на HTTP/mail сървъра е първокласна, вариант 1 увеличава повърхността на атака толкова много, че сигурността на HTTP/mail сървъра не помага наистина.
Допълнителни подробности:В началото уточних „при положение, че сървърът използва стандартен хардуер и софтуер“. Ако не използвате стандартен хардуер и софтуер, можете да правите неща като зареждане от хранилище само за четене и да използвате само криптирана база данни, като се изисква човек да предоставя ключа за декриптиране при всяко зареждане. След това декриптираната информация живее само в паметта и никога не се записва на диск. По този начин, ако сървърът бъде откраднат, нападателят трябва да изключи сървъра и така да загуби цялата декриптирана информация, която някога е била само в паметта. Този вид настройка понякога се използва за Kerberos KDC (със сървъра в заключена кутия за допълнителна сигурност), но рядко се използва в противен случай и е откровено излишен, когато има лесен начин да решите проблема си, без да се прибягвате до всичко това допълнително разход.
