Как надо хешировать пароли и как не надо

    image

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

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

    Сразу определю какую задачу применения хешей буду рассматривать — аутентификация пользователей. Не токены восстановления паролей, не аутентификация запросов, не что-то еще. Это также не статья про защиту канала передачи данных, так что комментарии по challenge-response и SSL неуместны!



    Матчасть (короткая)


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

    Для криптографических хэшей есть три дополнительных условия, которые отличают их от всех остальных:
    • Необратимость: для заданного значения хеш-функции m должно быть вычислительно неосуществимо найти блок данных X, для которого H(X)=m.
    • Стойкость к коллизиям первого рода: для заданного сообщения M должно быть вычислительно неосуществимо подобрать другое сообщение N, для которого H(N)=H(M).
    • Стойкость к коллизиям второго рода: должно быть вычислительно неосуществимо подобрать пару сообщений ~(M, M'), имеющих одинаковый хеш

    Подробнее — ru.wikipedia.org/wiki/%D0%A5%D0%B5%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

    Вникать в тонкости криптографии прикладному разработчику не обязательно, достаточно запомнить какие хэш-функции (алгоритмы по названию) можно сейчас использовать, а какие уже нет. MD5 — уже нельзя, коллеги, — используйте bcrypt/scrypt.

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

    Ниже перечислены требования, которым ваш хеш в базе должен удовлетворять:
    • стойкость к атакам перебора (прямой перебор и перебор по словарю)
    • невозможность поиска одинаковых паролей разных пользователей по хешам


    Для выполнения первого требования нужно использовать стойкие в настоящее время (а не в 90х годах!) хеш-функции.
    Для выполнения второго — к паролю перед хешированием добавляется случайная строка (соль). Таким образом, у двух пользователей с паролем «123456» будут разные соли «соль1» и «соль2», а соответственно и хеш-функции от «123456соль1» и «123456соль2» в базе тоже будут разные.

    Теперь немного про систему хранения — и соль и сам хеш хранятся в базе данных.
    То есть получив доступ к СУБД, злоумышленник получает и значения хешей и соли.

    Используйте локальный параметр!


    Чтобы усложнить жизнь при атаке перебора следует дописать соль к паролю, а не наоборот (для людей, которые пишут слева направо, конечно).
    Так как хеш-функция, как правило, вычисляется последовательно по строке (требования поточности алгоритма), то злоумышленнику при переборе «соленых» хешей, будет проще, когда подхешовое выражение начинается с соли.
    Проще потому, что он (злоумышленник) может предвычислить заранее хеш(соль) и далее считать хеш(соль)+хеш(пароль) уже куда быстрее (практически с той же скоростью, что и просто хеш(пароль)). Для всех паролей, что он будет перебирать.

    Для того чтобы еще усложнить жизнь атакующему, Solar Designer www.openwall.com/presentations/YaC2012-Password-Hashing-At-Scale/mgp00005.html предлагает ввести еще одну штуку, под названием локальный параметр.

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

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

    Единственный раз мы (ONsec) ломали хеши с локальным параметром, выработав при этом тактику атаки на сам локальный параметр (регистрируемся в приложении, затем ищем в базе свой хеш, соль (свой пароль мы и так знаем) и перебираем ЛП). И тщетно. На длинах 16+ байт для современных функций хеширования — это очень дорого по железу. В итоге проще оказалось скомпрометировать систему аутентификации (проставить себе role=admin в базе через UPDATE ;) )

    Очень рекомендую ознакомиться с презентацией: www.openwall.com/presentations/YaC2012-Password-Hashing-At-Scale/mgp00001.html

    Защищайте свои хранилища надежно и грамотно!

    Заключение

    Буду реалистом — естественно, никто не станет переписывать свои проекты ради «каких-то» хешей. Но новые проекты можно писать на scrypt/bcrypt. А также — внедряйте локальный параметр даже на слабых MD5 — он правда помогает, проверено :)

    При переходе на другой тип хеширования, помимо трудозатрат, часто встает вопрос производительности. Действительно, более стойкие алгоритмы потребляют больше ресурсов. Тестируйтесь перед внедрением для своих нагрузок по скорости аутентификации пользователей в секунду (для большинства крупных проектов переход на scrypt оказался безболезненным). Выбор конкретного идеального типа хеша в конкретной ситуации может сильно разнится. Так, например, ДБО все чаще выбирают железные решения для генерации хешей с заданной скоростью.

    В заключении, привожу скорости перебора хешей (единицы измерения — мегахэши в секунду, то есть количество ), полученных на карточке AMD Radeon 7990 стоимостью менее $1000 (даже по старому курсу):

    • MD5: 16000 M/s
    • SHA-1: 5900 M/s
    • SHA256: 2050 M/s
    • SHA512: 220 M/s
    • NTLM: 28400 M/s
    • bcrypt: 8,5 k/s


    А по поводу эффективности перебора bcrypt рекомендую также ознакомиться с www.openwall.com/presentations/Passwords13-Energy-Efficient-Cracking/Passwords13-Energy-Efficient-Cracking.pdf
    Share post

    Comments 331

      +32
      теперь нас научили солить
        +3
        и не сравнили алгоритмы хэширования
          +5
          Причём не вдаваясь в подробности зачем это нужно и как это делать.

          1. bcrypt'ованый пароль уже включает соль
          2. bcrypt не участвовал и не выигрывал на конкурсах хеширования
          3. Нет основания доверять bcrypt, его анализом никто не занимался, а его реализация для PHP имеет коллизии

          Относящееся к bcrypt можно также утверждать в отношении scrypt.

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

          Так что то, что автор тут нам советует, защищает от одного вектора атак, но подставляет под другие.
          0
          Проще говоря, нужно солить sha512("{$user->password}{$user->salt}{$global_salt})?

          Ещё я интуитивно делаю хешеривание на стороне приложения, а не в БД — избегаю передачи пароля и глобальной соли лишний раз даже на локальной машине по файловым сокетам, не говоря о сети — мало ли кто как к каналу присосался. Или к логам БД.
            0
            «Ещё я интуитивно делаю хешеривание на стороне приложения, а не в БД — избегаю передачи пароля и глобальной соли лишний раз даже на локальной машине по файловым сокетам, не говоря о сети — мало ли кто как к каналу присосался. Или к логам БД.»

            напишите как схема работает, клиент передает hash(login.salt), где hash вычисляется на JavaScript?
              +3
              Речь идет о серверной части веб-приложения. То ксть, клиент тут не при чем. Коммент выше просто о том, что хэш вычисляется перед помещением в запрос, а не на стороне СУБД.

              А вариант с клиентом не будет работать. Digest авторизация несовместима с хэшированем паролей, увы.
                +1
                Речь о сервере — клиент передаёт в открытом (для сервера приложений) виде, тот сам хэширует и передаёт СУБД уже хэш. Перехват канала сервер — СУБД или логирование запросов СУБД не даст злоумышленнику значений паролей и глобальной соли, только индивидуальную соль сможет получить и общий хэш — пароль и глобальный хэш ему останутся недоступными.
                  –1
                  Предположу что как нибудь так:

                  var hash = CryptoJS.SHA3(Password + CryptoJS.SHA3(Login));

                  А уже на сервере этот хеш солить случайным и глобальным хешем.

                  Хотя нафига, если можно просто зайти по https каналу?
                  0
                  А можно так: sha512($user->secret_formula($user->password,$user->salt)).
                  А функция secret_formula мешает особым образом байты пароля, соли и $global_salt в зависимости от например $user->id (и естественно тоже находится не в базе).

                  А вообще всегда интересовал вопрос: накой нужно подбирать пароль, если уже вся база слита? Из-за теоретической возможности через год залезть в систему с тем же паролем, если дыру закрыли?
                    +1
                    Многие используют одинаковые регистрационные данные на разных сервисах. Подобрали пароль к какому-то локальному чатику, а получили к веб-мани и т. п. Ну или базу слили, а хочется в ней что-то изменить.
                      0
                      Существует несколько общепринятых объяснений.
                      Одно из них — болшинство хомячков имеет один и тот же пароль подо все сервисы => можно уводить мыло, твиттер и пр.
                      Или, авторизовавшись можно получить доступ на запись, а слив мог быть произведён только через чтение — и пр.
                        0
                        Нет. Из-за теоретической возможности слить только базу паролей, без остальных нужных злоумышленнику данных.
                          –1
                          Кстати наиболее известный мне защищенный от подбора способ, это вместо глобального «соления» хранить в базе связку хэш и соль созданую как описано, хоть тем же blowfish, дополнительно «упакованые» aes-ом или twofish-ем, для этого обязательно использовать глобальную связку ключ + начальный вектор (оба не из базы), потому как оба эти алгоритма (blowfish к сожалению нет) вариируют шифр при упаковке каждый раз (т.е. рандомные) при одинаковых ключах. Подобрать такое (плюс еще и неизвестен хэш) практически не реально.

                          Пример, зашифровано 12345 (скажем такой хэш:) ключем 0123456789ABCDEF вектор IVXYZ (прим. *-wo без вектора, только ключ):
                          aes-wo:		MC_	hex: 4d43075f14	
                          aes/iv:		pÚ=Pï	hex: 70da3d50ef
                          twofish-wo:	íX]z!	hex: ed585d7a21	
                          twofish/iv:	ùÒz	hex: 0bf9d2027a
                          blowfish-wo:	™·Pèa	hex: 99b750e861
                          blowfish/iv:	íuxŠ	hex: c3ad75788a
                          
                          и еще раз (как видим aes/iv и twofish/iv изменились):
                          aes-wo:		MC_	hex: 4d43075f14	
                          aes/iv:		ôåÚ2Ý	hex: f4e5da32dd	
                          twofish-wo:	íX]z!	hex: ed585d7a21	
                          twofish/iv:	õU²¶	hex: 0cf555b2b6	
                          blowfish-wo:	™·Pèa	hex: 99b750e861	
                          blowfish/iv:	íuxŠ	hex: c3ad75788a	
                          

                          Не зная ключа и вектора, практически невозможно подобрать пароль, потому что даже выковырять хэш и соль из динамичного шифра — это очень большая проблема.
                            0
                            Эх. Зачем это, скажем, форуму, на котором 3.5 анонимуса?
                              –1
                              ему не надо, но там и солить не сильно нужно…
                              А так это ж просто, практически двумя строчками, не сильно усложноив алгоритм соления (при создании зашифровать, при логине расшифровать значение из базы), настолько усложнить жизнь хакеру, что можно даже скормить ему базу (я утрирую), нехай терзает свое железо.
                                0
                                Солить нужно всегда. В отличие от подключения современных хэш-функций (которых может не быть в стандартной библиотеке используемого языка/фреймворка), для соления паролей вообще не надо никаких трудозатрат.
                          • UFO just landed and posted this here
                              –3
                              Вы не путайте теплое с мягким. Это если бы я sha512 сверху md4 обернул, тогда да, а так одна мешанина заменяется на другую (не предсказуемо ни то, ни другое), а хэширующая функция одна и та же.
                              Спор про то куда ставить соль, в начало или в конец, вылазит в каждом топике про соль. Часто, люди которые спорят, не представляют, что хэш-функции оперируют с битами и уже после 10-й (иногда 5-й) итерации абсолютно все равно, где была соль.
                              • UFO just landed and posted this here
                                  –1
                                  так то оно так, но в этом разделе к subj относится только
                                  Compare these minor benefits to the risks of accidentally implementing a completely insecure hash function and the interoperability problems

                                  «риск что-то накосячить», т.е. в общем FUD (хотя риск конечно есть).

                                  весь основной текст в разделе относится к тому что не нужно так делать чтобы получить выгоду (типа «новый секретный алгоритм») т.к. исходник обычно известен злоумышленнику.
                                  • UFO just landed and posted this here
                                    –4
                                    ответил здесь. там хоть дискусия какая-никакая, конструктивная. У вас же не делай так потому, что низя, а почему низя — сам не знаю. Вы хоть раз, криптоанализ делали? Потому по этим ссылкам либо чушь, либо часный вырожденый случай…
                                      0
                                      Видимо надо все же развернуть ответ:

                                      На примере SHA-512: функция работает с блоками 1024 bit при длинне слова 64 bit (длинна констант).
                                      Чтобы соблюдать все мыслемые каноны безопасности хэширования с солью, нужно придержаться всего 2-х правил:
                                      — сумма длинн соли и пароля желательна быть длиннее 1024 bit и в любом случае не кратна 1024;
                                      — длинны соли и пароля по отдельности не должны быть кратны 1024 bit, и по возможности не кратны 64 bit;

                                      Если не соблюдать эти правила, как раз в случае с последовательностью «пароль.соль» теоретически а для некоторых функций уже практически можно использовать коллизии, а в лучшем случае создать таблицы из незаконченых хэшей например для паролей с длинной кратной 4, 8, 12, 16… символам (*1). И заканчивать эти хэши перебором используя соль из базы. Ускорить таким образом перебор можно и для паролей с другой длинной, т.к. можно быстрее исключить все пароли с длинами 4, 8, и т.д (длинны зависят от конкретной реализации хэш функции).
                                      Кроме того это вообще не касается хэш-функций, которые нельзя считать последовательно и которые считают хэш не поблочно, а всегда целым куском.

                                      А вот как раз последовательность «соль.пароль», «соль1.пароль.соль2» или в идеальном случае произвольная для каждого пользователя смесь является наиболее стойкой, т.к. в этом случае невозможно использование никаких таблиц.
                                      И в случае возможного нахождения в будущем коллизий для функции, как раз при использовании произвольньной смеси для каждого пользователя, необходимо перестройка всех таблиц для каждого пользователя, что практически полностью исключает их использование.

                                      Единственный же вырожденый часный случай, в котором можно получить незначительное минимальное ускорение брута на последовательности «соль.пароль» — ТОЛЬКО когда длинна соли кратна длинне блока хэш функции (т.к. каждую итерацию брут-атаки можно начинать с подготовленого незаконченого хэш блока от соли, для sha512 это 1024 бита). Но, как говорилось уже это часный случай и противоречит 2-му правилу и это все равно остается перебором.

                                      Если же мы солим ключи (что-то подлиннее пароля) то последовательность «ключь.соль» является наиболее опасной в случае кратности длинны ключа размеру блока хэш-функции. Для примера SHA-512 — это ключи длинной 128, 256, 512… байт. Вот тогда таблицы из незаконченых хэшей очень усоряют процесс подбора.

                                      *1 — не путать с радужными таблицами из законченых хэшей, их можно применять только в случае когда соли нет вовсе.
                                        0
                                        ускорение брута на последовательности «соль.пароль» — ТОЛЬКО когда длинна соли кратна длинне блока хэш функции (т.к. каждую итерацию брут-атаки можно начинать с подготовленого незаконченого хэш блока от соли, для sha512 это 1024 бита)

                                        Что-то я не понял.
                                        Для hash(соль.пароль) можно заранее посчитать внутренее представление hash(соль).
                                        (при этом речь не идёт о том чтобы финализировать этот хэш и выдать его в hex виде, например). Просто в нашем языке программирования скармливаем соль в хэшфункцию и делаем метод clone внутреннего состояния хэша. Это должно быть справедливо для любой хэш-функции (из привычных sha1, sha2 итд)
                                          –1
                                          Да, но, как показал бенчмарк ниже, зачастую сама операция клонирования внутреннего состояния оказывается дороже, чем вычисление хеша заного.
                                            0
                                            клонирование должно быть таким же быстрым как memcopy, всё остальное — погрешности реализации.
                                              0
                                              да нет же, блин.
                                              это и в принципе-то возможно ТОЛЬКО если длинна соли КРАТНА длинне блока хэшируемого последовательно… см. ниже.
                                              А про клонирование, это вообще отдельная тема.
                                              0
                                              Что-то я не понял.
                                              К сожалению не только вы...
                                              можно заранее посчитать внутренее представление hash(соль)
                                              Только если длинна соли кратна размеру блока последовательно хэшируемой функции.
                                              Пусть у нас функция хэширует поблочно 32 бита или 4 байта (ну так короче объяснить):
                                              В случае когда соль длинной 4 или 8 байт это можно сделать:
                                              [SsSs][PpPp]Pp…
                                              [SsSs][SsSs][PpPp]Pp…
                                              т.е. соли SsSs SsSsSsSs для этой хэш-функции «не стойкие», потому что мы можем их заранее подготовить и всегда начинать перебор с подготовленного пре-хэша хэшируя сверху подбираемые пароли…
                                              В случае когда соль длинной например 3 байт этого сделать невозможно:
                                              [SsSP][pPpP]p…
                                              Просто потому что в первом же хэшируемом блоке есть и неизвестная составляющяя из пароля (соль злоумышленнику известна, пароль — нет).
                                                +1
                                                хм. теперь понял.

                                                ну и в случае [SsSs][SsSP][pPpP], можно «заготовить» [SsSs].

                                                можно сказать что «заготовить» можно L — L % 4 байтов, где L — длина соли.

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

                                                если вырожденный случай, когда она = 0 (в случае если соль меньше блока).

                                                совет не использовать длину кратную длине блока, позволяет избежать «экономии» злоумышленником максимум L-1 байтов (т.е. 3 байтов).

                                                так?
                                                  0
                                                  да, но не совсем, просто если соль спереди то смысла в соли длиннее блока (т.е. 6 а не 3) нет никакого.
                                                  Так что мешать, мешать и еще раз мешать. (Кстати замес это операция конкатенации, что само по себе уже усложняет процесс разпаралеливания брута — fpga и всякие asic очень не любят работать с памятью).
                                              0
                                              Что-то я не понял… Какая атака становится возможной, если сумма длин пароля и соли кратна 1024 бита?
                                                –1
                                                Атака это громко сказано, но представить способ упрощающий в этом случае перебор (это не совсем коллизия) я могу. Не будем окунатся в мир формул, а просто на простом тупом примере:
                                                Злоумышленнику известен хэш (ну и соль, что пока не суть важно). Используя радужные таблицы (при наличии соответствующей мощности конечно) он может гораздо быстрее найти ВСЕ последовательности этой известной длинны.
                                                Далее у нас есть соль. Если мы знаем где она стоит в последовательности — остальное предполагаемый пароль.
                                                А я вам похожих сценариев (при известных коллизиях) еще штук пять нарисую.
                                                  –1
                                                  Хм, почему-то я не нашел в этих рассуждениях числа 1024…
                                                    0
                                                    Потому что остаток от «вычитания» соли из найденых последовательностей — уже предполагаемый пароль, не нужно искать какой он длинны.
                                                    Даже то что длинна пароля известна заранее очень и очень плохо.
                                                    Это правило нашел давненько у какого-то гуру криптографии (не помню за давностью), исследующего коллизии первого рода md5, а в часности вырождение ее на конкретном примере в какой-то библиотеке. Так вот, там генерация соли была сделана добиванием пароля до 512 байт из случайной последовательности.
                                                    В результате формул и выкладок где-то страниц на 5-6, библиотека получила неуд.
                                                      0
                                                      опечатка: до 512 БИТ, но не суть важно…
                                                        +1
                                                        А, я понял. Но ведь в таком случае случайное совпадение суммы длин соли и пароля с числом 1024 проблемой не является? Да и число 1024 тут опять-таки не при чем — плохо «добивать» солью пароль до любой длины.

                                                        Тогда это правило лучше сформулировать так: «длина соли не должна зависеть от длины пароля». Или даже так: «соль должна никак не зависеть от пароля».
                                    0
                                    Скажите, пожалуйста, именно по скорости и затрат ресурсов, сильно ли проигрывает(или выигрывает) хеширование bcrypt по сравнению, например, с SHA512?
                                      0
                                      там же снизу цифры!
                                      220M против 8,5k, то есть где-то на 4 порядка для GPU
                                        0
                                        То есть перебор, а меня интересует именно создание хэша
                                          0
                                          Зависит от, надо тестировать конкретную систему. Если у вас скорости менее 1000 хэшей в секунду — вы ничего не заметите. Иначе — давайте смотреть ТТХ.
                                            +8
                                            Перебор и создание хеша — по факту одно и то же.
                                              +2
                                              Ну просто здесь GPU скорости описаны, а для CPU будут другие соотношения. bcrypt специально спроектирован для противодействия GPU атакам.
                                                +2
                                                Ждем создания специального ASIC для перебора bcrypt
                                                Теорически это вполне состоится, если все массово перейдут на использования данной хэш функции.

                                                Кстати, если всем пользователям менять пароли, то сразу начинаются слухи о взломе, и ведь не докажешь, что это в целях безопасности, имидж часто всё.
                                                  +1
                                                  Для scrypt уже выпустили ASIC, но пока скорость одного девайса на порядок ниже, чем GPU.
                                                    +4
                                                    Кстати, если всем пользователям менять пароли, то сразу начинаются слухи о взломе, и ведь не докажешь, что это в целях безопасности, имидж часто всё.


                                                    Можно не менять пароли. Просто при следующем логине создать для пользователя более стойкий хеш.
                                                      0
                                                      Отличный хинт, спасибо!
                                                        0
                                                        Я слышал ещё про другое решение: просто изменить хэш‐функцию с old(secret) на new(old(secret)).

                                                        Если вы используете вариант с изменением хэша при логине, то вы получаете сразу две проблемы: во‐первых, пользователи, которые к вам более не заходят, лишаются защиты, во‐вторых, вам нужно сильнее изменить код, занимающийся авторизацией. В моём варианте нужно просто один раз изменить базу и изменить функцию хэширования, не добавляя более никакой логики.
                                                  • UFO just landed and posted this here
                                                0
                                                У bcrypt можно настроить уровень сложности при генерировании соли. Можно как упростить, так и усложнить.

                                                Вот пример из документации на bcrypt модуль для Python:
                                                # gensalt's log_rounds parameter determines the complexity.
                                                # The work factor is 2**log_rounds, and the default is 12
                                                hashed = bcrypt.hashpw(password, bcrypt.gensalt(10))
                                                


                                                На E3-1240v2 с параметром gensalt(10) хеш получается примерно за доли секунды, с gensalt(12) — где-то за секунду, а когда, например, gensalt(18), то примерно 15 секунд надо что бы сгенерировать один хеш.
                                                +14
                                                Тема PBKDF2 не раскрыта :)
                                                  +1
                                                  Серьезно, столько комментариев с рассуждениями как, что, чем солить, сколько раз хешировать и т. д.? Как из паролей сделать надежный ключ? Использовать любую современную KDF, блин. Кстати, PBKDF2 даже каким-то там стандартом является. И не нужно ничего изобретать, возьмите готовое, благо реализация почти под все известные языки есть.
                                                    –1
                                                    Расскрываю:)
                                                    Вообще-то, из-за зацепленных вычислений псевдослучайной функции, скорость подбора ключа очень мала, но это на стандартном CPU, даже на виртексах, с появлением же железа типа ASIC и т.п. разпаралеливается на ура, что ведет к увеличению скорости перебора на несколько порядков. Но все еще не миллионы в секунду — пока нет.
                                                    Хуже, то что теоретически алгоритм позволяет использовать словарь для ускорения перебора, что уже безпокоит.
                                                    Источник: Computer Security – ESORICS 2012. Evaluation of Standardized Password-Based Key Derivation against Parallel Processing Platforms.

                                                    Тот же bcrypt в этом смысле гораздо надежнее.
                                                      0
                                                      <del>
                                                    +1
                                                    А какой-же алгоритм лучше использовать? Недавно вычитал, что самый оптимальный будет blowfish, но сомневаюсь.
                                                      0
                                                      я же большими буквами написал, что bcrypt
                                                        +1
                                                        Спасибо. Извиняюсь за невнимательность.
                                                        +6
                                                        bcrypt использует blowfish
                                                          0
                                                          Есть еще scrypt, основанный на упомянутом выше PBKDF2. Где-то читал недавно совсем, что bcrypt не протестирован, как следует, в отличие от PBKDF2.
                                                          –2
                                                          Использовал md5(md5(логин+дата регистрации+константа)+пароль) — вроде нормально, и без лишних полей в таблице. Единственное, это лучше перейти на SHA512.
                                                            0
                                                            Константа вне базы? Тогда это и есть локальный параметр.
                                                            Дата регистрации — это соль фактически, пользовательская.
                                                              –4
                                                              Да. Локальный параметр. Но это было в 2007. Вообще, не должно быть в БД никаких полей типа salt и прочего. Много неизменяемых вещей, как логин, дата регистрации, айпи при регистрации и тп. И их стоит использовать как соль.
                                                                +4
                                                                С точки зрения оптимизации — вы полностью правы. Но проблемы возникают на доказательстве реально величины энтропии этих случайностей.
                                                                  +5
                                                                  Вообще, не должно быть в БД никаких полей типа salt и прочего.

                                                                  Почему не должно? Зачем навешивать на одну сущность «вещь» несколько ответственностей, не позволяя в случае чего изменить схему данных без правок в алгоритме генерации хэша?
                                                                    +1
                                                                    Ну, строго говоря, при использовании современных функций хэширования, отдельное поле действительно не нужно — соль генерируется вместе с хэшем, и функция возвращает (и принимает) их единой строкой.
                                                                      0
                                                                      Вас минусуют неоправданно. В случае с bcrypt так и есть (как минимум в php).
                                                                  +4
                                                                  Главная ошибка у вас даже не MD5, а пароль в конце.
                                                                    0
                                                                    Это тоже исправить надо.
                                                                    –11
                                                                    Не совсем понял. ну например создал я такой хеш, а что далее? Пользователь вводит свой пароль, а как мне получить с него хеш и как проверить правильный пароль или нет?
                                                                      0
                                                                      Ну логин-то пользователь тоже вводит. А все остальное у вас есть.
                                                                    0
                                                                    что мешает просто дописывать к каждому паролю соль подлинее?
                                                                      0
                                                                      Эта соль будет в базе и захватив хранилище можно будет проводить атаку.
                                                                      Если соль не будет в базе, а будет одна на всех — то можно будет быстро найти все одинаковые пароли.
                                                                        0
                                                                        Есть промежуточные варианты — например, соль — ид пользователя, но, имхо, не стоит оно того.
                                                                      –18
                                                                      Интересно, что ни одна переполненная бочка с гневом, рассказывая в очередной раз о необходимости использования соли, не находит пары слов о такой штуке, как сложность пароля.
                                                                      При том что пароль вида «123456», захэшированный какой угодно медленной функцией, с какой угодно (известной атакующему) солью, раскалывается за секунды.
                                                                      Отсутствие же локального параметра в базе — довольно шаткая защита. Классическая security through obscurity — как раз в том варианте, в котором на неё полагаться не стоит.
                                                                        +5
                                                                        Специально начал статью с определения условий применимости, чтобы избежать таких странных комментов — но всем пофигу :)
                                                                          –14
                                                                          Ну, если вы считаете, что сложность подбора не имеет отношения к защите паролей — то, видимо, так оно и есть.

                                                                          С такими вводными ваша заметка действительно представляет огромную ценность. «Как поставить бронированную сейфовую дверь на сарай из гипсокартона».
                                                                            +12
                                                                            Парольная политика — организационная мера. Очень важная и правильная. Также как и осведомленность сотрудников о том, что пароли не надо выкладывать на pastebin, ssh ключи пушить в github, и записывать секреты на бумажках рядом с мониторами. Но текст не об этом.
                                                                              –16
                                                                              Об этом и речь. Сложность проля — никакая не организационная, а самая что ни на есть техническая мера.

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

                                                                              Если пароль выбирается из словаря в тыщу слов, то ни соль, прицепленная с правильного конца, ни супер-пупер алгоритм хэширования не помогут.

                                                                              Но про определения я понял.
                                                                              Это заметка про защиту сферического пароля в вакууме при комнатной температуре и 80%-й влажности. Очень, очень познавательно, спасибо.
                                                                                +1
                                                                                Все пользователи никогда не будут следовать всем техническим мерам.
                                                                                Как уже сказано в посте, в толково организованных базах не хранятся пароли, берётся hash(password|salt), где | — операция конкатенации. Поэтому неважно, что пароль слабый. Хэш работает не над ним.
                                                                                Да, технические меры и рекомендации по паролям нужны. Но они не сделают ваш сарай бронированным.
                                                                                  –8
                                                                                  Всегда приятно получить развёрнутый комментарий — сразу становится ясно, что именно не понимает собеседник.

                                                                                  К сожалению, стойкость пароля — это важно.

                                                                                  Соль, по определению атакующему известна. алгоритм — тоже.
                                                                                  Он берет словарь, и в цикле производит ту же самую «операцию конкатенации», подставляя пароли из словаря. И получает все слабые пароли за считанные секунды.
                                                                                  Перебор по словарю — это первое, что делает атакующий. ДО брутфорса.

                                                                                  Теперь понятно?
                                                                                    +17
                                                                                    Какие-то у вас странные претензии к автору. Автор пишет: «Поговорим о велосипеде. У велосипеда все должно быть прекрасно. И руль, и колеса, и рама, и седло. И все это важно. Но сегодня мы поговорим о руле». На что вы отвечаете: «Автор, какой руль, колеса, вот что важно!»
                                                                                    Глупая ситауция, не находите?
                                                                                      –11
                                                                                      Нет, не нахожу. Пароль — это часть «руля». Стойкость хэша, о которой нам пишет автор, зависит от трёх элементов, а не от двух. Поэтому надо говорить про все три.
                                                                                      Но для тех, кому рассказ про соль явился небесным откровением, возможно, стойкость пароля действително кажется неважным параметром.
                                                                                        +4
                                                                                        стойкость пароля действително кажется неважным параметром.

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

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

                                                                                        Я думаю, что найдется очень много вещей, очевидных для других, для вас будут небесным откровением. Профессионалами не рождаются, а становятся. Кто-то может этого не знать и не знает. Почитайте комменты ниже. Да что говорить, тот же ozon вон пароли в открытом виде на почту шлет и ничего, а вы тут про откровения :)
                                                                                          0
                                                                                          Двухэтапная аутентификация спасет от слабых паролей?
                                                                                          А про соление — везде, где можно, лучше использовать случайные соли. И хранить все в различных местах.

                                                                                          [irony]Не забывая, конечно, про требование спецслужб оставить им закладку (скажем, в ослабленном алгоритме псевдослучайных чисел).[/irony]
                                                                                  +5
                                                                                  И какие будут предложения? Заставить пользователя ставить такой пароль, чтобы в нем были символы в верхнем регистре, символы в нижнем регистре, цифры, спецсимволы, кровь девственницы, суммарно не менее 18 символов и не более 12?

                                                                                  Из-за такой деятельности на редко используемом и не хранящем важной информации ресурсе зачастую проще заново зарегистрироваться, чем вспомнить/восстановить пароль. Да, можно уведомлять пользователя о ненадежности пароля, запугивать его ужасными хакерами, предлагать сделать пароль сложнее. Но если я хочу поставить пароль 123456 на данном конкретном ресурсе, дайте мне его поставить. Спасение утопающего — дело рук самого утопающего. Если это с работой связано, то должны объяснить. Если личное — предупреждение было.

                                                                                  Хуже этого только «Вы полгода не меняли пароль, мы его вам сбросили, поставьте новый. Ой, знаете, выбранный вами пароль был у вас три года назад, нельзя его ставить.»
                                                                                    –7
                                                                                    Можно разрешать простые пароли.
                                                                                    Только надо понимать, что никакие алгоритмы с «локальными параметрами» такой пароль не защитят.

                                                                                    И в очередной раз закипая яростью благородной по поводу ламеров, не умеющих солить — о таком важном в звене защиты упоминать надо обязательно. Оговаривая, что при простом пароле все вышеперечисленные методы окажутся неэффективными.
                                                                                      0
                                                                                      Пост о том, как уменьшить вероятность получения пароля пользователя, имея доступ к БД.
                                                                                      Перебор по словарю — это уже совсем другая история, как и социнжиниринг, например. Тот же сканер сетчатки имеет «уязвимость», допустим, в виде слабо подготовленного физически пользователя. Это же не значит, что обучение боевым искусствам отдельных пользователей является технической мерой обеспечения безопасности системы аутентификации.
                                                                                        –8
                                                                                        Я вас умоляю. Посты про то как «уменьшить вероятность» не нужны.
                                                                                        Другая история про перебор по словарю — это очень, очень смешно.
                                                                            +11
                                                                            Это вообще не security through obscurity, это называется разделяемый секрет.
                                                                            Security through obscurity — это если бы атакующий не знал алгоритма хэширования.
                                                                              –16
                                                                              … и «разделяемый секрет» АКА «секретную соль».
                                                                              то есть, мы строим свою систему, исходя из предположения, что данный параметр ему неизвестен. Классическая security through obscurity.
                                                                              Защита хэшированием всегда должна строиться из предположения, что соль атакующему известна. Страусиная политика здесь не годится.

                                                                                +9
                                                                                Мы сводим к невозможной офлайн атаку через доступ только к одному хранилищу.

                                                                                Не знаю сколько систем вы атаковали, но могу сказать по своей статистике за 5 лет, что это очень хороший уровень защиты. Про его обходы написано в теле статьи.
                                                                                  +12
                                                                                  Неправда ваша. Классическая security through obscurity — это «Мы складываем все буквы пароля по модулю 23145. Да, это не совсем безопасно, но так сложилось исторически. Кроме того, мы никому не скажем свой алгоритм хеширования.»

                                                                                  Здесь же самая правильная схема — открытый алгоритм — и закрытые входные данные. Скажите, если кто-нибудь подпишет некоторый файл своим закрытым ключом — вы ему тоже скажите: «У вас классическая security through obscurity — сначала добейтесь стойкости алгоритма при раскрытом ключе — а потом уже хвастайтесь своим алгоритмом подписи?»
                                                                                    –9
                                                                                    Здесь абсолютно то же самое.
                                                                                    «Мы хэшируем пароль с солью 23145. Да, если соль будет известна злоумышленнику, это облегчит брутфорс. Кроме того, мы никому не скажем свой алгоритм хеширования.»

                                                                                    Судя по всему, людей, понимающих смысл защиты хэшированием, в комментах очень мало.
                                                                                      0
                                                                                      Вы и правда не видите разницы между «мы хешируем пароль, используя свой велосипед» и «мы хешируем пароль, используя bcrypt»?
                                                                                        –1
                                                                                        Я не вижу разницы между подходами «мы никому не скажем секрет, который по определению хранится в открытом виде», которые используются и в том и в другом случае.

                                                                                        Вы думаете, что security through obscurity — это защита лажовым алгоритмом, про который никто не знает, Это не так. Про качество защиты там нет ничего. Речь не про конкретный алгоритм, а про предположение о том, что некий ключевой элемент системы неизвестен атакующему. Это предположение ложное.

                                                                                        Если уповать на секретность секретной соли, то можно и не хэшировать, а шифровать с тем же ключом. А что — «ведь она секретная, никто её не узнает! а алгоритм у нас стойкий!». Но так никто не делает. Потому что «секретная» соль на самом не секретная. И предполагается известной взломщику.

                                                                                        Гениальность принципа одностороннего хэширования как раз в том и состоит, что она, при соблюдении всех правил, безопасна даже если у атакующего есть все данные — хэш, соль, алгоритм. Увы, хабрасообщество очередной раз упало в моих глазах, взявшись рьяно обсуждать тему, в которой понимает понаслышке.
                                                                                          0
                                                                                          Если уповать на секретность секретной соли, то можно и не хэшировать, а шифровать с тем же ключом.
                                                                                          Простите, но кто уповает на секретность-то соли? Никто не уповает, соли хранятся вместе с теми же паролями.
                                                                                          А локальный параметр решает совсем другие задачи. Да, вместо локального параметра можно было использовать шифрование. Но локальный параметр — быстрее шифрования, а потому — лучше.
                                                                                            –6
                                                                                            Простите, но у вас каша в голове :)
                                                                                            Начиная с того, что для алгоритма хэшированя скорость не достоинство, а недостаток — скорость однократного создания хэша при авторизации не критична, а вот при переборе чем медленнее алгоритм, тем сложнее брутфорс.
                                                                                            И, разумеется, никто не шифрует пароли совсем не потому что это «медленнее».

                                                                                            Автор уповает. Я там ниже вам написал, что вы изобрели себе какой-то «локальный параметр» и по какой-то неведомой причине полагаете, что он чем-то принципиально отличается от соли. Это даже забавно. Такой метод ведения дискуссии — изобрести ничего не значащее слово и ссылаться на него :)
                                                                                              0
                                                                                              Да, насчет скорости — соглашусь. А по поводу «неведомой причины» — нет.

                                                                                              Все очень просто. Локальный параметр отличается от соли тем, что его нельзя использовать как соль. Вы считаете это недостаточным отличием?

                                                                                              UPD: в комментарии ниже оппонент сознался, что не понимает разницы между Security through obscurity и Pre shared secret. Потому не вижу смысла продолжать спор.
                                                                                                –2
                                                                                                Он добавляется к паролю при хэшировании — то есть, используется, как соль :)
                                                                                                Где она хранится — вопрос десятый. Хранение вместе с хэшем — это просто частный случай.

                                                                                                Предполагать, что «секретная соль» неизвестна атакающему — это ровно то же самое, что предполагать, будто у атакующего нет доступа к хэшам.
                                                                                                  0
                                                                                                  Предполагать, что «секретная соль» неизвестна атакающему — это ровно то же самое, что предполагать, будто у атакующего нет доступа к хэшам.

                                                                                                  Не тоже самое. Это как предполагать, что атакующему неизвестен пароль пользователя и пароль рута на апп-сервере, а известен только пароль рута СУБД.
                                                                                            0
                                                                                            Речь не про конкретный алгоритм, а про предположение о том, что некий ключевой элемент системы неизвестен атакующему.

                                                                                            Если все элементы криптосистемы известны атакующему, то вообще ни о какой защите речи быть не может. Давайте обсуждать ситуацию, когда у атакующего есть пароль пользователя, его индивидуальная соль и соль глобальная. Что тут обсуждать?
                                                                                              –3
                                                                                              В том-то и дело, что может. Именно в этом и состоит принцип хэширования. Вот уж от кого не ожидал такого ляпа. :\

                                                                                              И это. Нет никакой «глобальной», «локальной» или «специальной» соли. Есть просто соль. Она заведомо известна атакующему. Это азы.
                                                                                                0
                                                                                                Почему тогда пароль заведомо неизвестен атакующему?

                                                                                                В данной ситуации хэш у нас функция трёх параметров: пароль (хранится у пользователя), индивидуальный хэш (хранится в базе рядом с хэшем) и глобальный хэш (хранится на апп-сервере). Подбор только пароля требует взлома и апп-сервера, и СУБД. Если мы взломали только СУБД, то нам для определения пароля нужно подбирать кроме него и глобальную часть соли.
                                                                                                  –5
                                                                                                  Криптография не строится на допущениях. Рассуждения вида «что требуется взломать, чтобы добраться туда-то» относятся к безопасности приложения в целом. Но если говорить о безопасности конкретно хэшей, то только стойкий пароль (в сочетании с остальными правилами) может действительно её гарантировать.
                                                                                                  Рассуждения типа «а вот мы придумаем тайное слово и никому его не скажем» — это детская игра в секретики.

                                                                                                    +3
                                                                                                    Что есть пароль как не такое тайное слово?
                                                                                                      –2
                                                                                                      Пароль — это субъект защиты. В контексте данного обсуждения.
                                                                                                        0
                                                                                                        В контексте данного обсуждения субъект защиты не пароль вообще, а пароль в базе данных. Глобальная часть соли, не хранящаяся в БД, как раз вводится для того, чтобы усложнить переборы (и прямой, и по словарю). Особенно усложняется как раз подбор коротких и/или словарных паролей — вместо «123456» атакующему нужно будет подобрать «GJLGJD*(^&*T^#@&TKFVDMNVDVHG#I&#T@K@HGVDK@HFVD123456».

                                                                                                        В общем, как не крути, вынесение части соли из БД усиливает криптозащиту при атаках на базу.

                                                                                                        Думаю, недопонимание возникло из-за рассмотрения разных видов атак.
                                                                                                          –4
                                                                                                          В контексте данного обсуждения субъект защиты не пароль вообще, а пароль в базе

                                                                                                          — В контексте моей модели задача решена не для скачек вообще, а для случая сферического коня в вакууме.
                                                                                                          =)
                                                                                                      +9
                                                                                                      Криптография не строится на допущениях.

                                                                                                      Строго говоря, именно на них она и строится. Например, асимметричная криптография строится на предположении, что задачу, которая вообще-то имеет единственное решение, всё-таки решить в приемлемое время не смогут (хотя бы случайно) и предположении, что хотя сейчас эффективных алгоритмов решения этой задачи нет, они не будут найдены в ближайшее время.
                                                                                                +7
                                                                                                Я тогда предлагаю размяться и узнать пароль на конкретном примере.
                                                                                                Хэширование — md5
                                                                                                Первые 5 паролей 123456, кодировка cp1251
                                                                                                С секретными солями будет так:
                                                                                                123456Erk`
                                                                                                123456pEMt
                                                                                                123456Yf1H
                                                                                                123456K#N@
                                                                                                123456tx|$

                                                                                                Локальный параметр неизвестен. Соли просто дописываются сзади пароля, то есть алгоритм такой md5(user_passwd+secret_salt+local_param)
                                                                                                Хэши:
                                                                                                29c82a4a118a69b6764943072995770b
                                                                                                d20d533e7fb9d512e0e3e1f2928542df
                                                                                                8007b02939821a40ab57afe95da11199
                                                                                                ab3020a1e8c9c728810fb3acc0e91fae
                                                                                                a342fbb6d236a9c69aa99d24351fd371
                                                                                                Узнайте какой пароль под этим хэшем — d1d4fa8330f7eeb77241699797b258d8
                                                                                                  +2
                                                                                                  Да, локальный параметр един для всей базы данных.
                                                                                                    –9
                                                                                                    К сожалению, вы не поняли обсуждаемого вопроса.
                                                                                                    Точно так же я могу задать встречный вопрос — «Есть хэши, но соль неизвестна. Предлагаю размяться».
                                                                                                    Или — «есть база, пароли лежат в открытом виде». Узнайте пароли.
                                                                                                    При анализе уязвимости надо всегда предполагать худший сценарий. Тот факт, что я не откадаю пароль в вашей задачке, никак не поможет человеку, у которого скомпрометированным окажется «секретный» параметр.

                                                                                                    А игры «отгадай число, которое я задмуал» стоит оставить для детского сада.
                                                                                                      0
                                                                                                      Для компрометации локального параметра требуется как минимум рутовый доступ с серверу, на котором крутится приложение. И подчеркну, что рутовый доступ на сервер приложения и доступ к базе данных — абсолютно разные и не взаимосвязанные вещи. Никто не говорит, что данная схема полностью неуязвима. Но данная схема более устойчивая к взлому чем прочие. Не верите — предложите лучшую и объясните почему.
                                                                                                        –2
                                                                                                        Я предлагаю на протяжении всего этого топика.
                                                                                                        Для хэша, который не имеет заведомо слабых звеньев, весь этот детский лепет с «локальными параметрами», «повышающими» базопасность становится ненужным.
                                                                                                        А «чтобы поломать нашу систему надо найти иголку, которая в яйце, яйцо в утке, утка в зайце, заяц в а… фиге» — это классическая security through obscurity.

                                                                                                        Само наличие условий «чтобы… надо» — уже говорит о заведомой скомпрометированности подхода. В действительно защищенной системе нету никаких «если». И «повышать» её безопасность не требуется.
                                                                                                          0
                                                                                                          Слабые звенья есть всегда. Абсолютно защищенная система — система которой не существует.

                                                                                                          Скажем, с тру-паролями, тоже есть условия «чтобы… надо». Скажем, «чтобы никто посторонний не мог зайти, надо чтобы пароль хранился в секрете».
                                                                                                            –2
                                                                                                            Речь в топике идет о взломе хэша. Не надо уводить разговор в сторону.
                                                                                                              0
                                                                                                              По-моему, очевидно, что точно взломать хэш трех параметров, хранящихся в разных местах (голова пользователя, апп-сервер, БД) сложнее чем двух (голова пользователя, апп-сервер или БД).

                                                                                                              При одинаковых требованиях к паролям какая система будет защищена больше — с одной солью или с двумя?
                                                                                                                –4
                                                                                                                В случае с электронной подписью не требуется никаких «секретных локальных параметров». Есть условная «голова пользователя» и открытый ключ. Всё. Даже «доступ к БД» не требуется, не говоря уже ни о каких «апп-серверах» — всё и так открыто.

                                                                                                                Давайте вы сначала поучите всех операторов электронных подписей, как правильно организовывать безопасность — хранить открытый ключ в закрытой БД, а еще один дополнительный открытый ключ в ещё одной дополнительной БД. И если они согласятся, что да — так надёжнее — то мы вернёмся к этому вопросу.
                                                                                                                  0
                                                                                                                  Тут скорее речь о том как хранить закрытый ключ. Скажем, хранится он локально на машине пользователя длиной 256 бит. Какой-нибудь специалист однозначно скажет, что если удлинить ключ до 512 бит, первую половину хранить так же локально, а вторую пускай на флэшке, то безопасность системы снизится?
                                                                                                                    –1
                                                                                                                    Ещё раз. Мы десь не говорим об атаке на пароль. Оставьте голову пользователя в покое.
                                                                                                                    В данном топике обсуждается стойкость по определению доступных хакеру данных.
                                                                                                                    Речь о защите хэша, а не пароля.
                                                                                                                    Хороший хэш в костылях не нуждается. Он защищен сам по себе.
                                                                                                                    Локальный параметр — детский лепет «а вот мы спрячемся и никто нас не найдет». Вся защита строится на допущениях. Утверждение «чтобы получить локальный параметр, нужно иметь локальный доступ» ничем принципиально не отличается от утверждения «чтобы получить дамп базы, надо получить доступ к базе». И то и другое — допущения.

                                                                                                                    При анализе защиты всегда предполагается худший сценарий. Защита «локальным параметром» такую проверку не проходит. Защита стойким паролем — проходит. Это — принципиальная разница.
                                                                                                                    Если вы не в состоянии этого понять, то продолжать бесполезно.
                                                                                                                      0
                                                                                                                      Товарищ говорит о модели угроз. Вы почему-то оперируете каким-то термином «допущение».

                                                                                                                      Есть модель, в которой локальный параметр недоступен атакующему, в это случае атака становится на порядки сложнее.

                                                                                                                      Эта модель очень применима для веб-приложений на основе 5 лет аудитов.

                                                                                                                      Если Вы говорите, что модель не применима — аргументируйте.
                                                                                                                        +2
                                                                                                                        При анализе защиты от чего, от какого вида атак?

                                                                                                                        Топик о защите хэша, да, о сложности восстановления захэшированных данных из дампа БД. Атакующему нужно восстановить либо пароль, либо пароль и «локальный параметр». Что сложнее при одинаковой сложности пароля?
                                                                                                                          –1
                                                                                                                          Если пароль сильный, то необходимая сложность будет уже досигнута. И костыль не нужен.

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

                                                                                                                            0
                                                                                                                            Какая необходимая? И это не костыль, а усложнение подбора любого пароля при определенных атаках весьма низкой ценой. Слабый пароль — хорошо, он превращается в сильный. Сильный — ещё лучше, он превращается в очень сильный.
                                                                                                                            И оговаривать их в статье, если уж взялся поучать других.


                                                                                                                            То есть получив доступ к СУБД, злоумышленник получает и значения хешей и соли.

                                                                                                                            Вектор атаки явно обозначен — получение доступа к СУБД. Об атаках на само приложение речи нет.
                                                                                                                              0
                                                                                                                              Слабый не превращается в сильный.
                                                                                                                              Сильному превращаться в «очень сильный» не нужно. Да и не превращается он. Это самообман.

                                                                                                                              Про сферический вектор атаки я уже комментировал. Осталось злоумышленнику рассказать, что он обязан атаковать только БД, а остальное — ни-ни!

                                                                                                                              (Вы это — вообще понимаете, какую чушь сейчас несете, с этим своим «вектор атаки обозначен»? Пишем статью про защту от SQL инъекций и обозначаем вектор — атакуем только строки в запросе. польза от такой защиты и статьи — просто небывалая).
                                                                                                                                0
                                                                                                                                Пост не полная инструкция по безопасности, а раскрывает защиту по конкретному виду атак. Хотите узнать как защищаться от других атак — ищите другие статьи.

                                                                                                                                И не самообман это. А то самообманом можно назвать установку замков на двери в квартиру, но не установку их на окна. Просто защитились от одного из вида угроз — проникновения через дверь путем простого захода. Никто не утверждает, что обеспечена полная безопасность, но один из векторов атак перекрыт, что увеличивает защищенность.
                                                                                                                                  –3
                                                                                                                                  Дело в том, что «обозначение вектора» — это шулерство.

                                                                                                                                  ЕСЛИ БЫ в статье действительно рассматривалась атака только система «хакер — БД», то это была бы просто неполная и бесполезная статья.
                                                                                                                                  Но, увы, стаья не ограничивает себя на самом деле рамками атаки на базу. Поскольку САМА ЖЕ вводит такую сущность, «атака на приложение». И это уже превращается в шулерство.
                                                                                                                                  Автор говорит — «а вот предположим, что у нас есть приложение, которое никто не поломает. и тогда мы в него положим секретный ключ». Это уже чушь и обман читателей.

                                                                                                                                  Это, конечно, замечательный способ писать статьи — выделить в защищаемом объекте условно «ломаемую» часть и условно «защищенную», возложить обязанности по защите на вторую — и вуаля! — проблема решена. Но объяснить хакеру, в отличие от незадачливых читателей, что «здесь я играю, а здесь — в домике» будет затруднительно.

                                                                                                                                  Окна — неверная аналогия. Если есть возможность положить вещь в сейфовую ячейку, бронированную со всех сторон, то окон там не будет. И самообмана не будет.

                                                                                                                                  А вот если делать, как автор статьи — ставить дверь, а про окна сказать «этаж у нас 22-й, никто не залезет» — это-то и будет самообман. Так понятнее?

                                                                                                                                  Учитывая же отношение автора к сейфовой ячейке — сугубо негативное — статья получается и откровенно вредная.
                                                                                                                                    +1
                                                                                                                                    Дело в том, что «обозначение вектора» — это шулерство.

                                                                                                                                    Это не шулерство, это обычная практика защиты. Причем не в данном контексте, а вообще защиты чего угодно от чего угодно. Прежде чем защищаться нужно определиться от чего защищаться, от каких атак. Невозможно защититься от всего, сейфовая ячейка, например, защищена только от некоторых видов атак, а от атаки типа революции с национализацией и автогеном не защищена.
                                                                                                                                      –2
                                                                                                                                      Увы, опять забываем о контексте обсуждения, и отвечаем на комментарий «в лоб», без учета не то что всей дискуссии но даже и предыдущей пары комментариев.
                                                                                                                                      Судя по всему, даже флуд в 40 тысяч сообщений не может научить этому простому навыку.
                                                                                                                                        +1
                                                                                                                                        Вы вводите несуществующий контекст «защиты от всего».
                                                                                                                                          –3
                                                                                                                                          Неправда.
                                                                                                                                          Как раз я объясняю этим горе-специалистам, как правильно обеспечить безопасность пароля в контексте доступа к БД, без применения костылей и введения дополнительных сущностей.

                                                                                                                                          А вот вы как раз всей компанией лёгким движением руки вводите дополнительную сущность «получение доступа к приложению» помимо сущности «получение доступа к СУБД». Причем требуется это вам из-за заведомно несекурного способа хранения пароля.

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

                                                                                                                                          Говорите про хранение в БД? Отлично, ограничивайтесь БД. А вводить дополнительную сущность, которая никак критически не оценивается, и принимается априори секурной — это шулерство автора и потенциальная дыра в приложении.

                                                                                                                                          Если бы автор понимал важность сложных паролей, он бы об этом упомянул в статье — и вопросов бы к нему не было. Но он, если даже и понял постфактум, то самолюбие не даёт ему в этом признаться — и теперь ему только и остаётся, что цепляться за свою идею раздельного хранения, которая по определению менее секурна. Но оскорбленное самолюбие я еще могу понять. А вот добровольных адвокатов, на голубом глазу рассказывающих про векторы «мы лечим только голову. То, что после лечения голова отделяется от тела — не наша проблема. Не вводите несуществующий контекст лечение всего!» — я понять не могу.
                                                                                                                                            0
                                                                                                                                            Какая разница хранится в БД хэш от (сложный пароль)+(индвидуальная соль) хэш от ((простой пароль)+(глобальная соль))+(индивидуальная соль). В базе у нас в любом случае есть только хэш и индивидуальная соль и для восстановления пароля нужно или перебрать сложные пароли, или перебрать объединение простого пароля и соли. Для базы эти сущности внешние.
                                                                                                                                              –2
                                                                                                                                              Вот! Наконец-то мы пришли к общему знаменателю.

                                                                                                                                              Дело в том, что задача «перебрать сложные пароли», при соблюдении остальных двух правил, совершенно корректно описанных в этом топике — медленный хэш и уникальная соль — задача не-ре-ша-е-ма-я. Об этом я и все время говорю на протяжении этой чрезмерно растянувшейся дискуссии. Именно в этом и состоит разница. У подхода «сикретный тайничок» есть слабое звено. У подхода «сильный пароль при соблюдении других двух условий» — нет. Потому что работает именно так, как эта система и была задумана.

                                                                                                                                              Теперь понятнее?

                                                                                                                                              Собственно, при соблюдении всех трех правил система становится самодостаточной. Ей вообще становятся не нужны никакие «сущности», «векторы», «ограниченные задачи» и любые другие искусственные контексты для того, чтобы быть неуязвимой. Здорово же?
                                                                                                                                                +2
                                                                                                                                                Вычислительно задачи одного порядка (вернее при требовании к глобальной соли таким же как к сильному паролю, подбор одновременно и слабого пароля, и глобальной соли на порядки сложнее, а требования к соли на практике могут быть куда сильнее). Отличия лишь в том, что в вашей ситуации секрет, не хранящийся непосредственно в БД, известен только одному лицу, а в нашей он распределён — никто «пароля» целиком не знает. Опасность лишь в том, что если всё же злоумышленник подберёт глобальную соль, то остальные слабые пароли подбирать ему будет легче, но это компенсируется возможностью задавать сколь угодно сильную глобальную соль, сильнее любого практически применимого пароля (сохраненные пароли таковыми уже считаться не могут, имхо).
                                                                                                                                                  –2
                                                                                                                                                  Не компенсируется.
                                                                                                                                                  Не надо проводить знак равенства между неравнозначными величинами. И не надо подменять понятия. Речь идёт не о «подборе» «секретной соли», а о таком же взломе.

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

                                                                                                                                                  Сам принцип хэширования предполагает, что соль хранится открыто. И при соблюдении всех правил, это совершенно безопасно.

                                                                                                                                                  Про разделение соли для защиты слабых паролей можно говорить только в качестве компромисса. Подробно информируя читателя:
                                                                                                                                                  — во-первых, о правильной практике
                                                                                                                                                  — во-вторых, о недостатках предложенного трейд-оффа
                                                                                                                                                  Если бы это было сделано, то у меня к статье не было бы ни одной претензии.
                                                                                                                                                    +1
                                                                                                                                                    Опять возвращаемся к различным видам атак. В статье расписана атака, в результате которой злоумышленник получает доступ исключительно к БД. Что там с приложением — за рамками статьи, как, например, за рамками вместо атаки на приложение произвести атаку на сервис хранения паролей, которым пользуется большинство пользователей, или прийти к каждому пользователю с утюгом.
                                                                                                                                                      –3
                                                                                                                                                      Об этом и речь.
                                                                                                                                                      Чтобы оправдать слабость своего подхода, авторам статьи и их добровольным адвокатам приходится юлить и изворачиваться, изобретая «векторы атак», «рамки подходов» и прочую чепуху, не имеющую ни малейшего отношения к криптографии :)

                                                                                                                                                      В самой статье, кстати, тема «атаки на БД» не педалируется столь бешено, как в попытках оправданий в комментариях :)
                                                                                                                                                      В веб-приложениях, в числе прочего, хеш-функции используются для безопасного хранения секретов (паролей) в базе данных.

                                                                                                                                                      — скорее наоборот, речь идёт именно о приложении.

                                                                                                                                                      Кстати, ещё один фейл в статье (спасибо за повод перечитать её почнимательнее):
                                                                                                                                                      Ниже перечислены требования, которым ваш хеш в базе должен удовлетворять:
                                                                                                                                                      1. стойкость к атакам перебора (прямой перебор и перебор по словарю)
                                                                                                                                                      Для выполнения первого требования нужно использовать стойкие хеш-функции.

                                                                                                                                                      На самом деле стойкость хеш-функции не защищает от перебора по словарю.
                                                                                                                                                      — это ещё один довод за то, что все эти векторы и прочие отмазки придумываются по ходу дела, а не «так было задумано, отвяжитесь» :)
                                                                                                                                                        +2
                                                                                                                                                        Дождался, пока вы закончите перепалку.

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


                                                                                                                                                        Это вообще перл! Его надо запомнить и передавать из поколения в поколение.

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

                                                                                                                                                        Советовать собственный алгоритм хеширования программистам — это диверсия :)

                                                                                                                                                        Веб-программисты! Никогда не пишите своей криптухи, никогда!

                                                                                                                                                        Поставлю точку. Локальный параметр — это секрет. Такой же секрет, как ваш закрытый SSH ключ, как закрытый ключ от SSL сертификата вашего веб-сервера. И как все секреты его надо защищать.

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

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

                                                                                                                                                        Такие расходы и уровень защищенности для большинства веб-проектов не обоснованы, поэтому хранить локальный параметр предлагается в отдельном месте от хранилища хешей и солей.
                                                                                                                                                          –1
                                                                                                                                                          Вы сейчас расписались в том, что не понимаете смысла защиты хэшированием.

                                                                                                                                                          По-вашему, это обычный подход «все спрятать и никому ничего не показывать», «ограничить доступ» и пр. Но на самом деле смысл хэширования — это «спрятать у всех на виду». Возьмём для примера электронную подпись: её вообще никто не прячет. Она всегда доступна, равно как и подписываемый текст, и используемый алгоритм. «Ломайте, кому не лень». Сам принцип хэширования — в заведомой открытости хэша.

                                                                                                                                                          Собственно, хэширование — это «средство последней надежды», возможность защитить пароли, когда приложение скомпрометировано. Поэтому защищать хэш средствами приложения — оксюморон.
                                                                                                                                                          +1
                                                                                                                                                          Чтобы оправдать слабость своего подхода, авторам статьи и их добровольным адвокатам приходится юлить и изворачиваться, изобретая «векторы атак», «рамки подходов» и прочую чепуху, не имеющую ни малейшего отношения к криптографии :)

                                                                                                                                                          Да, это не имеет отношения к криптографии. Но к реальной защите реальных данных на реальных серверах имеет! И с чего начинается анализ защищённости информационной системы?
                                                                                                                                                            –3
                                                                                                                                                            Хэширование имеет.
                                                                                                                                                            При этом хэширование паролей, как раз, к защите «информационной системы» имеет отношение весьма опосредованное.
                                                                                                                                                            Поскольку основное его предназначение — как я уже писал выше — спасти хотя бы пароли, если систему поломали.

                                                                                                                                                            Своим «локальным параметром» вы вносите в систему заведомо слабое звено. При этом по какой-то (очевидной, разумеется, но не будем на ней заострять) причине насмерть отрицаете вариант с защитой без оного. Довольно забавно это выглядит.
                                                                                                                                                              +1
                                                                                                                                                              вы вносите в систему заведомо слабое звено.
                                                                                                                                                              Да нет же. Необходимость соления хэшей вы же не отрицаете? Что есть соль? Дополнительная информация, наличие которой в последовательности для хэширования пароля затрудняет или делает невозможным брут. От того что, соль известна или нет, сам алгоритм не становится слабее. Эта неизвестная составляющая соли делает брут или криптоанализ практически невозможным.
                                                                                                                                                              Только в случае если «слили» секретный ключ вместе с базой, все сводится как всегда к стандартной задаче — и хэш и соль известны — подбираем пароль.
                                                                                                                                                              Посему, «вносить в систему заведомо слабое звено» это, извините, чушь.
                                                                                                                                                                –3
                                                                                                                                                                Вы тоже не понимаете основных принципов и оперируете ложными посылками.
                                                                                                                                                                Соль у нас служит не против брута, а против радуги.
                                                                                                                                                                И она считается по определению известной. Это не секретный ключ, а наоборот — открытый.
                                                                                                                                                                  +2
                                                                                                                                                                  Это жонглирование понятиями (улицу не перебегают, а переходят), не отменяет всего вышесказаного.
                                                                                                                                                                    –3
                                                                                                                                                                    Офигеть «жонглирование понятиями» :)
                                                                                                                                                                    Почитайте сначала, что есть брут, а что радуга. Когда поймёте, что это не одно и то же — продолжим.
                                                                                                                                                                      +2
                                                                                                                                                                      Не отменяет всего вышесказаного
                                                                                                                                                                      что тут непонятного?
                                                                                                                                                                      1) Радугу нельзя применять для соленых хэшей, только брут или тяжелый криптоанализ, основы которого вам боюсь недоступны.
                                                                                                                                                                      2) Что тяжелее по вашему брут с известной солью (например 80бит Х = пароль + 220бит соль) или с неизвесной солью (300бит Х, хотя даже 300-ли нам неизвестно, т.к. соли нет).
                                                                                                                                                                      3) Украсть секретный ключ на порядок сложнее, если он в железе или на другом компе (web-service в локальной сети) то вообще невозможно.
                                                                                                                                                                      4) Если он все-таки украден, все сводится как всегда к задаче брута или тяжелого криптоанализа с извесной солью.
                                                                                                                                                                      ВСЕ.
                                                                                                                                                                        –3
                                                                                                                                                                        Вот этот комментарий уже лучше, чем предыдущая бессмыслица про
                                                                                                                                                                        соль… затрудняет или делает невозможным брут
                                                                                                                                                                        но опять на мотив старой песни «локальный параметр».

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

                                                                                                                                                                        Разговоры про «X тяжелее чем Y» при том, что X достаточно для выполнения задачи, напоминают бородатые каламбуры про «расстрелять через повешение с последующим утоплением» :)

                                                                                                                                                                          +2
                                                                                                                                                                          Точнее, это костыль для слабых паролей.
                                                                                                                                                                          Да что вы привязались к слабым паролям. У вас, помоему, проблема с пониманием причинно-следственной связи.
                                                                                                                                                                          Это, если хотите, есть решение для любых паролей (и то, что слыбые попадают в группу тоже, не есть предпосылка, а есть следствие). Если пользователь-дурак хочет пароль ABC, и кроме всего прочего, самым «второстепеннейшим» образом мы затрудняем узнать злоумышленнику, что пользователь-дурак пароль не äA54mFà53DEg6450õ. Это что, плохо?

                                                                                                                                                                          То, что ему разрешили слабый пароль:
                                                                                                                                                                          1) как минимум выходит за рамки этой статьи.
                                                                                                                                                                          2) имеет множество других причин (например, клиент или заказчик всегда прав, или например он уйдет на другой сайт, если уму предписать, как выбирать его же личный пароль).
                                                                                                                                                                          3) абсолютно не важно, по следующей причине: есть два пароля, X и Y. Чем X хуже Y? И теперь, не зная ничего про эти величины, находясь в одинаковых условиях для обеих — «угадайте», которая из этих двух неизвестных — слабая. X, а может все-таки Y?
                                                                                                                                                                          4) То, что X и Y уже находятся в одинаковых условиях, гарантирует соль, и для обеспечения этой гарантии, известность соли имеет второстепенное значение, т.к. вы только предполагаете, что пароль слаб, и начинаете ваш перебор со словаря из, известных вам, слабых паролей или начинаете перебор с коротких паролей.
                                                                                                                                                                          Как-то так…

                                                                                                                                                                          А какой, кстати по вашему мнению, слабый пароль, 6 символов или может 8 символов? Или 10?
                                                                                                                                                                          А если у меня есть десяток virtex-ов?
                                                                                                                                                                            –4
                                                                                                                                                                            Это не решение, а костыль.
                                                                                                                                                                            Ваше «решение» оставляет потенциальную дыру — параметр, хранящийся в открытом виде.
                                                                                                                                                                            Когда вы, наконец, это признаете, мы сможем двигаться дальше.

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

                                                                                                                                                                            При этом систему, которая в костылях не нуждается, вы ну наотрез отказываетесь даже рассматривать. Ну что за детский сад? :)

                                                                                                                                                                            А какой, кстати по вашему мнению, слабый пароль
                                                                                                                                                                            Хороший вопрос. Давайте считать. Насчет виртексов не знаю, возьмём цифры из статьи:
                                                                                                                                                                            8,5 k/s полученных на карточке AMD Radeon 7990 стоимостью менее $1000 (даже по старому курсу):
                                                                                                                                                                            соответственно, за месяц у нас получится (8,500 × 3600 × 24 × 30) ~ 22М вариантов.
                                                                                                                                                                            Это очень приятная цифра, с ней и пароль из 8 букв, с его миллиардами комбинаций уже становится неплохим вариантом.
                                                                                                                                                                            Если у вас «десяток virtex-ов» — приводите их цифры, будем на них смотреть.
                                                                                                                                                                              +3
                                                                                                                                                                              При этом систему, которая в костылях не нуждается

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

                                                                                                                                                                              Да, для атак на базу данных (взлом ли сервера, получение ли доступа к базе через sql-injection, слив ли бэкпа) он неуязвим.
                                                                                                                                                                                +2
                                                                                                                                                                                Вы придумали себе очень удобную сказку про «отдельный параметр», назначили его неуязвимым, и от этого строите дальше свою защиту. Это не защита, а фуфло.
                                                                                                                                                                                Вы не слышите просто никаких аргументов, итог опонент в дискусии бессилен (перечитайте еще раз ветку, может тогда дайдет). Вам же говорят, что если он не «неуязвим», то ничего не изменилось: имеем те-же условия, как если бы его небыло вовсе, а именно: вся соль известна. Вы же все время твердите, что мы тем самым «ослабляем» систему, а это совершенно не так, даже если этот кусок соли в десять раз длиннее, чем соль из базы для каждого юзера.

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

                                                                                                                                                                                По поводу AMD Radeon 7990 vs. virtex, гуглите сами. Просто виртексы это FPGA, т.е. «чисто» железное решение и хоть и сильно зависит от алгоритма хэширования, но при прочих равных порвет при переборе любую граку, хоть на CUDA, хоть нативно…
                                                                                                                                                                                  –2
                                                                                                                                                                                  Нигде я не писал, что введением своего параметра вы ослабляете систему. Я говорю, что она остаётся изначально дырявой, даже при наличии костыля.

                                                                                                                                                                                  Про сложность пароля не стоило спрашивать, если у вас нет своих цифр.
                                                                                                                                                                                  Пока у нас есть только те, что приведены в статье. Если они вас не устраивают — предъявляйте претензии автору, а не мне.
                                                                                                                                                                                    0
                                                                                                                                                                                    Коллега, скажите, при какой температуре утюга вы согласитесь по секрету рассказать мне свой пароль? И если такая температура существует (а она существует) — то какой смысл вообще что-то защищать?
                                                                                                                                                                                      +1
                                                                                                                                                                                      С чего вы взяли, что система изначально была дырявой?
                                                                                                                                                                                        +1
                                                                                                                                                                                        Нигде я не писал, что введением своего параметра вы ослабляете систему
                                                                                                                                                                                        Да ну?
                                                                                                                                                                                        Своим «локальным параметром» вы вносите в систему заведомо слабое звено.
                                                                                                                                                                                          –3
                                                                                                                                                                                          Здесь да — виноват. Формулировка подкачала.
                                                                                                                                                                                          Имелось в виду то же, что и выше — «Проектируя систему так, чтобы её безопасность зависела от „локального параметра“, вы вносите в неё заведомо слабое звено».

                                                                                                                                                                                          В рамках парадигмы «пароли находятся в безопасности для случая сферической базы в вакууме» система получается безопасной. Проблема в том, что взломщик не будет связывать себя такими смехотворными рамками — «ломать только базу, и больше ничего» :)

                                                                                                                                                                                            +4
                                                                                                                                                                                            Взломщик конечно не будет. Но мы-то можем его связать, правда? Вот он получил базу, а там фиг. Чтобы что-то достать, ему теперь мало сломать базу, придётся ещё ломать сервер приложений. Работы больше. (А там не факт, что всё просто: базу он через инъекцию, например, получил, а в сервер приложений влезть посложней будет.)

                                                                                                                                                                                            Итак: работы взломщику больше в любом случае. Значит, взлом становится дороже. Для чего любая защита и затевается.
                                                                                                                                                                                              –3
                                                                                                                                                                                              Защита хэшированием устроена по другому принципу.
                                                                                                                                                                      +1
                                                                                                                                                                      Хэширование имеет.

                                                                                                                                                                      Я имею ввиду: «векторы атак» не имеет непосредственного отношения к криптографии. Точнее, отношение может быть такое: одним из векторов атаки может быть атака на криптоалгоритм, например, использование его слабости. Такое, как всем известная брутфорсоподверженность MD5.

                                                                                                                                                                      Хеширование паролей — это как раз защита от определённого типа атак (с вектором — украсть базу и получить все пароли разом).

                                                                                                                                                                      Но на вопрос вы всё-таки не ответили.

                                                                                                                                                                      Как нужно начинать анализировать безопасность системы?
                                                                                                                                0
                                                                                                                                Ошибаетесь. В ЭЦП есть и третья сторона — регистратор, который собственно и генерирует ключи. Причем ему еще необходимо доверие всех участников.
                                                                                                                          +1
                                                                                                                          А пример этого мифического хэша без слабых звеньев можно?
                                                                                                                          0
                                                                                                                          Необязательно рутовый. Вполне достаточно зайти под пользователем имеющем права на чтение, скажем веб-сервер или бэкап.
                                                                                                                            0
                                                                                                                            В общем да, достаточно. Я как-то сразу подумал о локальном параметре зашитом в недра исполняемого файла веб-сервера)
                                                                                                                            0
                                                                                                                            Рутовый пароль может не потребоваться. Ведь приложение работает под своим пользователем и имеет доступ к локальному параметру, верно?..
                                                                                                              +2
                                                                                                              Если этот секрет компрометирован, то это навсегда, без плясок с бубном вокруг базы Вы не сможете изменить его. А скомпрометировать секрет довольно просто — уволился сотрудник, имеющий к нему доступ, например. Я, честно говоря, не вижу в нем смысла при условии надежности прочих компонент.

                                                                                                              Кстати, а scrypt не тестили на скорость?
                                                                                                                +1
                                                                                                                Ну, взломщику потребуется ещё и найти такого уволенного сотрудника. А когда секрет станет ему известен, задача сведётся к «пароль с солью», которая тоже не то, чтобы проста.
                                                                                                                  +2
                                                                                                                  Часто взломщик и уволенный сотрудник — это одно лицо. А если попадет в публичный доступ этот секрет — все, можно считать, что его уже и нет. Так зачем усложнять алгоритм?
                                                                                                                  0
                                                                                                                  Если этот секрет компрометирован, то это навсегда, без плясок с бубном вокруг базы Вы не сможете изменить его.

                                                                                                                  Изменяем в коде и пользователи не смогут войти и начнут восстанавливать пароли. :)
                                                                                                                0
                                                                                                                При том что пароль вида «123456», захэшированный какой угодно медленной функцией, с какой угодно (известной атакующему) солью, раскалывается за секунды.

                                                                                                                А системы где такие пароли запрещены, многие пользователи избегают. Вечное противостояние безопасности и удобства.
                                                                                                                  –3
                                                                                                                  Дело не в том, что где запрещено.
                                                                                                                  А в том, что пароль — ключевое звено. Не менее важное, чем алгоритм или соль. Это критический элемент, который сводит последние два на нет.
                                                                                                                  Стойкость хэша зависит от трёх элементов, а не двух.

                                                                                                                  Но по какой-то причине про соль и алгоритм кричат на каждом углу, а про пароль начинают рассказывать сказки о вечном противостоянии. Нелогичненько получается.
                                                                                                                    +5
                                                                                                                    Вот пример из жизни: у вас есть SQL-инъекция в SELECT с правами на чтение таблицы users. Это mysql, FILE_PRIV нету, никаких других полезных прав кроме этой таблицы на чтение у вас (у того пользователя базы, от которого выполняется SQL запрос) нету. Пусть даже вы можете читать файлы через инъекцию, но СУБД расположена на отдельном сервере, а не на сервер приложений (все так делают, правда).

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

                                                                                                                    Думаете редкий пример? Отнюдь :)
                                                                                                                      +2
                                                                                                                      И да, представьте что у всех этих пользователей пароль 1234.
                                                                                                                      Вы все-равно не сможете это доказать или опровергнуть :)
                                                                                                                        +2
                                                                                                                        Проверить через форму логина :)
                                                                                                                        –5
                                                                                                                        Во-первых, этот комментарий иррелевантен моему.
                                                                                                                        Я писал про стойкость хэша в зависимости от пароля. А комментарий — про «секретную соль».

                                                                                                                        Во-вторых, про надежды на секретность секретной соли я уже писал. Не буду повторяться. Уповая на неё, вы расписываетесь в непонимании принципа защиты хэшированием. Который предполагает, что соль известна атакающему. Что при правильном применении никак не сказывается на стойкости.
                                                                                                                          +1
                                                                                                                          Что означает слово «уповая»? Никто ни на что не уповает. К паролю при хешировании дописываются две строки — соль и локальный параметр. Они решают свои задачи. Соль решает свою — а локальный параметр свою.
                                                                                                                            –4
                                                                                                                            Не надо на ходу изобретать терминологию :)
                                                                                                                            С точки зрения алгоритма хэширования никаких «локальных параметров» не существует. Это та же соль.

                                                                                                                            Автор статьи уповает на то, что «секретная» соль так и останется неизвеcтной взломщику. Это security through obscurity.
                                                                                                                              +2
                                                                                                                              Не я придумал терминологию локального параметра. Написал откуда она. И не думаю, что можно оспаривать эти материалы.
                                                                                                                                +4
                                                                                                                                МНогие уповают на то, что пароли пользователи атакующему недоступны. Это тоже security through obscurity?
                                                                                                                                  –4
                                                                                                                                  Разумеется.
                                                                                                                                    0
                                                                                                                                    Есть пример реально существующей системы криптозащиты, в которой все компоненты (алгоритм и все его параметры) известны атакующему?
                                                                                                                                      –7
                                                                                                                                      Любая система электронной подписи :)
                                                                                                                                      Как алгоритмы, так и «соль» — открытый ключ — заведомо известны и даже по возможности широко распространяются.
                                                                                                                                        +7
                                                                                                                                        Я слыхал что там еще один ключ есть…
                                                                                                                                          +5
                                                                                                                                          А как быть с закрытым ключом? Он разве считается заведомо известным атакующему?
                                                                                                                                            –3
                                                                                                                                            Эм. Что мы имеем в виду под «всеми» компонентами?
                                                                                                                                            Грубо, закрытый ключ — это аналог пароля. Если он известен атакующему, то все остальное становится ненужным. Мы говорим о взломе или о чём?
                                                                                                                                            Если не устраивает ответ, то тогда стоит конкретизировать вопрос.
                                                                                                                                              +1
                                                                                                                                              Грубо, глобальная часть соли — это аналог второго пароля.
                                                                                                                                                –2
                                                                                                                                                Это ерунда, а не аналог второго пароля.
                                                                                                                                                «второй пароль» — это та же соль. Которая просто хранится отдельно. И её утеря, при соблюдении всех правил, никак не скажется на стойкости хэша.
                                                                                                                                                Утеря же закрытого ключа гарантированно компрометирует все подписанные документы. Неужели даже в запале желания во что бы то ни стало уесть оппонента не видно разницы? Ну, жаль. Всё-таки, ололо побеждает разум.

                                                                                                                                                  0
                                                                                                                                                  И её утеря, при соблюдении всех правил, никак не скажется на стойкости хэша.

                                                                                                                                                  Хранение частей соли отдельно означает, что вероятность компрометации двух частей одновременно менее вероятна чем компрометация одной. Храня (индивидуальную) соль в БД мы решаем задачу невозможности получения паролей всех пользователей в одном цикле подбора. Храня (глобальную) соль на апп-сервере мы делаем недостаточным получения доступа только к БД, чтобы ограничиться подбором исключительно паролей. Храня одну (индивидуальную) часть в БД, а другую (глобальную) на апп-сервере, мы делаем невозможным подбора исключительно паролей всех пользователей в одном цикле при получении доступа исключительно к БД. Общая стойкость системы повышается.
                                                                                                                                                    +1
                                                                                                                                                    Хранение частей соли отдельно означает, что мы сознательно вносим в систему слабое звено — нестойкий пароль, а дальше занимаемся классической security through obscurity — начинаем выдумывать всякие способы для повышения стойкости нашей заведомо нестойкой системы.

                                                                                                                                                    В то время как для случая элекстронной подписи никто не занимается такими детскими играми в секретики, внося в систему некий третий «локальный параметр», помимо собственно субъектов защиты — польователя и его данных.

                                                                                                                                                    Для системы хэширования паролей, у который все три составляющие не скомпрометированы —
                                                                                                                                                    1. медленный хэш против перебора
                                                                                                                                                    2. уникальная соль против радуги
                                                                                                                                                    3. сложный пароль против словаря и перебора
                                                                                                                                                    — эти детские игры, опять же, становятся не нужны.

                                                                                                                                                    Я, разумеется, согласен, что всякие «локальные параметры» — это tradeoff в пользу юзабилити. Но об этом надо прямо и честно заявлять, а не стыдливо прятать голову в песок, прикрываясь кучей ничего не значащих терминов, выдавая заведомо нестойкую систему за эквивалент заведомо стойкой.

                                                                                                                                                    И в этом контексте реакция местных завсеггдатаев меня поражает. Ну, то есть, понятно, что она-то как раз неудивительна. Но всё равно, всякий раз сталкиваясь со столь массовым невежеством и неумением отличить заведомо нестойкую систему, которой требуется «повышение» стойкости, от заведомо стойкой, которой такие костыли не нужны — как-то становится не по себе.
                                                                                                                                                      +1
                                                                                                                                                      Хранение частей соли отдельно означает, что мы сознательно вносим в систему слабое звено — нестойкий пароль

                                                                                                                                                      Хранить части соли отдельно или нет никак не зависит от того стойкий пароль или нет. Храня их отдельно мы повышаем стойкость системы, независимо от того стойкий пароль или нет. Да, система с раздельной солью и стойким паролем более защищена чем система с раздельной солью и нестойким паролем. Но вот что система с раздельной солью и нестойким паролем более защищена чем система и единой солью и стойким паролем далеко не факт в общем случае.
                                                                                                                                                        –2
                                                                                                                                                        Зависит. При стойком пароле локальный параметр не нужен. Его выдумали какие-то доморощенные «эксперты» и носятся с ним, как с писаной торбой. Нормально защищённая система в таких костылях не нуждается.
                                                                                                                                                          +2
                                                                                                                                                          Что значит «не нужен»? Безопасность системы не увеличивается от того, что в некоторых сценариях угроз взломщику нужно получить доступ к двум серверам, а не к одному? Или, может, она ещё и понижается от этого?
                                                                                                                                                        –1
                                                                                                                                                        Локальный параметр по сути включен в подпункт
                                                                                                                                                        2. уникальная соль против радуги
                                                                                                                                                        А нужен он для того, чтобы при компрометации
                                                                                                                                                        2. уникальная соль против радуги
                                                                                                                                                        у взломщика была дополнительная головная боль.
                                                                                                                                                          –1
                                                                                                                                                          Для тех, кто решил поучаствовать в дискуссии, не понимая, о чем она: соль заранее считается скомпрометированной. Сам принцип использования соли предполагает это, он на этом основан. Тот же рекомендуемый в статье bccrypt кладёт её в одну строку с возвращаемым хэшем.
                                                                                                                                                          Частые вопросы о соли для новичков
                                                                                                                                                          — Где хранить соль? Не опасно ли хранить ее в открытом виде? Можно ли поместить соль в код и ее использовать для всех паролей?
                                                                                                                                                          — Все, что может быть украдено, будет украдено. Если вы уверены в защищенности кода, то свой алгоритм хеширования поможет лучше соли. Помните: соль не защищает один конкретный хеш от перебора, поэтому нет цели прятать соль — она хранится в открытом виде рядом с хешем. Задача соли — спасти набор украденных хешей, «удлиняя» пароль, а сделать она это может только в том случае, если у каждого хеша будет своя соль. Поэтому мы храним соль рядом с хешем и для каждого хеша генерируем свою уникальную последовательность символов соли.
                                                                                                                                                            0
                                                                                                                                                            Считайте «локальный параметр» принудительным усложнением каждого пароля, а не соли.
                                                                                                                                                              0
                                                                                                                                                              Хотя FanatPHP на протяжении всей перепалки получает минусы, он — прав.
                                                                                                                                                              1. медленный хэш против перебора
                                                                                                                                                              2. уникальная соль против радуги
                                                                                                                                                              3. сложный пароль против словаря и перебора

                                                                                                                                                              Именно эти пункты обеспечивают безопасность. Если он выполнены, то остальное просто не нужно. Более того, можно все испортить.
                                                                                                                                                              Считайте «локальный параметр» принудительным усложнением каждого пароля, а не соли.

                                                                                                                                                              Именно. Локальный параметр — усиление слабого пароля.
                                                                                                                                                              Теперь давайте поговорим о проблемах такого усиления:

                                                                                                                                                              1. Не существует ни единой академической работы или RFC или подробного исследования, где бы рекомендовалось использовать такой локальный параметр.
                                                                                                                                                              В основном, источники подобных идей — разного рода блоги рядовых разработчиков (ну и 2 предложения на слайде из этого поста).

                                                                                                                                                              2. Не существует ни единой реализации известных проверенных алгоритмов, которые бы принимали локальный параметр, как аргумент.
                                                                                                                                                              Соль — есть, локального параметра — нет.
                                                                                                                                                              Т.е. нужно самому придумывать способ внедрения локального параметра.
                                                                                                                                                              Можно удлинять соль, но это не всегда возможно (например, bcrypt имеет фиксированную длину соли).
                                                                                                                                                              Можно удлинять пароль. Опять же, с какого краю дописывать?
                                                                                                                                                              Насколько вообще это эффективно дописывать везде одну и ту же строку?

                                                                                                                                                              3. Идея локального параметра строится на предположении, что злоумышленник украдет только базу через инъекцию, а к остальному у него доступа не будет.
                                                                                                                                                              Это очень оптимистично.

                                                                                                                                                              Итого, мы имеем довольно серьезные проблемы с реализацией такого решения и неслабую вероятность сделать только хуже. И все это ради очень призрачной выгоды.
                                                                                                                                                              Криптография — это сложно. А ложное ощущение безопасности — это главный враг.
                                                                                                                                                                0
                                                                                                                                                                Давайте так. С чего начинается анализ безопасности системы? Не «криптографической устойчивости алгоритма», а именно безопасности системы в целом — блога, электронной почты, системы платежей и так далее. (Я в итоге хочу подвести к тому, что ваше высказывание по поводу п.3 — бессмысленно.)
                                                                                                                                  0
                                                                                                                                  … смысл хранить ее в очень другом месте?
                                                                                                                                  Правда, если хакер увел не только базу, но получил root доступ к серверу, то, разумеется, любой способ бессилен и здесь нужно действовать на более низком уровне — менять все пароли на сервере, искать возможные оставленные им лазейки типа дропперов, спамить пользователей советом изменить их пароль — желательно, менее угадываемым…
                                                                                                                                  То есть, цитируя, безопасность системы оценивается наиболее слабым ее узлом.
                                                                                                                                    0
                                                                                                                                    Уповая на неё, вы расписываетесь в непонимании принципа защиты хэшированием. Который предполагает, что соль известна атакающему. Что при правильном применении никак не сказывается на стойкости.

                                                                                                                                    Ё-мое…

                                                                                                                                    Задача. Есть две базы на сто миллионов пользователей каждая. В одной пароли хешираются как hash(passwd), в другой hash(password+salt). У вас есть терабайты радужных таблиц. В случае одной из баз вы можете достать винт с терабайтами радужных таблиц, а если нет этих терабайтов, запустить один брутфорс на ВСЕ пароли разом. В случае другой радужные таблицы выкидываются в мусорку, и надо запускать по брутфорсу на каждого пользователя (сто миллионов пользователей = сто миллионов брутфорсов по одному и тому же словарю).

                                                                                                                                    Вопрос. Сказывается ли наличие соли на стойкости паролей вида 12345, и станет ли вообще кулхацкер пытаться достать пароли из правильно соленой базы?
                                                                                                                                      –1
                                                                                                                                      Ответ: Не сказывается. Станет. Чтобы понять — почему, надо понять разницу между брутфорсом и перебором по словарю. Это не так сложно.

                                                                                                                                      Особенно если внезапно! не две базы, а одна. И с солью.

                                                                                                                                      Но сам неожиданный ход мысли мне понравился. Воображаем себе хакера в ресторане, где ему предлагают на выбор две базы — с солью и без. И на том основании, что он выберет ту из них, которая никак не относится к обсуждаемой теме, с блеском докажем несостоятельность доводов оппонента. Люблю когда у автора хорошо с фантазией.
                                                                                                                                        –1
                                                                                                                                        Ответ: Не сказывается.

                                                                                                                                        Вы уверены?
                                                                                                                                        Формулирую вопрос по-другому. Дайте примерную сравнительную оценку сложности нахождения всех пользователей с паролем «12345» (может, хоть так будет понятно).
                                                                                                                                        Чтобы понять — почему, надо понять разницу между брутфорсом и перебором по словарю.

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

                                                                                                                                        Конечно. Вы ведь доказываете, что соль не увеличивает криптостойкость. Так почему кулхацкер выберет несоленую базу И там, и там вряд ли достанут 16-значный пароль, состоящий из букв, цифр и символов. И там, и там могут достать пароль «12345». Но в чем же разница?
                                                                                                                                          0
                                                                                                                                          Я не знаю, КАК надо читать, чтобы "известная атакующему соль" прочесть как "отсутствующая".
                                                                                                                                          Но если все ваши претензии сводятся к этому, то вы меня очень обяжете, если избавите от необходимости копаться в ваших фантазиях.
                                                                                                                                            0
                                                                                                                                            Нет, известная атакующему соль не равна отсутствующей:
                                                                                                                                            1) хорошая соль исключает применение радужных таблиц
                                                                                                                                            2) хорошая соль уменьшает скорость подбора (считать хэш например 16 символов и 272 несколько разные по сложности задачи обычно)
                                                                                                                                            3) индивидуальная соль делает невозможным подбор паролей всех пользователей в одном цикле перебора.
                                                                                                                                              0
                                                                                                                                              Количество фантазёров, беседующих сами с собой, уже начинает напрягать.
                                                                                                                                              Нет — я всё понимаю. Беда больших сайтов, эффект толпы и всё такое. Но топик как бы тоже не про цену морковки на рынке. Предполагает некоторое умение концентрироваться на проблеме и логически мыслить. А не выхватывать из контекста одно-два слова и изливать в ответ набор банальностей.

                                                                                                                                              Нигде я не писал, что известная атакующему соль равна отсутствующей в общем случае. Если дать себе труд прочесть переписку, которую взялся комментировать, там будет написано:
                                                                                                                                              Сказывается ли наличие соли на стойкости паролей вида 12345,

                                                                                                                                              Ответ, рождённый работой мысли, а не бездумным повторением заученных мантр — нет. В базе John the Ripper пароль 12345 стоит на втором месте. Что означает практически полное отсутствие задержки при взломе. Перебор по всей базе в 3,5К также не будет медленнее перебора про радуге. Из чего можно сделать тот самый вывод, о котором я говорю с самого начала этой занимательной дискуссии — для паролей вида 12345 наличие соли не сказывается на стойкости.
                                                                                                                                                0
                                                                                                                                                Если зайти на фейсбук и подобрать пароль к какому-нибудь аккаунту это будет взломом? Черт, как это оказывается просто — взломать фейсбук!
                                                                                                                              +1
                                                                                                                              При таком подходе хэширование это тоже security through obscurity. Если скомпрометирована вся сеть, то атакующий может снять пароли в открытом тексте в точке авторизации.

                                                                                                                              Но я скажу страшную вещь: о плохости security through obscurity говорилось тогда, было идеализированное представление о безопасности. Сейчас понимание безопасности другое. Невозможно сделать что-то безопасное. Возможно сделать что-то безопасное до определенной степени. Например, то, что требет 0-day эксплоита и что невозможно взломать за $1000 — уже неплохая степень защиты. В этом плане все, что усложняет взлом, делает его затратней по времени и ресурсам или закрывает один из возможных векторов можно считать полезным.
                                                                                                                              +4
                                                                                                                              злоумышленник может предвычислить заранее хеш(соль) и далее считать хеш(соль)+хеш(пароль) уже куда быстрее (практически с той же скоростью, что и просто хеш(пароль))

                                                                                                                              А можно этот момент более подробно? Я не понял как поможет вычисление хаша соли при поиске хэша соли+пароля
                                                                                                                                +6
                                                                                                                                Например, md5 действует последовательно. То есть, когда вы считаете хэш от каких-то данных, это можно представить в виде:
                                                                                                                                hasher = new MD5Hash()
                                                                                                                                for piece in data:
                                                                                                                                hasher.feed(piece)
                                                                                                                                return hasher.getvalue()

                                                                                                                                Соответственно, при каждой «кормёжке» объекта хэшера данными, он вычисляет следующее состояние хэша. Если данные всегда начинаются с известной соли, то можно в качестве начального состояния хэшера брать всегда одинаковый хэшер (с заданным состоянием), куда уже скормили соль, и просто перебирать пароли, как будто соли нет вообще.
                                                                                                                              • UFO just landed and posted this here
                                                                                                                                  +5
                                                                                                                                  В тексте ссылки на тексты Solar Designer, какому еще эксперту в криптографии вы доверяете?
                                                                                                                                    +1
                                                                                                                                    И еще что-то мне подсказывает, что текст статьи совпадает с мнением Владимира Воронцова)
                                                                                                                                      0
                                                                                                                                      Очень тонко :)
                                                                                                                                        0
                                                                                                                                        Я старался. Судя по никам, сюда набежало довольно много людей с конкурса PHD)
                                                                                                                                  +5
                                                                                                                                  Подписан на канал Youtube Computerphile — доходчивые рассказы на различные темы из области IT. Поясняют самые основы, но интересно. Не так давно было видео о хэшировании и хранении паролей.
                                                                                                                                  На английском языке.
                                                                                                                                  Hashing Algorithms and Security


                                                                                                                                  How NOT to Store Passwords!

                                                                                                                                    +3
                                                                                                                                    Чтобы усложнить жизнь при атаке перебора следует дописать соль к паролю, а не наоборот (для людей, которые пишут слева направо, конечно).
                                                                                                                                    Так как хеш-функция, как правило, вычисляется последовательно по строке (требования поточности алгоритма), то злоумышленнику при переборе «соленых» хешей, будет проще, когда подхешовое выражение начинается с соли.
                                                                                                                                    Проще потому, что он (злоумышленник) может предвычислить заранее хеш(соль) и далее считать хеш(соль)+хеш(пароль) уже куда быстрее (практически с той же скоростью, что и просто хеш(пароль)). Для всех паролей, что он будет перебирать.

                                                                                                                                    Не согласен. Хеш пароля тоже можно вычислить заранее, даже проще, ибо соль — случайна, а пароли пользователи используют, в основном, плохие. Т.е. есть возможность использовать словарь.

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

                                                                                                                                    Аргументы против «локального параметра» можно посмотреть в статье "Properly Salting Passwords, The Case Against Pepper".
                                                                                                                                      0
                                                                                                                                      «Я могу предположить, что злоумышленник, написав модифицированный алгоритм нужной хеш-функции, может заранее посчитать известные начала строк, но при условии, что длина этих строк кратна размеру блока хеш-функции.»

                                                                                                                                      Очень странно. Нет, не может. «Известные начала строк» — откуда они известные?
                                                                                                                                        0
                                                                                                                                        «Известные начала строк» — откуда они известные?

                                                                                                                                        В статье Вы пишете:

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

                                                                                                                                        Т.е. злоумышленнику известна соль.

                                                                                                                                        Очень странно. Нет, не может.

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