почему хеш + соль? это лучше, чем прибавить соль до вычисления хеша?
// Установка пароля
$salt = generate_random();
$footprint = md5($_POST['password'].$salt).$salt;
save_to_database($footprint);
// Проверка пароля
$footprint = get_from_db();
$expectedHash = substr($footprint, 0, 32);
$salt = substr($footprint, 32);
$actualHash = md5($_POST['password'].$salt);
$is_valid = hash_equals($actualHash, $expectedHash);
я видел в php функцию генерации случайных чисел. но вот случайных токенов - нет. что это за функция?
я прочил про Bcrypt. он уже использует соль. таким образом, дополнительно солить перед использованием этой функции не надо?
// Установка пароля
$footprint = password_hash($_POST['password'], PASSWORD_BCRYPT);
save_to_db($footprint);
// Валидация пароля
$footprint = get_from_db();
$is_valid = password_verify($_POST['password'], $footprint);Не выше, чем для строки qwertyFd4^hLJI*f6
Fd4^hLJI*f6 тоже плохая, недостаточно энтропии.Нет. Никаких требований к сложности и непредсказуемости для соли нет, это вы к паролю такие требования можете предъявлять. А для соли достаточно длины.
1111111111111, 000000000000, my super super super salt ever - это всё словарные варианты, а значит вероятность их попадания в радужную таблицу высока.
1111111111111 плохая, ибо вероятность того, что в радужных таблицах есть хэши для строки qwerty1111111111111 все ещё достаточно велика.
db себе оставляете чисто реализацию абстрактного интерфейса. В db/sqlite его реализацию под SQLite. В коде используем абстрактный интерфейс, а на этапе инициализации приложения инжектим SQLite'ную реализацию где нам надо.
Странно.. Тут многие писали, что вложенность хешей упрощает коллизию. Или это не так?
Миллионы и миллионы операций практически нисколько не изменят количество элементов в выходном множестве.
Для ceph'а есть Rook.