Безопасное хранение и извлечение паролей (MySQL)

Сначала определись, что ты хочешь с ними сделать.

mysql

побоку

кешировать

хэшировать

их обратно извлекать

не нужно, проще и безопаснее сменить

md5 не очень, sha1 получше

man соль; sha256 > sha1 а вообще — http://www.f-secure.com/weblog/archives/00002095.html

И да, если из твоей базы можно извлечь пароли в исходном виде — ты плюёшь на безопасность пользователей. Так не делают.

Тогда как поступать в тех случаях, когда пароль нельзя сменить?

Что значит «нельзя сменить»?

Определись, что именно ты хочешь.

Хранить чужие пароли — моветон. Только солёные хэши. Бред про «нельзя сменить» не пройдёт.

ну он там писал, что-то про шифрованые разделы, на которых ключевую фразу без старой не сменить
может ТС городит свой велосипед для хранения паролей?

И использовать для этого мускул? При живом sqlite?

Скажите пожалуйста, как лучше всего хранить пароли в базе (mysql)?

Вводишь пароль, добавляешь соль, хешируешь, сохраняешь в базу результат и соль.

Если кешировать, то как их обратно извлекать, в случае утраты пароля (иногда бывает ломается файл keepass'a с паролем от раздела секретного и поменять пароль без старого нельзя). Если сравнивать, то берем пароль введенный, кешируем его и сами кеши сравниваем, а вот как извлечь его в человеский вид?

Когда кто-то вводит пароль, ты к нему добавляешь сохраненную соль, хешируешь, сравниваешь с хранимым результатом.

Способа восстановления пароля не должно быть, только смена.

Не горожу хранение для паролей)

Все пароли заменить не проблема, кроме как случая с секретными разделами, если бы не они, я бы не думал в эту сторону.

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

И подобные случаи более, чем часты.

Варианты с бекапами не предлагайте, это есть и процент уменьшен, но не панацея.

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

Получается, равносильно хранить пароль в открытом виде?

Жопа получается)

Спасибо) буду избегать)

Тогда шифруй пароли, если функция должна быть обратимой.

Обратимое хэширование — это, например, несолёный md5 (или crc, если на то пошло), где по хэшу можно получить что-то, дающее тот же хэш, но это не обязательно будет исходным паролем.

А топикстартер с тем же успехом может хранить в плейнтексте. Впрочем, пару раз обожжётся — и перестанет нести чушь про бесполезность бэкапов и секретные разделы.

А может быть выходом будет, создавать файл с паролями, того же кипасса , например?

Запароленный, то есть . чтоб просто заменить его и все...

Только вот, есть ли возможность генерить такие файлы с раширением kdbx, для кипаса или подобные? Не в ручную)

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

man симметричное/асимметричное шифрование

Пароли пользователей, которые надо только проверять — храни в ассиметричном шифре (sha-1, sha-256). А если уж надо восстанавливать — то симметричный (aes например) и ключ спрятать так, чтоб лучшие специалисты АНБ должны были потратить месяц, чтоб догадаться, что ключ вообще существует. И меняй почаще его (заведи скрипт) и сделай тайм-аут для пользовательских паролей.

Спасибо...

Почитаю...

Если имеется в виду что-то вроде keepass: AES_ENCRYPT(compress('cpyaF8QDu33PQIKqp0SeeT2e'),UNHEX('F3229A0B371ED2D9441B830D21A390C3'));

SELECT uncompress(AES_DECRYPT(UNHEX('B0F3CDE343E3A3159196A6F7C025FA1C3380BD9E753AD829B6D4FD7D667ED1A299E96DC5B2FCCB74A731C7297C93A1D1'),UNHEX('F3229A0B371ED2D9441B830D21A390C3')));

Ключик само-собой надо помнить наизусть / записать на бумажке, query cache отключить.

