Каким образом происходит сообщение пароля

Обновлено: 05.07.2024

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

Технологии безопасности постоянно совершенствуются, только вот неизменным остается один аспект, играющий центральную функцию – существование паролей. Но ведь именно они и являются самым простым инструментом для взлома злоумышленником. Существует множество политик и технологий, которые пытаются сделать пароли более устойчивыми, однако человеческий фактор никто не отменял. Всем давно известно, что в качестве паролей обычно используются имена близких людей, клички животных, дата рождения и т.д.

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

При использовании NTLMv2 хэши паролей достаточно надежны

Наилучший пароль имеет вид Gfh%w3M@x

Оптимальная длина пароля – 14 символов

В LM хэши паролей делятся на два семи-символьных хэша. Фактически такой подход делает пароли более уязвимыми, так как brute-force атака (или атака грубой силы) может быть применена одновременно к каждой половине пароля. 9 символьный же пароль также будет делиться на две части – 7 символьный хэш и двухсимвольный. Нетрудно догадаться, что взлом двухсимвольного хэша займет немного времени, а вот семисимвольная займет побольше времени, однако и оно характеризуется часами. Зачастую короткая часть может существенно облегчить взлом длинного кусочка. Именно по этой причине многие профессионалы и рекомендуют иметь пароль с оптимальной длиной в 7 или 14 символов, что будет соответствовать уже двум 7-символьным хэшам. В NTLM ситуация улучшена за счет использования всех 14 символов для сохранения хэшей паролей. Это действительно облегчает жизнь, только вот диалоговое окно NT ограничивает пароль 14 символами, тем самым система "намекает", что именно такая длина пароля будет оптимальной для безопасности. В более новых версиях Windows дела обстоят иначе, в Windows 2000 и XP пароли уже могут быть длиной до 127 символов, никаких ограничений в 14 символов уже не существует. Более того, открылось следующее обстоятельство – если длина пароля более 14 символов, то Windows даже не сохраняет правильно LanMan хэши. В качестве LM хэша сохраняется некая константа, которая эквивалента нулевому паролю. Так как пароль, естественно не нулевой, то и взломать данный хэш не удастся. С учетом этого использование паролей с длиной от 14 символов было бы хорошим решением. Только вот реализовать это с помощью шаблонов безопасности или политики групп невозможно, так как никто не позволит установить минимальную длину пароля в 15 символов.

Хорошим паролем является комбинация типа M1chael99

По требованиям к сложности пароля, выдвигаемыми Windows 2000, такая комбинация подходит, хотя на самом деле она совсем не сложна. Сегодня программы для взлома паролей перебирают в секунду миллионы комбинаций, им ничего не стоит заменить букву "i" на цифру "1" и обратно или добавить к концу слова пару цифр. Некоторые программы даже проверяют такие наборы методов, используемые пользователями, подбирая длинные и кажущиеся надежными пароли. Поэтому следует быть более непредсказуемыми. Вместо замены "о" на "0" можно попытаться использовать двух скобок "()", вместо "1" можно попробовать использовать символ "l". Не стоит также забывать и о том, что устойчивость конечно же увеличится с удлинением пароля.

Рано или поздно любой пароль может быть взломан

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

Пароли необходимо менять ежемесячно

Этот совет хорошо подходит некоторым паролям с низкой защищенностью, только вот обычным пользователям он не подходит. Ведь такое требование заставляет пользователей использовать каждый раз при смене довольно предсказуемые пароли или использовать какие-то методы, которые снижают эффективность безопасности. Да и не нравится пользователю постоянно каждые 30 дней придумывать новые пароли и запоминать их к тому же. Вместо ограничений в возрасте пароля лучше сосредоточиться на создании более устойчивых, увеличить компетенцию пользователей. Для среднего пользователя вполне достаточно времени в 3-4 месяца для хранения пароля. Такой шаг, предоставление людям большего времени, даст возможность убедить их использовать более сложные пароли.

