Безопасный хэш и соль для паролей PHP
Дейв ДеЛонг прав. Я думаю, что вы ищете способ опрокинуть кластер, посмотрите на NSObjectSafe , это крошечная среда с открытым исходным кодом, которая привязывает большинство обычно используемых функций контейнера Foundation, таких как [NSArray objectAtIndex:]
7 ответов
ПРАВОВАЯ ОГОВОРКА : Этот ответ был записан в 2008.
С тех пор, PHP дал нам
password_hashиpassword_verifyи, начиная с их введения, они - рекомендуемый пароль, хеширующий & проверка метода.теория ответа является все еще хорошим чтением все же.
TL; DR
Don'ts
- не ограничивает, какие пользователи символов могут ввести для паролей. Только идиоты делают это.
- не ограничивают длину пароля. Если Ваши пользователи хотят предложение с supercalifragilisticexpialidocious в нем, не препятствуйте тому, чтобы они использовали его.
- Никогда не хранят пароль Вашего пользователя в простом тексте.
- Никогда не посылают пароль по электронной почте Вашему пользователю кроме тех случаев, когда они потеряли их, и Вы отправили временный.
- Никогда пароли журнала любым способом.
- Никогда пароли хеша с SHA1 или MD5 или даже SHA256! современные взломщики могут превысить 60 и 180 миллиардов хешей/секунда (соответственно).
- не смешиваются bcrypt и с сырые данные вывод хеша () , или используют шестнадцатеричный вывод или base64_encode это. (Это относится к любому входу, который может иметь жулик
\0в нем, который может серьезно ослабить безопасность.)
сценарий Использования Dos
- , когда Вы можете; bcrypt, если Вы не можете.
- Использование PBKDF2, если Вы не можете использовать или bcrypt или сценарий с хешами SHA2.
- Измененный общие пароли, когда база данных поставилась под угрозу.
- Реализация разумная символьная минимальная длина 8-10, плюс требуют по крайней мере 1 прописной буквы, 1 строчной буквы, числа и символа. Это улучшит энтропию пароля, в свою очередь делая его тяжелее для взламывания. (См. раздел "What makes a good password?" для некоторых дебатов.)
, Почему пароли хеша так или иначе?
цель позади хеширования паролей проста: предотвращение злонамеренного доступа к учетным записям пользователей путем заключения компромисса базы данных. Таким образом, цель хеширования пароля состоит в том, чтобы удержать хакера или взломщика путем стоения им слишком большого количества времени или денег для вычисления незашифрованных паролей. И время/стоимость является лучшими средствами устрашения в Вашем арсенале.
Другая причина, что Вы хотите хороший, устойчивый хеш на учетные записи пользователей, состоит в том, чтобы дать Вам достаточно времени для изменения всех паролей в системе. Если Ваша база данных поставится под угрозу, то Вам будет требоваться достаточно времени к в [1 132], наименьшее количество блокирует систему вниз, если не изменяют каждый пароль в базе данных.
Jeremiah Grossman, технический директор безопасности Whitehat, указанный на его блоге после недавнего восстановления пароля, которое потребовало повреждения "в лоб" его защиты паролем:
Интересно, в переживании этого кошмара, я изучил МНОГО я, didn’t знают о взламывании пароля, устройстве хранения данных и сложности. I’ve прибывают для понимания, почему устройство хранения данных пароля настолько более важно, чем сложность пароля. Если Вы, которых знают don’t, как Ваш пароль хранится, то все действительно можно зависеть от, являетесь сложностью. Это могло бы быть общеизвестным к паролю и crypto профессионалам, но для среднего InfoSec или эксперта по безопасности в Интернете, я высоко сомневаюсь относительно него.
(Шахта Emphasis.)
, Что делает хороший пароль так или иначе?
Энтропия . (Не то, чтобы я полностью подписываюсь на точку зрения Randall.)
Короче говоря, энтропия состоит в том, сколько изменения в пароле. Когда пароль является только строчными римскими буквами, это - только 26 символов. Это не много изменения. Алфавитно-цифровые пароли лучше с 36 символами. Но разрешение верхнего регистра и нижнего регистра, с символами, является примерно 96 символами. Это намного лучше, чем просто буквы. Одна проблема, для создания наших паролей незабываемыми, мы вставляем patterns—, который уменьшает энтропию. Ой!
энтропия Пароля , приблизился легко. Используя полный спектр символов ASCII (примерно 96 typeable символов) приводит к энтропии 6,6 на символ, который в 8 символах для пароля является все еще слишком низким (52,679 битов энтропии) для будущей безопасности. Но хорошие новости: более длительные пароли и пароли с unicode символами, действительно увеличивают энтропию пароля и делают ее тяжелее для взламывания.
существует более длительное обсуждение энтропии пароля на сайт Crypto StackExchange . Хороший поиск Google также поднимет много результатов.
В комментариях я говорил с @popnoodles, кто указал, что осуществление политика паролей X длин с X много букв, числа, символы, и т.д., могут на самом деле уменьшить энтропию путем создания схемы пароля более предсказуемой. Я действительно соглашаюсь. Randomess, максимально действительно случайный, всегда является самым безопасным, но наименее незабываемым решением.
, Насколько я был в состоянии сказать, делая лучший в мире пароль, Уловка - 22. Любой не незабываемый, слишком предсказуемый, слишком короткий, слишком много unicode символов (трудно для ввода в Windows/мобильном устройстве), слишком долго, и т.д. Никакой пароль не действительно достаточно хорош в наших целях, таким образом, мы должны защитить их, как будто они были в Форт-Ноксе.
Лучшие практики
Bcrypt и сценарий текущие лучшие практики. Scrypt будет лучше, чем bcrypt вовремя, но это не рассматривало принятие как стандарт Linux/Unix или веб-серверами, и еще не имело всесторонних обзоров его алгоритма, отправленного. Но тем не менее, будущее алгоритма действительно выглядит многообещающим. Если Вы работаете с Ruby существует драгоценный камень сценария , который выручит Вас, и Node.js теперь имеет свое собственное пакет сценария . Можно использовать Scrypt в PHP или через расширение Scrypt или расширение Libsodium (оба доступны в PECL).
я высоко предлагаю читать документацию для функция склепа , если Вы хотите понять, как использовать bcrypt или нахождение себя хороший обертка или использовать что-то как [1 121] PHPASS для реализации более прежней версии. Я рекомендую минимум 12 раундов bcrypt, если не 15 - 18.
я передумал об использовании bcrypt, когда я узнал, что bcrypt только использует ключевое расписание шифров с механизмом переменной стоимости. Последний позволяет Вам увеличить стоимость для "в лоб" пароль путем увеличения уже дорогого ключевого расписания шифров.
Средние методы
я почти не могу больше воображать эту ситуацию. PHPASS поддерживает PHP 3.0.18 до 5,3, таким образом, это применимо почти на каждой установке imaginable— и должно использоваться, если Вы не делаете , знают для определенного что Ваша поддержка сред bcrypt.
, Но предполагают, что Вы не можете использовать bcrypt или PHPASS вообще. Что тогда?
Попытка реализация [1 123] PDKBF2 с максимальное количество раундов , который может терпеть Ваш environment/application/user-perception. Самое низкое количество, которое я рекомендовал бы, является 2 500 раундами. Кроме того, удостоверьтесь, что использовали hash_hmac () , если это доступно для создания операции тяжелее для репродуцирования.
будущие Методы
Прибытие в PHP 5.5 полная библиотека защиты паролем что краткие обзоры далеко любые боли работы с bcrypt. В то время как большинство из нас застревает с PHP 5.2 и 5.3 в наиболее распространенных средах, особенно совместно использованных хостах, @ircmaxell создал уровень совместимости для ближайшего API, который обратно совместим к PHP 5.3.7.
Резюме Криптографии & Правовая оговорка
Вычислительная мощность, требуемая к на самом деле трещина хешированный пароль, не существует. Единственный путь к компьютерам для "взламывания" пароля состоит в том, чтобы воссоздать его и моделировать алгоритм хеширования, используемый для обеспечения его. Скорость хеша линейно связана со своей способностью, которая будет вынуждена скотами. Что еще хуже, большинство хеш-алгоритмов может быть легко параллелизировано для выполнения еще быстрее. Поэтому дорогостоящие схемы как bcrypt и сценарий так важны.
Вы не можете возможно предвидеть все угрозы или пути нападения, и таким образом, необходимо приложить максимальное усилие для защиты пользователей честный . Если Вы не делаете, то Вы могли бы даже пропустить то, что Вы подверглись нападению, пока не слишком поздно... и Вы ответственны . Избегать что ситуация, действие, параноидальное для начала. Нападите на свое собственное программное обеспечение (внутренне) и попытайтесь украсть удостоверения пользователя, или изменить учетные записи другого пользователя или получить доступ к их данным. Если Вы не тестируете безопасность своей системы, то Вы не можете обвинить никого, но Вас.
Наконец: Я не шифровальщик. Независимо от того, что я сказал, мое мнение, но я, оказывается, думаю, что оно основано на старом добром здравом смысле... и большом чтении. Помните, быть максимально параноидальными, сделать вещи максимально трудно для внедрения, и затем, если Вы все еще волнуетесь, свяжитесь с хакером белой шляпы или шифровальщиком для наблюдения то, что они говорят о коде/системе.
-
1На самом деле IPEndPoint наследовался EndPoint. Предложенный состав исполнителей может перестать работать во время выполнения. – Sebastian Good 13 July 2011 в 03:14
SHA1 и соль должны быть достаточными (зависящий, естественно, на том, кодируете ли Вы что-то для Форт-Нокс или система входа в систему для Вашего списка покупок) для обозримого будущего. Если SHA1 не достаточно хорош для Вас, используйте SHA256.
идея соли состоит в том, чтобы бросить результаты хеширования от баланса, так сказать. Известно, например, что MD5-хеш пустой строки d41d8cd98f00b204e9800998ecf8427e. Так, если бы кто-то с достаточно хорошим память видела бы, что хеш и знает, что это - хеш пустой строки. Но если строка посолилась (скажите со строкой" MY_PERSONAL_SALT"), хеш для 'пустой строки' (т.е." MY_PERSONAL_SALT") становится aeac2612626724592271634fb14d3ea6, следовательно неочевидным для следа. Что я пытаюсь сказать, что лучше использовать любой соль, чем не к. Поэтому это не слишком много важности, чтобы знать который соль использовать.
существуют на самом деле веб-сайты, которые делают просто это - можно подать его (md5) хеш, и это выкладывает известный простой текст, который генерирует тот конкретный хеш. Если Вы получили бы доступ к базе данных, которая хранит простые md5-хеши, это было бы тривиально для Вас, чтобы ввести хеш для администратора к такому сервису и войти в систему. Но, если бы пароли посолились, такой сервис стал бы неэффективным.
кроме того, двойное хеширование обычно рассматривается как плохой метод, потому что это уменьшает пространство результата. Все популярные хеши являются фиксированной длиной. Таким образом у Вас может быть только конечное значение этой фиксированной длины, и результаты становятся менее варьировавшимися. Это могло рассматриваться как другая форма соления, но я не рекомендую его.
-
1БАЙТ * pbData = " SomeString" длина size_t = 10 у меня есть длина перед рукой, таким образом, я использовал это: Я использовал этот метод, " станд.:: строка (reinterpret_cast< символ *> (pbData), длина); " Это работает, но однажды в том, в то время как я вижу катастрофический отказ в memcpy. Tryint для нахождения нашего, почему катастрофический отказ произошел, хотя это кажется работой для меня – Unicorn 4 November 2009 в 12:45
Я обычно использую SHA1 и соль с идентификатором пользователя (или некоторая другая определенная для пользователя информация), и иногда я дополнительно использую постоянную соль (таким образом, у меня есть 2 части к соли).
SHA1 теперь также считают несколько поставившим под угрозу, но до намного меньшего градуса, чем MD5. При помощи соли (любая соль), Вы предотвращаете использование дженерика таблица радуги для нападения на хеши (у некоторых людей даже был Google использования успеха как своего рода таблица радуги путем поиска хеша). Взломщик мог очевидно генерировать таблицу радуги с помощью соли, так вот почему необходимо включать определенную для пользователя соль. Тем путем они должны будут генерировать таблицу радуги для каждой записи в Вашей системе, не всего один для Вашей всей системы! С тем типом соления даже MD5 прилично безопасен.
-
1Как педант мобильности, я хочу указать, что это только работает над системами с 2' s дополнительная арифметика. На 1' s дополнение или архитектура величины знака, это не безопасно к reinterpret_cast между
char*иunsigned char*(хорошо, it' s безопасный, но you' ll получают неожиданные результаты, еслиcharподписывается, и любой из символов имеет главный набор битов). В этом случае корреспондент находится, очевидно, в Windows, таким образом, без проблем. – Steve Jessop 4 November 2009 в 13:52
В конце двойное хеширование, математически, не предоставляет преимущества. На практике, однако, это полезно для предотвращения радуги основанные на таблице нападения. Другими словами, именно больше преимущества, чем хеширование с солью, занимает намного меньше процессорного времени в Вашем приложении или на Вашем сервере.
-
1Это не работает, я получаю ошибку при высказывании " ' станд.:: basic_string< _Elem, _Traits, _Ax>:: basic_string (станд. константы:: allocator< _Ty> &) ': не может преобразовать параметр 1 из ' БАЙТ *' к ' станд. константы:: allocator< _Ty> & ' " – Unicorn 4 November 2009 в 12:29
Google говорит, что SHA256 доступен PHP.
необходимо определенно использовать соль. Я рекомендовал бы использовать случайные байты (и не ограничил бы себя символами и числами). Как обычно, чем дольше Вы выбираете, тем более безопасным, медленнее это становится. 64 байта должны быть прекрасными, я предполагаю.
-
1That' s, потому что
std::stringdoesn' t имеют конструктора, который беретunsigned char*, и таким образом, компилятор возвращается к шаблонному конструктору, предназначенному для средств выделения. Необходимо или использоватьstd::string(Iterator begin, Iterator end), илиstd::string(const char*, std::size_t n)и бросить БАЙТ* к символу* – Charles Salvia 4 November 2009 в 12:45
Я не сохранил бы пароль, хешированный двумя различными способами, потому что тогда система, по крайней мере, так же слаба как самый слабый из используемых хеш-алгоритмов.
-
1Нет это won' t. В обоих случаях литеральная строка появится однажды в сегменте данных на запуске программы (берущий ~15 байтов пространства в.EXE файле) и будет скопирована в стек, когда та функция будет вызвана, таким образом, будет 2 копии в оперативной памяти в то время. Автор WTF запутался. (Точка о внесении широко распространенных изменений без преимуществ все еще стоит, конечно.) – j_random_hacker 15 January 2010 в 13:47
Хотя на вопрос был дан ответ, я просто хочу повторить, что соли, используемые для хеширования, должны быть случайными и не похожими на адрес электронной почты, как было предложено в первом ответе.
Более подробное объяснение доступно на- http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/
Недавно я обсуждал, солят ли хэши паролей. со случайными битами более безопасен, чем бит с угадываемыми или известными солями. Давайте посмотрим: если система, хранящая пароль, скомпрометирована как , так и система, которая хранит случайную соль, злоумышленник будет иметь доступ как к хешу, так и к соли, независимо от того, является ли соль случайной или нет, неважно. Злоумышленник может сгенерировать предварительно вычисленные радужные таблицы для взлома хэша. А вот и самое интересное: не так уж и тривиально создавать предварительно вычисленные таблицы. Возьмем пример модели безопасности WPA. Ваш пароль WPA никогда не отправляется на точку беспроводного доступа . Вместо этого он хешируется с вашим SSID (сетевое имя , например Linksys, Dlink и т. Д.). Здесь очень хорошее объяснение того, как это работает. Чтобы получить пароль из хэша, вам необходимо знать пароль, а также соль (имя сети). Церковь Wifi уже предварительно вычислила хэш-таблицы, которые содержат 1000 самых популярных SSID и около 1 миллиона паролей. Размер всех таблиц составляет около 40 ГБ. Как вы можете прочитать на их сайте, кто-то использовал 15 массивов FGPA в течение 3 дней для создания этих таблиц. Предполагая, что жертва использует SSID как «a387csf3 ″ и пароль как« 123456 ″, будет ли он взломан этими таблицами? Нет! .. оно не может. Даже если пароль слабый, в таблицах нет хэшей для SSID a387csf3. В этом вся прелесть случайной соли. Это будет сдерживать взломщиков, которые преуспевают в предварительно вычисленных таблицах . Может ли это остановить решительного хакера? Возможно нет. Но использование случайных солей действительно обеспечивает дополнительный уровень защиты. Пока мы обсуждаем эту тему, давайте обсудим дополнительные преимущества хранения случайных солей в отдельной системе. Сценарий № 1: хэши паролей хранятся в системе X, а значения соли, используемые для хеширования, хранятся в системе Y. Эти значения соли являются предполагаемыми или известными (например, имя пользователя). Сценарий № 2: {{ 1}} Хэши паролей хранятся в системе X, а значения соли, используемые для хеширования , хранятся в системе Y. Эти значения соли случайны. В случае, если система X была скомпрометирована, как вы можете догадаться, существует огромное преимущество использования случайной соли в отдельной системе (Сценарий № 2). Злоумышленник сделает это. необходимо угадать дополнительные значения, чтобы иметь возможность взломать хэшей. Если используется 32-битная соль, для каждого угаданного пароля может потребоваться 2 ^ 32 = 4 294 967 296 (около 4,2 миллиарда) итераций.