AES_ENCRYPT(compress - шифрует

uncompress(AES_DECRYPT( - дешифрует?

Верно?

основная идея такая (это относится к любой подобной системе/БД) - сервер не хранит пароль клиента в явном виде и не должен знать о нем физически. Это идеал системы.

Пароль знает и задает только пользователь на свое стороне (клиентской части) т.е. например в браузере. По сети передается периодически подсаливаемый предварительно (каждые 5-10 сек) хэш. Смотри hmac sha512 или больше для надежности. Например. Не соленые хеши по md5 и соленые статически - совершеннейшая ерунда, а так-же хеши слабее sha256 (по хорошему надо иметь несколько вариантов хэшей)

Можно предусмотреть и другие схемы, но главная идея д.б. понятна.

Смысл в том, чтобы к админу хоста/сайта не было претензий и он был бесполезен и вне подозрения, да и ему будет спокойнее. Это значительно исключает утечку информации и не делегирует хранение закрытой персональной информации никому.

Посмотрите pbkdf2 с sha-256 для соли. Количество итераций 10К-100К. Вместо sha-256 можно scrypt, чтобы гиморнее аппаратно ускорять было, но чаще используют sha-256 пока что. Количество итераций специально делают большим, чтобы работало медленно, подробности в гугле.

Хранят обычно как-то так: «алгоритм$сколько_итераций$соль$хеш_пароля» (строка, где $ или : - разделитель, а данные hex или base64). Это занимает одну колонку в базе и позволяет менять параметры генерации пароля, сохраняя совместимость со старыми. Пример:

«$pbkdf2sha256$10000$HW/UjFzFHvI96Hjr1HNFKg==$dnEDCamnTWtxyAOhGHBLU8Hi4KAoOt3y/FH4DoTLbIg=

Можно хранить компактнее, но потеряется универсальность. А шансы что в ближайшие 10 лет захочется поменять хешер и увеличить количество итераций - есть.

эту схему можно в браузере поднять?

В чем конкретно вопрос? Имплементации хешеров гуглятся на любых языках. pbkdf2 - всего лишь сахар, чтобы хешер гонять в цикле, т.к. на один проход таблицы строят, особенно на md5.

Есть еще тенденция (хз откуда) юзать bcrypt хешер, но по нему мало исследований, и он нигде не принят в качестве стандарта. А стандартом принят scrypt, но почему-то пока еще не распространился.

bcrypt и scrypt задумывались для того, чтобы нельзя было с адекватными затратами сделать аппаратный ускоритель.

Понял, спасибо.

У вас в голове смешалось 2 вещи - проверка пароля и шифрование данных. Для того, чтобы проверить, что юзер ввел правильный пароль, его хранят в соленом и хешированном виде, как я описал выше. Для того, чтобы шифровать данные, используют симметричные шиферы типа aes-128.

Обычно ключ шифрования генерят рандомно, а потом шифруют паролем. Это позволяет проделывать такие вещи как «смена пароля» (достаточно перешифровать ключ), «совместный доступ» (у каждого ключ пошифрован его паролем) и «мастер-пароль» (для ключей делаются резервные копии и шифруются паролем админа).

ассиметричном шифре (sha-1, sha-256)

Кенни, а ты-бы сам маны почитал что-ли.
http://ru.wikipedia.org/wiki/Асимметричное_шифрование
http://ru.wikipedia.org/wiki/Sha1

В чем конкретно вопрос?

Благодарю за расшаривание интересной схему во первых.

Собственно, хотел выяснить, что строчку типа как в твоем примере «$pbkdf2sha256$10000$HW/UjFzFHvI96Hjr1HNFKg==$dnEDCamnTWtxyAOhGHBLU8Hi4KAoOt3y/FH4DoTLbIg= можно сформировать в браузере и передать на сервер.

Ведь в этой строчке практически ничего не открыто, так-что можно передать по сети в таком виде теоретически...

Не смешалось) просто не явно выразился)

А так, мне больше нужно шифрование, это я понял, прочитав все что мне написали и на кидали ссылок.)

Сейчас вот пробую...

Спасибо.

На самом деле это более или менее стандартная схема хранения паролей сейчас. На сколько я помню в WordPress (этакая винда в мире CMS) нечто подобное используется, только колличество итераций не хранится явно, а подразумевается названием алгоритма (первый элемент строки).

Но всё-таки в web-е все эти хитрости происходят на сервере, а пароль передаётся в открытом виде. Перенести необратимую модификацию пароля на клиента, по идее, можно только используя JS (ну или всякие там Java/Flash…) или реализовав соответствующие алгоритмы непосредственно в браузере.

На самом деле это более или менее стандартная схема хранения паролей сейчас.

Давно не погружался в эту тему откровенно говоря, может что-то уже не так. Но насколько мне известно, такие схемы достаточно давно уже прижились, по крайней мере использование разделителя $

Просто мне более привычна схема hmac, хотя проблема частой смены соли требует дополнительного внимания. Поэтому интересны (и всегда актуальны особенно в нынешнее время) идеи шифрования полностью на клиенте, а соленые хэши так, для порядка...

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

Да и вообще задача хранения пароля на сервере, например в скриптах, то-же довольно актуальна. Так или иначе связана с темой.

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

Тема давно исследована, надо только выбрать нужный вариант и ни в коем случае не изобретать своё.

хеширование ≠ шифрование

