Всем привет!
Часто бывает ситуация — пользователь забыл пароль от какого-либо сервиса/сайта.
Если по его запросу, ему на почту высылать его логин/пароль, это чем может быть плохо?
Выглядит удобным — юзеру не надо заморачиваться с процедурой смены пароля. Однако большинство сервисов в этом случае
предлагают выполнить процедуру по смене пароля.
И кроме аргумента, что на стороне сервиса придётся хранить не хэш пароля а в явном виде..
MH>И кроме аргумента, что на стороне сервиса придётся хранить не хэш пароля а в явном виде..
если этого не достаточно, то можно ещё вспомнить про передачу секрета через третьи руки
MH>Выглядит удобным — юзеру не надо заморачиваться с процедурой смены пароля.
может тогда лучше одноразовый код для авторизации?
Письмо с пароль пойдет в открытом виде через цепочку SMTP-серверов.
Каждый такой сервер может сохранять сообщения локально, передавать для анализа сторонним системам (скажем, вирусной аналитике или спам-детекторам), писать в логи и т.п.
Значит, с каждым хопом в этой цепочке, attack surface стремительно увеличивается.
В случае с ссылкой — это не работает, т.к. время жизни ссылки ограничено (обычно, в пределах часа) и сама ссылка одноразовая.
Поэтому даже если злоумышленник как-то заполучит такую ссылку (скажем, взломав какой-то промежуточный сервер), воспользоваться ею он уже не сможет.
BE>Хранить нужно хеш пароля да еще и с солью. Иначе утечет ваша бд и все.
Неочень понимаю опасность хранения пароля. В случае утечки БД уже всё, тк именно БД содержит ценные сведения.
И этот также значит что систему жестко взломали и доступ получили почти ко всему (самое страшное — бд).
А то что там будет хэш или пароль уже малоинтересно, тк основные данные то уже получили.
если приводить аналогию — дом сгорел (самое ценное), но дверь из армированного железа осталась.
Здравствуйте, MadHuman, Вы писали:
MH>Здравствуйте, BlackEric, Вы писали:
BE>>Хранить нужно хеш пароля да еще и с солью. Иначе утечет ваша бд и все.
MH>Неочень понимаю опасность хранения пароля. В случае утечки БД уже всё, тк именно БД содержит ценные сведения. MH>И этот также значит что систему жестко взломали и доступ получили почти ко всему (самое страшное — бд). MH>А то что там будет хэш или пароль уже малоинтересно, тк основные данные то уже получили.
MH>если приводить аналогию — дом сгорел (самое ценное), но дверь из армированного железа осталась.
Пользователям свойственно использовать одни и те же логины и пароли на разных сервисах. Хранение хеша это забота о них.
MH>Неочень понимаю опасность хранения пароля. В случае утечки БД уже всё, тк именно БД содержит ценные сведения.
Не обязательно.
Это может быть БД чисто для сервиса аутентификации, т.е. в ней только пользователи, их права и пароли.
А бизнес-данные могут быть в другой БД, даже на другом физическом хосте, в защищённой подсети.
Здравствуйте, MadHuman, Вы писали:
MH>Неочень понимаю опасность хранения пароля. В случае утечки БД уже всё, тк именно БД содержит ценные сведения. MH>И этот также значит что систему жестко взломали и доступ получили почти ко всему (самое страшное — бд). MH>А то что там будет хэш или пароль уже малоинтересно, тк основные данные то уже получили.
Пользователи обычно используют один и тот же пароль "для всего".
То что утекут ваши данные — пофик, проблема в том что укравший базу с открытыми паролями сможет
ими воспользоваться не для вашей, а для другой системы (для онлайн банка например)
Здравствуйте, MadHuman, Вы писали:
MH>А то что там будет хэш или пароль уже малоинтересно, тк основные данные то уже получили.
Проблемы будут у пользователей, которые часто используют один пароль везде.
Здравствуйте, MadHuman, Вы писали:
MH>И кроме аргумента, что на стороне сервиса придётся хранить не хэш пароля а в явном виде..
Добавлю к уже сказанному. Пароль в открытом виде будет лежать не только в БД, но и в почтовом ящике пользователя. А также, возможно, в локальном почтовом клиенте, в кэше браузера, в кэше прокси сервера и еще в нескольких местах. Соответственно вероятность утечки возрастает пропорционально.
