Как правильно хранить пароли?

Question

[Space]

Заношу через два поля Логин и пароль. Как правильно и надежно хранить пароли в БД? md5+соль еще актуально или нет? База Mysql.
Если возможно - то пример на php.

UPD:
Мне нужно получать пароль из другого языка, до этого я получал чистый пароль, делая запрос в БД, что небезопасно. Но если я буду хэшировать пароль, например, с помощью password_hash(), то как мне получить его в чистом виде? Делать каким-то образом запрос POST запрос?

Answer 1

[DevMan]

php.net/manual/ru/book.password.php
https://gist.github.com/nikic/3707231
habrahabr.ru/post/194972

хранить в бд как строки.

Comments

[Space]

Спасибо.

Мне нужно получать пароль из другого языка, до этого я получал чистый пароль, делая запрос в БД, что небезопасно. Но если я буду хэшировать пароль, например, с помощью password_hash(), то как мне получить его в чистом виде? Делать каким-то образом запрос POST запрос?

[Назар Мокринский]

Cosmos: Вам не нужно его получать в чистом виде, НИКОГДА!
Для проверки есть функция password_verify(), куда вы передаете сохранённый хэш и якобы пароль, а функция возвращает true если пароль тот, что нужно. Вам же дали пачку ссылок - сходите, почитайте, там всё написано с примерами.

[DevMan]

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

[Lander]

Cosmos: Если я правильно понял, то авторизация проходит чем то типа ajax-запроса. То есть вы можете получить на сервере хэш пароля с помощью password_hash, но использовать на клиенте password_verify Вы не можете. В password_hash используется алгоритм Blowfish, то есть нужно на клиенте написать свою реализацию функции password_verify с использованием Blowfish. Это сложно. Используйте какой нить алгоритм хеширования постандартней. Хешируйте в md5. Реализации md5 есть уже, по-моему, под все языки.

[Валерий Рябошапко]

Lander: откровенно говоря, Вы какой-то бред написали. Зачем на стороне клиента выполнять проверку пароля? Клиенту нельзя доверять такие вещи. Да и про md5 в криптографии пора забыть, 2015-й год к концу подходит.

[DevMan]

Cosmos: лучше объясните зачем нужно "как мне получить его в чистом виде?", ибо есть стойкое ощущение что вы либо делаете что-то не так, либо неправильно описали задачу.
хеши - необратимы, из них нельзя получить исходный текст. если все же нужен пароль в чистом виде, то вам нужно шифрование.

[Space]

DevMan : мне нужно сравнить его на стороннем сервере и преобразовать, ибо там есть бот, который в специальный интерфейс должен внести самый обычный чистый пароль, как будто вводит его человек.

[DevMan]

Cosmos: тогда вам нужно шифрование, которое доступно на обеих платформах.

[Space]

DevMan : понял. Спасибо.

[DevMan]

Cosmos: пожалуйста)

[Lander]

Валерий Рябошапко: Всё что я написал не касается принципов постороения безопасности В ОБЩЕМ. Это касается конкретного вопроса. Человеку надо проверить валиден ли введённый пароль тому, который хранится на сервере или нет (Причём на клиентской стороне)? Я ему и подсказываю решение для его конкретной задачи, так как всей остальной архитектуры и почему именно такое решение требуется мы не знаем.
Да и чем Вам md5 не угодил? Причём тут 2015 год? Он протух?

[DevMan]

Lander: > Он протух?
кагбе да. и не вчера.

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

[Lander]

DevMan : На чём основано мнение о его небезопасности? Или это просто не модно?

[DevMan]

Lander: ну гугланите немного, чесслово. модность тут совершенно не при чем.

[Lander]

DevMan : Гуглил. Да, в качестве цифровой подписи сообщения использовать его не рекомендуется. Я не понимаю почему его для хеширования паролей нельзя использовать? Интересно Ваше авторитетное мнение.

[DevMan]

Lander: потому что достаточно легко поддается брутфорсу: еще лет 5 назад на не самой мощной видеокарте можно было тупым брутом проверять порядка 500 млн хешей в секунду.
в общем читатйте https://ru.wikipedia.org/wiki/MD5 и гуглите остальное сами.

[Lander]

DevMan : Перебрать 2^128 значений не представляется возможным физически! Минимальная энергия изменения состояния помноженая на 2^128 превышает энергию вселенной (К сожалению ссылку на оригинальную статью не нашёл - честно искал :) ). Атаку основанную на парадоксе дней рождения в контексте хеширования паролей осуществить так же невозможно. От использования радужных таблиц спасает использование соли. Да, есть некоторое количество частных случаев строк для которых нашли коллизию, но это всего 8 (помоему) штук и у каждого алгоритма есть такие. Вообщем отправляя меня на википедию и в гугл вы показываете свою некомпетентность и не способность самостоятельно анализировать информацию в области криптографии. Уверен что вы даже не понимаете почему для подписи сообщения md5 не безопасен, а для хеширования безопасен.
В этом нет ничего страшного - каждый специалист в своей области, но спорить про md5 с человеком, который последние 10 лет занимается криптографией - не стоит :)

[DevMan]

Lander: > Перебрать 2^128 значений не представляется возможным физически!
вы не понимаете или намеренно упускаете из виду тот факт, что перебирать 2^128 значений не нужно. достаточно ограничится перебором по словарю и паролями до 8-10 символов чтоб под удар попала существенная доля пользователей слитой базы.
да и просчитанные заранее пары пароль-хэш растут с каждым годом и подбор сводится к банальному поиску по базе.

