1. Там сейчас 501,636,842 Pwned пароли
2. Они все еще хешированы SHA-1, но с некоторым удаленным мусором
3. Каждый пароль теперь имеет счетчик рядом с ним
4. Я не включил длину пароля
5. Загрузка данных
6. Запрос данных онлайн
7. Cloudflare, конфиденциальность и к-анонимность
8. Использование API (и механизм поиска диапазона)
9. Пароли в действии
10. закрытие

В августе прошлого года я запустил небольшую функцию в Я был Pwned (HIBP) я звонил Pwned Пароли , Это был список из 320 миллионов паролей от различных нарушений данных, которые организации могли бы использовать для лучшей защиты своих собственных систем. Как? NIST объясняет :

При обработке запросов на установление и изменение запомненных секретов верификаторы ДОЛЖНЫ сравнивать предполагаемые секреты со списком, который содержит значения, о которых известно, что они обычно используются, ожидаются или скомпрометированы.

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

Теперь все это было отличным советом от NIST, но они не смогли предоставить одну вещь, которая действительно необходима организациям для выполнения всей этой работы: сами пароли. Вот почему я создал Pwned Passwords - потому что был пробел, который нужно было заполнить - и давайте посмотрим правде в глаза, у меня есть доступ к довольно многим из них благодаря использованию HIBP. Итак, 6 месяцев назад я запустил сервис, и сегодня я рад запустить версию 2 с большим количеством паролей, большим количеством функций и тем, что меня особенно радует - с большей конфиденциальностью. Вот что это такое:

Там сейчас 501,636,842 Pwned пароли

Вернувшись к запуску V1, я объяснил, как исходный набор данных состоял из таких источников, как списки Anti Public и Exploit.in а также "множество других источников данных". В V2 я расширил его, включив в него несколько источников данных и два основных:

1. Рекорд 711 миллионов Onliner Spambot свалка , Это была большая работа по анализу различных форматов данных, и если вы прочитаете комментарии к этому сообщению в блоге, вы получите представление о том, как много людей хотели этого (и почему это было проблематично).
2. 1.4B учетные данные открытого текста из «темной паутины» , Эти данные привели ко многим раздутым новостям (и вошли в мой пост в блоге FUD на «темной паутине» на прошлой неделе), но они послужили полезным справочным материалом для V2. Эти данные также имели ряд проблем с целостностью, что означало, что фактическое число было несколько меньше. Например, одни и те же пары имени пользователя и пароля появляются с разными разделителями:

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

Но я не только добавил данные, но и удалил некоторые. Позвольте мне объяснить, почему и для начала давайте сделаем краткий обзор обоснования их хеширования.

Они все еще хешированы SHA-1, но с некоторым удаленным мусором

Когда я запустил V1, я объяснил, почему я их SHA-1 хэшировал:

Неважно, что SHA1 - это быстрый алгоритм, который не подходит для хранения паролей ваших клиентов, потому что это не то, что мы делаем здесь, а просто обеспечение того, чтобы исходные пароли не были сразу видны.

Это все еще на 100% верно на сегодняшний день. Есть конечно те, кто не согласен с этим подходом; они утверждают, что либо данные легко обнаруживаются достаточно онлайн в любом случае, либо наоборот, что SHA-1 является недостаточно надежным алгоритмом для хранения паролей. Они тоже правы - в обоих аспектах - но дело не в этом. Весь смысл в том, чтобы гарантировать, что любая личная информация в исходных данных будет запутана таким образом, чтобы потребовались согласованные усилия для снятия защиты, но чтобы данные по-прежнему могли использоваться по назначению. SHA-1 сделал это в V1, и я все еще достаточно уверен в модели, чтобы использовать тот же подход в V2.

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

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

1. $ HEX [e3eeeb]
2. 6dcc978317511fd8
3. <div align = \\\ 'center \\\' style = \\\ 'шрифт: полужирный 11px Verdana; ширина: 310px \\\ '> <a style = \\\' background-color: #eeeeee; отображение: блок; ширина: 310px; граница: сплошная 2px черная; padding: 5px \\\ 'href = \\\' http: // ...

Конечно, возможно, что люди действительно использовали эти строки в качестве паролей, но применяя немного Бритва Оккама предполагает, что это просто анализ проблем перед этим набором данных. Всего CynoSure Prime выявило 3472226 ненужных записей, которые я удалил в V2. (Кстати, это те самые парни, которые нашел недостатки в подходе хранения паролей Эшли Мэдисон еще в 2015 году - они делают качественную работу!)