пароли НЕ НУЖНО ХРАНИТЬ и извлекать. Зачем тебе это? Потому их и не хранят, а хранят только хеш.

Пароль к самой базе храни в простом текстовом файле, зашифрованном GnuPG. Из базы его извлечь невозможно, и это не баг, а фича.

PS: md5 ничуть не хуже sha1 на сегодня и на ближайшие 50 лет. За то быстрее, и работает везде. Конечно при условии, что сам пароль достаточно хорош, и имеет соль(как минимум 128 эффективных бита).

Обратимое хэширование — это, например, несолёный md5

что за бред ты пишешь? Пробовал обращать? Вот попробуй, потом пиши. Если пароль достаточно сложный, ты его не подберёшь (за ближайшую 1000 лет). Соль нужна лишь для зашиты от тех дебилов, что ставят пароль «123» или типа того (короткий и/или имеющийся в словарях). Учти, что радужная таблица это тоже словарь (эффектный способ натолкать Over9000 рандомных паролей в небольшое число Гб).

Пароли пользователей, которые надо только проверять — храни в ассиметричном шифре (sha-1, sha-256).

блжад. Ещё один. Это ХЕШИРОВАНИЕ. А НЕ шифрование. Учи матчасть.

Пароль знает и задает только пользователь на свое стороне (клиентской части) т.е. например в браузере. По сети передается периодически подсаливаемый предварительно (каждые 5-10 сек) хэш. Смотри hmac sha512 или больше для надежности. Например. Не соленые хеши по md5 и соленые статически - совершеннейшая ерунда, а так-же хеши слабее sha256 (по хорошему надо иметь несколько вариантов хэшей)

да сколько жеж вас?!

ну сам подумай:

1. клиент делает sha512 от пароля, и передаёт на сервер

2. что мешает врагу вместо пароля использовать ЭТУ sha512???

В том-то и фича, что клиент должен передать на сервер ПАРОЛЬ, и сервер САМ должен сделать соль, и хеш.

Если уж хочешь шифрование по дороге, юзай асимметричное(TLS например. Если параноик, юзай самоподписанный сертификат, если боишься коррумпирования ЦС)

Тема давно исследована, надо только выбрать нужный вариант и ни в коем случае не изобретать своё.

ППКС

а теперь порекомендуй готовое решение для браузера.

да сколько жеж вас?!
ну сам подумай:

там оговорка есть - схема не хранящая пароль на сервере это идеал. Готовых схем нет в этом плане, но есть комбинированные варианты, хотя тоже не идеальные.

1. клиент делает sha512 от пароля, и передаёт на сервер

2. что мешает врагу вместо пароля использовать ЭТУ sha512???

передвать пароль по сети в открытом виде не интересно. Это любой сможет и любой заснифит. Гораздо сложнее и наверное полезнее когда по открытым каналам (да пофиг каким) передается криптованый пакет. Хотя да - тут спасает только SSL.

Вообще, использование hmac с динамической солью для передачи по открытым каналам стандартная практика. Другой вопрос как сделать остальное :) Но пусть не идеал, но к этому можно стремиться...

что за бред ты пишешь? Пробовал обращать?

Да.

Если злоумышленнику попала база MD5-хэшей, он за вполне вменяемое время может подобрать коллизии (не обязательно оригинальные пароли). И да, это делают не на CPU.

радужная таблица это тоже словарь

Спасибо, Кэп.

в небольшое число Гб

Возможно, Вы имели в виду «ТБ».

Соль нужна лишь для зашиты от тех дебилов, что ставят пароль «123» или типа того (короткий и/или имеющийся в словарях)

В словарях могут быть ВСЕ комбинации ASCII-символов длиной в 8-9 символов. А называть клиентов дебилами — не лучший способ ведения бизнеса. Если даже у 10% из них подобрали пароли — это уже плохо.

там оговорка есть - схема не хранящая пароль на сервере это идеал. Готовых схем нет в этом плане, но есть комбинированные варианты, хотя тоже не идеальные.

зачем применять кривые велосипеды, если есть хороший, годный танк?

передвать пароль по сети в открытом виде не интересно. Это любой сможет и любой заснифит.

передавать хеш — тоже самое, только с лишними сложностями. Какая разница что снифать?

Хотя да - тут спасает только SSL.

ну дык что его не юзать во все поля? Если ресурс «только для своих», то хороший метод — сделать самоподписанный сертификат. А для публичного — пусть будет обычный, ну например я не против, если АНБ/КГБ узнает мой пароль к ЛОРу.

