Что такое валидный пароль
Проверка сложности паролей на 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. Возможно их база также была скомпрометирована.
Валидация полей 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 аттрибуты скопом и применить их к новому полю (не забудьте только заменить название класса).
Валидация — что это простыми словами? Чем отличается валидация от верификации? + ПРАКТИЧЕСКИЙ СОВЕТ
Здравствуйте, дорогие читатели! Добро пожаловать на блог!
Валидация — что это простыми словами? Чем отличается валидация от верификации? Ответы на эти вопросы — в статье.
Многие слова «валидация» и «верификация» считают синонимами. Но это не так. Разница есть, но она очень тонкая. Давайте разбираться.
Валидация и верификация — что это простыми словами?
Справедливости ради надо сказать, что в разных областях деятельности (в банках, в платежных системах, в интернете), в разных отраслях производства эти термины используются по-разному. Я решила привести здесь определение валидации и верификации из стандарта ISO 9000.
Мы видим, что определения совпадают в значительной части, но не полностью. Однако, несмотря на такое большое совпадение валидация и верификация — это разные действия.
Чтобы проще было понять, что такое валидация, давайте сначала разберемся, чем валидация отличается от верификации.
Чем отличается валидация от верификации?
Итак, что такое верификация? Более детально можете узнать из этой статьи, но здесь скажем коротко, что слово «верификация» происходит от английского слова «verification» — проверка. А слово «валидация» происходит от английского «validation» — придание законной силы.
Примеры валидации и верификации в разных сферах.
Без примеров трудно понять отличия валидации и верификации. Приведем несколько примеров из разных областей.
Пример из области медицины
Скажем, разработали новое лекарство. Провели многочисленные тесты для ПРОВЕРКИ, что лекарство лечит такую-то болезнь. Здесь речь идет о ВЕРИФИКАЦИИ (о проверке соответствия лекарства его предназначению). Но Вы знаете, что на самом деле лекарство подходит не всем. Чтобы начать лечение Вам нужна ВАЛИДАЦИЯ врача. Только врач может ПОДТВЕРДИТЬ, что это лекарство подойдет КОНКРЕТНО Вам.
ВЕРИФИКАЦИЯ — это тестирование лекарства с целью ПРОВЕРКИ на соответствие его предназначению. А ВАЛИДАЦИЯ — это ПОДТВЕРЖДЕНИЕ врача, что лекарство подойдет КОНКРЕТНОМУ больному.
Пример из области производства
Предположим завод по производству велосипедов принял заказ на партию велосипедов. Так вот, ВЕРИФИКАЦИЮ (ПРОВЕРКУ) на соответствие требованиям заказчика выполняет сам завод-производитель. А вот ВАЛИДАЦИЮ (ТЕСТИРОВАНИЕ, ПРОВЕРКУ) на соответствие своим требованиям будут выполнять представители самого заказчика.
Пример из области IT
Аналогичный пример можно привести из области IT. Компания — разработчик программного обеспечения получила заказ на разработку какого-то софта. Программа, которая была создана, прошла тестирование. Результатом тестирования является ВЕРИФИКАЦИЯ на стороне компании, выполняющей заказ, что программа полностью соответствует тех заданию заказчика. А вот ВАЛИДАЦИЮ будет выполнять сам заказчик, когда установит программное обеспечение и протестирует его.
Пример из сферы интернета
Социальная сеть Твиттер проводит ВЕРИФИКАЦИЮ аккаунтов знаменитостей, чтобы участники сети точно знали, что посты публикуются действительно этой знаменитостью. В результате верификации в аккаунте знаменитости появляется синий значок с галочкой.
Еще пример. Для того, чтобы стать продавцом на Амазоне, Вам необходимо пройти ВЕРИФИКАЦИЮ личности. Также необходимо пройти верификацию при регистрации аккаунтов во всех платежных системах (Вебмани, Яндекс.Деньги, Киви и т.д.)
Пример из законодательной области
Инициативный депутат решил улучшить жизнь и придумал прогрессивный Закон. Законотворческие органы выполнят ПРОВЕРКУ нового Закона на соответствие другим Законам и международному праву и ВЕРИФИЦИРУЮТ его. Но Закон вступит в силу не сразу, а только через месяц — после его ВАЛИДАЦИИ (придания законной силы) высшим органом законодательной власти. За этот месяц можно отозвать Закон, выявив вред для каких-то КОНКРЕТНЫХ слоев населения.
Например, соц сеть Твиттер верифицирует аккаунты знаменитостей для того, чтобы пользователи были уверены, что сообщения действительно публикует эта знаменитость или её официальный представитель. В аккаунте пользователя Твиттере, который прошел такую верификацию, ставится синий значок с галочкой.
Теперь можно сделать общий вывод, что верификация (проверка) встречается чаще, чем валидация. Валидация (подтверждение для конкретного случая) нужна не всегда.
Практический совет
Вы спросите, для чего нужно разбираться в этих терминах? Скажу, что есть и практическая польза. Главная цель верификации и валидации — безопасность, чтобы Ваши банковские карты и аккаунты были защищены. Однако, пользуясь тем, что многие не разбираются в этих терминах, злоумышленники для похищения личных данных часто применяют такой способ, как сообщение с просьбой верифицировать или валидировать вашу банковскую карту, аккаунт и т.д..
Практический совет: При появлении окна с просьбой верификации или валидации Ваших данных проверьте в адресной строке данные сайта, нет ли пропущенных или лишних символов. Либо попробуйте зайти в эту программу с другого устройства и если такого сообщения не появляется, значит Ваш компьютер надо лечить от опасных вирусов.
Резюме
Надеюсь, статья, оказалась полезной для Вас и Вы теперь знаете ответы на вопросы: Валидация — что это простыми словами? Чем отличается валидация от верификации?
Вот по традиции порция полезного видео. В котором Жак Фреско учит мыслить нестандартно, не так, как все. ЭТИ НЕСКОЛЬКО МИНУТ БУДУТ ТОЧНО ПОТРАЧЕНЫ НЕ ЗРЯ!
Желаю всем новых идей и много сил для их реализации!