Честно говоря, нет смысла удалять несколько миллионов ненужных строк. Это уменьшило общий размер данных V2 на 0,69% и, кроме крошечной доли дополнительных байтов, добавленных в набор, не имеет практического значения для того, как используются данные. По этому вопросу и с точки зрения посторонних записей я хочу быть действительно ясным по поводу следующего:

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

Несмотря на то, что общее количество записей, включенных в V2, является значительным, оно также не рассказывает всей истории, и, действительно, отзывы от V1 заключались в том, что для паролей 320M требовалось нечто большее: показатель того, насколько плохими были на самом деле все.

Каждый пароль теперь имеет счетчик рядом с ним

Пароль "abc123" хуже, чем "acl567"? Большинство измерителей надежности пароля считают их эквивалентными, потому что математически они есть. Но, как я уже говорил, индикаторы надежности пароля помогают людям делать неосведомленный выбор и это прекрасный пример этого. Они оба ужасные пароли - не поймите меня неправильно - но предсказуемый расклад клавиатуры делает первый намного хуже, и теперь это отражено в данных Pwned Passwords.

Теперь, с одной стороны, вы можете утверждать, что если пароль был взломан хотя бы один раз, он непригоден для использования в будущем. Он войдет в словари паролей, будет проверен на имя пользователя, с которым он был рядом, и навсегда останется слабым выбором, независимо от того, где он появится в будущем. Тем не менее, я получил много отзывов от V1 о том, что «простая блокировка паролей 320M - это кошмар с точки зрения удобства использования». Блокировка полмиллиарда, тем более.

В V2 каждый пароль имеет счетчик рядом с ним. Это означает, что рядом с «abc123» вы увидите 2670319 - именно столько раз оно появлялось в моих источниках данных. Очевидно, что с таким высоким числом оно появилось много раз в одних и тех же источниках, потому что многие люди выбирали один и тот же пароль. С другой стороны, пароль «acl567» появился только один раз. Наличие информации о распространенности означает, что, например, вы можете полностью заблокировать каждый пароль, который появился 100 или более раз, и заставить пользователя выбрать другой (в наборе данных 1858690 из них), настоятельно рекомендуем выбрать другой пароль, если он появляется от 20 до 99 раз (есть еще 9 985 150) и просто помечает запись, если она находится в исходных данных менее 20 раз. Конечно, пароль «acl567» вполне может считаться слишком слабым в соответствии с требованиями сайта, даже без Pwned Passwords, так что это ни в коем случае не единственный тест, который должен применяться сайтом.

Всего из этих 501 636 842 уникальных паролей было 3 033 858 815 экземпляров. Другими словами, в среднем каждый пароль появлялся 6 раз при различных нарушениях данных. В некоторых случаях один и тот же пароль появлялся много раз в одном инциденте - часто тысячи раз - потому что именно столько людей выбрали один и тот же чертов пароль!

Теперь, сказав все это, в преддверии запуска V2 я заставлял людей решительно утверждать, что все они должны быть заблокированы или что ни один из них не должен быть заблокирован или любая комбинация между ними. Это не мое дело, это зависит от того, кто использует эти данные, моя работа заключается в том, чтобы просто предоставлять людям достаточно информации, чтобы принимать обоснованные решения. Мой собственный субъективный взгляд на это состоит в том, что «это зависит»; Разные уровни риска, разная аудитория и разные меры по смягчению последствий должны принимать во внимание это решение.

Я не включил длину пароля

Один запрос, который появлялся несколько раз, состоял в том, чтобы включить атрибут длины в каждый хэш пароля. Таким образом, те, кто использует данные, могут исключить пароли из исходного набора данных, которые не соответствуют их минимальным требованиям к длине пароля. Мысль о том, что это уменьшит объем данных, которые они ищут, таким образом, реализует некоторый прирост производительности (и, возможно, финансовый). Но есть много причин, почему это в конечном итоге не имеет смысла:

Во-первых, с точки зрения защиты исходных данных (помните, что они содержат PII местами), явное указание длины значительно уменьшает усилия, необходимые для взлома паролей. Да, я знаю, что говорил ранее, что подход хеширования не должен был быть высокоэластичным, но предоставление длины значительно ухудшило бы защиту, которую обеспечивает SHA-1.

