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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это по сути делает персональный сертификат.

да. Проблема в том, что если передавать сертификат по интернету, сервер может НЕ ТОМУ сертификат передать. Откуда сервер знает, что ему пишет Вася Пупкин, а не Петя Залупкин?

Не, SSL/TLS даёт конечно такую возможность используя локальный ключ, но тут другая проблема: в 95% случаев у клиента Windows™, а значит локально уязвима.

Т.е. идентификация сервера проблемы не представляет, но с клиентом сложнее: нужно что-то такое, что юзер вводит САМ, ручками.

да. Проблема в том, что если передавать сертификат по интернету, сервер может НЕ ТОМУ сертификат передать. Откуда сервер знает,

1. второй пароль

2. персональный сертификат

Т.е. идентификация сервера проблемы не представляет, но с клиентом сложнее: нужно что-то такое, что юзер вводит САМ, ручками.

3. самое простое: вычисление соленого/подсоленого хэша

4. манипуляции с крипто-контейнерами (тупо encode сообщения каким-то крипто-стойким алгоритмом, работающим на JS в браузере)

5. расширение браузера (для лисы :))

6. юзер САМ вводит, да. Возможны реализуемые варианты. По сути это 1,4 пункт этого списка.

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

а как насчёт врага, который осилил написать скрипт?

Насчет длины 9 символов не согласен. Где оговаривается обоснованно это?

ну возьми и посчитай. Только учти, что md5 является сама по себе сложновычисляемой, и это не баг, а фича. И что РТ не такие уж и хорошие, как это кажется в теории. В теории тебе нужно прочитать C раз по 16 байт. Это кажется «быстро». Но это только кажется. На самом деле, _никакой_ современный девайс по 16 байт читать тупо не умеет, в т.ч. DRAM. Потому скорость НАМНОГО медленнее. HDD тут тупо непригодны.

Ну и да, вопрос в деньгах. 9 символов в пароле достаточно, если бюджет взломщика <$1000 (на сегодня конечно). Если бюджет анлимный, то надо ещё символов добавить.

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

