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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Только на клиенте такого не будет(если мы гооворим о веб приложения:) )
Tim, так что, то что написал kobezzza сейчас лучший вариант .

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

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

Резюме:

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

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

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

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

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

свой коммент выше убрал сюда http://javascript.ru/forum/offtopic/...tml#post438555

nerv_,
cyber,
kobezzza,
благодарю за ответы, ушел читать матчасть :)

адын мамент =)

а почему не будет? есть js библиотеки для шифрования

ага, они дают тебя PRNG
https://www.random.org/randomness/
P.s я конечно могу ошибатся, но даже если и можно сделать то это доп. нагрузка на клиент

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

Хеши необратимы поэтому невозможно востановить(сломать) исходные данные. Но для md5 возможно с большой долей вероятности и за приемлемое время подобрать исходные данные для известного хеша.

Упрошено говоря берётся словарь часто используемых слов/паролей и по ним считаются хеши в результате появляется таблица пароль - хеш от него.
Радужные таблицы это способ компактно хранить эту таблицу в памяти и ускорение поиска по этой таблице.
В любом случае для построения радужной таблицы необходимо знать хеш функцию.
Соль позволяет избежать использование заранее построенных таблиц по уже известным функциям т.е. md5+соль гораздо безопаснее чем SHA-2 без соли.

Основное отличие md5 от SHA это скорость вычисления хеш функции если в md5 используется 4ре итерации то в SHA уже около сотни отсюда их сильные и слабые стороны.
Если для мд5 достаточно часика на домашнем компьютере то для SHA уже придется искать майнера с приличной фермой и заводить там python + cuda с другой стороны md5 вообще не нагружает рабочий сервер SHA заметно нагружает сервер сложность построения таблицы вполне преодолима на современном железе.
Прямое преобразование паранои в тепловую энергию :lol:

Только в специальной папочке подальше от всех :)