Затем я немного научился этому и посмотрел на то, какая минимальная длина пароля требуется для веб-сайтов. На самом деле, именно поэтому я написал кусок на минимальная длина по лучшим сайтам мира пару недель назад; Я хотел поставить жесткие цифры на это. 11 из 15 сайтов, на которые я ссылался, имели минимальную длину 6 символов или менее. Когда я тогда пошел и посмотрел на набор данных, который я использовал, исключая пароли менее 6 символов, можно было бы уменьшить набор только на менее чем 1%. Исключение всего, что меньше 8 символов, сократило бы его чуть менее чем на 16%. Они очень маленькие числа.

Кроме того, накладные расходы требуются для размещения и поиска этих данных, то есть накладные расходы, которые несут организации, которые их используют. Это должно быть очень близко к нулю с полмиллиардным набором данных. Бросьте его в структуру хранилища, такую ​​как хранилище таблиц Azure, и вы будете смотреть на однозначные доллары в месяц с поиском в однозначных миллисекундах. Нет необходимости, чтобы это было более сложным, чем это.

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

Загрузка данных

А теперь самое главное - загрузка данных. Как и в случае с V1, есть один большой архив 7z, который вы можете иди и сразу же открывай со страницы Pwned Passwords на HIBP , Также, как и раньше, он доступен через прямую загрузку с сайта или через торрент. Я хочу настоятельно призвать вас взять его через торрент, позвольте мне объяснить, почему:

Базовая конструкция хранилища для этих данных - хранилище BLOB-объектов Azure. Если бы я должен был предоставить файл непосредственно оттуда, я бы выписал очень большой счет за данные. Cloudflare пришел на помощь в V1 и дал мне бесплатный план, который позволил кэшировать файл такого размера в качестве их краевых узлов. Влияние этого на мой счет было огромным:

Представьте себе обсуждение с моей женой, если бы не поддержка Cloudflare! И это было до загрузки еще 6 месяцев. Cloudflare, возможно, предоставил мне услугу бесплатно, но им все равно придется платить за пропускную способность, поэтому я хотел бы попросить вас о поддержке в сборе данных через торренты, а не по прямой ссылке для скачивания. Для этого пользовательский интерфейс активно рекомендует вам захватить торрент:

Если вы не можете захватить торрент (и я понимаю, что, например, в корпоративной среде торренты заблокированы), скачайте его напрямую, но сделайте свою лепту, чтобы помочь мне, поддерживая тех, кто меня поддерживает. Как и в случае с V1, торрент-файл подается непосредственно из хранилища BLOB-объектов HIBP, а рядом с ним вы найдете хэш SHA-1 файла Pwned Passwords, чтобы вы могли проверить целостность, если вы так склонны.

Так что это загрузка - иди вперед и делать хорошие вещи с ним! Теперь что-то еще круто, и это онлайн-поиск.

Запрос данных онлайн

В V1 я встал функция онлайн-поиска где вы можете подключить пароль и посмотреть, появился ли он в наборе данных. Это было на вершине API, который я также сделал доступным для независимого потребления, если люди захотят его использовать. И многие люди использовали это. На самом деле, некоторые из участников мое соревнование, чтобы выиграть ноутбук Lenovo использовал эту конкретную конечную точку, в том числе победитель конкурса, 16-летний Феликс Жиффар. Он создал PasswordSecurity.info который напрямую использует API Pwned Passwords через клиентскую часть:

Возвращаясь к поиску в Интернете, осознавая, что не хотите отправлять неправильное сообщение людям, непосредственно перед окном поиска я поставил очень четкое и очень смелое сообщение: «Не отправляйте пароль, который вы активно используете, сторонним службам. - даже этот!

Но люди не всегда читают эти вещи. Сервис получил кучу прессы, и миллионы людей спустились на сайт, чтобы проверить свои пароли. По крайней мере, я предполагаю, что это были их пароли, я, конечно, не регистрирую эти поиски, но основываясь на новостных статьях и комментариях в социальных сетях, да, это была бы куча реальных паролей. И я действительно согласен с этим - позвольте мне объяснить:

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

Онлайн-поиск работает почти так же, как и в V1, хотя счетчик паролей теперь тоже представлен:

Довольно простые вещи и по большей части тоже довольно знакомые. Но есть одна очень важная и очень крутая разница. Позволь мне объяснить:

Cloudflare, конфиденциальность и к-анонимность

