Вопросы безопасности в веб-технологиях → Распределение символов в паролях
Как известно, в последнее время Sony выступает мальчиком для битья среди хакеров. Благодаря Sony, много учетных записей и паролей циркулируют в интернете. Недавно, Трой Хант провел небольшой анализ этих паролей. Вот выдержка его поста:
- Из примерно сорока тысяч паролей, треть подвержена простой атаке по словарю.
- Только один процент паролей содержал небуквенно-цифровые символы.
- 93 процента паролей содержали от 6 до 10 символов.
В этом посте, мы исследуем остальные 24 тысячи паролей, которые выдержали атаку словарем.
Распределение символов
Как отмечает Трой, абсолютное большинство паролей содержало только один тип символов — или все в нижнем регистре, или все в верхнем. Однако, всё даже хуже, если мы рассмотрим частоту символов.
В базе паролей существуют 78 уникальных символов. Если эти пароли были бы по настоящему случайными, каждый символ должен встречаться с вероятностью 1/78 = 0,013. Но, когда мы посчитаем реальную частоту символов, мы явно увидим, что распределение не случайное. Следующий график показывает топ 20-ти парольных символов, а красная линия показывает ожидаемое 1/78 распределение.
Криптография → ФБР не смогло взломать зашифрованный диск (сдались через год брутфорса)
И вот сейчас стало известно, что ФБР в апреле 2010 года вернуло диски назад.
Как сообщается, для криптозащиты дисков использовалось две программы: одна из них — бесплатная Truecrypt, вторая неизвестна. Шифр 256-битный AES. По данным отчёта ФБР, американцы использовали тот же метод, что и INC: подбор пароля по словарю. В ФБР брутфорс продолжался более года, но тоже с нулевым результатом.
Информационная безопасность → Атака на Twitter: шаг за шагом
Из последних сообщений на TechCrunch мы можем узнать всё о Hacker Croll (HC), в том числе где он работал раньше в своей Франции и чем занимается сейчас (как раз ищет новую работу), когда начал интересоваться хакингом, с чего начинал, почему взломал Twitter и (самое интересное) — в деталях — как именно был осуществлён взлом. С этого момента подробнее.
Персональные блоги → Теперь будет PGP против ElcomSoft?
Adobe наехал на ElcomSoft в 2001 году. Поднялась волна протестов «Свободу Дмитрию Склярову». А потом еще и США долго судилось с российской фирмой…
Сегодня узнал, что на ЭлкомСофт наехал PGP. Опять двадцать пять?
Веб-разработка → Так ли безопасно хранение пароля в виде хеша
Практически любой, даже начинающий разработчик, скажет вам, что пароли в базе надо хранить только в виде хеша (например md5). Это обеспечит их сохранность и увеличит безопасность системы в целом. Так ли это на самом деле?
В действительности нет, не так. Безопасность, да и сохранность, конечно повысится, но не очень сильно. В интернете уже давно есть базы хешей многих паролей. Трехминутный поиск только по Яндексу вывел меня на следующие сайты - MD5decrypter (568 002 хешей) и Insidepro (10 148 884 хешей). Уже не мало, ведь так? А это только открытые проекты и только по md5. Я думаю у любой серьезной хакерской группы есть свои базы, благо, с наличием бот-сетей распределенные вычисления перестают быть проблемой.
Кто-нибудь самый догадливый предложит, а давайте к пользовательскому паролю добавлять свой секретный длинный префикс. Ну или делать, например, md5 от md5. Взломщик никогда об этом не догадается и пароль не подберет.
Не поможет. В действительности при взломе хеша нам важен не оригинальный пароль, а поиск коллизии. Ведь неважно введем мы пароль 76854 или Fhndkts если md5(’76854′) будет совпадать с md5(’наша_секретная_строка’.’Fhndkts’).
Единственная проблема, что вариантов хешей все таки очень много и они будут занимать очень большое место в базе данных. да и поиск по ним потребует очень длительного времени.
Однако и эта проблема решается при помощи Rainbow Tables. Используя их мы на несколько порядков уменьшаем размер хранимой базы и скорость поиска пароля. Более подробно об этом можно почитать здесь и здесь. Для построение таких таблиц также нужны распределенные вычисления. И такие проекты есть - Rainbowcrack.com. Размах впечатляет - 2,628 таблиц, 102,080,000,000 цепочек (в каждой цепочке примерно 1000-1500 паролей), 1.49 Тб данных. Есть также российский подобный проект, но пока добились они намного меньшего.
Вот и как теперь хранить пароль?