Время, необходимое для подбора пароля[править | править код]

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

Возможность взлома паролей с использованием компьютерных программ также зависит от количества проверяемых паролей в секунду. Если хеш целевого пароля известен атакующему, это число может быть достаточно большим. Если нет, скорость зависит от того, установлен ли лимит скорости аутентификации (как часто может вводиться пароль), либо от временных задержек, капчи, или принудительной блокировки после некоторого числа неудачных попыток. Другая ситуация, когда возможно быстрое угадывание, — если пароль используется для формирования криптографического ключа. В таких случаях злоумышленник может быстро проверить, успешно ли проверяемый пароль декодирует зашифрованные данные. Например, один коммерческий продукт может проверить 103,000 WPA-PSK паролей в секунду.

Индивидуальные настольные компьютеры могут проверить более ста миллионов паролей в секунду, используя утилиты для взлома паролей, запущенных на CPU и миллиарды паролей в секунду при использовании утилит, использующих GPU. Рассмотрим John the Ripper. Выбранный пользователем пароль из восьми знаков с числами, в смешанном регистре, и с символами, по оценкам, достигает 30-битной надежности, в соответствии с NIST. 2^30 — это один миллиард перестановок и потребуется в среднем 16 минут, чтобы взломать его. Когда обычные настольные компьютеры объединяются для взлома, как это может быть сделано при ботнетах, возможности взлома пароля значительно расширяются. В 2002, distributed.net успешно подобрало 64-битный ключ RC5 за 4 года, используя более 300000 различных компьютеров в разное время, и генерируя в среднем более 12 миллиардов ключей в секунду. Графические процессоры могут ускорить взлом паролей на коэффициент с 50 до 100 и более для компьютеров общего назначения. С 2011 коммерческие продукты имеют возможность тестирования до 2,800,000,000 паролей в секунду на стандартном настольном компьютере с использованием мощного графического процессора. Такое устройство может взломать 10-символьный пароль в одном регистре за один день. Следует отметить, что работа может быть распределена на несколько компьютеров для дополнительного ускорения пропорционально числу доступных компьютеров с сопоставимыми GPU.

Несмотря на свои возможности, настольные процессоры медленнее во взломе паролей, чем специально построенные машины, предназначенные для взлома пароля. В 1998 the Electronic Frontier Foundation (EFF) собрали выделенный взломщик паролей, использующий FPGA, в отличие от CPU. Их машина, Deep Crack, сломала 56-битный ключ DES за 56 часов, тестируя около 90 млрд ключей в секунду. В 2010, the Georgia Tech Research Institute разработали метод использования GPGPU для взлома паролей, придумывая минимально безопасную длину пароля в 12 символов.

Почему я должен хешировать пароли пользователей в моем приложении?

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

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

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

Алгоритм хеширования паролей

1. На основе времени суток генерируется случайное значение S (12 битов или больше), которое затем преобразуется в строку из двух или более символов и запоминается в файле учетных записей как первые символы поля с хеш-значением пароля.

2. Магическое значение M длиной 64 бита, состоящее из нулей, зашифровывается по алгоритму DES, причем в качестве ключа шифрования длиной 56 бит используется пароль пользователя P, а S применяется для модификации алгоритма шифрования.

3. Полученное значение длиной 64 бита вновь зашифровывается на том же ключе (общее число повторений равно 25).

4. Полученное окончательное значение преобразуется в 11 символов (каждым 6 битам соответствует один символ из множества {‘.’, ‘/’, ‘0’-‘9’, ‘A’-‘Z’, ‘a’-‘z’});

5. Полученная строка символов записывается в файл учетных записей после случайного значения.

В современных версиях Unix на шагах 2 и 3 вместо функции шифрования DES используется функция хеширования MD5.

Минимальная длина пароля

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

Хеширование паролей Пароли пользователей обычно хранятся в базе или в файле. Хранить их можно и просто в открытом виде. Однако это является некоторой дырой в безопасности. Т.к. злоумышленник, получивший доступ только для чтения к этой базе, может взломать систему. Случай, когда он получает доступ еще и на запись, не рассматриваем, т.к. никакой md5() здесь уже не поможет. Вообще-то, дыра в безопасности не в этом. При настройке БД вменяемым администратором, никто посторонний доступа получить не должен. Однако народ у нас администраторам не доверяет и пароли в базе шифрует. Т.е. в большинстве случаев, как уже выяснили, не шифрует, а хеширует. В большинстве случаев это выглядит следующим образом: 1. При регистрации пользователя, введенный им пароль хешируется. В простейшем случае просто md5($password). И именно хеш заносится в базу. Исходный пароль не сохраняется нигде. 2. При авторизации пользователь вводит пароль, который отправляется на сервер. На сервере он так же хешируется и сравнивается с хешем в базе. Т.е. не хеш из базы преобразуется к нормальному виду, а наоборот. Злоумышленник, получивший доступ к базе может узнать только хеши, а не исходные пароли, так что его дальнейшая задача усложнится. Подбор пароля при известном хеше Как уже было сказано, исходный пароль узнать нельзя, т.к. одному хешу может соответствовать несколько исходных строк. Однако искать исходный пароль и не нужно, достаточно найти любую из этих строк и отправить на сервер в качестве пароля. Две различные строки, дающие одинаковый хеш, называются коллизиями. Поиск коллизии, имея из исходных данных только хеш, можно осуществить только одним способом – банальным перебором всех значений. Время на подбор составляет: <количество времени на вычисление хеша для одного значения> * <количество хешей, которые необходимо перебрать>. Количество перебираемых хешей пропорционально мощности множества всех возможных значений хеша, т.е. 16³², т.е, примерно, 10³⁸. С учетом того, что md5 достаточно длительный для вычисления алгоритм, время подбора выливается на современных компьютерах в достаточно ощутимый промежуток. Хотя, это время подбора абстрактного значения. Если у вас пароль может содержать латинские символы в обоих регистрах и цифры и иметь длину от 6 до 15 символов, то общее число вариантов – (26*2 + 10)¹⁵ – (26*2 + 10)⁵ = 10²⁶. А с учетом того, что большинство пользователей не будет набирать более 10 символов – 10¹⁸. Что уже несколько веселее для взломщика. Если требуется подобрать пароль только к одному пользователю, имея базу по всем пользователям сайта, то делите это число еще и на их количество. Обращаю внимание, что это средние теоретические цифры. Существует вероятность, что вы наткнетесь на нужный вариант уже на первой итерации. Примерно 1 на 10¹⁸. Так же это все верно при случайной генерации пароля. Однако, треть учетных записей администраторов ломается вводом пароля "god". А еще треть – "admin". Алгоритм хеширования В простейшем случае пароль хешируется банально – md5($password). Однако старателями уже собраны достаточно большие базы на md5-хеши. Немного изменив алгоритм, можно сделать их бесполезными.  Простой md5(md5($password)) увеличит время подбора вдвое. Добавьте туда логин, идентификатор пользователя и секретную строку: md5(md5($password.$login).$secret). Перемешайте все это и сделайте так, чтобы никто не узнал точный алгоритм. На каждом сайте немного изменяйте его.  Все, вы неуязвимы :) Недостатки С одной стороны плохие люди не могут получить исходный пароль. С другой – хорошие тоже. Наиболее неудобно это при восстановлении пароля. Выслать старый пароль нельзя. Поэтому либо приходится генерировать новый, либо давать пользователю специальную ссылку, где он сам может ввести нужный.