Да. Если злоумышленнику попала база MD5-хэшей, он за вполне вменяемое время может подобрать коллизии (не обязательно оригинальные пароли). И да, это делают не на CPU.

да хоть на чём. Кстати, раз ты такой опытный, может покажешь короткую коллизию md5? А то я видел >1000 байт только. И то, специально сгенерированные горы мусора. Ты точно не в теме, раз говоришь такую глупость.

Возможно, Вы имели в виду «ТБ».

сейчас — да. Несколько Тб SSD. Раньше приходилось юзать несколько(десятков) Гб DRAM. HDD для этого не подходят, проще уж так брутить(к тому же «так» можно брутить ВСЕ хеши из БД сразу)

В словарях могут быть ВСЕ комбинации ASCII-символов длиной в 8-9 символов.

бред. Все 281474976710656(64^8) символов? Если ты не знал, то такой словарь будет весить никак не меньше 32768 ТЕРАБАЙТ(sic!). Да, радужную таблицу ты можешь ужать до 32Тб(с цепочкой 1024), но СКОЛЬКО веков ты её будешь делать(даже просто запись на 32х терабайтный SSD массив займёт не одну сотню лет, а ведь ещё и считать нужно)? На сегодняшнем этапе развития технологий это нереально.

А называть клиентов дебилами — не лучший способ ведения бизнеса.

а не называй. Пусть им пароли делает простой JS скрипт в их браузере. Ну а если клиент САМ поставил «123», то это уже ССЗБ, и он должен страдать.

А то я видел >1000 байт только

Серьёзно? Посчитай, сколько байт в самой md5.

Если ты не знал, то такой словарь будет весить никак не меньше 32768 ТЕРАБАЙТ(sic!). Да, радужную таблицу ты можешь ужать до 32Тб(с цепочкой 1024), но СКОЛЬКО веков ты её будешь делать(даже просто запись на 32х терабайтный SSD массив займёт не одну сотню лет, а ведь ещё и считать нужно)? На сегодняшнем этапе развития технологий это нереально.

MD5 Length 8 full US charset tables

MD5 length 8 tables, full US character set, chain length 200k, 4 tables (one torrent per table). Total size with indexes, roughly 1.5TB. GRT-MD5-len8-all-v2-idx0.torrent GRT-MD5-len8-all-v2-idx200k.torrent GRT-MD5-len8-all-v2-idx600k.torrent GRT-MD5-len8-all-v2-idx900k.torrent These tables are now generated and available for download and purchase! To obtain them on external drive, purchase a set online. All major credit cards accepted.

http://cryptohaze.com/gpurainbowtables.php

ещё и считать нужно

md5? Этим можно пренебречь по сравнению со временем I/O.

зачем применять кривые велосипеды, если есть хороший, годный танк?

не спорю, всякий транспорт хорош для своей местности и решаемых задач - происхождение велосипеда связано со специфической задачей разумеется

передавать хеш — тоже самое, только с лишними сложностями. Какая разница что снифать?

это работает в идеале, когда сервер знает пароль - он солит, криптует у себя и результат запоминает, отсылая клиенту соль (специи по вкусу).

Клиент, зная пароль вычисляет результат и отсылает на сервер его.

Сервер (тоже зная пароль) сверяет результат и осуществляет допуск, если ок.

Враг тоже так хочет, но не может т.к. не знает параметров вычисления хэша (вернее может знать по MITM, но у него мало времени на подбор хэша и нет возможности заснифить ввод пароля у клиента) и пароль он не знает разумеется - в целом ему надо снова инициировать запрос на вычисление. Соль динамическая - валидна например 10 сек.

Тут все хорошо, но надо серверу знать пароль. Варианты возможны более сложные - несколько паролей, криптоконтейнер, encode на клиенте. Их цель свести к минимуму присутствие пароля на сервере.

ну дык что его не юзать во все поля? Если ресурс «только для своих», то хороший метод — сделать самоподписанный сертификат. А для публичного — пусть будет обычный, ну например я не против, если АНБ/КГБ узнает мой пароль к ЛОРу.

self-signed имеет место, да SSL спасает в основном. Публичный? Да пофиг, если нечего скрывать, а если например это приватная информация или доступная только с по личному разрешению, да мало ли для чего?

Серьёзно? Посчитай, сколько байт в самой md5.

серьёзно. Байт там ровно 16. Да, согласен, ВОЗМОЖНЫ коллизии, мало того, они ЕСТЬ. Вот ты пойди, и НАЙДИ. Будешь первым.

MD5 Length 8 full US charset tables

