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

Число спецификатора% s не соответствует количеству передаваемых вами аргументов. У вас есть 12 аргументов, но только 11 '% s'.

19
задан John Topley 13 November 2008 в 17:30
поделиться

10 ответов

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

1
ответ дан 30 November 2019 в 01:46
поделиться

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

2
ответ дан 30 November 2019 в 01:46
поделиться

If an application is to show grade information at the university then having access to the password will allow you to get the grades for that person. If the password also allows you to log into the online course system then you can submit tests as that user.

If the data is even more sensitive, such as credit card numbers or health records, you are open to lawsuits.

Odds are that the more sensitive information may be on a more secured system, behind stronger firewalls, so they may have found a weakness by hacking into the authentication database.

By hashing the password, then those that have access to the authentication database can't see the password and so log into the very sensitive system as a different user.

0
ответ дан 30 November 2019 в 01:46
поделиться

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

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

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

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

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

33
ответ дан 30 November 2019 в 01:46
поделиться
  1. Иногда хакер не получает полный доступ к Вашему DB. Иногда они находят немного дыры Внедрения SQL или другую слабость, которую кто-то не кодировал правильно, и таким образом, они могут только сделать, простым вещам сначала нравится, распечатывают ячейки базы данных по одному. Если они могут распечатать действительный пароль внезапно, вещи становятся намного хуже.

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

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

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

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

53
ответ дан 30 November 2019 в 01:46
поделиться

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

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

Примечание, что использующий серверы аутентификации, такие как Kerberos, RADIUS или аутентификация домена Windows эффективно поместил Вас пароли на другой сервер.

4
ответ дан 30 November 2019 в 01:46
поделиться

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

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

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

Это - просто хорошая, твердая практика для хеширования Вас пароли.

3
ответ дан 30 November 2019 в 01:46
поделиться

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

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

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

  • необходимо разделить веб-сервер от базы данных и любых других драгоценных ресурсов, для изоляции нападения к наименее ценному активу.

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

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

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

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

9
ответ дан 30 November 2019 в 01:46
поделиться

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

3
ответ дан 30 November 2019 в 01:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: