Аутентификация: имя пользователя (электронная почта) и пароль хэшируются вместе в одном поле базы данных

Question

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

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

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

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

В основном есть две таблицы, которые необходимы для этого процесса. Таблицы находятся в одной базе данных, конечно.
Одна таблица входа в систему с полем хэш-комбинации (электронная почта, pw, salt) и одна таблица профиля, которая содержит, помимо прочего, электронное письмо в виде открытого текста в одном поле. Давайте назовем это profile_email.

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

Итак, мои вопросы: это безопасное и выполнимое решение? Можете ли вы вспомнить какие-либо непредвиденные проблемы? Вы слышали о похожих решениях?

Answer 1

С точки зрения сущности-отношения...

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

у вас есть таблица профиля, которая содержит обычную информацию о профиле, включая конфиденциальную информацию (электронная почта)

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

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

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

скажем, у вас есть в вашей таблице входа в систему:

s = randomSalt
е =cryptoHash(электронная почта,static_system_wide_salt)
р =cryptoHash(пароль, с)
ID =KeyForRelationToOtherEntities

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

адрес электронной почты в процессе аутентификации хешируется и защищен от радужных атак

пароль тоже

вы можете индексировать e colum для поиска во время входа в систему

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

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

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

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

Answer 2

Мне не совсем понятен ваш сценарий, но я думаю, что-то вроде этого:

valueToStore = hash(email) + delimiter + hash(password, salt) + delimiter + salt;

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

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

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

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

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