К - кибер безопасность.
Вспомнил, что у меня когда то был аккаунт на лайвджорнале, зашел посмотреть. Вот один из постов который добавлял 10 сент. 2013 года.
раскрыть ветку (21)
раскрыть ветку (20)
раскрыть ветку (4)
раскрыть ветку (2)
раскрыть ветку (1)
Посмотри в гугле алгоритм bcrypt. Я сейчас точно все не вспомню и с телефона неудобно писать.
могу немного ошибаться в деталях:
случайным образом генерируется соль, соль вместе с паролем используется для создания ключа шифрования. (У алгоритма есть параметр стоимость - сколько циклов сделает алгоритм, используя результат предыдущего цикла). Затем полученный ключ используется для шифрования заранее известной строки
Результат сохраняется как $стоимость$сольхэш (например $2y$10$ad7R28Wr876hJhvsu736X.RDm51950XV9vN2TlrUBAdQ4/BuOAMq2), где соль - всегда строка в 22 символа
для проверки пароля строка разбивается на стоимость и соль, генерируется новый хэш и сравнивается с существующим
раскрыть ветку (13)
В том, что есть такая штука как соль, которая к конечному хешу добавляется. И получается, что даже если пароли идентичные, хеш будет разным.
раскрыть ветку (12)
А где эта соль хранится? Просто если рядом с паролем(а больше и негде), то смысла от неё нет. Но задачу это усложняет, не спорю.
раскрыть ветку (11)
Она конкатенируется с паролем. Хотя тут я уже путать могу, честно говоря. Давно про это читал.
раскрыть ветку (10)
Это понятно, но если соль всегда разная, то её надо хранить где-то. А если она хранится где-то, то пароль подобрать для конкретного аккаунта не так уж и сложно, а следовательно это смысла не имеет)
раскрыть ветку (9)
Примеры солей - айди, время_регистрации(UNIX - timestamp), ник, почта, рандомно сгенерированная строка, что угодно. Прикол не в том, что соль не узнать, прикол в том, что если у каждого своя соль, то становятся невозможными такие хаки как радужные таблицы(заранее высчитанные хэши по заданному алгоритму) и прочее
раскрыть ветку (3)
Почему радужки невозможны? Соль узнать не так уж сложно. Берёшь, регистрируешься на сервисе заранее. А после по своей записи определяешь соль. Тут, конечно, если не знаешь алгоритм, то попа, но если не знаешь алгоритм, то и солить не надо)
раскрыть ветку (2)
Радужки возможны, но если у каждого своя соль, то для каждого будет своя радужка. Про "узнать соль" - сомнительно, для этого надо знать реализацию шифрования (не только саму функция шифрования, но еще и способ соления и т.д., т.е. полную реализацию алгоритма шифровки).
раскрыть ветку (1)
По поводу подбора - можешь сам оценить время, которое понадобится для подбора хэша к 10 значному паролю (с учетом того, что алгоритм не имеет коллизий), если 1 проверка занимает, например, 10 наносекунд. Могу подсказать, только для латинского алфавита это будет 24^10 / 10^8 = 634033 секунд > 7 дней. Это в самом простом случае. Еще пароли часто имеют в себе спецсимволы и не только строчные, но и заглавные буквы(у строчной и заглавной буквы разные хэши), так что количество символов становится не 24, а ~60.
А еще хорошие сайты применяют т.н. slow hash, это когда используется заведомо долгий алгоритм и по нескольку раз. В итоге проверка гарантированно будет занимать не >10^(-8) c, а, например, > 0.1 c.
В итоге правильно зашифрованный пароль из 6 символов будет подбираться примерно 150 лет (если пароль не совсем нубский)
раскрыть ветку (3)
Радужные таблицы для определенного алгоритма можно построить за очень небольшое время. К примеру вычислять хеши можно на gpu. Это очень ускоряет перебор. На однопоточном cpu - вы правы, подбор будет долгим. Но это не значит, что надо использовать cpu)
раскрыть ветку (2)
Я не пробовал осуществлять перебор на gpu, но если на топовом однопоточнике одна шифровка занимает 0.1мс, не думаю, что это время возможно существенно снизить. Но не берусь судить.
Так же все, как всегда, многое упирается в сложность пароля
раскрыть ветку (1)