почему «дурь»? Единственная беда в том, что человеку такой код с первого раза не вбить, и он его 10 раз будет вбивать, что конечно очень обрадует злоумышленника. Человек вообще не может запомнить более 7и символов за раз, и то, если они «простые» (например буквы _родного_ алфавита), так символ «{» занимает как минимум две «ячейки» мозга. Т.е. пароль вида "!;%%We#$c" придётся вбивать за три приёма минимум, три раза показывая злоумышленнику бумажку (ибо запомнить это нереально)

Но насчет максимальной длины соли не маловато ли 9?

да, это я ошибся. 6*9=54. Для 128и бит надо минимум 15 символов в соли, при условии идеального ГСЧ и алфавита 64 символа. IRL я просто беру 20 байт из хорошего ГСЧ для соли.

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

увы — нет. IRL я юзаю GnuPG. А в своих велосипедах криптографию из OpenSSL.

тупо encode сообщения каким-то крипто-стойким алгоритмом, работающим на JS в браузере

хм, с этого места пожалуйста поподробнее... Я помнится видел md5 на JS, это УЖЕ лютые тормоза. А что, есть какой-нить AES например?

по остальным пунктам это либо пароль, либо NoWay.

а как насчёт врага, который осилил написать скрипт?

не успеет - на то и дается 10 сек + комбинации и смены алгоритмов

Человек вообще не может запомнить более 7и символов за раз

1. pwsafe copy/paste,

2. ssh-id типа

да, это я ошибся. 6*9=54. Для 128и бит надо минимум 15 символов в соли, при условии идеального ГСЧ и алфавита 64 символа. IRL я просто беру 20 байт из хорошего ГСЧ для соли.

вот мне то-же показалось, даже смутило. Но это зачетно т.к. тут довольно легко заблуждаться, ошибиться - главное мнимизировать ошибки, докопаться до приемлемой схемы. Паранойя подсказывает что лучше 256,512,1024 битовые. Это сложно конечно. По сути соль это вектора, ключи. На этой слабости основаны кряки wi-fi и кстати там в полный рост используется hmac.

Да, когда свое - трудно детектировать и предсказать... Так что актуально. Ну и плюс SSL.

хм, с этого места пожалуйста поподробнее... Я помнится видел md5 на JS, это УЖЕ лютые тормоза. А что, есть какой-нить AES например?

AES нафиг (много нареканий и наездов - предмет горячих споров), bluefish есть из свободных, TEA но он не совсем свободен. Надо посмотреть в ядре, что там популярно и погуглить реализацию на JS. Если интересно то могу позже выслать ссылки на JS-кодеры. Но это гуглится легко в общем. От гугла есть библиотека вроде еще.

Я помнится видел md5 на JS, это УЖЕ лютые тормоза.

Скорость постоянно улучшается да и сам говоришь он по определению тормознут. Да, есть и много очень.

а как насчёт врага, который осилил написать скрипт?

не успеет - на то и дается 10 сек + комбинации и смены алгоритмов

скрипт успеет.

pwsafe copy/paste,

1. убей не понимаю, чем это лучше чистого текста в gpg?

2. в сбербанке paste не работает. А на ЛОРе можно прямо в браузере хранить пароль.

Паранойя подсказывает что лучше 256,512,1024 битовые.

ну говорю же: да, для машины лучше 1024 бита и даже больше. А вот для человека — увы. Мозги у нас такие, не эффективные в этом смысле. Слабость сильного пароля в том, что его задолбаешься набирать, если в нём нет смысла. Е?л? с?ы?л е?т?, его просто подсмотреть.

Да, когда свое - трудно детектировать и предсказать..

своих алгоритмов я не использую. Те же md5/sha есть в OpenSSL.

AES нафиг (много нареканий и наездов - предмет горячих споров)

а я юзаю. Как и большинство юзеров GnuPG. И ты тоже наверное(для проверки введи gpg --edit-key you, потом showpref). Ты что-то путаешь.

bluefish есть из свободных

ну GnuPG его умеет.

Надо посмотреть в ядре

вот ядро нафиг. Зачем там шифрование?

Скорость постоянно улучшается

ага. Как и алгоритмы. Чем лучше алгоритм, тем он медленнее. Сравни например md2, md4, md5, sha*. (это хеш, но по скорости та же картина)

да и сам говоришь он по определению тормознут.

он «тормознут» если речь про меня с C/C++ и x86, и врага с C/C++ и x86. Тогда у меня «тормознут», а врагу NoWay. А вот если у меня JS+LLVM, а у врага C/C++ + x86, то всё не так радостно.

Да, есть и много очень.

пионерские поделки скорее всего. Да, ещё надо RSA какой-нить. MD5, как я говорил, я видел.

а я юзаю. Как и большинство юзеров GnuPG. И ты тоже наверное(для проверки введи gpg --edit-key you, потом showpref). Ты что-то путаешь.

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

вот ядро нафиг. Зачем там шифрование?

там есть секция в настройках по криптографии. Используется думаю для wi-fi. Удобно по ядру выбирать алгоритм, который наверняка будет нормально реализован и не будет иметь проблем с лицензиями - т.е. практически свободен.

ну GnuPG его умеет.

не исключено, что GnuPG есть (в облегченном варианте) на JS для браузеров или какие-то кастомные версии...

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

с какими ещё «ослабленными»? RSA вполне надёжный *алгоритм*. Ты явно путаешь с чем-то другим. Может с недавним скандалом в жёлтой прессе(отголоски здесь, оригинала в рунете ненагуглил, только «журнал хацкер», «хабра», и прочее говно. Здесь тему удалили. ИМХО правильно.)

Эти три буквы «RSA» в деле Сноудена значат совсем другое.

там есть секция в настройках по криптографии. Используется думаю для wi-fi

wi-fi это РЕШЕТО. Я его сам ломал. О чём тут может идти речь-то? Если честно, я не знаю, зачем стандарты связи РЕШЕТО. Наверное это здесь оффтопик. Впрочем, лично я этим доволен. Мне-то фиолетово, у меня связь внутри моих сеток вся через OpenSSH. А остальные пусть страдают, да.

не исключено, что GnuPG есть (в облегченном варианте) на JS для браузеров или какие-то кастомные версии...

ну говорю-же: скорость никакая. Или если сделать ключ в 36 бит, его любой мудак сломает.

wi-fi это РЕШЕТО. Я его сам ломал. О чём тут может идти речь-то? Если честно, я не знаю, зачем стандарты связи РЕШЕТО.

С WPA2-AES то? А ещё и 802.1x EAP-TLS прикрутить? Но тут я бы скорее не доверял бы точке доступа (подобные бекдоры там уже были). Для критичного трафика, очевидно, нужно end-to-end туннель поднимать.

С WPA2-AES то?

оно устойчивое если только пароль хороший.

Но тут я бы скорее не доверял бы точке доступа

и это тоже.

Для критичного трафика, очевидно, нужно end-to-end туннель поднимать.

для _любого_. Ибо в противном случае, враг может отличить критичный трафик от не критичного.