"nik222" написал:
Пфф, мне непонятен один момент: в базе пароли у меня зашифрованы, все ок. Но когда я ввожу данные авторизации в клиенте, я ведь ввожу пароль в открытом виде и в этом виде он отдается dovecot-у ?
дело в том, что злоумышленник может получить доступ к базе данных, и КО ВСЕМ паролям на вашем сервере.
Однако, если злоумышленник получит все хеши, а не все пароли, то это ему ничего не даст. Суть в том, что можно из пароля вычислить хеш, но обратное преобразование невозможно (только полным перебором, что для пароля из 8+ символов невозможно на сегодня).
"Cruiser78" написал:
Далее, если есть таки нарушитель и он перехватил не плайн-пароль, а его дайджест, то это всё равно, что перехватил сам плайн-пароль. Так как нет ничего проще подставить именно перехваченный дайджест при атаке.
если злоумышленник перехватил именно пароль, то он может им воспользоваться. Однако, имея хеш пароля, ничего сделать нельзя. В том случае, конечно, если этот хеш вычисляется сервером. Последнему нужен именно пароль, а не хеш, который сервер вычисляет самостоятельно, и сравнивает его со своим хешем из БД. У одинаковых паролей одинаковые хеши, потому хранить пароли НИКОГДА не нужно.
У этой схемы имеются две уязвимости:
1. действительно, можно перехватить пароль. Однако, выловить пароль не так уж и просто, нужен полный доступ хотя-бы к одному из транзитных маршрутизаторов
2. можно воспользоваться радужными таблицами, которые можно приготовить заранее, а затем быстро взломать пароль по его хешу. К счастью, для защиты можно добавить к паролю случайную соль, которая приведёт к тому, что таблица не сработает.
"Cruiser78" написал:
1. Сервер, получив идентификатор пользователя должен послать ему случайное число.
2. пользователь вычисляет из этого случайного числа и дайджества своего пароля новый суммирующий случайный (разовый) дайджест и отправляет его серверу.
3. сервер делает аналогичную операцию с хранимым на нем дайждестом и сравнивает полученный от пользователя дайджест со своим вычислением. Ну и если результат совпал, то юзер знает секрет и его можно пропускать.
Это есть базовый механизм устойчивой ко взлому системы аутентификации
и что помешает злоумышленнику проделать точно такую-же операцию? К сожалению, если юзер не может доверять серверу, а сервер не может доверять юзеру, то данная схема НЕ сработает. Такие дела.
Но и тут есть выход - нужно привлечь какую-либо третью сторону, которой доверяет и клиент, и сервер. Т.е. серверу необходим сертификат, подписанный третьей стороной. В этом случае, клиент может проверить сертификат сервера, и будет уверен в том, что данный сервер не является подставой (fake). В противном случае клиент может послать свой пароль/дайджест/хеш/хитромудрый ключ на 100500 бит не на сервер, а прямо злоумышленнику, со всеми вытекающими.
