А ты хто такой? Эволюция протоколов аутентификации MySQL и MariaDB в лицах

    замок на старом сейфе В далекие времена, до фейсбука и гугла, когда 32 мегабайта RAM было дофига как много, security была тоже… немножко наивной. Вирусы выдвигали лоток CD-ROM-а и играли Янки Дудль. Статья «Smashing the stack for fun and profit» уже была задумана, но еще не написана. Все пользовались telnet и ftp, и только особо продвинутые параноики знали про ssh.

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

    Michael Widenius (или просто Monty) явно был знаком с параноидальными безопасниками не понаслышке, чего стоит один такой момент (из исходников, global.h):

    /* Paranoid settings. Define I_AM_PARANOID if you are paranoid */
    #ifdef I_AM_PARANOID
    #define DONT_ALLOW_USER_CHANGE 1
    #define DONT_USE_MYSQL_PWD 1
    #endif
    

    Так что неудивительно, что пароли в MySQL открытым текстом не передавались никогда. Передавались случайные строки на основе хешей. А конкретно, первый протокол аутентификации (цитируется по mysql-3.20, 1996) работал так:

    • Сервер хранил хеш от пароля. Впрочем хеш был совсем простенький, примерно вот такой:

        for (; *password ; password++)
        {
          tmp1 = *password;
          hash ^= (((hash & 63) + tmp2) * tmp1) + (hash << 8);
          tmp2 += tmp1;
        }
      

      Это, на минуточку, 32 бита всего.

    • Для аутентификации сервер слал клиенту случайную строку из восьми букв.

    • Клиент считал хеш (тот что выше) этой строки и хеш же пароля. Потом XOR-ом этих двух получившихся 32-битных чисел инициализировал генератор случайных чисел, генерировал восемь «случайных» байт и отсылал их серверу.

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

    Плюсы этого решения были очевидны. Пароль никогда не пересылался в открытом виде. И не хранился в открытом виде тоже. Но, право, 32 бита на хеш — это несерьезно даже в 1996. Поэтому уже в следующем мажорном релизе (mysql-3.21) хеш был 64-битный. И в таком виде под именем «old mysql authentication» этот протокол живет и сейчас. Из MySQL-5.7 его выпилили, но в 5.6 он еще был, а в MariaDB есть даже и в 10.2. Искренне надеюсь, что им никто сейчас не пользуется.

    * * *

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

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

    Придумывали мы его тогда (а «мы» это были я, kostja, Петр Зайцев, и еще несколько товарищей) с такими целями:

    • То что хранится на сервере — недостаточно для аутентификации
    • То что пересылается по проводу — недостаточно для аутентификации
    • Бонус — использовать нормальную крипто-хеш функцию, хватит самодеятельности

    И получился следующий «двойной-SHA1» протокол, который вошел в MySQL-4.1 и в неизменном виде используется до сих пор:

    • Сервер хранит SHA1(SHA1(password)).

    • Для аутентификации сервер по-прежнему шлет клиенту случайную строку (20 букв) ­— которая исторически называется «scramble».

    • Клиент шлет серверу вот такую штуку:

      	SHA1( scramble || SHA1( SHA1( password ) ) ) ⊕ SHA1( password )
      

      где ⊕ — XOR, а || — конкатенация строк.

    • Соответственно, сервер не знает SHA1(password), но он знает scramble и SHA1(SHA1(password)), а значит может посчитать первый операнд в этой клиентской конструкции. Потом XOR-ом он получает второй, то есть SHA1(password). И считая от него SHA1 может, наконец-то, сравнить его с тем, что хранится в таблице для этого юзера. Уфф.

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

    * * *

    Все было хорошо, но прогресс, увы, не стоит на месте. MySQL перешла под крыло Оракла, MariaDB отпочковалась и зажила своей жизнью, и, независимо от этих пертурбаций, надежность SHA1 падала с каждым годом. Первыми засуетились в Оракле. Разработку нового протокола поручили товарищу Кристоферу Петерсону. Я к тому времени был уже в MariaDB, так что могу только догадываться, что он думал и с кем советовался. Впрочем, основное понятно — цель была перейти на SHA2 и убрать эту маленькую оставшуюся ложку дегтя. Он правильно сообразил, что нужна криптография с открытым ключом. Так что новый протокол в MySQL-5.7 использует SHA256 (256-битный вариант SHA2) и RSA. И работает все это так:

    • На сервере хранится SHA256(password)
    • Сервер, как и раньше, посылает клиенту 20-буквенный scramble
    • Клиент читает открытый RSA-ключ сервера из заранее припасенного файла
    • Клиент XOR-ит пароль полученным scramble-ом (если пароль длиннее, scramble повторяется в цикле), шифрует ключом сервера и отсылает
    • Сервер, соответственно, расшифровывает своим секретным ключом, XOR-ит обратно, получает пароль в исходном открытом виде, считает от него SHA256 и сравнивает

    Все довольно просто. Минус, с моей точки зрения, один, но большой — чертовски неудобно раздавать заранее всем клиентам серверный открытый ключ. А серверов-то еще может быть много, и одному клиенту может быть надо подключаться ко всем по очереди. Для этого, наверно, в MySQL и сделали, что клиент может запросить открытый ключ с сервера. Но этот вариант в наше беспокойное время серьезно рассматривать нельзя — ну в самом деле, с чего бы клиенту верить, что какой-то набор байт, которые ему кто-то прислал — это действительно открытый ключ сервера? Man-in-the-middle еще никто не отменял. И еще, как-то нехорошо, что сервер получает пароль в открытом виде, мало ли что. Мелочь, а неприятно.

    Впрочем в MariaDB не было даже этого, только SHA1. В принципе, хватало, хотя банки и ворчали. Но в свете последних новостей мы тоже стали искать замену хешу-ветерану. Вообще-то ничего страшного пока не произошло — ну научились искать коллизии, ну сможет кто-то сгенерировать два пароля с одинаковым хешем, а дальше-то что? Но каждому юзеру это не объяснишь. Да и вдруг завтра еще чего для SHA1 найдут?

    * * *

    Новый протокол я тоже строил на основе криптографии с открытым ключом. Так чтобы ни mysql.user, ни перехват трафика, ни и то и другое вместе, ни даже полная компрометация сервера не смогли бы открыть пароль. И, конечно, с точки зрения пользователя все должно было работать как раньше — ввел пароль, получил доступ. Никаких файлов, которые надо распространять заранее. Протокол получился на основе ed25519, это крипто-подпись с использованием эллиптической кривой, которую придумал легендарный Daniel J. Bernstein (или просто djb). Он же написал несколько готовых к использованию реализаций, одна из них используется в OpenSSH. Кстати, название происходит от типа используемой кривой (Edwards curve) и порядка поля 2255–19. Обычно (в openssh да и везде) ed25519 работает так (опуская математику):

    • Генерируется 32 случайных байта — это будет секретный ключ (почти).
    • От них считается SHA512, потом происходит всякая математическая магия и получается открытый ключ.
    • Текст подписывается секретным ключом. Подпись можно проверить открытым ключом

    Вот на основе этого и работает новый протокол аутентификации в MariaDB:

    • Вместо случайных 32-х байт мы просто берем пароль пользователя (то есть пароль фактически является секретным ключом), а дальше — SHA512 и вычисление открытого ключа, как обычно.
    • На сервере в качестве пароля в mysql.user хранится открытый ключ (43 байта в base64)
    • Для аутентификации сервер шлет случайный 32-байтный scramble
    • Клиент его подписывает
    • Сервер проверяет подпись

    Все! Даже проще, чем с SHA1. Недостатков, собственно, пока не видно — пароль на сервере не хранится, не пересылается, сервер его вообще ни в какой момент не видит и восстановить не может. Man-in-the-middle отдыхает. Файлов с ключами никаких нет. Естественно, пароли можно брутфорсить, ну тут уж поделать ничего нельзя, только отказываться от паролей совсем.

    Этот новый протокол впервые появился в MariaDB-10.1.22 в виде отдельного плагина, и в 10.2 или 10.3 будет поплотнее интегрирован в сервер.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 24

      +3
      Сергей, спасибо что включаешь меня в соавторы, но по правде сказать я был тогда такой зелёный, что разве что мог послужить «подопытным кроликом». Шаги протокола несколько раз прокрутил в голове в процессе реализации, уязвимостей придумать так и не смог. А ещё мне до сих пор стыдно за CVE с nil-terminated string в MYSQL CHANGE USER который я в своё время проморгал.
        0
        Про велосипеды ранних 90-е еще можно понять, но сейчас их городить? Разве что потому, что SRP not invented here.
          0
          Нет, просто он неудобный. Все схемы с солью добавляют еще один round-trip к аутентификации. А этот SRP, похоже, даже два. Мы же, наоборот, старается уменьшить число round-trip-ов в протоколе, так что раздувать протокол не хотелось бы.
            0
            Он совершенно также дает плюс один round-trip, как и эти велосипеды. Но кроме всего прочего позволяет клиенту удостовериться что сервер тоже знает пароль. Да, последнее не стойко к компрометации серверной базы, но как минимум стойко к прослушке.
              0
              Можно посчитать.

              В нашем протоколе так:
              1. сервер→клиенту: «привет, вот scramble»
              2. клиент→серверу: «username такой-то, пароль такой-то»
              3. сервер→клиенту: «ok» (или «пошел на фиг»)

              причем шаги 1 и 3 обязательны, плагин на них не может повлиять.

              В SRP будет так:
              1. сервер→клиенту: «привет»
              2. клиент→серверу: "I and A"
              3. сервер→клиенту: "s and B"
              4. клиент→серверу: «вот мой M1»
              5. сервер→клиенту: «ok, вот мой M2»

              да, в плюс один можно уложиться.

              Идентификация сервера — это хорошо, но в задачу не входило. Для этого можно включать SSL. Может потом сделаем и с идентификацией сервера.
                0
                По количеству запросов SRP практически такой же, единственная разница что в вашем случае серверу не нужно ждать первого авторизационного пакета, он может сразу выдать scramble. Честно говоря сомнительное ускорение. При этом SRP хорошо проанализирован, стандартизован и проверен. В нем учтены всевозможные векторы атаки. Его разрабатывали специалисты, его анализировали специалисты. Зачем городить самопал?

                Первое правило криптографии: не изобретайте собственных алгоритмов.
          +1
          А что djb думает по поводу того что вместо случайный 32 случайных байт ключ всего от силы 10 неслучайных?
            0
            Я, конечно, не спрашивал. Ну а что тут думать — плохо это, подобрать 10 неслучайных байт проще, чем 32 случайных. Но если без соли, то за случайность отвечает пользователь, мы тут ничего улучшить не можем. А соль увеличивает число round-trip-ов, поэтому ее пока что избегаем.

            Кстати, вначале я использовал немодифицированный ed25519 и получал 32 «случайных» байта как SHA256(password). Потом решил, что лишний SHA256 случайности не добавит, и убрал :)
            0
            «Man-in-the-middle отдыхает»

            Вопрос1:
            А каким образом при регистрации пароль юзера первый раз передается на сервер?

            Вопрос2,3:

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

            — Если MITM получит подписанный юзером scramble и переправит на сервер, после этого разве он не сможет выполнять любые команды от имени юзера? (актуально если нет шифрования трафика после авторизации или необходимости подписи всех команд отправляемых на сервер юзером)
              0
              1. Есть варианты. Обычно он передается открытым текстом и на сервере хешируется. Это не есть хорошо. Но можно хеш посчитать и локально, тогда на сервер попадет только хеш.

              2. Или SSL или ничем, смотря как настроено.

              3. Если SSL — то не сможет, если нет SSL — то сможет. В протоколе после аутентификации никакой защиты нет. Велосипедить свой собственный аналог OpenSSL не хочется, да и не нужно это никому — в смысле никто никогда за 20 лет это не просил.
                0
                Хм, тогда какой же здесь «Man-in-the-middle отдыхает»? :)

                Если используется SSL то, вообще зачем нужен какой-то дополнительный протокол, просто клиент через SSL открыто (для сервера) посылает захешированный пароль и сервер пишет его в базу, а при авторизации тоже самое, клиент по SSL открыто (для сервера) отправляет хешированный пароль и сервер сравнивает его с хешем из БД. При взломе сервера пароли никто не получит. Это просто и надежно.

                Если без SSL, то от MITM у вас защиты никакой нет, есть только защита от снифера.

                Заранее распространенный файл с ключем/сертификатом сервера (например через официальный дистрибутив клиента) нужен как раз для защиты от MITM.
                  0
                  1. Ну как. Это протокол аутентификации. Как он работает — определяет плагин. Но он инкапсулирован в MySQL client-server protocol, и все равно все происходит по правилам этого протокола, который несколько шире, чем аутентификация, и плагин на него влиять не может (пока что. хотим это менять).

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

                  В приведенном новом протоколе аутентификации MitM-у ловить нечего. За его пределами — да, можно. Но тут уже всю систему менять надо, то есть сам клиент-серверный протокол. Это задача совсем другого уровня, в 10.1 (да и в 10.2) это сделать невозможно.

                  2. Неее. Это как раз то, что мы исправляли в начале двухтысячных. При взломе сервера «кто-то» получит все хэши. И потом сможет их по SSL слать, пароли ему не нужны.

                  3. Защита он снифера у нас такая же как и от MitM. Во время собственно аутентификации —- ни MitM, ни сниффер ничего не получат. После — обоим путь открыт, если не использовать SSL.

                  4.Заранее распространенный файл от MitM-а не поможет, если сессия не шифруется. А она шифруется только, если включить SSL. Так что тут заранее распространенный файл бесполезен от слова совсем. Он нужен не для этого, а для аутентификации сервера клиенту. Чтоб клиент знал, что он подключается к правильному серверу. Но в том же вышеупомянутом SRP эта задача решена гораздо элегантнее, без всяких файлов. И через официальный дистрибутив ключи нельзя распространять, в том же весь смысл, чтоб у разных серверов были разные ключи.
                    0
                    2. Неее. Это как раз то, что мы исправляли в начале двухтысячных. При взломе сервера «кто-то» получит все хэши. И потом сможет их по SSL слать, пароли ему не нужны.
                    — Тут согласен

                    3. Защита он снифера у нас такая же как и от MitM. Во время собственно аутентификации —- ни MitM, ни сниффер ничего не получат. После — обоим путь открыт, если не использовать SSL.
                    — Тут ошибка. Защиты от MITM нет, так как если между клиентом и сервером стоит ПК, который во время аутентификации перехватывает пакеты и просто дублирует их для клиента и сервера, то в момент получения от клиента подписанного scramble и переправки его на сервер, злоумышленник полностью получает доступ с правами юзера. А например юзеру, он перешлет «ошибку подключения к серверу».
                    От снифера есть, т.к. пароль в открытом виде не передается, и подсмотренный подписанный юзером scramble ему не пригодится, так как при попытке авторизации scramble уже будет выслан другой.

                    4.Заранее распространенный файл от MitM-а не поможет, если сессия не шифруется.
                    — :) Так он же как раз и распространяется для шифрования сессии SSL при авторизации и защиты от MITM (подмены сервера).

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

                    Что бы ваш протокол авторизации был по надежности сравним с SRP, надо решить проблему указанную выше в пункте 3.
                      0
                      3. Согласен, но это то же, что и я говорил. Во время аутентификации ни снифер ни MitM не могут узнать пароль (или «информацию, эквивалентную паролю», как в примере с хэшем). После аутентификации MitM может посылать от имени юзера команды. А снифер может видеть все данные, что запрашивает юзер — без SSL после аутентификации защиты нет, тут надо весь протокол менять.

                      Вот, например, в новом sha256 протоколе в 5.7 если заранее не дать клиенту открытый ключ, он его запросит с сервера. MitM может этот ключ подменить своим и узнать пароль клиента, plain-text. Тут сама аутентификация уязвима к MitM. То же самое в SSL, если у клиента нет возможности проверить сертификат.

                      4. Нет, в sha256 плагине, файл используется только для шифрования пароля, не всей сессии. Аутентификационный плагин в принципе не может повлиять на всю сессию, он используется только для аутентификации. Так устроен протокол. Если использовать SSL (и проверять валидность сертификатов) то неважно как аутентифицировать, все равно SSL все зашифрует и обеспечит.

                      5. Да, если свой дистрибутив со своим сертификатом ­— то конечно, согласен.

                      6. Нет, SRP тут не причем. Если использовать SRP в рамках теперешнего протокола (и без SSL), то сессия все равно будет не зашифрованной и не защищенной от MitM. Вообще неважно насколько сложный, крутой и непробиваемый будет протокол аутентификации, если основной клиент-серверный протокол останется, какой есть. Надо сам протокол переделывать, плагином это не исправить.
                        0
                        Собственно мы говорим разными словами об одном и том же :)

                        «После аутентификации MitM может посылать от имени юзера команды.»
                        — А разве кто-то вообще может посылать команды до аутентификации? Просто перехват (компрометация) выполняется именно в момент отправки юзером подписанного scramble, т.е. в процессе аутентификации ибо scramble только для этого процесса и нужен. А команды естественно уже выполняются потом. Пароль MITM в процессе аутентификации юзера не узнал, но доступ получил.

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

                        6. Нет, SRP тут не причем
                        — Ну, я имел в виду именно сравнение авторизации через SRP, и тем вариантом авторизации, который предложен в статье. В этом смысле отличие SRP в том, что он от MITM защищен. Безопасная работа уже с самой авторизованной сессией должна обеспечиваться протоколом передачи данных/команд.

              0
              Подскажите, почему выбор пал на ed25519 в качестве основного криптоалгоритма?

              Если вы упомянули банки и их запросы, то для них более спокойно было бы если вы использовали какой-либо сертифицированный / стандартизованный / рекомендованный алгоритм.
                0
                Ну, я хотел использовать криптографию с открытым ключом, создать пару ключей на основе пароля (обычно для ключей нужно определенное количество случайных байт, я бы вместо них брал SHA2(password)). Тогда сервер бы хранил открытый ключ, клиент шифровал бы scramble, сервер бы его расшифровывал и сравнивал.

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

                Я полез в OpenSSH смотреть, как там создаются ключи, и нашел ed25519. Четыре готовые реализации, public domain, бери, не хочу, уважаемый автор, не абы кто. Аккуратная реализация с защитой от side attacks (а это весьма нетривиально). Опять же, для OpenSSH он достаточно хорош и там он как раз рекомендованный.

                И, кстати, все равно SHA512 первым шагом делается, а это уже вполне себе стандартизованный алгоритм.

                Новый плагин, как я понимаю, сейчас не просто достаточно, а избыточно безопасен. Сейчас основные проблемы безопасности клиент-серверного протокола находятся в тех его областях, которые аутентификационным плагином не покрываются. В комментах выше, вон, это подробно обсуждалось. Так что нет смысла делать плагин еще безопаснее, защищеннее, ну или сертифицированней. Надо сперва остальной протокол до этого уровня подтянуть.
                  0
                  А что вы думаете о возможности замены / использования криптоалгоритмов на современные Российские ГОСТы, в частности ГОСТ 34.11-2012 для хэша и ГОСТ Р 34.10-2012 для подписи? Да и блочного шифра ГОСТ 34.12-2015?

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

                    Но если кто захочет аутентификацию с ГОСТовскими алгоритмами — это несложно. Если есть готовая библиотека с подходящей лицензией, то плагин можно за час-два написать. Вот, например, https://github.com/MariaDB/server/blob/10.1/plugin/auth_ed25519/server_ed25519.c — там просто все.
                0
                В предлагаемой вами схеме все таки есть уязвимость и она в следующем.

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

                Пример 1. Хакер Али, сделал себе пароль «qwerty», получил хэш «0xAABB», дальше он крадет таблицу с открытыми ключами пользователей и ищет строки «0xAABB». Дальше думаю понятно

                Пример 2. Хакер Зина, украла таблицу с открытыми ключами. У нее есть pre-computed таблицы (например, rainbow table) вида пароль-открытый ключ, где вместо хэш функции используется функция получения открытого ключа по хэшу. Дальше классическая атака через pre-computed таблицы.

                Пример 3. Хакер Джэк является MiTM. При авторизации он подменяет scramble идущий от сервера на свой. У Джека есть pre-computed таблица вида свой свой исходный пароль — подписанный scrumble. Дальше аналогично (2).

                Таким образом фундаментальной проблемой схемы является генерация ключей на базе «чистых паролей пользователей». Для ее устранения подобных проблем в схему нужно добавлять случайность — соль для каждого пароля.
                  0
                  Ну конечно. Я же в конце написал, что брутить пароли можно. Соль добавляет один round-trip, поэтому пока что мы пытаемся обойтись без нее. И так уже три пакета на аутентификацию уходит, с солью будет пять. А в идеале хотелось бы ноль (то есть аутентификация, конечно, есть, но вот overhead-а от нее нет).

                  Последний пример, с заранее подписанными скрамблами — это интересно. Можно как часть скрамбла время передавать и проверять на клиенте, чтоб не сильно отличалось. Тогда, правда, надо будет часы синхронизировать…
                    0
                    С точки зрения дизайна в чем проблема добавить round-trip?

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

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

                    С другой стороны, помогая «криворуким» программистам вы закладываете в систему проблемы безопасности которые отразятся на всех пользователях.

                    На практике, проводя аудит безопасности систем, когда открываешь табличку с паролями пользователей и видишь что у половины из них одинаковые коды паролей (хэши) испытываешь смешанные чувства… причем, для самого распространённого пароля — «1» можно даже визуально запомнить хэш.

                    Хочу отметить, что взлом через радужные таблицы это все таки не brute force.
                    Радужные таблицы mixaplhanumeric1-12 дадут злоумышленикам очень хорошие результаты по взлому любых систем построенных по аналогичной схеме вообще. Причем атака будет проводиться практически в режиме реального времени и для этого могут использоваться облачные сервисы, фактически похачить можно с мобильника.
                  0
                  Вы ничего не улучшили, даже ухудшили. Раньше надо было хэш + скрамбл тащить, теперь достаточно лишь «публичных ключей», которые, по сути — те же хэши. Отличная работа
                    0
                    публичного ключа недостаточно для аутентификации. публичного ключа + скрамбла — тоже не достаточно. Нужен секретный ключ. Или брут-форс, но он всегда помогал, тут ничего нового.

                  Only users with full accounts can post comments. Log in, please.