Свой пароль категорически запрещается записывать куда-либо

Хотя и совету этому многие стараются следовать, иногда все же приходится свои пароли записывать. В таком случае пользователи чувствуют себя более комфортно при создании сложного пароля, ведь они будут уверены в том, что даже если и забудут его, то смогут в надежном месте прочитать его. Следует уделить вниманию и тому, как правильно записывать пароли. Конечно же глупо записывать пароль на наклейку на мониторе, а вот хранить бумагу с паролем в сейфе или хотя бы запирающемся ящике может быть достаточной мерой. Не стоит пренебрегать безопасностью при избавлении от бумаги со старым паролем, многие взломы как раз и происходили из-за того, что хакеры тщательно просматривали мусор организации в поисках записанных старых паролей. Часто пользователи прибегают к идее сохранения своих паролей в специализированных программных утилитах. В таких продуктах возможно сохранение множества паролей, которые защищены главным мастер-паролем. Однако его утеря чревата тем, что злоумышленник получит доступ сразу ко всему списку паролей. Поэтому перед тем, как разрешить пользователям сохранять пароли с использованием таких средств, следует предусмотреть следующие нюансы. Во-первых, это программный метод, следовательно, он уязвим для атаки, во-вторых, сам мастер-пароль может стать единственной причиной провала всех паролей пользователей сразу. Зачастую мастер-пароль к тому же делают довольно простым. Лучше всего будет совместить физическую безопасность, политику компании и применение технологий. Иногда пароли просто-таки необходимо документировать. Бывает, что системный администратор заболел или уволился. А ведь зачастую это единственный человек, знающий администраторские пароли на доступ, в том числе, к серверам. Часто даже приходится одобрять записывание паролей, конечно этот шаг должен быть предельно продуманным и использоваться в крайних случаях.

В пароле не должно быть пробелов

Несмотря на то, что пользователями это мало востребовано, Windows XP и Windows 2000 разрешают использовать в паролях и пробелы. Фактически, если такой символ есть в Windows, то его можно использовать и в пароле. Таким образом пробел является совершенно приемлемым символом для пароля. Однако некоторые приложения пробелы обрезают, поэтому лучше в самом начале и самом конце пароля пробел не использовать. С помощью пробелов, кстати, пользователи могут создавать более сложные пароли. Так как этот символ может использоваться между словами, то с ним можно придумывать пароли из нескольких слов. С пробелом вообще сложилась интересная ситуация, так как он не подпадает ни под одну из категорий сложности пароля в Windows. Ведь это и не буква, и не цифра, да и символом он в общем-то не считается. Таким образом, если есть желание сделать пароль более сложным, то пробел ничем не хуже любого другого символа, его использование в большинстве случаев сложности пароля не уменьшает. Однако нельзя не упомянуть об одном значимом недостатке, который возникает при использовании пробела. Клавиша его при нажатии создает уникальный звук, который мало с чем можно спутать. Поэтому использование в пароле пробела выдается уникальным звуком. Поэтому использовать пробелы в общем можно, только не стоит этим злоупотреблять.

Следует пользоваться библиотекой Passfilt.dll

Эта библиотека вынуждает пользователей создавать устойчивые пароли. В Windows XP и 2000 это происходит с помощью системной политики, которая определяет требования сложности для него. Хотя эта политика довольно неплоха, многие пользователи расстраиваются, когда оказывается, что их пароли не подходят, так как недостаточно сложные. Бывает, что даже опытные администраторы не сразу могут ввести пароль, пока тот не пройдет требования сложности. Неудивительно, что пользователям такая мера не понравится, едва ли они поддержат политику безопасности пароли. В такой ситуации лучшим выходом будет требование длинных паролей вместо этой политики. Если заняться подсчетами, то окажется, что 9-символьный пароль, в котором буквы находятся в нижнем регистре по сложности примерно таков же, как и 7-символьный, в котором используются буквы обоих регистров и цифры. Разница лишь в том, как программы для взлома паролей обрабатывают различные подмножества. Некоторые из таких средств в началае перебирают все комбинаций букв в нижнем регистре и только после этого начинают рассматривать варианты с использованием цифр и других символов. Можно также использовать Platform SDK sample, изменив его так, чтобы он был более снисходителен в вопросе выбора пароля. Немаловажным шагом в данном направлении будет организация работы с пользователями, обучение их усложнению паролей, предоставление им необходимых идей.

