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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

Потому что даже если у вас есть доступ к данным, доступ к APPLICATION на самом деле более важен. Приложение упрощает манипулирование данными, например.

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

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

Это просто хорошая, прочная практика хешировать ваши пароли.

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

Если у вас нет сохраненных паролей, у вас нет такой ответственности!

Ответ 10

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

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

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

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

Ответ 11

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

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

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

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

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

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

Ответ 12

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