В то, что оказалось очень случайным временем, Джунаде Али от Cloudflare обратились ко мне в прошлом месяце с идеей. Они хотели создать инструмент для поиска в Pwned Passwords V1, но сделать это таким образом, чтобы внешние участники могли использовать его и сохранять анонимность. Видите ли, проблема с моей существующей реализацией заключалась в том, что, хотя вы могли передать только хеш-пароль SHA-1, если он вернул попадание, и я должен был принять это и вернуть его обратно к чистому (что я мог легко сделать, потому что Я создал хэши в первую очередь!) Я бы знал пароль. Это усложняло отправку сервиса для отправки реальных паролей.

Идея Джунаде была другой, хотя; он предложил использовать математическое свойство под названием k -анонимность и в рамках Pwned Passwords это работает так: представьте, хотите ли вы проверить, существует ли пароль «P @ ssw0rd» в наборе данных. (Между прочим, хакеры разработали, что люди делают подобные вещи. Я знаю, это отстой. Они на нас.) Хэш SHA-1 этой строки имеет вид "21BD12DC183F740EE76F27B78EB39C8AD972A757", поэтому мы собираемся просто взять первые 5 символов , в данном случае это означает «21BD1». Это отправляется в API Pwned Passwords, и он отвечает 475 суффиксами хеша (это все, что после «21BD1») и подсчетом, сколько раз был увиден исходный пароль. Например:

1. (21BD1) 0018A45C4D1DEF81644B54AB7F969B88D65: 1 (пароль "lauragpe")
2. (21BD1) 00D4F6E8FA6EECAD2A3AA415EEC418D38EC: 2 (пароль "alexguo029")
3. (21BD1) 011053FD0102E94D6AE2F8B83D76FAF94F6: 1 (пароль "BDnd9102")
4. (21BD1) 012A7CA357541F0AC487871FEEC1891C49C: 2 (пароль "melobie")
5. (21BD1) 0136E006E24E7D152139815FB0FC6A50B15: 2 (пароль «квевекиный»)
6. ...

Я добавил префикс в скобках заранее, а исходные пароли в скобках потом, просто чтобы проиллюстрировать, что мы здесь делаем; это просто разные строки, которые хэшируются до значений с одинаковыми первыми 5 символами. Другими словами, все они находятся в одном и том же «диапазоне», и вы увидите, что этот термин упоминается позже. Используя эту модель, кто-то, осуществляющий поиск в наборе данных, просто возвращает суффиксы хеша и считает (все выделено жирным шрифтом после первых 5 символов), и он может затем увидеть, соответствует ли все после первых 5 символов их хеша какой-либо из возвращенных строк. Теперь имейте в виду, что, насколько мне известно, частичный хэш, который я послал, может быть любым из 475 различных возможных значений. Или это может быть что-то совершенно другое, я просто не знаю, и в этом заключается ценность анонимности.

Ради перспективы, вот некоторые статистические данные о том, что это означает для данных в Pwned Passwords:

1. Каждый префикс от 00000 до FFFFF заполняется данными (16 ^ 5 комбинаций)
2. Среднее количество возвращенных хэшей - 478
3. Наименьшее - 381 (префиксы хешей "E0812" и "E613D")
4. Наибольшее значение - 584 (префиксы хешей "00000" и "4A4E8")

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

Эта модель анонимности является тем, что сейчас скрывается за функцией онлайн-поиска. Вы можете увидеть это в действии, попробовав поиск «P @ ssw0rd», который вернет экран на предыдущем изображении. Если мы опустимся и посмотрим на инструменты разработки, вот фактический запрос, который был сделан:

Пароль был хеширован на стороне клиента, и только первые 5 символов были переданы в API (я расскажу подробнее о механике этого в ближайшее время). Вот что потом возвращается в ответе:

Как упоминалось ранее, существует 475 хешей, начинающихся с «21BD1», но только 1 соответствует остатку хеша для «P @ ssw0rd», и эта запись указывает на то, что пароль ранее был просмотрен 47,205 раз. И это все - это то, что я сделал с поддержкой Cloudflare, и это то, что мы сделали вместе, чтобы защитить анонимность и сделать сервис доступным для всех. Позвольте мне теперь поговорить о том, как вы можете использовать API.

Использование API (и механизм поиска диапазона)

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

