- 1
setcookie('password', $passHash , time() + $this::TIME_COOKIE * 1000 + $remember ? $this::TIME_COOKIE_REMEMBER : 0 * 1000 );-
PHP / Говнокод #15808
+157
И я то думал, почему кука не появляется...
Запостил:
Dart_Sergius,
21 Апреля 2014
Follow us!
Вот говно
Если у тебя упёрли базу с чистыми или плохо просоленными паролями - ты подложил жирную свинью своим юзерам ;) Ведь большинство из них юзало эти пароли на других сайтах.
Ну и насчет загрузить кодярник. А что, если хакер нашел только sql иньекцию, которая позволяет надергать записей о юзерах из таблички с оными, а полного доступа не получил?
Кстати о просолки паролей у нас пароли юзеров солятся разными солями. если id пользователя кратен 5 то одна соль если 2 то другая. Если не 1 и не 2 то 3. По мне это параноя но как есть.
Вот поставят у вас юзер с айдишкой 10 и юзер с айдишкой 15 одинаковый пароль, и будет у них одинаковый хеш ;) Толку от такого алгоритма - ноль без палочки. Соль должна быть случайная и разная (ну по возможности, из-за конечной длины соли она может изредка совпадать) во всех учетках, ну на крайний случай - базироваться на логине/айдишке. Так что это не паранойя, а затыкание пробоины пальцем ;)
> Тут главное условие если уперли БД.
Тут главное условие - получили доступ к табличке с аккаунтами. Всю бд для этого переть излишне.
google PBKDF2, bcrypt, scrypt
Разломали по словарю тысчонку другую паролей из ста тысяч - это уже профит ;)
Тремя разными солями ты увеличил им время работы в 3 раза (по сравнению с несолёными). Круто, чо.
P.S. Хеш надеюсь не md5?
1. хеш 2. соль. надо только вычислить способ соления (т.е. куда соль прикладывается к паролю спереди сзади в середину или еще как).
И поэтому этот алгоритм, внезапно, легче исследовать и доказывать его надежность.
> надо только вычислить способ соления
Упрут из кода. Не забывай, что злодеем может оказаться психанувший бывший сотрудник твоей же конторы.
Я тут вот что подумал что надо конечно в БД хранить соли к паролям юзера + солить еще солью с кода. тогда все станет еще сложней. Ну и обязательно формы авторизации через https
Самый лол в том, что одноглазники до сих пор до этого не додумались :) Пароли летают прямо открытым текстом.
Поскольку 99% разработчиков небогаты фантазией, то, если известен хотя бы один пароль на ресурсе, соль можно и набрутить. Или даже алгоритм соления.
Как я написал ниже, у меня была база хэшей и солей, но неясно, каких. Ну, фигле, зарегал нового пользователя, поставил пароль 123456, посмотрел хэш, соль, засунул в генератор и нашёл, что алгоритм примитивный.
Явсегдабудучитатьвесьтредпереддобавление мкомментария.
Но вектор атаки вполне очевидный.
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )
>Тут главное условие если уперли БД.
с таким подходом из даже из базы воровать не надо, достаточно XSS
пароль должен 1 раз передаваться на сервер, чтобы там сравнить хеш, и все, дальше идентификатор сессии.
В идеале он вообще не должен никуда передаваться ;)
а так, да, помечтать можно
Ну если не srp -так любой challenge-response на жс наваять можно.
но вообще, это на уровне браузера должно работать, а не амебного JS
Само собой. Причем в идеале это должно быть какое-то особое окошко, которое никак нельзя изобразить с помощью хтмл и жс.
Не-не-не. Я себе это так представляю. В самом хтмл будет только кнопка "войти" (без ограничений по дизайну, просто кнопка). И дальше браузер будет показывать свое всплывающее окно, которое юзер всегда сможет отличить от любой верстки. Можно воспользоваться затенением всего браузера, как в UAC семерочки, а может быть как в фаерфоксе сейчас выпадает окошко запомнить пароль...
Ну и юзер должен привыкнуть, что пароль он вводит только в это окошко, и никуда больше.
Иначе толку от всего этого SRP в браузере - ноль.
Это совсем не то, т.к. от митма оно не защищает вообще никак.
И причем тут браузеры? TLS-SRP это стандарт, часть TLS. Ну согласен, должны. Но у меня оно вообще нигде еще не работало. Есть желающие попробовать, кстати?
?
Потому что если окошко для ввода пароля можно сэмулировать на хтмл/жс - то страничка может получить и отправить этот пароль безо всяких SRP куда надо. Сделают тот же самый MITM с подменой формы/скриптов, что и с жсной реализацией, да и всё.
Короче без отдельного окошка браузерное SRP будет ничуть не безопасней, чем если его запилить на жс.
Иллюзия безопасности хуже ее отсутствия ;)
Какие пробовал?
http://web.archive.org/web/20111018150520/http://trustedhttp.org/wiki/TLS-SRP_in_OpenSSL
Ну и google:tls-srp openssl
Кстати, есть еще одна тонкая проблема: SRP никак не защищает от хуёвых паролей. А из-за того, что пароль никогда не будет доступен серверу - он не сможет проверить, удовлетворяет ли этот пароль требованиям безопасности...
Т.е. придется еще и политику паролей форсить на уровне браузера ;( Я это вижу так - при регистрации сайт указывает минимальные требования к паролю, а браузер проверяет их.
Оптимист. Рейт обычно держится около 60%.
Я как-то случайно выкачал базу одного, гм, говнопортала. Там отдельная кулстори.
Если вкратце - разработчики упоролись и выводили в коде страницы (!) хэши (!!) паролей пользователей, мыла (!!!) и всякую подобную инфу. Страница весила мегабайт двадцать.
Скрипт, который выгребал хэши, словарь на шесть гигов, вот и эти самые 60-70% винрейта.
Можешь начинать :)
http://www.php.net/manual/en/ref.password.php
а) почти безразлично, насколько хорош собой алгоритм, если словарём можно вскрыть 60..90% паролей;
б) будущее за аппаратными средствами, в хранении паролей в базе не будет необходимости. Уязвимости могут существовать, например, всё ещё можно украсть пароль из браузера или памяти сервера, но сливать базу на сотни тысяч паролей будет невозможно.
И это после разоблачений Сноудена?
К нему на блатхату пришли журнализды, он собрал мобилки, выключил и спрятал в холодильник.
Это говорит либо о том, что он упорот, либо любит хорошие мистификации, либо статью писал норкоман.
Столлман об этом десятилетиями говорит.
Мож ПРОЦЫ не такие медленные как раньше?
Влом тебе все расписывать.
А если ты добавил соль в начало, то это не усложнит злоумышленнику жизнь
Так во всем виноват разраб, забывший добавить кнопочку "забыли пароль"? :)
P.S. А, понял, тут атакующий подбирает соль зная хеш и пароль. Да, вполне логичная атака.
Ну вот научатся браузеры в SRP - будет кошерно. Сам жду этого дня ;(
Соль можно хранить в базе, она не секретна и нужна для того, чтобы порадовать злоумышленника и не дать ему подобрать пароли по радужным таблицам