вопрос безопасности пароля - PullRequest
0 голосов
/ 17 сентября 2009

Я работаю над аутентификацией пользователя для веб-сайта.

Прочитав книгу Innocent Code, я последовал ее совету для хранения паролей в виде хэша (имя пользователя + пароль + соль). Теория заключается в том, что хеширование пароля само по себе небезопасно (подвержено атакам по словарю / радужной таблице и, возможно, не является уникальным хешем на любом сайте, если несколько пользователей используют один и тот же пароль). Хэширование имени пользователя и пароля вместе должно быть уникальным на любом сайте, но пользователи могут повторять эти же учетные данные на разных сайтах, поэтому, если он будет взломан на одном, он может быть взломан на многих сайтах. Поэтому использование хэша имени пользователя, пароля и значения соли для конкретного сайта должно создать глобально уникальный хеш (с учетом ограничений самого алгоритма хеширования)

В настоящее время у меня есть две таблицы в базе данных: пользователи и пароли.

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

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

Пока все работает хорошо.

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

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

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

Итак, мой вопрос: как мне с этим бороться?

Я параноик, храня пароли отдельно от таблицы пользователей? Создание большей проблемы для себя, чем я решаю? Неужели было бы больно помещать хешированные пароли в таблицу пользователей? Было бы лучше иметь единую таблицу со всей пользовательской информацией?

Ответы [ 5 ]

4 голосов
/ 17 сентября 2009

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

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

2 голосов
/ 17 сентября 2009

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

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

Тогда вы могли бы гораздо безопаснее хранить значения пароля + значения хэшируемой соли в таблице пользователей.

2 голосов
/ 17 сентября 2009

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

2 голосов
/ 17 сентября 2009

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

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

0 голосов
/ 17 сентября 2009

База данных является частной (нет публичного доступа)?
Вы уверены, что у вас нет проблем с инъекцией SQL?
Ваш солевой и хэш-ключ защищен? Каковы будут последствия взлома системы безопасности, обеспечивающего доступ к таблицам базы данных и хэшу паролей? (на тот момент, остальные данные будут моей самой большой проблемой ...)

Не думаю, что стоит иметь хэш пароля в отдельной таблице.

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