Во-первых, вы заметите, что я передаю этот API из другого домена в другие API HIBP и, действительно, из V1 службы Pwned Passwords. Для версии V2 я установил функцию Azure в домене api.pwnedpasswords.com, которая получает API-интерфейс с веб-сайта HIBP и вместо этого работает на бессерверной инфраструктуре. Я писал о функциях Azure в прошлом и они являются отличным способом построения легко масштабируемой, гибкой архитектуры «код как услуга». Это гарантирует, что нагрузка сходит с веб-сайта HIBP и что я могу бесконечно масштабировать службу Pwned Passwords, хотя и прямо на мой кошелек! Это также дало мне гибкость в таких вещах, как обрезание множества чрезмерных заголовков, таких как политика безопасности контента, используемая HIBP (это бесполезно для одиночной конечной точки API).

Во-вторых, существующий API (от которого многие люди создали зависимости!) По-прежнему работает просто отлично. Примечание: из-за успеха модели k-анонимности, поиск по паролю был прекращен 1 июня 2018 года , Он также указывает на хранилище V2 с установленным паролем, поэтому теперь он просматривает полмиллиарда записей. Я оставлю этот запуск в обозримом будущем, но если вы используете его, я бы предпочел, чтобы вы перешли на конечную точку на api.pwnedpasswords.com по причинам, упомянутым выше, и по этим другим причинам:

Если вы использовали исходный API через HTTP GET, переход на новый API в вашей реализации абсолютно ничего не меняет, кроме URL, который будет выглядеть следующим образом:

ПОЛУЧИТЕ https://api.pwnedpasswords.com/pwnedpassword/ averagepassword}

Он все равно вернет HTTP 200, когда пароль найден, и 404, если его нет. Единственное отличие (и это не должно нарушать существующее использование) состоит в том, что ответ 200 теперь также содержит счет в теле в виде единственного целого числа:

И, как и раньше, вы всегда можете передать хеш, если предпочитаете:

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

https://api.pwnedpasswords.com/range/{hashPrefix}

Который возвращает результат как это:

Помните, что все это суффиксы хеша (за которыми следует счетчик), поэтому полное значение первого хеша, например, «21BD10018A45C4D1DEF81644B54AB7F969B88D65». Кстати, при вводе данных в API не учитывается регистр, поэтому «21bd1» работает так же хорошо, как и «21BD1». Все возвращаемые суффиксы хеша (и в действительности те, которые указаны в загружаемых данных) пишутся заглавными буквами просто потому, что это вывод из Хэш-функции SQL Server (Я обработал исходные данные в локальном экземпляре RDBMS).

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

Теперь, еще несколько вещей, касающихся некоторых дизайнерских решений, которые я принял: я очень осторожен с потенциальным влиянием на мой кошелек такой работы сервиса. Одно дело - поддерживать V1, который только возвращал код ответа HTTP, был ограничен по скорости и действительно не был предназначен для массового вызова одним потребителем (учитывая последствия для конфиденциальности), это совсем другое - делать то, что я сделано с V2, особенно когда каждый поиск API диапазона возвращает сотни записей. Например, этот поиск "P @ ssw0rd" возвращает 9 730 байт при сжатии (это довольно средний размер), и я плачу за выходную пропускную способность из Azure, выполнение функции и вызов основного хранилища. Крошечные суммы каждый раз, заметьте, но мне пришлось уменьшить это влияние на меня, насколько это возможно, с помощью ряда мер.

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

Вы также заметите, что в заголовке элемента управления кэшем есть длинный максимальный возраст:

Это кэш-память на 31 день, и последующий заголовок состояния кеша Cloudflare объясняет, почему: путем маршрутизации через свою инфраструктуру они могут агрессивно кэшировать эти результаты, что гарантирует не только молниеносный ответ (помните, в настоящее время они имеют 121 краевой узел по всему миру так что есть один рядом с тобой), но я не ношу финансовый удар людей, которые бьют мое происхождение. Особенно, если учесть степень, в которой несколько человек используют один и тот же пароль, когда мы говорим о поиске диапазона, где многие разные пароли имеют одинаковые префиксы хеша, есть некоторые существенные преимущества, которые можно получить от кэширования. Как упоминалось ранее, в диапазоне от 00000 до FFFFF существует 16 ^ 5 различных хеш-префиксов (1 048 576), поэтому вы можете увидеть, насколько широкое использование выиграет от кэширования во многих миллионах поисковых запросов. Одно только различие в производительности при сравнении кэшированного результата с не кэшированным дает веский аргумент:

Это означает, что, хотя ответ значительно больше, чем в V1, если я могу обработать запрос к новому API из кэша, на самом деле это огромное улучшение. Вот серия обращений к V1, где каждый раз, когда запрос должен был пройти весь путь до исходного сервера, нажать API и затем запросить 320M записей:

Чтобы сделать возможным агрессивное кэширование, я также поддерживаю только HTTP GET. Теперь некоторые люди сойдут с ума по этому поводу, потому что они скажут: «Это означает, что он входит в журналы, и вы будете отслеживать пароли, которые искали». Если вы беспокоитесь о том, что я что-то отслеживаю, не используйте сервис. Это не предназначено, чтобы быть легкомысленным утверждением, скорее простым подтверждением того, что вам нужно доверять оператору службы, если вы собираетесь отправлять пароли в любой форме или форме. Смещение - это вся ситуация k-анонимности; даже если вы не доверяете сервису или считаете, что журналы могут быть утечки и злоупотребления (и, кстати, ничего явно не регистрируется, это не более чем временные системные журналы), поиск диапазона проходит очень долгий путь к защите источника. Если вы по- прежнему не доверяете ему, просто скачайте хеши и разместите их самостоятельно. Нет, на самом деле, в этом весь смысл делать их доступными и, честно говоря, если бы я строил поверх этих хэшей, то я бы определенно запросил свой собственный репозиторий.

Таким образом, если вы используете поиск по диапазону, вы получаете защиту исходного пароля намного больше, чем я мог сделать в V1, плюс это значительно быстрее, если кто-то еще выполнил поиск любого пароля, который хэшируется до те же первые 5 символов SHA-1. Плюс, это очень помогает мне с точки зрения снижения затрат!

Пароли в действии

Наконец, я хочу привести несколько примеров первого поколения Pwned Passwords в действии. Я надеюсь, что они вдохновят других на создание этого набора данных и, в конечном счете, внесут позитивный вклад в безопасность веб-сайтов для всех.

Например, Workbooks.com (среди прочего, они делают программное обеспечение CRM) объясняет клиентам, что пароль Pwned слабый или ранее появлялся в утечке данных ,

Тогда есть Colloq (они помогают вам открывать конференции), который написал отличный кусок с множеством характеристик производительности об их реализации данных.

Или же попробуйте создать аккаунт на Toepoke с паролем "P @ ssw0rd" и посмотрите, как это вам подходит:

safepass.me также взял данные и обернул их в автономный коммерческий фильтр Active Directory (плюс бесплатная домашняя версия).

На мобильном фронте есть Pwned Pass в магазине Google Play который находится поверх существующего API.

Ничто так не набирает обороты, как свободные вещи! Предоставление HIBP бесплатного поиска по вашему адресу (или всему вашему домену) - лучшее, что я когда-либо делал с точки зрения того, чтобы заставить его работать. Через несколько месяцев после запуска сервиса я встал страница пожертвований где вы могли бы купить мне пива (или кофе или другие вещи). Он поднялся только после того, как люди специально попросили его («Эй, классное обслуживание, могу я принести тебе кофе?»), И я был очень доволен ответами на него. Как я сказал на странице, это больше затрат времени, которое действительно стоит мне (я независим, поэтому, пока я создаю что-то вроде Pwned Passwords, я не занимаюсь чем-то другим), но есть и затраты, которые могут вас удивить :

Это одно из тех «австралийских» проявлений любезности того факта, что моя скорость разгона достигает 1,5 Мбит / с (а затем распределяется между всеми вещами в моем доме, которые отправляют данные). Пониженная скорость составляет около 114, но подъем чего-либо - это кошмар. (А для австралийских друзей, нет, в моем районе Золотого Берега еще нет NBN, но, видимо, это не за горами.) И нет, это не решаемая проблема, когда все делается в облаке, и есть много причин, почему это не сработало бы (я опубликую их позже).

Если вы хотите помочь принять эти расходы и кричи мне сочувствие кофе или пиво (с) Это все еще очень ценится!

закрытие

Pwned Passwords V2 теперь доступен! Все, что вам нужно для их использования, закончилось страница Pwned Passwords в HIBP где вы можете проверить их онлайн, узнать об API или просто скачать все. Все эти модели бесплатны, неограниченны и даже не требуют атрибуции, если вы не хотите их предоставлять, просто берите то, что есть, и делайте с этим что-то хорошее 😀

Похожие

Комментарии