Зачем шифровать пароли пользователей?

Ответ 1

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

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

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

Edit:

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

Ответ 2

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

Ответ 3

Причины:

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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