Недавно я получил рекомендацию установить пароль длиной более 20 символов. Для шифрования используется алгоритм AES с 256-битным первичным ключом. Насколько безопасен, скажем, пароль из 8 символов от атак грубой силы для расшифровки зашифрованных файлов?
Я знаю, что на большинстве веб-сайтов такой размер пароля считается хорошим. Одна из причин этого в том, что они могут остановить атаку после 3 попыток или около того.
Вы можете указать того, кто написал эту политику, на это сообщение в блоге Брюса Шнайера.
Это хорошая статья о том, почему надежность паролей - наименьшая из проблем в сети.
это интересная статья (см. PDF печать если веб-архив недоступен). В нем подробно описано, сколько времени теоретически потребуется для перебора пароля для различных длин и наборов символов.
Посмотрите на принятый ответ в эта почта. Показывает, что для взлома даже 8-значного пароля с полным набором символов может потребоваться ~ 10 000 лет!
Если считать использование радужных таблиц грубой силой (мнения расходятся), то для 8 символов с использованием радужных таблиц, которые включают все символы в пароле, около 10 секунд. Пароль из 20 символов (те же символы, те же радужные таблицы), менее 30 секунд. Загвоздка в том, что требуется длинный время для создания таблиц. Моему потребовалось около месяца для генерации на машине с частотой 3 ГГц, обрабатываемой только ночью. С другой стороны, вам нужно сделать это только один раз.
Проблема запоминания длинных паролей легко решается комбинацией подстановки символов и использования фразы. Даже такая простая вещь, как "# Fr3ddy M3rcury #", достаточно сложна для большинства применений, но ее очень легко запомнить.
Учтите, что пароль из восьми символов можно запомнить. 20-значный пароль воля быть записанным.
И тогда кто-нибудь сможет это прочитать.
Вы можете быть заинтересованы в этой статье "Пароли против кодовых фраз". Их вывод заключается в том, что символ 9 совершенно случайно пароль примерно эквивалентен парольной фразе из 6 слов. Но они считают, что фразу из шести слов будет легче запомнить.
Все зависит от используемых вами персонажей, так как это меняет количество имеющихся у вас комбинаций. Предполагая 8 символов:
Словарное слово:
egrep "^.{8}$" /usr/share/dict/words | wc -l
15601Строчные буквы: 268 или 208827064576
Строчные и прописные буквы: 528 или 53459728531456
Нижний, верхний и цифры: 628 или 218340105584896
Добавьте знаки препинания и другие символы, и перебор займет некоторое время.
Эти числа представляют собой общие комбинации, которые нужно будет попробовать. Очевидно, что хакер не собирается пробовать каждую комбинацию после получения пароля, поэтому разделите на два, чтобы получить среднее количество требуемых комбинаций.
Более сложные хэши приводят к увеличению времени процессора для вычисления хеша, поэтому общее время больше. Пример от Джона:
Benchmarking: Traditional DES [64/64 BS]... DONE Many salts: 819187 c/s real, 828901 c/s virtual Only one salt: 874717 c/s real, 877462 c/s virtual Benchmarking: BSDI DES (x725) [64/64 BS]... DONE Many salts: 29986 c/s real, 30581 c/s virtual Only one salt: 29952 c/s real, 30055 c/s virtual Benchmarking: FreeBSD MD5 [32/64 X2]... DONE Raw: 8761 c/s real, 8796 c/s virtual Benchmarking: OpenBSD Blowfish (x32) [32/64]... DONE Raw: 354 c/s real, 356 c/s virtual Benchmarking: Kerberos AFS DES [48/64 4K]... DONE Short: 294507 c/s real, 295754 c/s virtual Long: 858582 c/s real, 863887 c/s virtual Benchmarking: NT LM DES [64/64 BS]... DONE Raw: 6379K c/s real, 6428K c/s virtual Benchmarking: NT MD4 [Generic 1x]... DONE Raw: 7270K c/s real, 7979K c/s virtual Benchmarking: M$ Cache Hash [Generic 1x]... DONE Many salts: 12201K c/s real, 12662K c/s virtual Only one salt: 4862K c/s real, 4870K c/s virtual Benchmarking: LM C/R DES [netlm]... DONE Many salts: 358487 c/s real, 358487 c/s virtual Only one salt: 348363 c/s real, 348943 c/s virtual Benchmarking: NTLMv1 C/R MD4 DES [netntlm]... DONE Many salts: 510255 c/s real, 512124 c/s virtual Only one salt: 488277 c/s real, 489416 c/s virtual
Конечно, это все чисто академично, потому что хакеры просто позвонят вашему секретарю и сообщат им, что они из ИТ и им для чего-то нужен их пароль, а ваш надежный пароль бесполезен.
Я использую нетривиальные парольные фразы для защиты
* assets that are important * stuff that's не subject to anti-hammering (lock-out after repeated attempts) * stuff that can conceivably be exposed to brute-forced/dictionary-based/hybrid attacks
Меня меньше беспокоит моя учетная запись gmail, поскольку попытки взлома пароля грубой силой просто заблокируют учетную запись (и любой, у кого есть доступ к серверу, просто заменит хеш на свой выбор, а не попытается его взломать).
Лучшая кодовая фраза - длинная (> 12 символов) и криптографически случайная. Однако их сложнее запомнить. Таким образом, парольная фраза, которая объединяет несколько слов с кажущимися случайными символами, может быть хорошим компромиссом (возможно, первые 1 или 2 буквы из первых двух строк текста вашей любимой песни).
Это безопасность, которую вы получаете от взаимодействия клиент / сервер, например как вы сказали, когда вы можете остановить злоумышленников после 3 попыток (когда они атакуют по сети, как с веб-приложениями). При таком сценарии можно утверждать, что достаточно пароля практически любой длины.
Если, однако, инсайдер захватит эту базу данных с короткими хешированными паролями и сможет обойти ограничение «по сети» в 3 попытки, игра изменится.
Предостережение при ограничении количества попыток для одной учетной записи заключается в том, что этого будет достаточно только для целевых попыток для одной конкретной учетной записи. Вам также необходимо защитить от атаки все учетные записи с заданным (или измененным) паролем - это не вызовет никаких тревог, если вы просто ограничите количество попыток для каждой учетной записи. Учитывая сегодняшние NAT и ботнеты, вы даже не можете утверждать, что ограничение количества попыток на один IP-адрес - хороший способ думать о безопасности.
Хорошие ресурсы для чтения уже были даны в других ответах.