Ключевые слова:security, pop3, mail, (найти похожие документы)
_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : Solar Designer 2:5020/400 Wed 14 Oct 98 20:10
Subj : Re: mail server security
________________________________________________________________________________
From: Solar Designer <solar@cannabis.dataforce.net>
Alex Korchmar <Alex.Korchmar@p100.f28.n5020.z2.fidonet.org> wrote:
> AO> Тут возникла проблема с аутентификацией пользователей при заборе
> AO> почты. POP3 гоняет пароли в виде текста и перехватить их может
> AO> любой у кого есть LanAnalyser. Сервер чисто почтовый.
> AO> Кто-нибудь посоветуйте что можно сделать с этой проблемой. Я тут
> почитать rfc на APOP.
К сожалению, еще не очевидно лучше или _хуже_ APOP, чем USER/PASS:
1. APOP требует _хранения_ паролей на сервере в plaintext. Если кто-то
сервер ломает, требуется немедленная смена всех паролей, что во многих
случаях неосуществимо.
2. Пробегающие хеши могут быть подвергнуты подбору, точно также как и
пароли из shadow. Только вот в APOP нет ни salt'ов ни замедления, так
что на практике ломаться будет гораздо больший процент.
Таким образом, выбор между APOP и USER/PASS не столь очевиден, и зависит
от конкретной ситуации. Hапример, для одного себя APOP лучше (свой пароль
в случае чего поменять не сложно, да и выбрать его с запасом надежности
тоже можно). Hо на машине с тысячей юзеров APOP уже, IMHO, не разумен.
Альтернативы? Вот несколько:
1. Как уже кто-то говорил, POP3 over SSH port forwarding. Разумеется, все
работает. (Тут у нас даже один юзер такой умный оказался.:-)
2. Команда AUTH, пришедшая в POP3 из IMAP'а. Для POP3 определяется в RFC
1734. Поддерживает разные методы; исходный IMAP'овый набор дан в RFC 1731.
В том числе некоторые с шифрованием всей последующей сессии. Кто все это
поддерживает -- не знаю, не видел. (Кто знает, расскажите.)
3. RFC 2095 -- еще один метод для команды AUTH, как раз как замена APOP --
тоже challenge/response на основе MD5, но не требует хранения паролей в
plaintext. Правда, насколько я понимаю, хранящиеся хеши достаточны для
логина по POP3 же (что подтверждается советами в security considerations).
Так что по существу единственное достоинство по сравнению с APOP только в
том, что, даже если юзер выберет одинаковый пароль для POP3 и чего-то еще,
взломан может быть только доступ по POP3. Тот же вопрос что и выше -- пока
не видел ни одной реализации.
4. Microsoft'овый AUTH twinkie. Hикакой информации. Все, что мне удалось
найти на вебе: Internet Mail supports a proprietary encryption, sometimes
referred to as "twinkie". Интересно было бы узнать больше и, возможно,
реализовать в своем сервере.
5. SSL, здесь уже обсуждали.
--
/sd
--- ifmail v.2.14dev2 * Origin: DataForce ISP (2:5020/400@fidonet)
_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : Solar Designer 2:5020/400 Wed 14 Oct 98 21:08
Subj : Re: mail server security
________________________________________________________________________________
From: Solar Designer <solar@cannabis.dataforce.net>
Solar Designer <solar@cannabis.dataforce.net> wrote:
> 2. Пробегающие хеши могут быть подвергнуты подбору, точно также как и
> пароли из shadow. Только вот в APOP нет ни salt'ов ни замедления, так
> что на практике ломаться будет гораздо больший процент.
Oops, поправляя сам себя -- аналог salt'ов как раз есть. Hо это этого не
сильно легче, остальное остается справедливо.
--
/sd
--- ifmail v.2.14dev2 * Origin: DataForce ISP (2:5020/400@fidonet)
