Как вы храните пароли и проверяете их корректность

[Tim]

Обычно я не заморачивался, да и задачи такие возникали не часто. Но сейчас задача ответственная.

На сколько я понимаю способов хранения паролей в БД не много:
1) В открытом виде (не обсуждаем его)
2) MD5
3) Обратимое шифрования (blowfish например)

2 MD5
На мой взгляд, тут минус в том, что пароль будет передаваться по сети, и если нет HTTPS, то это не самое надёжное решение. Это немного защищает от слива БД, но не от перехвата трафика.

3) blowfish
Тут можно сделать алгоритм хитрее.
1) Клиент получает случайную строку, которую ему требуется зашифровать с помощью ключа-пароля.
2) Сервер ищет строку в БД с соотв логином, пытается расшифровать полученнную от клиента строку с помощью пароля юзера взятого из БД и сравнивает результат с исходной случайной строкой, которая привязана к сессии.
3) Сами пароли в БД могут так же храниться зашифрованные алгоритмом blowfish

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

Минус: где то, на сервере должен лежать ключ, которым можно расшифровать пароль пользователя. Тут возникает вопрос как его защитить. Есть идея сделать отдельный сервис на С++ занимающийся проверкой паролей.

Пока это всё что я смог придумать. Что думаете товарищи?

[kobezzza]

Tim, твои знания безнадёжно устарели. md5 100 лет как нигде не используется, этот алгоритм скомпроментирован и элементарно ломается через радужные таблицы. Т.е. если используешь md5, то можешь хранить в чистов виде - разницы нет.

Для хранения хешей паролей есть стандартизированная функция PBKDF2 (в ноде из коробки есть), где используется алгоритм SHA-2. Надёжность определяется длиной ключа, количеством итераций хеширования и длиной соли. Я обычно использую длину 256, соль 32 (уникальная для каждого пароля, хранится в БД) + статическая соль 32 (хранится в коде) и 8000 итераций, но если надёжность оч важна, то ставь 512 и хотя бы 10 000. Операция хеширования крайне тяжёлая, поэтому есть смысл положить на отдельный сервак.

Что касается снифинга трафика - ставь https и не еби мозг.

А вот пытаться придумать свой алгоритм защиты точно не стоит Криптография -не место для велосипедов.

тк шифруемая случайная фраза каждый раз будет разная.

Тока если у тебя генератор истинно случайных чисел, например снимаются показания сейсмической активности или еще что) В противном случае - это все псевдослучайные величины, тот же Math.random не разу не криптостойкий. Используй хотя бы тогда crypto.randomBytes из ноды - для генерации соли сойдёт.

[Tim]

этот алгоритм скомпроментирован

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

Вот нагуглиг кое-что по теме:
Какое шифрование АНБ не по зубам
АНБ скомпрометировало протокол Диффи-Хеллмана?

А вот из википедии выдержка:

Хеш-функции SHA-2 разработаны Агентством национальной безопасности США и опубликованы Национальным институтом стандартов и технологий в федеральном стандарте обработки информации FIPS PUB 180-2 в августе 2002 года[1].

LOL ))))


kobezzza,
а как на счёт защиты ключа который лежит на серваке?

[Tim]

kobezzza,
я имею ввиду, как защитить ключ если сервер подломят.

[cyber]

Tim, используй SHA-2

[cyber]

1) Клиент получает случайную строку, которую ему требуется зашифровать с помощью ключа-пароля.

Только на клиенте такого не будет(если мы гооворим о веб приложения )

Тока если у тебя генератор истинно случайных чисел

Tim, так что, то что написал kobezzza сейчас лучший вариант .

используется алгоритм SHA-2.

Что касается снифинга трафика - ставь https и не еби мозг.

[kobezzza]

kobezzza,
я имею ввиду, как защитить ключ если сервер подломят.

Ну, если угнали базу и код, то всё равно, чтобы подобрать пароль брутом, если ты использовал pbkdf2 с ключом 512 и кол-вом итераций скажем 10к (т.е. хеш функция вызывается столько раз: хеш от хеша и т.д.) нужны охренительные вычислительные ресурсы, которые есть тока у оч крупных дядей вроде АНБ или гугла. Больше вероятность, что если ты нужен АНБ, то тебя ночью закинут в мешок и отвезут в гуантанамо, где ты сам всё расскажешь

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

Резюме:

1) Используй HTTPS;
2) Используй PBKDF2, а не чистую хеш функцию;
3) Храни статичные коды доступа в переменных окружения сервера.

Также если хочется использовать шифрование на клиенте, то смотри новое API браузера Crypto или компиль в asm.js/wasm и тащи на клиент C-ные либы, но сам ничего не пиши

[cyber]

Больше вероятность, что если ты нужен АНБ, то тебя ночью закинут в мешок и отвезут в гуантанамо, где ты сам всё расскажешь

А если гуглу то тебя либо купят либо засудят

[nerv_]

Tim, судя по твоему первому посту, я предлагаю тебе освежить в глове матчасть по методам шифрования, вспомнить, кто такой Боб, кто Алиса. После чего определиться, какое именно шифрование требуется в твоем конкретном случае (симметричное/ассиметричное).

Если симметричное, см. пост кобеззы.
Если ассиметричное, вероятно, пригодится библиотека от гугла -- crypto-js.

[cyber]

свой коммент выше убрал сюда Обсуждений тред