Хранить зашифрованный хэш имени пользователя в базе данных

Question

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

Это говорит о том, что я понимаю практику (и необходимость) добавления / хранения (соленого) хэша пароля в базе данных в виде большого двоичного объекта, в отличие от пароля (зашифрованного или нет). Я уже реализовал это.

Есть ли что-то, что можно получить, заполняя / хэшируя имя пользователя и сохраняя хеш в базе данных, в отличие от имени пользователя в виде простого текста (или зашифрованного)? Меня удивляет, что было бы немного сложнее определить, какие пользователи могут получить доступ к системе, используя базу данных для аутентификации.

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

Редактировать: возможно, некоторые языки, которые я использую, не на 100% правильны: не стесняйтесь исправлять: -)

Edit2: я изменил одну из своих первых точек, чтобы указать хэши засолки - спасибо всем, что указали, что я пропустил это: -)

Edit3: удалена формулировка, указывающая на то, что я шифрую / дешифрую пароль. Я использую соленые хэши и сохраняю это в БД - спасибо Скотти за то, что указал на это.

Answer 1

Зависит от контекста

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

Сценарий 1: приложение для социальных сетей

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

Вердикт - Хеширование = Плохо

Сценарий 2: сайт электронной коммерции

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

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

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

Примечание: я смотрю на вас Amazon.com .

Вердикт: обычная практика! = Хорошая практика

Сценарий 3: порно сайт

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

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

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

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

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

Сценарий 4: Банк

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

Безопасность может быть увеличена на:

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

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

---

Вывод:

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

1. Hash имя пользователя
2. Генерация уникальной соли для пользователя
3. Хешируйте пароль, используя соль
4. Хранить пароль с солью в базе данных

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

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

Если вам нужны жесткие / быстрые правила для простоты, вот несколько хороших предположений, которые следует запомнить:

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

Если вы решите хранить конфиденциальные / личные данные, то выполнение дополнительного шага может спасти вам PR / правовой кошмар в будущем.

Обновление: Интересная статья о начальном хешировании только что появилась на Coding Horror .

Answer 2

Краткий ответ: Скорее всего, нет.

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

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

Дополнительная подсказка (бесплатно!): соль хэши вашего пароля . Обычные хэши гораздо менее безопасны .

Answer 3

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

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

Answer 4

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

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

Примечание: В своем вопросе вы говорите о расшифровке своего поля пароля. Вы, вероятно, хотите сделать это невозможным (буквально). Большинство людей шифруют свои пароли с помощью однонаправленной хеш-функции (популярны MD5 и SHA256) вместе с солью. «Односторонняя» часть просто означает, что, запустив что-то через функцию, вы не сможете использовать то, что получили, чтобы получить то, с чего начали. Однако, если вы начнете с одного и того же ввода, вы всегда получите один и тот же вывод. Соль - это секрет, который знает только ваше приложение (вроде ключа шифрования), который добавляется к тому, что вы шифруете, до того, как он будет запущен через односторонний хэш. Это делает невозможным сопоставление двух зашифрованных паролей с двух разных сайтов (при условии, что они используют разные соли).

Answer 5

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

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

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

Answer 6

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

Salt_ (криптография)