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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

Это зависит от контекста

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разумеется, не стоит тратить средства на банковские/финансовые сайты.

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

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

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

Вывод:

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

Введите имя пользователя
Создайте уникальную соль для пользователя
Хешируйте пароль, используя соль
Сохраните пароль с помощью соли в базе данных

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

Salt_(cryptography)

Ответ 6

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

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

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