Для наиболее устойчивого пароля следует использовать ALT+255

Для развенчания данного мифа рассмотрим использование символов с большим ASCII-кодом, это должно усложнить пароль. На клавиатуре их естественным образом набрать нельзя, однако с помощью удержания ALT и набора кода символа на клавиатуре, возможен его ввод. Иногда такой метод и может быть полезным, однако сразу же обратимся к его недостаткам. Прежде всего удержание клавиши ALT и последующий ввод цифр может быть без труда замечен окружающими, во-вторых, создание одного такого символа потребует нажатия сразу пяти клавиш. Может быть стоило бы просто сделать пароль длиннее на это число символов, чем каждый раз вводить с помощью замысловатой комбинации по сути один символ. Так, пароль из 5 символов, которые введены с помощью большого ASCII-кодов потребует 25 нажатий. Общее число комбинаций для такой длины составит очевидно 255^5, а вот для 25 символьного пароля созданного только из букв нижнего регистра число комбинаций 26^25, что несоизмеримо больше. Так что лучше использовать длинные пароли. Также немаловажно помнить и о том, что в некоторых портативных компьютерах клавиатуры не всегда позволяют ввести код с цифровой клавиатуры, да и не все утилиты командной строки поддерживают пароли с использованием ASCII-кодов. К примеру ALT+0127 в Windows можно использовать, но в командной строке набрать его не удастся. И наоборот, коды некоторых символов можно будет набрать в командной строке, а вот в диалоговых окнах Windows их использовать не удастся (ALT+0009, ALT+0010 и т.д.). В редких случаях такие разногласия могут быть весьма неудобными. Однако использование расширенных символьных кодов зачастую полезно и оправданно. К примеру, в случае с использованием учетной записи сервиса или локального администратора, которые редко используются, использование расширенных символов заслуживает лишнего нажатия нескольких клавиш. Такой подход может стать достаточной гарантией от взлома, так как на обработку расширенных символов настроено мало взламывателей паролей. В таких случаях не стоит останавливаться на большом коде ASCII. Оказывается, в действительности можно пользоваться полным набором Unicode, в котором 65535 символов. Однако не следует забывать, что символ ALT+64113 будет все равно не столь устойчивым как равное количество нажатий клавиш с обычными символами. В конце-концов обратим внимание на использование неразрывного пробела с кодом ALT+0160. Этот символ отображается как обычный пробел и может обмануть того, кто случайно увидел Ваш пароль. К примеру при использовании логгера клавиатуры неразрывный пароль в лог-файле будет выглядеть как обычный пробел. Если взломщик не посмотрит действительный ASCII-код и ничего не знает о неразрывном пробеле, то полученный пароль ничего не даст.

Пароли использовались с древнейших времён. Полибий (? 201 до н. э. ) описывает применение паролей в Древнем Риме следующим образом:

То, каким образом они обеспечивают безопасное прохождение ночью выглядит следующим образом: из десяти манипул каждого рода пехоты и кавалерии, что расположено в нижней части улицы, командир выбирает, кто освобождается от несения караульной службы, и он каждую ночь идёт к трибуну, и получает от него пароль — деревянную табличку со словом. Он возвращается в свою часть, а потом проходит с паролем и табличкой к следующему командующему, который в свою очередь передает табличку следующему. [1]

