В любом случае, почему я должен заботиться о хешировании паролей?

Question

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

Answer 1

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

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

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

4. Дело не только в тебе. Пользователи, как правило, обмениваются паролями между системами. Возможно, однажды (не дай Бог) у вас будет взлом, который не имеет ничего общего с паролями, но в ходе этого взлома ваши таблицы аутентификации станут одной из целей злоумышленника. Если вы храните пароли в виде простого текста, вы также просто взломали учетные записи пользователей во многих других службах, и ваш очень плохой день стал намного хуже.

Если вы считаете, что такого не происходит, поговорите с парнями из Reddit.

Answer 2

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

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

Answer 3

Лучшие практики безопасности предлагают:

• Вы должны использовать уникальную (userId, пароль) пару для каждой вашей учетной записи. Но большинство людей используют одну пару для многих ресурсов (электронная почта, банк, и т. Д. ). Злоумышленник может украсть их у одного ресурса и использовать их для доступа к другому. Хеширование паролей с помощью salt & mdash; см. http://en.wikipedia.org/wiki/Salt_(cryptography)—prevents такого рода атаки.

• Вы должны зашифровать все конфиденциальные данные в вашей базе данных, а не только пароли. Ваше мнение, что кто-то может украсть всю вашу БД (или ваш сервер), совершенно верно.

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

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

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

• Вы значительно уменьшите свое воздействие, если ваши данные будут украдены.

• Вы защищены от социальной инженерии атак, в которых злоумышленник подражает действительному пользователю и призывает сотрудника раскрыть пароль. См http://en.wikipedia.org/wiki/Social_engineering_(security).

Answer 4

Должен ли я хранить пароли на другой сервер для остальной части моего данные

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

Обратите внимание, что при использовании серверов аутентификации, таких как Kerberos, RADIUS или аутентификация домена Windows, пароли на другом сервере фактически помещаются.

Answer 5

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

Answer 6

Потому что даже если у вас есть доступ к данным, доступ к ПРИЛОЖЕНИЮ на самом деле важнее. Приложение значительно облегчает манипулирование данными, например.

Хеширование пароля предотвращает случайное воздействие на все глаза.

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

Это хорошая и надежная практика хэширования паролей.

Answer 7

Иногда вы не знаете, кто будет системным администратором. Вы по-прежнему хотите защитить своих пользователей от них. Таким образом, хэшируя пароли и всю важную информацию (например, данные кредитной карты), вы делаете это действительно труднее для хакера или администратора. И я думаю, что пароль никогда не должен быть написан буквально. Я имею в виду, что я использовал пароль с 2 лет, и я никогда не видел его записанным .. почему администратор, которого я не знаю, должен видеть МОЙ пароль ?!

Answer 8

Использование хешированного пароля не позволяет злоумышленнику войти в ваше приложение, даже если он знает хеш. Ваша страница входа запрашивает исходный пароль, поэтому для входа в систему с его помощью им придется изменить хеш (вычислить коллизию). Например, используя радужную таблицу, это довольно тривиально для MD5, и именно здесь начинается засолка. Тогда злоумышленнику необходимо знать 1) способ, которым вы комбинируете соль и пароль (не так уж много безопасности), 2) соль что, вероятно, уже в БД) и 3) они должны вычислить это значение для каждой комбинации пароля и соли. Это намного больше, чем просто вычисление хэшей общих паролей и поиск совпадений.

Answer 9

Если он сможет расшифровать пароли, он, вероятно, сможет получить доступ к учетным записям вашего пользователя и на других сайтах (а также независимо от того, сколько раз мы говорим людям не использовать пароли повторно, они делают это). Хранение незашифрованных паролей - это хороший способ раздачи учетных записей PayPal, eBay и Amazon всех ваших пользователей.

Answer 10

Весь LinkedIn "скандал" был полностью об утечке хешированных паролей.

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

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

Если вы храните пароли в открытом виде, для доступа к нему потребуется всего 0 вычислительных лет. Скандал в LinkedIn выглядел бы намного хуже. Все, что вам нужно сделать, это SELECT * FROM USERS (либо через инъекцию, либо через инсайд).

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

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