Учетная запись логин же передать другой адрес электронной почты

1

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

Если у меня есть пользовательская система, будь то тонкий клиент, веб-приложение, программное обеспечение и у меня есть 2 пользователя, Билли и Джон. Билли и Джон имеют один и тот же пароль по совпадению, pass1234, но разные электронные письма, таким образом:

billy@test.com - pass1234

john@test.com - pass1234

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

Существуют ли какие-либо механизмы программирования / системы / администратора для предотвращения чего-то подобного? Как то, что мешает кому-то использовать фиксированный пароль «Passw0rd», а затем циклически перебирать тысячи разных писем, пока не получит хит. (исключая использование каптчей)

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

JRed
источник
Разве это не грубое принуждение? Также, возможно, Cloud Flare имеет механизм для предотвращения этого, поскольку он, очевидно, предотвращает DDoS-атаки. И я не думаю, что обычный пользователь сделает это, так как большинство пользователей просто нажимают «Запомнить мое имя пользователя и пароль на этом сайте».
Hatsune Vocaloid Miku
1
Вы можете использовать двухстороннюю аутентификацию, пароль + OTP или пароль + RSA ID.
manjesh23

Ответы:

5

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

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

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

То есть Если вы не разрешаете своим сотрудникам создавать простые пароли, такие как «Password1», но требуют, чтобы они вводили заглавные буквы, цифры, символы, то вероятность того, что они введут тот же пароль, не исключается, потому что, например, кто-то может легко это сделать. "Password123!".

Хеширование защищает только данные, хранящиеся в базе данных, потому что сервер берет данные, введенные пользователем - & gt; возвращает хеш, соль (и перец, если они используются) - & gt; запускает введенные и полученные из БД данные по алгоритму - & gt; если результат сравнивается с сохраненным хешем, то данные верны и позволяют пользователю войти. Это только для проверки деталей - ничего общего с тем, что пользователь вводит и выбирает установить свой пароль. Соль и перечеркивание позволяют просто не дублировать хэш в другом месте базы данных (т. Е. Если два хеша идентичны, то пароль будет одинаковым для обеих учетных записей - baaad).

Как уже говорили другие ответы, лучшим решением является многофакторная (более одного из следующих, но не более одного и того же фактора) аутентификация:

  1. Что-то у вас есть - & gt; смарт-карта, генератор RSA и т. д.
  2. Что-то, что вы знаете - & gt; Пароль или ПИН
  3. Что-то, что вы есть - & gt; биометрический (отпечаток пальца, сетчатка и т. д.)

Например.

  • Смарт-карта + Пароль = Хорошо
  • Генератор RSA + Пароль + Отпечаток пальца = Хорошо
  • Пароль + PIN = Плохо
Kinnectus
источник
не могли бы вы сказать, хешируйте имя пользователя billy@test.com, хешируйте пароль pass1234 - затем объедините значения и хешируйте это? billy@test.compass1234 это означает, что хеш не будет одинаковым, так как 2 пользователям не разрешено использовать одно и то же имя пользователя.
JRed
1
Нет, потому что пользователь все еще вводит свое имя пользователя и пароль. Как показывает ваш пример, введенные данные, по сути, одинаковы. Алгоритм хеширования защищает от взлома самой базы данных, а не деталей, выбранных пользователем
Kinnectus
Я вижу, и другие ответы привели к этому. Спасибо
JRed
1

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

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

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

djsmiley2k
источник
0

Вы можете использовать двустороннюю аутентификацию,

Пример: пароль + OTP или пароль + идентификатор RSA

manjesh23
источник
1
Можете ли вы предоставить некоторый контекст / ссылку на ФП?
Burgi
Одноразовый пароль?
manjesh23
Этот ответ будет лучше в качестве комментария. Вы не предоставляете контекста или ссылок для OP, чтобы исследовать их. Пожалуйста, посмотрите на Как ответить ,
Burgi