Пароли использовались в компьютерах с первых их дней. Например, MIT, появившаяся в 1961 году, была одна из первых открытых систем. Она использовала команду LOGIN для запроса пароля пользователя.

UNIX. Его алгоритм, известный как crypt , использует 12-битный [источник не указан 4659 дней] снижая риск перебора по словарю .

Безопасность пароля пользователя

Исследования показывают [2] , что около 40 % всех пользователей выбирают пароли, которые SHA-1 от обычных псевдослучайных последовательностей, по алгоритмам вида [3] , [4] [5] (в коде Linux

Генерация пароля

В pwgen . Например

сгенерирует 1 пароль длиной 10 символов.

Альтернативные методы контроля доступа

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

Технология единого входа
Методы передачи пароля через сеть

Простая передача пароля

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

Риск перехвата паролей через Интернет можно уменьшить, помимо прочих подходов, с использованием Transport Layer Security TLS, которая ранее называлась SSL, такие функции встроены во многие браузеры Интернета.

Базирующийся на хешах

Пароль передается на сервер уже в виде хэша (например, при отправке формы на web-странице пароль преобразуется в md5-хэш при помощи JavaScript), и на сервере полученный хэш сравнивается с хэшем, хранящимся в БД. Такой способ передачи пароля снижает риск получения пароля при помощи [источник не указан 4659 дней]

Проектирование защищенного программного обеспечения

Общие методы повышения безопасности программного обеспечения систем защищенных паролем включают:

Исходя из подходов к проведению атаки можно сформулировать критерии стойкости пароля к ней.

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

Методы защиты от атаки

Методы защиты можно разделить на две категории: обеспечение стойкости к взлому самого пароля, и предотвращение реализации атаки. Первая цель может быть достигнута проверкой устанавливаемого пароля на соответствие критериям сложности. Для такой проверки существуют автоматизированные решения, как правило работающие совместно с утилитами для смены пароля, например, cracklib [6] .

Вторая цель включает в себя предотвращение захвата хэша передаваемого пароля и защиту от многократных попыток аутентификации в системе. Чтобы предотвратить перехват, можно использовать защищенные (зашифрованные) каналы связи. Чтобы усложнить злоумышленнику подбор путем многократной аутентификации, обычно накладывают ограничение на число попыток в единицу времени (пример средства: fail2ban [7] ), либо разрешением доступа только с доверенных адресов.

Комплексные решения для централизованной аутентификации, такие как [8] или [9] уже включают в себя средства для выполнения этих задач.

Когда данные покидают ваш компьютер, куда они направляются? Что с ними происходит по пути? Какие существуют системы, обеспечивающие приватность вашей информации в пути следования и после прибытия к месту назначения? Если кратко — их много. Итак, пристегнитесь, вас ждет увлекательная экскурсия, в ходе которой мы расскажем о страшных мытарствах вашего логина и пароля, через которые им приходится пройти ради неразглашения ваших тайн в Интернете.

Рукопожатие TLS и центры сертификации

В контексте данного примера TLS обеспечивает две критически важные услуги: верификацию конечной точки и шифрование. Верификация конечной точки гарантирует, что все данные, которые вы получаете, исходят исключительно от того лица/с того сервера, откуда вы рассчитываете их получить (например, с Facebook). В предыдущем примере Труди смогла добавить крупицу своей вредоносной информации в транзакцию между нами и Facebook. Однако при верификации конечной точки мы можем быть уверены, что вся поступающая к нам информация приходит непосредственно от Facebook (даже если Труди все равно вклинилась в наше соединение). Шифрование обеспечивает, что Труди не сможет прочесть никаких данных, передаваемых между двумя сторонами.

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

Концептуально шифрование открытым ключом — довольно простой феномен (а обсуждение его сложных деталей выходит за рамки этой статьи). При симметричном шифровании один и тот же ключ используется для шифрования и дешифровки любых данных, которые вы собираетесь передавать. Защита напоминает обычный замок: если к вам в квартиру кто-нибудь подселяется, то вы даете ему точно такой ключ, какой уже есть у вас. Этим ключом можно открыть или закрыть дверь. При шифровании открытым ключом должно быть сгенерировано два ключа— публичный и соответствующий ему приватный. Данные зашифровываются приватным ключом, а расшифровать их можно только публичным.

Шифрование приватным ключом напоминает древний обычай скрепления писем восковой печатью и использование восковых клейм. Если на письме стоит печать с изображением лютоволка Старков, то кто угодно может открыть его (просто сломать печать,то есть воспользоваться публичным ключом). Кроме того, первый, кто вскроет это письмо, может не сомневаться,
что оно отправлено кем-то из дома Старков.

Я за всю жизнь не придумал более безупречной метафоры, которая бы описывала шифрование публичным ключом, чем следующая. Нормальная метафора такова: шифрование данных публичным ключом напоминает работу с сейфом, в котором есть ячейка, как в почтовом ящике. Кто угодно может бросить письмо в сейф, а прочесть его может лишь владелец сейфа. Если вы знаете более точную метафору – поделитесь в комментариях!

Facebook запрашивает Verisign (крупный центр сертификации) создать и подписать для него сертификат. При этом Verisign получает от Facebook его публичный ключ.
Verisign создает сертификат, в котором содержится идентификационная информация о Facebook и о публичном ключе Facebook.
Verisign шифрует сертификат своим приватным ключом. Это означает, что кто угодно может расшифровать эти данные, воспользовавшись публичным ключом Verisign; а также что прочитать сертификат можно только после такой расшифровки. Если кто-нибудь попробует расшифровать сертификат при помощи публичного ключа Verisign, и данные действительно окажутся в читаемом виде, то мы будем уверены, что сертификат действительно был подписан приватным ключом Verisign.
Когда Facebook присылает нам свой сертификат, мы расшифровываем его публичным ключом Verisign. Если сертификат откроется, и мы сможем извлечь оттуда публичный ключ Facebook, мы тем самым убедимся, что действительно общаемся с Facebook (поскольку доверяем Verisign).

Итак, работая по протоколу SSL/TLS, можно установить безопасное соединение и удостовериться, что мы действительно подключились к тому серверу (вышли на контакт с тем лицом), с которым собирались (при условии, что мы доверяем Verisign). Но случай с грандиозным взломом Equifax всегда напоминает, что даже если наши данные зашифрованы при передаче, это еще не гарантирует, что они будут защищены и в период хранения.

Хранение и хеширование паролей

Допустим, вы работаете в Facebook, в частности, управляете некоторыми базами данных компании. У вас есть права администратора, и это означает, что вы в любой момент можете обратиться к базе данных и проверить, какие данные там находятся. Далее предположим, вы знаете, что в Facebook о вас распускают грязные слухи. Согласитесь, хочется подсмотреть пароль обидчика, войти в систему под его именем и публично извиниться перед собой от лица обманутого таким образом негодяя. Либо, скажем, сотрудника ущемил сам Facebook, и он хочет немного отыграться, нелегально сбыв на черном рынке большой кэш с комбинациями логинов и паролей. Наконец, существует риск, что в базу данных проникнет посторонний (хакер), и такой риск тоже никогда нельзя свести к нулю. Даже если вы полностью доверяете всем своим сотрудникам, всегда сохраняется риск, что вашу базу данных могут взломать.

Основная проблема хранения паролей состоит в том, как сохранить достаточное количество информации, нужное для аутентификации пользователя, но при этом не допустить, чтобы кто-нибудь проник в базу данных и выдал себя за этого пользователя? Иными словами, как удостовериться, что нам предоставили корректный пароль, не сохраняя сам пароль? Для этого применяются криптографически безопасные хеш-функции.

К сожалению, хакеры научились обходить и такой механизм хранения данных.

Радужные таблицы

Радужная таблица – это атака, нацеленная на базы данных с хешированными паролями. Она основана на допущении, что большинству людей свойственна как минимум одна из этих слабостей:

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

Подсоленный хеш: не просто перекус на завтрак

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

Смысл соли удобнее всего объяснить на примере – с него и начнем. Допустим, мой пароль — “superSafe123” . Запустив в командной строке команду openssl , можно вычислить хеш моего пароля по алгоритму sha-256 (-n в следующем коде нужна, чтобы не появлялись переходы на новую строку от echo , а 256 я выбрал, потому что такой вариант лучше помещается на большинстве мониторов — 512 было бы надежнее):

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

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

Уникальная соль позволяет сгенерировать даже из самых распространенных паролей уникальные хеш-коды, если пароль хешируется в подсоленном виде. Любые атаки на основе заранее вычисленных значений в таком случае будут безуспешны, если только злоумышленник не научится систематически угадывать, какая именно соль добавляется к каждому конкретному паролю. Внося такую долю случайности, мы хорошо страхуемся против радужных таблиц, поскольку заранее вычислить все возможные исходные комбинации для хешей (пароль+соль) невозможно, тогда как вычислить хеши для всевозможных паролей вполне реально.

Что все это значит лично для меня?

Компьютерная безопасность – это война на истощение. Хакеры постоянно изобретают новые приемы, а специалисты по безопасности вырабатывают контрмеры. Чтобы защитить от хакеров себя и свою компанию, лучше всего постоянно обновлять ПО. При большинстве атак используются хорошо известные уязвимости, найденные в старых версиях программ. Среднестатистический хакер не занимается поиском новейших уязвимостей, а отыскивает, где уже установлен старый софт, уязвимости которого давно известны. С чем бы вы ни работали, будь то серверный фреймворк, операционная система или браузер – всегда устанавливайте новейшие обновления систем безопасности.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее

Sony Pictures database

Исследование Троя Ханта, который взял за предмет своих изысканий, базу пользователей Sony Pictures, стоит отметить, что все пароли хранилась в открытом виде. А дальше он проанализировал пользовательские пароли. Вот такие результаты у него получились.

Длина пароля

Как мы видим, основное количество паролей с диной от 6 до 10 символов. При этом у половины он менее 8 символов.

Используемые символы

1% - только буквы верхнего регистра
4% - только цифры
45% - только буквы нижнего регистра
50% - другие варианты

Криптографическая стойкость пароля определяется вариацией букв различных регистров + цифры + спец. символы ^ длина пароля. На данном примере мы можем наблюдать, что используются пассы одного типа.

Словарные пароли

36% - словарный пароль
64% - пароль не из словаря

Тест на уникальность

8% - уникальный пароль
92% - повторно используемый пароль

В базу Sony Pictures так же включены пароли для других сервисов. Собственно на таблице отображено, сколько юзеров везде используют один и тот же пасс.

Брутфорс хеша

18% - сложно взламываемый
82% - легко взламываемый через радужные таблицы

Поскольку все пароли хранились в открытом виде, но даже в случае если это были-бы хеши, нам удалось бы дешифровать примерно 82% от общего числа, с применением радужных таблиц.

E-mail password's

Пароли можете даже не пробовать сопоставлять, поскольку все это дело было намерено перемешано. Поскольку целью было не компрометация пользователей, а проведение анализа используемых паролей. Изначально список состоял из 24,546 записи. Все они имели следующий формат username@domain/password. После проведение небольшой очистки, осталось 23,573 аккаунта. Затем были удалены дубликаты и на выходе получился список из 21,686 аккаунта.

6. hotmail.fr – 346

12. hotmail.es – 117

Наиболее часто используемый пароль по прежнему остается 123456. Как вы можете увидеть ниже, из общего числа в 21,866 паролей, 91 из них 123456. Вот ТОП-100 наиболее часто используемых паролей из списка.

1. 123456 – 91
2. neopets – 39
3. monkey – 27
4. 123456789 – 26
5. 123321 – 24
6. password – 23
7. iloveyou – 17
8. princess – 16
9. horses – 16
10. tigger – 15
11. pokemon – 14
12. cheese – 14
13. 111111 – 13
14. kitty – 13
15. purple – 12
16. dragon – 12
17. nicole – 12
18. 1234567 – 11
19. alejandra – 11
20. daniel – 11
21. bubbles – 10
22. alejandro – 10
23. michelle – 10
24. 12345 – 10
25. hello – 10
26. c***** – 10
27. chocolate – 9
28. hottie – 9
29. alberto – 9
30. 12345678 – 9
31. fluffy – 9
32. buddy – 9
33. 123123 – 9
34. cassie – 9
35. andrea – 9
36. secret – 9
37. shadow – 9
38. tequiero – 9
39. ****llica – 9
40. poop – 8
41. hi – 8
42. sebastian – 8
43. jessica – 8
44. adopt – 8
45. 654321 – 8
46. justin – 7
47. newpw123 – 7
48. scooter – 7
49. soccer – 7
50. holly – 7
51. hannah – 7
52. flower – 7
53. 1234 – 7
54. jessie – 7
55. ashley – 7
56. tiger – 7
57. lauren – 7
58. football – 7
59. elizabeth – 7
60. casper – 7
61. roberto – 7
62. 000000 – 7
63. legolas – 7
64. estrella – 7
65. 159753 – 7
66. anime – 7
67. sabrina – 6
68. moomoo – 6
69. angelica – 6
70. cat123 – 6
71. bonita – 6
72. buster – 6
73. kitten – 6
74. killer – 6
75. qwerty – 6
76. chelsea – 6
77. sasuke – 6
78. olivia – 6
79. theresa – 6
80. america – 6
81. beatriz – 6
82. mariposa – 6
83. oscar – 6
84. rainbow – 6
85. yellow – 6
86. cool – 6
87. ginger – 6
88. maggie – 6
89. friends – 6
90. asdfgh – 6
91. abc123 – 6
92. neopet – 6
93. dancer – 6
94. amanda – 6
95. avatar – 6
96. boogie – 6
97. greenday – 6
98. thumper – 6
99. 666666 – 6
100. bob – 6

По формату паролей, можно извлечь следующую статистику.

43.3% — буквы, в нижнем регистре. Пример: monkey

2.1% — буквы, верхний и нижний регистр. Пример: Thomas

15.8% — только цифры. Пример: 123456

35.1% — буквы и цифры. Пример: j0s3ph

3.6% — буквы, цифры и спец. символы. Пример: sandra19_1961

30% — заканчивается цифрой. Пример: hello1

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

Для дешифровки использовался John the Ripper. Большинство паролей были подобраны с применением словаря на 17.5 MB, а остальные добивались с помощью других комбинированных атак. Ниже представлены 10 наиболее часто используемых паролей.

Rank Password Accounts
1 | 123456 | 1023
2 | password | 392
3 | rootkit | 341
4 | 111111 | 190
5 | 12345678 | 181
6 | qwerty | 175
7 | 123456789 | 170
8 | 123123 | 99
9 | qwertyui | 92
10 | letmein | 91

Как мы видим снова засветился уже побитый 123456. Так же стоит отметить тот факт, 3 место по популярности, занял пароль аналогичный названию ресурса, аж 341 результат. Я так же хочу добавить основываясь на своем многочисленном опыте, когда работаешь с базами, по дешифровке пассов, довольно часто попадаются ресурсы, которые в качестве пароля используют адрес этого самого ресурса. При этом данное наблюдение не является правило. Но на моей практике уже были порталы, где % таких пассов был достаточно велик, а были где вообще не использовался ни разу. Я пока не нашел зависимости данного наблюдения.

Для проверки надежности пароля

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

Читайте также: