Антипаттерн: хранить пароли в базе "как есть"
Да, звучит как очевидный совет, но на практике до сих пор встречаются проекты, где пароль сохраняется в чистом виде или максимум в MD5(). Это огромная брешь в безопасности: одна утечка = полный доступ злоумышленника.
Как правильно:
1. Никогда не храните пароль в открытом виде.
2. Используйте алгоритмы адаптивного хэширования:
– bcrypt
– scrypt
– Argon2 (считается современным стандартом).
3. Настраивайте "cost factor" (число итераций), чтобы усложнить брутфорс.
4. Добавляйте "соль" (salt) к каждому паролю. Обычно библиотеки делают это автоматически.
5. Для дополнительной защиты можно применять pepper — секрет, хранящийся вне БД (например, в конфиге или KMS).
Плохой пример:
Хороший пример (псевдокод):
Итог: база данных не должна "знать" пароли пользователей. Она должна хранить только безопасные хэши.
Сохрани пост, чтобы потом показать тем, кто всё ещё пишет MD5(password)
Да, звучит как очевидный совет, но на практике до сих пор встречаются проекты, где пароль сохраняется в чистом виде или максимум в MD5(). Это огромная брешь в безопасности: одна утечка = полный доступ злоумышленника.
Как правильно:
1. Никогда не храните пароль в открытом виде.
2. Используйте алгоритмы адаптивного хэширования:
– bcrypt
– scrypt
– Argon2 (считается современным стандартом).
3. Настраивайте "cost factor" (число итераций), чтобы усложнить брутфорс.
4. Добавляйте "соль" (salt) к каждому паролю. Обычно библиотеки делают это автоматически.
5. Для дополнительной защиты можно применять pepper — секрет, хранящийся вне БД (например, в конфиге или KMS).
Плохой пример:
SQL:
INSERT INTO users (login, password) VALUES ('admin', MD5('123456'));
Python:
hashed = bcrypt.hashpw(password, bcrypt.gensalt())
store_in_db(user, hashed)Итог: база данных не должна "знать" пароли пользователей. Она должна хранить только безопасные хэши.
Сохрани пост, чтобы потом показать тем, кто всё ещё пишет MD5(password)
