Почему шифруют пароли пользователя? [дубликат]

Кроме того, вам не обязательно знать пароль пользователя. Создание хэша пароля на стороне клиента - хорошая идея. В зависимости от вашего местоположения могут существовать юридические требования при хранении личных данных и паролей.

Причины:

1. Если кто-то (изнутри или снаружи) украдет эти пароли и публично обнародует их, вы обречены, вы можете мгновенно закрыть свой бизнес.
2. Некоторые люди используют один и тот же пароль для многих сервисов. Если какой-то "злоумышленник" может получить доступ к адресу электронной почты и паролю, самый простой способ - проверить, работает ли этот пароль и для этой учетной записи электронной почты.

Вы не хотите, чтобы это произошло.

Если вы можете получить доступ к чужой учетной записи электронной почты, вы можете запросить отправку забытого пароля от различных служб жертвы и т.д.

Конфиденциальность, целостность, подлинность, конфиденциальность ... Вспомните свой первый курс по безопасности и попробуйте подсчитать, сколько тезисов обходятся вашей проблемой.

Четыре? Ну, это зависит от более конкретного взгляда на проблему, но все равно не далеко :)

Хорошо, я плохо задал вопрос. Позвольте мне перефразировать это.

Если кто-то взломает эту систему, то факт, что у него есть пароли пользователей, будет одной из наименьшей из моих проблем. Я буду шифровать пароли , но, по моему скромному мнению, другие данные в базе данных гораздо более ценны. Предположим, что если у внутреннего злоумышленника есть эти данные, он не заботится о паролях.

Если ничего больше в базе данных не зашифровано, а все остальное в базе данных - это то, что на самом деле хочет злоумышленник, действительно ли шифрование паролей решило что-нибудь?

Поскольку вы не хотите попасть в ловушку дизайна отправки незашифрованных паролей или думаете, что можете , поскольку у вас не будет ничего незашифрованного для сравнения, может быть.

Что делать, если у вас есть уязвимость SQL-инъекции, кто-то крадет вашу базу данных и использует сохраненные вами имена пользователей, адреса электронной почты и пароли в виде обычного текста для входа непосредственно в учетные записи электронной почты ваших пользователей, банковские счета и т. Д. . Вы действительно хотите взять на себя эту ответственность? И наоборот, действительно ли ВЫ хотите взять на себя ответственность видеть пароли своих пользователей в виде открытого текста?

Обычно в базе данных хранится хэш пароля, а не исходный текст. Это делается для обеспечения дополнительной защиты учетных данных пользователя от внешних атак на систему. Сравнение хэшей выполняется для проверки учетных данных пользователя.

Вы можете прочитать больше теории о том, почему используется именно такой подход, чтобы лучше понять его. Wiki может стать отправной точкой для этого.

Потому что хеширование паролей защитит его от атак изнутри организации. Таким образом, люди, имеющие доступ к базе данных, не узнают пароль пользователя.

Люди имеют привычку использовать один и тот же пароль снова и снова, поэтому, если ваша база данных случайно взломана, ваша организация не является той, которая делает другие учетные записи пользователя принадлежащими другим организациям. Теперь, если люди делают это, нет, но они это делают, и гораздо проще хэшировать пароли, чем объяснять вашим клиентам, почему кто-то изнутри завладел паролями и нанес ущерб нескольким учетным записям в других системах. не имеет отношения к твоему.

Если вы думаете, что эта причина слишком преувеличена, вы можете узнать, что на самом деле это случилось с Джеффом Этвудом, создателем Stack Overflow. Он описал, как был скомпрометирован весь Stack Overflow, в своем сообщении в блоге «Я только что вошел в систему как вы: как это произошло» .

Изменить:

Чтобы ответить на ваш вопрос, другие ваши конфиденциальные данные также должны быть зашифрованы. Многие кибератаки происходят внутри рабочих мест, и мне неприятно об этом говорить, но вы должны быть параноиками в отношении того, кто и какую информацию может видеть. Все, что вы считаете конфиденциальным и не хотите, чтобы люди знали, если они не имеют специального разрешения на просмотр этих данных, должно быть зашифровано в базе данных. Вы правы, бывают случаи, когда сравнение того, что может быть украдено, вас не беспокоит. Ключ «к тебе».Он предназначен для других людей и должен быть защищен вместе с другими конфиденциальными данными в системе.

При хранении хэша пароля. Не забудьте посолить его чем-нибудь, чтобы обратный поиск по хэшу не раскрыл пароль. Да, перед хэшированием превратите его в длинную строку.
Я не понял последний абзац вопроса. Извините.

Для внутренних атак, если я могу запомнить 5 комбинаций имени пользователя/пароля, затем подойти к общедоступному терминалу и получить доступ к этим учетным записям, вероятность того, что кто-то заметит атаку, меньше, чем если бы я использовал рабочую машину для прямого редактирования базы данных или вытаскивания большого количества данных, находясь на работе.

И, как отмечали все остальные, поскольку у каждого из нас есть сотня или больше мест в Интернете, где нужны разные пароли... многие, многие люди просто используют один и тот же пароль снова и снова, снова и снова. Если компания Williams Widget Company потеряет ваше имя, логин и пароль, а у вашего банка будет тот же логин и пароль, и выяснится, что именно компания Widget Company потеряла ваш пароль... тут возникает определенная путаница в ответственности.