The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

mail server security (security pop3 mail)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: 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 <[email protected]> Alex Korchmar <[email protected]> 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 <[email protected]> Solar Designer <[email protected]> wrote: > 2. Пробегающие хеши могут быть подвергнуты подбору, точно также как и > пароли из shadow. Только вот в APOP нет ни salt'ов ни замедления, так > что на практике ломаться будет гораздо больший процент. Oops, поправляя сам себя -- аналог salt'ов как раз есть. Hо это этого не сильно легче, остальное остается справедливо. -- /sd --- ifmail v.2.14dev2 * Origin: DataForce ISP (2:5020/400@fidonet)

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру