валидный пароль что это
Проверка сложности паролей на Python
Адекватной реакцией на эту проблему со стороны разработчиков является проверка пользовательских паролей и, соответственно если пароль слишком прост, предложение создать пароль посерьезней. Давайте рассмотрим как можно реализовать наиболее распространенные проверки.
Начальные действия
Валидация по формату пароля
Валидация по списку наиболее часто встречающихся паролей
Что ж наша функция легко находит такие очевидные слова типа qwerty, но что если пользователь будет не так прост, и на наше замечание, что его пароль слишком очевиден, скажем, просто добавит куда нибудь точку или поставит пару цифр вначале и в конце: (вставить результаты тестов?) qwert.y, 0qwerty0 или даже q.w.e.r.t.y.?
Добавим эти проверки в тест:
Такие очевидные хаки наш валидатор уже не в состоянии отловить.
Класс SequenceMatcher принимает на вход две последовательности и предоставляет несколько методов для оценки их сходства. Нас интересует метод ratio() который возвращает число в диапазоне [0,1] характеризующее «похожесть» двух последовательностей, где 1 соответствует двум абсолютно одинаковым последовательностям, а 0 абсолютно разным.
Перепишем нашу функцию валидации следующим образом:
Кроме того, здесь я использую функцию:
dropwhile(lambda x: x.startswith(‘#’), f)
из модуля itertools для того, чтобы пропустить закомментированные строки вначале файла common-passwords.txt, впрочем их можно было просто удалить вручную.
Протестируем наш переписанный валидатор:
Валидация по использованию в качестве пароля других полей
Проверим как работает наша функция:
Перечисленных способов, как правило, будет достаточно, впрочем, и ими тоже не стоит слишком увлекаться, иначе дружелюбность вашего интерфейса для пользователей станет примерно вот такой:
Так что, выбор какие способы и с какой степенью сложности использовать в своих проектах зависит лишь от серьезности вашего проекта, необходимой степени защиты. ну и пожалуй от ваших садистских наклонностей.
Анализ утёкших паролей Gmail, Yandex и Mail.Ru
Совсем недавно в публичный доступ попали базы паролей популярных почтовых сервисов [1,2,3] и сегодня мы их проанализируем и ответим на ряд вопросов о качестве паролей и возможном источнике (или источниках). Так же мы обсудим метрики качества отдельных паролей и всей выборки.
Не менее интересными являются некоторые аномалии и закономерности баз паролей, возможно, они смогут пролить свет на то, что могло служить источником данных и насколько данная выборка является опасной с точки зрения обычного пользователя.
Формально, мы рассмотрим следующие вопросы: насколько надежными являются пароли в базе и могли ли они быть собраны словарной атакой? Есть ли признаки фишинговых атак? Могла ли «утечка» данных быть единственным источником данных? Могла ли данная база быть аккумулирована в течение длительного периода или данные исключительно «свежие»?
Описание данных
Данные из всех трех баз представляют собой набор пар адрес-пароль, разделенные двоеточием. Никаких других «мета-данных» недоступно. Однако данные достаточно зашумленные т.е. в них присутствуют строки не являющимися ни адресами почты, ни допустимыми паролями.
Если мы исследуем особенности данных, то сможем выдвинуть (или опровергнуть) гипотезу о том, в результате какого процесса пароли могли быть получены.
Невалидные пароли и не-пароли
Самые простой критерий невалидности пароля — несоответствие длины пароля требованиям почтовых сервисов.
Полученные данные говорят, что пароли из выборки не могли быть получены в результате «внутренней» утечки, так как несколько тысяч паролей не являются валидными паролями в принципе из-за ограничений на длину пароля в шесть символов (а для современных паролей gmail в восемь символов).
Рассмотрим эти аномально длинные (более 60) и короткие пароли (менее 6) в деталях.
Примеры
Длинные пароли представляют собой куски HTML-кода, один из репрезентативных примеров:
Подобные примеры указывают, что одним из источников паролей мог быть фишинг. Запись в базе явно не была проверена человеком и получена автоматически, на фишинг так же указывает тот факт, что в пароле присутствует html-разметка, что довольно нетипично для кражи пароля через заражение.
Краткая выборка слишком коротких паролей:
Еще один индикатор того, что одним из источников мог быть фишинг — отсутствие логина и пароля в записях. Особенно интересно выглядит апостроф без указания пароля. Возможно, потенциальная жертва догадалась о фишинговой форме и попыталась проверить наличие SQL инъекции.
Что можно однозначно утверждать по проверенным данным? Автоматической валидации базы не происходило. Наиболее вероятные гипотезы: фишинг и заражение вирусом.
Для того, чтобы оценить качество всей выборки, мы удалим из неё заведомо неверные пароли длины меньше 6 и больше 60 и рассмотрим всё распределение в целом по нескольким параметрам.
Распределение длины паролей
Как видно из графика ниже, большая часть паролей имеет длину в 8 или менее символов. Что может указывать на то, что существенный пласт паролей потенциально неустойчив к различному виду атак переборных атак.
Распределение надёжности паролей
Тогда распределение надёжности имеет вид:
Как видно из графика большинство паролей попадают в категорию не-надежные. В качестве примера рассмотрим пароли нулевой надёжности, так как скорее всего это ещё один репрезентативный пример невалидных паролей.
Пароли нулевой надёжности
Как видно из примеров выше, данные пароли не являются валидными (и с точки зрения человека выглядят скорее ошибкой ввода, чем действительным паролем), так как почтовые сервисы не дают зарегистрировать ящик, если считают пароль слишком простым, например, повторением одного и того же символа шесть раз. А значит, что возможно ещё больший пласт паролей не является валидным согласно современным требованиям.
Возможно, что существенная часть базы собрана в течение длительного периода времени, когда требования к паролям были мягче? Иначе довольно сложно объяснить столь большую группу паролей, не соответствующих требованиям современных почтовых систем.
Словарная атака
В качестве дополнительного аргумента проведем следующий эксперимент: возьмём выборку релевантных словарей паролей из общего доступа, проведем атаку на доступные пароли по этим словарям и оценим какой процент паролей содержится в этой выборке словарей (автор буквально не уходил дальше первых трёх ссылок гугла по запросу [password dictionary]).
Из таблицы выше видно, что существенная доля паролей содержится в словарях, что так же указывает на то, что часть паролей могла быть получена в результате словарной атаки (или какой-то модификации перебора).
Топ паролей
Приведем подборку наиболее популярных паролей и заметим, что большая часть сейчас не является допустимыми паролями.
Выборка Gmail
Действия и данные, описанные и полученные в данной и следующей части, были произведены и переданы другом моего друга, пожелавшего остаться неизвестным.
Задача: проверить валидность (т.е. что пароль действительно подходит) паролей. Действие: по небольшой выборке из
150-200 попробовать получить доступ к ящикам. Из всей выборки в принципе валидными являются
2-3% (через несколько часов появления данных в открытом доступе), и фактически все являются деактивированными на момент проверки. Реально действующими являлись менее 1% ящиков и те заброшены владельцами по крайней мере в течение года.
Выборка Rambler
Несложно обнаружить в сети списки «действительно валидных» адресов, составленных широким кругом заинтересованных лиц (ака кулхацкеры).
Что интересно, среди них довольно большой процент адресов рамблера.
Rambler был предупрежден за несколько дней до публикации и был получен ответ, что необходимые меры безопасности будут приняты в ближайшее время.
Что интересно, процент валидных паролей существенно выше и до последнего времени rambler был вне медийного поля событий и не активизировал дополнительных систем безопасности.
Это позволило неизвестному антропологу утечки оценить последние моменты жизни почтовых ящиков. Несмотря на валидность паролей, все ящики являлись заброшенными в течение долгого времени (
1-1.5 года) и заканчивались одним из подобных писем:
Что является еще одним подтверждением гипотезы о фишинге и кумулятивной природе базы.
Анализ открытых источников
Вернемся к рассмотрению открытых источников. Активный поиск по паролям-логинам, привел нас к ряду раздач с геймерских форумов:
Оказывается, что часть списка уже в какой-то форме гуляла по сети.
Таким образом данные позволяют отвергнуть гипотезу о единственном источнике данных таком как «внутренняя утечка».
Основная часть используемого кода:
Заключение
Таким образом наиболее вероятной выглядит гипотеза, что данная выборка — компиляция различных источников (фишинг, заражение, словарно-переборные атаки, собрание популярных подборок) в течение длительного периода времени. Достаточная часть данных в принципе не является валидными паролями по формальным синтаксическим критериям, что также подтвердила экспериментальная проверка.
С точки зрения пользователя данное событие не несет существенной опасности и скорее выглядит попыткой создания инфоповода.
UPD. Еще одним свидетельством того, что слитые данные — компиляция различный источников является наличие подборки gmail аккаунтов с «+» фичей в базе, когда адрес имеет вид имя+домен\слово at gmail.com (за напоминание про эту фичу спасибо geka)
Топ-10 доменов из выборки (весь список тут)
176 xtube
132 daz
88 filedropper
66 daz3d
64 eharmony
63 friendster
62 savage
57 spam
54 bioware
52 savage2
…
11 paygr
11 comicbookdb
…
Про paygr: пользователь gkond писал, что
Нашел свой е-мейл в дампе. Пароль, которой рядом с ним указан автоматически сгенерировал мне сервис paygr.com, в далеком мае 2011 года.
при этом «paygr» встречается 11 раз в списке «+» gmail. Возможно их база также была скомпрометирована.
Как не обломать мозг об пароли вроде eLkdC,lk#jB
Нормальный стойкий пароль фиг запомнишь. Почти аксиома. Еще и безопасники радостно подбрасывают дровишек в этот костер ужаса, заставляя раз в месяц учить чудовищный фарш из мешанины символов. Параноидальные меры безопасности в лучших традициях «Хакера в столовой» приводят лишь к тому, что пользователи заботливо царапают пароли на мониторе или складывают под клавиатуру. Нет, серьезно, ну кто из обычных пользователей в здравом уме будет соблюдать требования к паролю в духе:
Энтропия
Классические пароли становятся более сложными для запоминания человеком и все более легкими в подборе для машины. Это прискорбно. На очередном очень важном и секьюрном сайте с кулинарными рецептами от вас требуют десятизначный пароль во всех регистрах и с цифрами? Тут могут быть три причины.
Сложность пароля в компьютерной индустрии обычно оценивают в терминах информационной энтропии (понятие из теории информации), измеряемой в битах. Вместо количества попыток, которые необходимо предпринять для угадывания пароля, вычисляется логарифм по основанию 2 от этого числа, и полученное число называется количеством «битов энтропии» в пароле. Пароль со, скажем, 42-битной сложностью, посчитанной таким способом, будет соответствовать случайно сгенерированному паролю длиной в 42 бита. Другими словами, чтобы методом полного перебора найти пароль с 42-битной сложностью, необходимо создать 2 42 паролей и попытаться использовать их; один из 2 42 паролей окажется правильным. Согласно формуле при увеличении длины пароля на один бит количество возможных паролей удвоится, что сделает задачу атакующего в два раза сложнее. В среднем атакующий должен будет проверить половину из всех возможных паролей до того, как найдет правильный.
Википедия
Валидация email
Подготовка
Перед тем как писать валидацию, надо знать из чего состоит email адрес. Думаю известно всем что это «username@hostname». Лучше всего будет разбить создание регэкспа на 2 логические части — валидация hostname и валидация username. Начнём с более объёмного.
Валидация hostname
Для начала подумаем, а из чего же состоит hostname?
Имя хоста состоит из нескольких компонентов, разделённых точкой и не превышающих 63 символа, и суффиксов (домены первого уровня). Компоненты, в свою очередь, состоят из латинских букв, цифр и дефисов, причём дефисы не могут быть в начале или в конце компонента. Суффиксы это ограниченный список доменов первого уровня (я нашёл список на сайте IANA). Для упрощения выражения запишем домены стран как [a-z][a-z] (любые 2 символа от a до z не зависимо от регистра). Так же не будем использовать не латинские символы, пока они официально не введены в публичное пользование. В итоге получим выражение проверяющее суффикс (конструкция (foo|bar) говорит о том что происходит поиск либо foo либо bar, т.е. заменяет или):
Для компонентов код будет посложнее:
[a-z0-9] # обязательная буква латинского алфавита или цифра
([-a-z0-9]<0,61>[a-z0-9])? # необязательная часть
\. # точка
Рассмотрим необязательную часть:
# дефис ставиться на первое место в группе символов, иначе он принимается за промежуток
# <0,61>после группы символов означает, что группа может повторятся от 0 до 61 раза
[-a-z0-9]<0,61>
# 61 для того, чтобы в группе не было более 63 символов в сумме
[a-z0-9]
В итоге мы получили выражение отвечающее за проверку hostname:
Обращу внимание на то, что присутствие компонентов не обязательно, т.к. некоторые домены первого уровня поддерживаются серверами. Пример.
Валидация username
На самом деле тут все просто: 1 или более символ [-a-z0-9!#$%&’*+/=?^_`
В итоге
Регэксп проверки email:
Это выражение можно каплю оптимизировать (про оптимизацию, я думаю, будет отдельная статья):
Бонус
Рассмотрим регэксп, который привели в пример в комментарии к вступительному топику:
Валидация полей iOS — быстро и просто
Валидация полей ввода — едва ли не самая распространенная задача в мобильных приложениях. Каждое приложение которое имеет форму авторизации и регистрации, также имеет некоторое количество средств ввода информации со стороны пользователя, которые порождают вполне ожидаемый садистско — изощренный ажиотаж тестировщиков. Продвинутая, технически-грамотная общность разработчиков научилась эффективно с ними с ним бороться путем встраивания регулярных выражений в исходный код.
Как правило, когда нужно ограничится регистрацией и авторизацией, не требуется прилагать особые усилия для достижения поставленной цели — код переносится из одного проекта в другой, практически не претерпевая изменений. И, что особо важно, без увеличения человеко-часов на дальнейшее сопровождение этого кода. Но мир не был бы столь прост, если бы не творческие порывы UI/UX дизайнеров, которые склонны вопреки устоявшейся традиции, логике и здравому смыслу изобретать новые способы взаимодействия с конечным пользователем, размещая на форме несколько, на их взгляд, необходимых элементов управления, доступность которых зависит от декартового множества условий проверки валидности большого количества полей ввода и других управляющих контролов. К сожалению, и эту ситуацию, вряд ли можно назвать редкой.
Раздражение разработчика нарастает пропорционально тому, как часто ему приходится нарушать DRY принципы: с одной стороны профессиональная гордость не позволяет идти на компромиссы, а с другой — копипаст кода — наиболее эффективный способ избежать длительного цикла тестирования — отладки. Однообразный скопипасщенный код значительно проще поддерживать, чем, идеологически выверенный уникальный «велосипед». Поиск же альтернативы не только растрачивает время творчества разработчика, но и добавляет зависимости в проект.
Вместе с тем, iOS SDK представляет некоторые крайне недооцененные возможности, которые легко масштабируются на множество задач связанных не только с валидацией — декларативное программирование сильно облегчает жизнь разработчика. Конечно же, автору известен непримиримый стан любителей друзей использования «неразбавленного» кода, но, поскольку профессиональная деятельность по верстке интерфейсов у автора статьи начиналась с разработки графического UI еще для MS DOS, то, большого желания тратить время на создание очередного совершенного класса — не возникает, и если при равной ценности можно использовать мышь — предпочтение будет отдано мыши. Соответственно, здесь изложено как минимизировать количество кода, чтоб ускорить и упростить процесс разработки.
Типичная минимальная задача выглядит следующим образом:
Имеется поля ввода логина и пароля, и кнопка авторизации. Необходимо чтоб кнопка авторизации меняла состояние (isEnable) в зависимости от того, что содержится в полях ввода.
Несколько более расширенная версия этой задачи выглядит так:
Имеем поля ввода email, password и phone number, а так же две кнопки — регистрация и запрос SMS кода на введенный телефон. Кнопка регистрации должна быть доступна только когда введены правильные данные в каждое из полей. А кнопка запроса кода — когда валидно поле номера телефона.
Типичное решение — создание взаимозависимых флагов путем комбинации операторов «if» и «switch» в одном вью-контроллере. Сложность будет нарастать с увеличением количества контролов вовлеченных в процесс. Значительно более продвинутым решением будет создание машины состояний. Решение отличное — но трудоемкое, к тому же, имеющее высокий порог вхождение — а это, отнюдь не то, что хочется реализовать ленивому (АКА «истинному») разработчику.
Общая идея предлагаемого состоит в следующем:
Существует класс для поля ввода и класс менеджера валидации. Поле ввода унаследован, как и ожидается, от UITextField. Менеджер валидации — наследуется от UIControl, содержит в себе коллекцию валидируемых элементов (совершенно не обязательно это должны быть потомки UITextField) и реализует паттерн «наблюдатель». Кроме того, он выступает менеджером для других элементов управления, которые должны менять свой статус доступности при изменении состояния валидируемых элементов. Другими словами, если поле содержит невалидный email, кнопка регистрации должна быть недоступна.
Поля ввода самовалидируемые — они могут ответить на вопрос валидные ли содержащиеся в них данные, и изменить свое состояние. Некоторые разработчики предпочитают использовать отдельный класс валидатора (и его потомки) для валидации полей ввода, но такая практика лишает возможности в полной мере насладится декларативностью и масштабируемостью переносимого кода. Для нас важно, чтоб поле ввода или любой другой валидируемый контрол поддерживало простой интерфейс вида:
Для добавления валидации в Ваш проект необходимо добавить 4 файла из примера размещенного в репозитории GitHub.
Процесс валидации показан на видео (gif).
Как видно, перед началом ввода поле находится в дефолтном состоянии, а валидация происходит по мере ввода данных. Если покинуть поле до завершения валидации, над полем появляется надпись, уведомляющая об ошибке. Кнопка регистрации будет недоступна до тех пор, пока оба поля не станут валидными.
Аналогичная ситуация складывается и на втором экране (который становится доступным только после активации регистрации). Но на втором экране валидация полей и кнопок происходит независимо — кнопка регистрации становится доступной только если все поля провалидизировались. В то же время кнопка отправки SMS доступна уже тогда, когда валидно поле с номером телефона.
А теперь фокус: Во всем проекте содержится только один класс для вью-контроллера, тот самый, который был создан XCode при создании проекта из шаблона. Он совершенно пустой. Но даже он не используется. В этом не сложно убедиться при помощи диспетчера.
Внимательный читатель заметил, что справа от респондера находится Объект из стандартной палитры компонентов XCode. Для него параметр Class переопределен классом DSValidationManager. Такой же трюк проделан и для полей ввода, с той лишь разницей, что там используется класс DSTextField.
Теперь все наше программирование сводится к следующим простым действиям:
Код DSValidationManager до безобразия примитивен.
Как видно, он получает уведомление от одной коллекции, и воздействует на другую.
Из всего кода TextEdit следует отметить только то, что поле должно позаботится о том, чтоб правильно выставить свойство «isValid», и дернуть метода «verified()» у своего делегата. Однако, обратите внимание, что в поле ввода используется не ссылка на объект менеджера, а коллекция. Это позволяет привязать поле ввода к нескольким менеджерам.
Соответственно, метод нужно будет дернуть у каждого из делегатов.
Теперь, если Вам потребуется сверстать новую форму с полями ввода, Вам даже не нужно будет выставлять кастомные значения свойств — достаточно будет скопировать нужные Runtime аттрибуты скопом и применить их к новому полю (не забудьте только заменить название класса).