ага. Ну я же не говорил, что их нет, есть. Хотя и за деньги. Вот только толку от них маловато, 8 букв это всего 512 эффективных бит(если энтропия каждого символа 64 бита), если ты добавишь как я советовал ещё не менее 128 эффектных бит информации в соли (а лучше больше, жалко что-ли), то составлять РТ будет бессмысленно.

md5? Этим можно пренебречь по сравнению со временем I/O.

ну если у тебя есть заточенный под MD5 ASIC, то да, можно. А если у тебя сотня Xeon'ов, то не думаю. MD5 специально сделали кривой и медленно вычисляемой.

Я думал, что мы изначально высококультурно беседуем о несолёных хэшах. С солью особых проблем нет.

передавать хеш — тоже самое, только с лишними сложностями. Какая разница что снифать?

это работает в идеале, когда сервер знает пароль - он солит, криптует у себя и результат запоминает, отсылая клиенту соль

не нужно знать клиенту соль. Просто отсылаешь пароль открытым тестом(по защищённому каналу разумеется), и всё. А соль клиенту знать необязательно.

И вообще, не мешайте вы все ДВЕ задачи в одну.

1. безопасно сохранить пароль так, что-бы его можно было сравнить(быстро и просто)

2. безопасно передать пароль на сервер от клиента.

Это ДВЕ разные задачи.

Тут все хорошо, но надо серверу знать пароль

всё это не нужно. Необходимо и достаточно двух вещей:

1. клиенту иметь свой ключ(открытый/закрытый)

2. секрверу иметь свой

Если у клиента есть ключ, то пароль, мягко говоря, не нужен.

Я думал, что мы изначально высококультурно беседуем о несолёных хэшах. С солью особых проблем нет.

соль — просто увеличивает длину пароля. Сейчас предел около 9и символов. (если они случайные и алфавит 64 штуки). Просто нужно заставлять клиентов использовать пароли больше 9и символов, и по возможности расширять алфавит в UTF-8 (например русскоговорящих заставлять юзать русские буквы).

Т.е. соль по факту защищает только от «дебилов», а юзеры и есть дебилы в области криптографии. Надо мне свои базы прошерстить, уверен, что у 95% юзеров пароль не сложнее «123».

Если у клиента есть ключ, то пароль, мягко говоря, не нужен.

увы. Как сервер сопоставит ЭТОГО юзера с ЭТИМ ключом? Не, есть конечно OpenID, вот только 5% юзеров его боятся, а 95% тупо про него не знают. Увы.

Я его тоже не использую, ибо с ним я также «спокоен», как белая ворона.

Как сервер сопоставит ЭТОГО юзера с ЭТИМ ключом?

Например, если ЭТОТ сервер подписывал ЭТОТ открытый ключ для ЭТОГО юзера — запросто.

Алсо, всевозможные распространённые в этой стране электронные подписи (некоторые госсайты, внезапно, умеют с ними работать) — яркий пример того, как оно работает.

Проблемы аутенфицировать клиента с ключом — нет. Авторизовать его — не сложнее, чем с паролем. Поэтому пароль из схемы часто выкидывается за ненужностью.

не нужно знать клиенту соль.

как насчет динамической соли временного хранения?

Насчет длины 9 символов не согласен. Где оговаривается обоснованно это? То что пароль более 14(-18?) символов дурь и только ухудшает стойкость это известно. Но насчет максимальной длины соли не маловато ли 9?

И вообще, не мешайте вы все ДВЕ задачи в одну.

не считаю так: 1: это криптование или хэши, 2: это или SSL и/или message digest. Где тут смешение?

всё это не нужно. Необходимо и достаточно двух вещей:

ну это уже фактически либо SSL (опять-же) либо gnupg, либо просто криптование как-либо алгоритмом. О чем собственно упоминалось как крипто-контейнер. Если тебе известна более простая схема или есть другая точка зрения, будет не безынтересно...

Поэтому пароль из схемы часто выкидывается за ненужностью.

Это по сути делает персональный сертификат. Но выкидывать пароль страшновато все-же. Если сертификат самоподписный, то уж лучше обмен/верификация дайджестами сообщений.

Например, если ЭТОТ сервер подписывал ЭТОТ открытый ключ для ЭТОГО юзера — запросто.

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

Алсо, всевозможные распространённые в этой стране электронные подписи (некоторые госсайты, внезапно, умеют с ними работать) — яркий пример того, как оно работает.

это которые с java-нашлёпками?

Проблемы аутенфицировать клиента с ключом — нет.

вопрос только в том, какое ПО этим будет заниматься? AFAIK SSL/TLS такого не умеет. Так речь про java нашлёпку? (плагин).