У меня есть приложение PHP, которое имеет несколько приличную пользовательскую базу. Теперь, к сожалению, он использует sha1 ($ password. $ Salt) все эти годы, и я действительно хочу, чтобы это было в пользу bcrypt. Я нашел несколько хороших способов получить хеш Blowfish, но я по-прежнему не уверен в том, что я должен использовать для преобразования. Вот мои варианты:
Каждый раз, когда пользователь входит в систему, я проверяю, начинается ли хэш с $ 2. Если нет, я предполагаю, что это sha1, введите пароль, введенный пользователем, получите хэширование bcrypt и замените старый хэш в базе данных.
Я заменяю свой класс auth, чтобы сделать это:
$hash = password_hash("rasmuslerdorf", sha1($password . $salt)); Таким образом, преобразование происходит быстрее.
Но, честно говоря, мне не очень нравится любой из вариантов. Оба предполагают, что я все еще сохраняю устаревшую проверку в кодовой базе, от которой я хочу избавиться.
Любые предложения, которые из этих двух лучше, с точки зрения стандартов кодирования? Или у кого-то есть лучшее решение?
Каждая система хранения паролей должна иметь возможность переключиться на лучший алгоритм хеширования, ваша проблема не является проблемой одноразового переноса, как вы думаете. Хорошие алгоритмы хэша паролей, такие как BCrypt, имеют фактор затрат, время от времени вам приходится увеличивать этот коэффициент затрат (из-за более быстрого оборудования), тогда вам нужна такая же процедура, как и для миграции.
Ваш вариант 1 – удобный подход, если хеши не являются ужасными небезопасными (несоленый или очень слабый алгоритм). В API нового пароля PHP вы даже будете иметь функцию password_needs_rehash (), чтобы определить, необходимо ли обновление.
Я бы рекомендовал оставить остаточное пребывание в коде, вы избавите своих клиентов от хлопот, чтобы противостоять их пользователям с недопустимым паролем. Как пользователь я не люблю электронные письма, которые требуют щелкнуть ссылку и повторно ввести мой пароль, пользователи учатся игнорировать такую электронную почту из-за фишинга. Как было сказано ранее, такие резервные копии кода не являются плохими, это необходимый шаг для безопасного обращения с паролями.
Добавьте новый DB col, скажем [passNeedSystemUpdate], ваше значение по умолчанию будет 1. 1 = true или yes и 0 = na.
Обработайте вход пользователя как обычно до тех пор, пока вы не дойдете до конца, а затем запустите проверку, чтобы проверить, не является ли passNeedsSystemUpdate = 1. Если пароль нуждается в обновлении, мы берем пользователей из поля пароля и обновляем новый пароль вместе с passNeedSystemUpdate, который теперь будет 0.
ПРИМЕЧАНИЕ. Если в случае, если ваша БД была скомпрометирована или была, у пользователей не будет другого выбора, кроме как создать совершенно новый пароль. Выше всего немного логики для использования, если вы меняете свое текущее шифрование с sha256 на swcrypt или что-то еще.