> От использования радужных таблиц спасает использование соли
разговор был про md5, а не соль.

в общем занимайтесь дальше криптографией и верой что пароль не прилетает в открытом виде, а я доверюсь собственным источникам.

[Lander]

DevMan : Ну вообщем то как я и сказал - вы не владеете предметной областью.

[DevMan]

Lander: да-да-да, вы самый умный. проходили такое не раз.

[Lander]

DevMan : Нет. Просто после: "вы не понимаете или намеренно упускаете из виду тот факт, что перебирать 2^128 значений не нужно. достаточно ограничится перебором по словарю и паролями до 8-10 символов чтоб под удар попала существенная доля пользователей слитой базы." и "> От использования радужных таблиц спасает использование соли
разговор был про md5, а не соль." я понял что спорить то с Вами бессмысленно так так предметом вы владете на уровне википедии. Наверное оно Вам больше и не надо. :)

[DevMan]

Lander: чувак, ты сейчас реально будешь на голубом глазу доказывать что перебор md5-хэшей не возможен?
ну тогда 10 лет было потрачено напрасно.

[Lander]

DevMan : Да перебирайте на здоровье. Никто вам не запрещает перебирать что либо... Впрочем любой "алгоритм" можно перебирать и конкретно md5 тут не причём. Конечно можно организовать атаку по словарю... да можно и вручную подобрать если пароль вроде "123" или "qwerty", но опять же безопасность алгоритма в данном случае не имеет никакого значения. Вы реально этого не понимаете?

[DevMan]

Lander: я реально понимаю что дохрена юзеров ставят пароли вида password1 (в лучшем случае) или а1а1а1 или admin (в худшем), которые при современных мощностях элементарно пробиваются.
Hash type: MD5
Speed/sec: 59.34M words
Hash type: md5($pass.$salt)
Speed/sec: 45.07M words

Hash type: SHA256
Speed/sec: 17.80M words
Hash type: sha256($pass.$salt)
Speed/sec: 16.82M words

Hash type: SHA512
Speed/sec: 4.10M words
Hash type: sha512($pass.$salt)
Speed/sec: 3.93M words
и это результат далеко не самой шустрой тулзы.

считаете, что md5 норм - ваше право, спорить мне не интересно.

Answer 2

[test13r]

В идеале ни сами пароли, ни какие либо ключевые последовательности вообще хранить не нужно нигде.
По возможности лучше не хранить пароли в открытом виде.
А приемлемым всё еще является хранение не самого пароля, а его одностороннего преобразования (hash) со всякими полезными нагрузками в виде "соли". Весь прикол в этом преобразовании в том, что самого пароля, то и нет. Есть лишь какая-то последовательность символов которую никак не преобразовать обратно.
Таким образом всё сводится к тому, что пароль в чистом виде по сети не передавался, а передавались результаты преобразования. В итоге при получении на сервере, к примеру, запроса авторизации, сверяется именно преобразованная последователь. Вот где-то тут и пропадает необходимость действия по восстановлению чистых паролей.

Comments

[DevMan]

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

[Lander]

DevMan : Пароль на клиента в открытом виде? То есть любой снифер может скомпроментирвоать всю систему? Вы ничего не путаете?

[DevMan]

Lander: для защиты от сниферов/mitm-атак используется https. походу это вы путаете.

[Lander]

DevMan : Ну речи про https не шло нигде. Да и поспешу Вас разочаровать, далеко не все сайты на которых есть авторизация работают через https. Да и все фреймворки и CMS не требуют https для работы, однако обеспечивают безопасность пароля.

[DevMan]

Lander: фреймворки и cms обеспечивают надежное хранение (да и то не все), а не передачу по сети.

спорить со мной не нужно: достаточно поставить любой http-снифер, залогинится на любой сайт без поддержки https и посмотреть на отправленные запросы.
ну и/или воспользоваться логикой и немного подумать.

[Валерий Рябошапко]

Lander: вот именно потому, что любой сниффер может легко украсть пароли, настолько активно HTTPS продвигается в жизнь, что в HTTP2 хотели даже вообще отказатья от нешифрованных соединений. И, ещё раз повторюсь, считать хэш от пароля на клиенте нельзя (не имеет смысла), потому что клиенту доверять нельзя. Это всё равно, что в браузере поставить галочку «я подтверждаю, что я Вася Пупкин» и пускать в систему по одной лишь этой галочке.

[zooks]

Lander: пароли действительно уже давно передаются через https даже на сайтах с http. А на сайтах без защиты они могут быть похищены с скомпроментированного промежуточного хоста.

Answer 3

[Александр Кубинцев]

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

Comments

[Space]

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

[Александр Кубинцев]

Cosmos: с этой постановки задачи и нужно было начинать. Если у вас есть ответственность перед кем-то за сохранность паролей, то задача переформулируется в то, как лучше зашифровать данные.
Если вспоминать практики хранения карточных данных, то в идеале у вас должен быть отдельный сервер или виртуальная машина под базу данных логинов и паролей. При этом он должен находиться в отдельной зафаерволенной подсети, куда доступ ограничен насколько только возможно. При этом ваше основное приложение не должно иметь прямого доступа к БД, только через API-сервис, который может крутиться на этом же сервере. Сервис в свою очередь обеспечивает шифрование/дешифрование данных с помощью одного или нескольких ключей, которые необходимо вводить при (ре-)старте сервиса. Транспортный уровень протокола также должен быть защищенным и это не сложно: настраивается проксирование nginx-ом, чтобы снаружи можно было подключиться только клиентскому SSL-сертификату.

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