Есть ли какое-либо преимущество для повторного хэширования сохраненных паролей во время входа в систему?

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

  • Хэши паролей генерируются с использованием bcrypt. (Так как правильные параметры, похоже, являются bcrypt, scrypt или pbkdf2, а bcrypt был наиболее легко доступен для меня в PHP.)

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

  • Хеш, параметры алгоритма и соль хранятся вместе. (С тех пор, что функция PHP crypt дает мне значение хэша.)

  • После успешного входа в систему хэш пересчитывается с помощью новой случайной соли.

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

Мои вопросы:

  • Разве это пустая трата времени?

  • Существуют ли какие-либо опасности при этом?

ОТВЕТЫ

Ответ 1

UPDATE

Re delnan comment: Если вы повторно используете хэшированный пароль, не делайте этого - вы никогда не знаете, какие уязвимости могут возникнуть, и их можно найти в цепочке хэшей. Очевидно, что с другой стороны вам нужно вычислить всю хэш-цепочку каждый раз, когда вы проверяете секрет пользователя - так что просто повторите хеш-текст.

ОРИГИНАЛ

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

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

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

  • Поощряйте пользователей выбирать трудно взломать пароли.

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

Ответ 2

UDPATE

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

ОРИГИНАЛ

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

Рассмотрим следующее:

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

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

Ответ 3

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

  • Нет никакой опасности в этом случае тратить ресурсы сервера.

Ответ 4

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