Comments 148
Рано или поздно базы украденных паролей достигнут такого размера (и объёма), что брутфорс цели будет быстрее поиска по базе
Пароли должны умереть как класс, есть Fast IDentity Online и надстройки над ними (типа passkey). Если очень хочется - то используй опционально пароль как второй фактор, чтобы утрата токена не стала утратой аккаунта
Чем отличается пароль в БД, от пароля как второй фактор в БД?
Первый фактор - аппаратный токен.
Второй - включай только если очень-очень хочется, не хочется - не включай. Ну утек пароль-второй фактор, что с ним делать-то?
Обычно люди по ту сторону интернета не имеют доступа к аппаратным токенам в твоем кармане. А случайный прохожий нашедший токен - тоже особо не сможет им воспользоваться ибо не знает куда и с каким логином заходить. Плюс опциональная защита пин-кодом…
Первый фактор - аппаратный токен.
Какого рода аппаратный токен? Если totp, то затравка для него не хешируется и при утечке с сервера базы затравок сразу вскрываются все аккаунты. Если какой-нибудь юбики, то возня с ним это сложно и с мобилками ещё сложнее.
аппаратным токенам в твоем кармане
То есть, всё-таки totp. Сколько аппаратных токенов вы носите в своём кармане? Если один со многими аккаунтами, то он ничем не отличается от гугл-аутентификатора на телефоне. Если по одному на каждый аккаунт, то у меня в базе кипасса пара сотен записей. Это мне с чемоданом токенов ходить прикажете? И при необходимости расплатиться в магазе по qr-колу перерыть весь чемодан в поисках токена от банка. Ну, и см выше про утечки - они в этом случае на порядки опаснее утечек баз паролей. Именно поэтому железные токены используют именно как второй фактор, а не как основной.
Какого рода аппаратный токен?
Fast IDentity Online
FIDO2-токен, или, при поддержке сервисом passkey - современное android/ios устройство. Windows вроде бы тоже сейчас умеет. Если уж совсем никак - есть ещё и кросплатформенный Bitwarden. Passkey - есть надстройка над FIDO2.
То есть, всё-таки totp
Нет
Сколько аппаратных токенов вы носите в своём кармане?
Один yubikey, это не считая телефона
см выше про утечки - они в этом случае на порядки опаснее утечек баз паролей.
Утечка публичного ключа опаснее утечки пароля?
Если какой-нибудь юбики, то возня с ним это сложно
Коснуться nfc модуля телефона по запросу сайта - сложно? Воткнуть в USB-порт пк и коснуться сенсорной кнопки вызывает трудности?
и с мобилками ещё сложнее.
С приходом passkey - навести камеру телефона на QR-код на экране, и отсканировать палец сканером отпечатка/ввести пароль экрана блокировки вызывает трудности? Или просто отсканировать палец если доступ к ресурсу напрямую с телефона
Самая большая проблема FIDO2 - это то что нужен аппаратный токен. А цены на них - не не очень приятные. Поддержка части спецификации, в частности universal 2nd factor была в андроиде если я не ошибаюсь аж с 6 версии. С помощью passkey вендоры попытались решить проблему необходимости токена. Теперь токеном может быть твой телефон без всяких проводов
P.S. Сейчас у меня вызывает недоумение вся эта цепочка начиная от моего первого сообщения под этим постом
С помощью passkey вендоры попытались решить проблему необходимости токена.
Я, кстати, не очень понимаю, почему гугломикрософты не завалили рынок этими самыми токенами так, чтобы в каждом супермаркете висели по стоимости ну хотя бы умеренно плохого механического замка на дверь. Вот наверняка они не настолько дорогие в производстве, как Yubiko, Алладины и прочие пытаются убедить.
гугломикрософты
Гугл, кстати, продает. Но снова $30 за 1 titan security key :c
Да и с внедрением они тянули не один год
Но снова $30 за 1 titan security key
Ну вот да. Что в этом микроконтроллере настолько дорогое?
Что в этом микроконтроллере настолько дорогое?
Жаба.
Цена пиццы, что в ней Настолько дорогое?
Там цена пиццы, у нас 1/6 от зп ставки учителя, а где-то даже месячная зарплата при тяжелом физическом труде.
Проще говоря - бросовая цена, но для стран "первого мира", очередной paywall.
Если бы компания действительно хотела массовости, ценник мог бы быть в районе 1$. Но гиганты ориентируются прежде всего на рынок США и Европы, что, впрочем, логично.
Я заметил, эти 30$ уже как некая магическая цифра минимальной суммы, которую там не жалко выбросить, соответственно цены разных подписок на всякого рода сервисах (даже совсем иных компаний) также стремятся к ней.
Не удивлюсь, если китайцы рано или поздно возьмут и займут эту нишу собственными однодолларовыми аутентификаторами (какой-нибудь "weechat security key"), заодно выиграют еще один инструмент контроля.
Если бы компания действительно хотела массовости, ценник мог бы быть в районе 1$.
Компании хотят прибыль. Массовость идет уже после. И совсем после - снижение цен.
у нас 1/6 от зп ставки учителя
Всего 1/6, даже копить не нужно. И покупается это не каждый месяц, а один раз в десять лет, может и дольше.
Ну как сказать, не явно завалили - в смартфонах уже повсеместно стоят спец. чипы. Всякие Google Titan (чип) у Apple свой есть, TPM тот же.
А вот устройства (те же чипы но с единственной задачей) по типу юбиков и т.д. это отдельный класс там есть и отдельные сертификации по типу fips для специфичных условий и применения в тех же госах. По сути они такие дорогие из-за своего класса и лицензирования. В основном в этих контроллерах дорогое это экранирования и прочие вещи с усложнением создания копии (речь про данные конечно же).
И все эти сертификации в контексте доступа к гугловой/микросовтовской учетке нужны зачем? Кому по должности положено и паранойя велит - пусть покупает весь этот в усмерть сертифицированный. Остальным можно и попроще.
Кроме того, смотрим банковские карты и SIM-ки сотовых операторов. Их даром раздают. Не знаю, столько они банкам и операторам стоят, но вряд ли бы это делали, если бы цена была как у этих продаваемых токенов.
Используйте смартфон от Apple, Google или Microsoft (это уже вряд ли) там уже имеется необходимый чип и вероятнее даже уже Passkeys доступны или в скором времени станут доступны (у Google и Apple уже).
Согласен, по сути весь Passkeys это плюс/минус тоже что происходит и с банковскими картами. При том же посещении банка когда просят поднести или вставить в терминал любую карту банка и ввести пин код.
Но токены по типу юбиков это всё же чуть другой уровень, это как те же корпоративные карты доступа (у сотрудников банка к примеру) там требования чуть повыше чем к банковским картам клиентов.
Используйте смартфон
Там, к сожалению, все на браузер в этом смартфоне завязали. И на связь с интернетом. И на наличие Bluetooth на десктопе. Иметь приложение и использовать какой-нибудь мелкий смарт, чтобы логинится на десктопе - нельзя. После чтения QR оно (да устройство, что QR прочитало) запускает хром или сафари, через интернет на сайт лезет, чтобы хандшейк сделать и посредством bluetooth проверяет, что я рядом нахожусь. Причем только для этого, а не для того, чтобы все то, для чего интернет понадобился, сделать.
Если бы этот смарфон можно было по USB подключить и он работал в качестве того самого хардварного токена и в оффлайне - было бы хорошо. Но оно так не умеет.
Ну это не совсем так, на сайт ничего не лезет от слова совсем, сайт общается через WebAuthn с хостом (браузер/sdk для нативных приложений) и обменивается только запросами регистрации или подписи, получая только ответ, браузер/sdk общаются уже по ctap с аутентификатором, который либо чип на этом же устройстве, либо подключенный внешний как-либо, если используется QR, то там общение происходит по Bluetooth для того, чтобы был фактор присутствия, если компьютер и смартфон могут соединиться по Bluetooth или nfc или usb мы уверены, что они рядом друг с другом. Это борьба с тем, что сфоткал QR, отправил куда-то и оттуда пытаешься подписать.
В теории в схеме с QR можно использовать кроме Bluetooth ещё и usb/nfc, но они не применяются. Возможно (надо посмотреть исходники хромиума) в схеме с QR устройства могут соединиться в рамках одной сети (Wi-Fi), тогда в схеме QR не нужны usb/nfc. Это на самом деле потенциальный feature request. Сам QR это по сути хендшейк на соединение по ctap.
Точно есть одно место где хромиум ходит по сети, это чтобы на связанное устройство отправить пуш уведомление с теми же настройками, что и в QR, а далее вновь Bluetooth.
Но хендшейк тут и все общение ctap вообще не затрагивает сайт.
Ну это не совсем так, на сайт ничего не лезет от слова совсем
При использовании QR-лезет. Вот описание.
Scanning the QR code triggers the users second device (e.g. smartphone or tablet) to interpret the FIDO URI and communicate with the authentication server, sending a signal that the user is attempting to authenticate via a new device (e.g. the friends laptop).
И ниже
No Bluetooth, Pure Internet: It is important to note that in this QR code-based passkey cross-platform authentication (hybrid transport), Bluetooth is not involved in the authentication and data exchange. This process relies entirely on an Internet connection for the transmission of encrypted data between the devices and the server.
Сам QR это по сути хендшейк на соединение по ctap.
Вот, к сожалению, нет.
Вот когда железку в порт втыкаем - там от воткнутой железки интернета не хотят, но смартфон таким образом использовать нельзя.
Вот, к сожалению, нет.
И всё же QR это хендшейк точнее часть хендшейка, в нем хранится публичный ключ для ECDH, shared secret (16 байт), число известных стандартизированных тоннелей (24 байта), доп флаги (дата, поддержка state assist) и хинт операции (создание ключа или подпись).
BLE Advert зашифрованная информация по выбранному хосту туннелирования, коду соединения и т.д.
По сути весь CTAP Cable можно реализовать и локально заменив Websocket общением по usb кабелю, чего сейчас нет, темнее как бы намекает.
В конечном счёте этим самым гибридным соединением управляет клиент (пусть и на стороне аутентификатора) с самим же чипом общение идёт по ctap на hid. У юбиков ну никак нет интернета.
Само наличие туннеля в гибриде темнеменее я не могу отнести к "общается с сайтом" т.к. туннель тут третья сторона, которая просто предоставила релей (сообщения отправляемые в туннель шифруются), более того туннель принадлежит реализующим данный гибридный аутентификатор сторонам.
Т.е. у Google (Chrome, Android, Play Services) это cable.ua5v.com и им владеет Google. У Apple это cable.auth.com.
В любом случае caBLE потенциально может использовать любой другой альтернативный канал кроме Интернета, за исключением Bluetooth.
Тут именно суть в том, гибридный аутентификатор, способный работать с QR является посредником между аутентификатором и клиентом. И в целом если клиент и гибридный аутентификатор умеют ходить не через сеть, а как-то ещё, сохраняя общий принцип установки туннеля по QR, то собственно им ничего не мешает это сделать другое дело это выход из текущего стандарта.
(пусть и на стороне аутентификатора) с самим же чипом общение идёт по ctap на hid. У юбиков ну никак нет интернета.
Вот именно. И них - есть оффлайн по очевидным причинам. А для смарфонов - интернет почему-то понадобился.
Вопрос стоит так. Вот этот протокол для втыкаемых в USB железок есть? Есть. Работает? Работает.
Но какие-то соображения мешают смартфону работать по тому же самому протоколу по тому же самому USB. Чего я слегка не понимаю.
Т.е. у Google (Chrome, Android, Play Services) это cable.ua5v.com и им владеет Google. У Apple это cable.auth.com.
Это у них развесистая экосистема. Просто для одиночного сайта можно считать, что соответствующий сервер аутентификации - это часть сайта.
На самом деле в теории по caBLE можно и юбики подключить, я на это собственно и указал, что гибридный аутентификатор это собственно приложение на смартфоне, которое как раз и устанавливает соединение из QR. В случае Android это будет Chrome или Play Services, однако за этим приложением стоит дальнейшее общение по hid с чипом.
Предположу, что изначально идея была в работе с QR без проводов, собственно caBLE это же Cloud Assisted BLE. Но общие концепции можно переложить как я указал на другие транспорты поменяв WebSocket на что-то ещё.
Это у них развесистая экосистема. Просто для одиночного сайта можно считать, что соответствующий сервер аутентификации - это часть сайта.
В том то и дело, что нет, это на данный момент два единственно известных релея для caBLE, придумывали caBLE в Google и сейчас это уже вторая версия.
Если вы используете соединение на смартфоне с сервисами Google или с Google Chrome, релеем будет cable.ua5v.com, если вы пользуетесь устройством Apple релеем будет cable.auth.com.
Ещё раз повторюсь, что конечный релей выбирает гибридный аутентификатор т.е. устройство, которое отсканировало QR, оно же эту информацию предоставит клиенту (десктоп к примеру) через зашифрованный BLE Advert.
Т.е. если вы отсканируйте на iPhone отображенный в Google Chrome QR, то общение будет через cable.auth.com.
Всё по тому, что через данные релеи можно инициировать соединение с привязанным устройством без QR, что по сути является запросом на специальный эндпоинт на релее: cable.auth.com/cable/contact/...
В данном случае релей отправит push уведомление на iPhone с данными для подключения. Собственно приложение реализующее гибридный аутентификатор получит данное уведомление и запустит BLE Advert.
Т.е. известно на данный момент о двух релеях, которые по сути управляются крупными производителями. На Android устройствах без Google Play Services, очевидно должено быть реализовано своё приложение, которое выступит гибридным аутентификатором и свой релей т.е. потенциально это Microsoft, если решат вновь взяться за мобильные устройства и пожалуй Huawei, ну может кто-нибудь у нас по импортозамещению такое сделает. Ну или на крайний случай Энтерпрайз для поддержки caBLE через своё приложение в своей закрытой сети со своим релеем.
Опять таки к сайту релеи не имеют никакого отношения и вообще глобально, что приложения, что сайты даже не в курсе того, что есть какие-то посредники, они видят чисто SDK, который за собой скрывает общение на прямую по ctap на hid, или общение через туннель, в конечном счёте превращающиеся в ctap по hid.
Опять таки к сайту релеи не имеют никакого отношения и вообще глобально, что приложения, что сайты даже не в курсе того, что есть какие-то посредники
Я все-таки буду настаивать. Если вход в сайт ломается без какого-то сервера, то этот сервер - часть сайта, пусть и отданная на оутсорс какой-то третей стороне.
Что, впрочем, не отменяет основного вопроса - почему хардварный USB ключ может авторизовать меня без интернета, а аутентификатор в смарфоне - нет? Какая, вообще, логика в том, что нужно стучаться в какой-то релей в интернете, если ключики они вот тут, прямо на устройстве, вроде бы, лежат?
Условно говоря отдана на аутсорс не владельцами сайта/приложения, а скорее владельцами платформы на которой этот сайт/приложение доступны и скорее даже не на аутсорс, а владельцы платформы сами предоставили данный сервис. Всё же это несколько иное, отношения к сайту ровно ни какого.
По USB, возможно это будет реализовано, возможно нет, однозначно связано с режимом работы и протоколом по USB, не просто так ведь есть выбор зарядка, передача файлов, midi, etc.
Всё же тебе юбики выполняю одну задачу, соответственно и протокол применяемый к usb порту будет так же единственным. Как и у флешек или камер.
Всё же это несколько иное, отношения к сайту ровно ни какого.
Владелец сайта перестанет так думать, когда вход в него отвалится из за отсутствия связи с этим релеем - вопросы к нему посыплются.
По USB, возможно это будет реализовано, возможно нет, однозначно связано с режимом работы и протоколом по USB, не просто так ведь есть выбор зарядка, передача файлов, midi, etc.
Неубедительно как-то. Ну ладно, не хотим шнурок или не можем проводом - ну так все равно же Bluetooth используется - почему бы по нему всю нужную информацию не передать?
Владелец сайта сам не знает каким методом через что там внутри отрабатывает, он видит только WebAuthn, который для него стандартный API, а вот платформа которая предоставляет это API и реализует уже по разному выглядит, разные опции даёт (по QR, по usb/nfc/BLE или вообще как-то проприетарно). Это вообще не известно владельцу сайта, потом это может быть целенаправленное требование как число символов в пароле и наличие спец символов. Ну если сайт ограничил на английском алфавите пароли, хоть как пользователь может плясать, кириллицу он не сможет использовать и собственно владельцам сайтов уже в данном случае заведомо всё-равно, а бывают ещё и законодательные требования, как внезапно пропали входы по OAuth в Яндексе со внешних сервисов.
Ну ладно, не хотим шнурок или не можем проводом - ну так все равно же Bluetooth используется - почему бы по нему всю нужную информацию не передать?
Я не проверял возможность использовать смартфон при ручном выборе аутентификации по Bluetooth, но caBLE форсируется из-за интеграции с платформой, те же связывания устройств, чтобы QR использовался только при первом входе с устройства, а дальше его можно было выбрать в меню и инициировать связь уже без QR через те же пуши.
но caBLE форсируется
А как соответствующая рекомендация гуглится? Или это тихое коллективное решение вендоров?
По сути нигде. Это решение связанное с продвижением Passkeys именно резидентных ключей с организацией дополнительно синхронизации в хранилищах ключей, всё для того, чтобы упростить жизнь пользователей. Минимизация проблем при утере устройства, когда синхронизируется ключ фактически не потерян и может быть восстановлен из облака. Так же и caBLE по сути помогает использовать ключи на устройствах из других экосистем с поддержкой связывания собственно говоря.
Собственно логика простая, если это обычный пользователь без каких-то доп требований и ограничений по типу air gapped инфраструктуры, то вот caBLE и Passkeys с интеграцией в хранилища ключей и синхронизации с облаками.
Если что-то специфичное, то уже обычные ключи по типу юбиков, которые можно отслеживать по серийникам и т.д. и т.п. Что глобально работает также, только транспорт usb/nfc/Bluetooth.
Да и в целом у всех у кого есть смартфон и ноутбук проблем с caBLE точно нет, для стационарников тоже постепенно пропадает т.к. на материнках всё чаще уже имеется Bluetooth модуль как собственно и TPM. Ну а интернет сейчас повсеместно, даже в банальном сценарии оплаты в магазине.
Тут вообще уже как бы современные тенденции к тому, чтобы у устройства был Bluetooth, TPM (или другой специализированный чип), ещё и чипы для машинного вычисления NPU. Чем дальше тем больше всего такого будет обязательным и это не плохо на самом деле.
Это решение связанное с продвижением Passkeys именно резидентных ключей с организацией дополнительно синхронизации в хранилищах ключей, всё для того, чтобы упростить жизнь пользователей.
С этим вопросом товарищи как-то не определились, кажется. Тот же гугл, судя по тому, что я видел - склонен создавать отельный для своей учетки passkey на каждом устройстве. Потому что 'отозвать доступ этого устройства к учетной записи' - так выполняется ловчее. А когда один ключик на всех устройствах используется - придется мудрить.
Там всё очень очевидно и определено Google, Apple и Microsoft пришли к тому, что у каждой из этих компаний есть своё хранилище паролей Google Password Manager, Apple Keychain, Windows Hello. Которые суммарно покрывают большую часть пользовательских устройств.
Буквально у практически любого человека есть хотя бы один аккаунт у одной из этих компаний т.к. имеется хотя бы одно устройство из одной из трёх крупнейших экосистем.
Так вот пользователь когда создаёт первый ключ (будем говорить о Passkey) в первую очередь создаётся cross-platform (это буквально best practice), такой ключ не привязан к устройству пользователя и может быть синхронизирован и собственно говоря синхронизируется в хранилище. В зависимости от экосистемы устройства на котором создаётся ключ он будет либо в Google Password Manager, либо в Apple Keychain, либо в Windows Hello.
Т.е. основной ключ у него легко синхронизируется в рамках одной экосистемы, если нужно войти в устройстве из другой экосистемы тут как раз и будет отрабатывать caBLE с QR и связыванием устройств (браузер буквально запомнит инфу для повторного подключения уже без QR и будет в списке устройств предлагать связанное). Более того эта инфа сейчас хранится на устройстве и к ней имеет доступ не только Google Chrome, но и Windows Hello вполне будет видеть связанное устройство. Таким образом потеря устройства не становится такой большой проблемой, ключ можно восстановить из облака.
Далее после создания первого ключа на сайте опять таки по best practice сайт предложит сделать platform ключ (он не синхронизируется и привязан к устройству жёстко, из чипа не экспортируется). Так и будет описано, что для обеспечения более простого взаимодействия на устройстве. Такие ключи по сути рекомендуется пользователю иметь на основных устройствах. При входе с нового устройства с применением cross-platform ключа также будет предлагаться сделать platform ключ для этого устройства.
Сам Google при входе в его аккаунт с Android автоматически создаёт такой platform ключ в аккаунте.
Важно, что все эти ключи создаются и работают при включенной блокировке экрана, хотя бы с графическим кодом. Надёжность и сложность разблокировки устройства полностью за пользователем, если нужно соблюсти требования пользователь ставит либо сложный пин, либо биометрию. Всё дело в том, что разблокировка устройства происходит через безопасный чип, сама разблокировка по сути расшифровывает мастер ключ чипа.
А ещё вы можете добавить cross-platform ключ в виде юбика и подобных nfc/BLE/usb security key.
В основном при утере будет удаляться либо юбик, либо platform ключ (как раз отзыв устройства в вашем примере), ключ из экосистемы пользователь вряд ли будет удалять, скорее просто удаленно разлогинит устройство из экосистемы.
Если у пользователя есть по ключу в каждой из трёх экосистем, как таковой платформенные ключи особо и не нужны.
Про недоумение: видимо кто-то не пробовал пасскеи, ни в виде телефона, ни в виде usb токена+pin, ни то, что предоставляется виндой, макосью или менеджерами паролей
Хотя удивительно — уже на каждом шагу они навязываются (гитхаб/гитлаб/эпол/гугл/мс и много где ещё)
Если totp, то затравка для него не хешируется и при утечке с сервера базы затравок сразу вскрываются все аккаунты.
В смысле? Т.е. вы храните секретные ключи своих клиентов как plaintext? Вроде бы все понятно, что секреты (пароли, API токены и т.д. и т.п.) нужно хранить заранее подготавливая - пароли хешируем, секреты которые нужно использовать, а не только проверять шифруем. Да даже PII нужно шифровать уже как бы...
То есть, всё-таки totp.
Очевидно, что ваш собеседник про FIDO2 в частности Passkeys (FIDO2 Discoverable Credentials).
Если по одному на каждый аккаунт, то у меня в базе кипасса пара сотен записей. Это мне с чемоданом токенов ходить прикажете?
Подход с FIDO2 который сейчас формируется это делаешь ключ в любом переносимом/платформонезависимом хранилище (1-2 хранилища) это может быть Yubikey, Рутокен + любой кейчейн которому доверяешь Google Passwords, Apple Keychain, Microsoft Hello, KeePass, etc... И несколько ключей на устройстве (платформозависимые) для быстроты авторизации (это уже опционально).
И при необходимости расплатиться в магазе по qr-колу перерыть весь чемодан в поисках токена от банка.
QR будет, если вы не будите иметь рядом usb/nfc или платформозависимые (на устройстве) ключ и то его нужно только отсканировать и ввести код разблокировки. Искать в чемодане не нужно он сами найдутся т.к. инфа для поиска user handle на ключах уже хранится (это касается FIDO2 Discoverable Credentials, они же резидентные).
Ну, и см выше про утечки - они в этом случае на порядки опаснее утечек баз паролей.
Не правда, FIDO2 на стороне сервера позволяет хранить только публичный ключ и максимум ряд технический параметров ключа (включая число использований). Утечка публичного ключа вообще не страшна на то он и публичный. Здесь другие векторы атаки нужны: нужно либо своровать токен, но он защищён пином и имеет лимит на число неверных вводов, либо ломать устройство, тоже есть защиты.
По сути FIDO2 и конкретно Passkeys это аналог плюс/минус того, что люди итак носят с собой (банковские карточки), только пин там не лимитируется в длине и нет cvc/cvv. (Вспоминаем аутентификацию в банке - пришли в банк за услугой, вас попросили приложить к терминалу любую карточку банка и ввести пин).
Именно поэтому железные токены используют именно как второй фактор, а не как основной.
Ну для начала Passkeys сам по себе это уже мультифактор - владение (устройством/юбиком), знание (пин), присутствие (взаимодействие, расстояние между устройствами общающимися по ctap и таймауты).
На GitHub можно использовать как основной способ входа, на Google аналогично, на Mos.ru, даже на Яндексе. Относительно Google они вообще своих сотрудников ещё в далёкие года переводили на юбики.
В случае потери токены у вас если вы позаботились будет резервный способ (другой токен), если вы входили через токен в облачном кейчейне, разлогиниваете потерянное устройство в сервисе с ключами, если потеряли устройство с платформозависимые ключом (а это и юбики в т.ч.) заходите с использованием дополнительного ключа на другом устройстве к примеру (с компьютера, если потерян смартфон) и в аккаунте удаляете эти ключи, да тут нужно в каждом сервисе лазить удалять, но запас времени есть т.к. ключи всё-равно под пином. В отличии от утекшего пароля, который прям везде один это не отличается по смене паролей ничем кроме того, что утекший пароль не защищён ещё дополнительным пином и его можно использовать сразу везде (всё же для каждого сайта будет новый FIDO ключ).
Ну и Passkeys не подвержены фишингу.
Аппаратный токен с паролем 123456 и юзерами, которые не вынимают их из компа и передают другим. Г - Безопасность. Шлак эти токены любого вида в эниерпрайзе. Примерно как бут пароль 123456.
Первый фактор - аппаратный токен.
Токен можно потерять или он может сломаться. Пароль можно записать и спрятать в потайном месте (можно разделить на части и хранить в разных местах). Токен придётся часто оставлять без присмотра, например, во сне, или банально можно забыть где-то. Пароль остаётся при мне даже когда сплю. Токен показывает, что у меня есть некий важный аккаунт, а если пароль в голове, то само наличие аккаунта потенциальным недоброжелателям может быть неизвестно.
Аппаратные токены конечно имеют право на существование как один из вариантов аутентификации, но вот не понимаю желания убрать пароли в принципе. Конечно, пароли часто ставят примитивные, но это уже вопрос организационных мер (пароли можно проверять, запрещая слова из словаря, даты, последовательность идущих подряд символов на клавиатуре и т.п.). Какое-то непонятное желание сделать сложную систему, даже пожертвовав интересами пользователя.
Токен можно потерять или он может сломаться
Используй два (к слову, базовая рекомендация, которая вышла вместе со стандартом FIDO). Один как резервный в секретном-секретном месте. Или используй passkey. В случае недоверия системам синхронизации и от apple/google/Microsoft - можешь даже себе развернуть сервер bitwarden
Токен придётся часто оставлять без присмотра, например, во сне, или банально можно забыть где-то
Включи опциональную фичу, с требованием ввода пинкода для FIDO2-токена. Помни только пинкод.
А вообще, с тем же успехом
спрятать в потайном месте
Это потайное место с паролем будет найдено злоумышленником
Токен показывает, что у меня есть некий важный аккаунт
Не показывает ничего. Опять же, с тем же успехом злоумышленник будет бить тебя «резиновой уточкой», пока не убедит себя, что ты наконец перестал врать. Или же продолжит это делать просто так.
но вот не понимаю желания убрать пароли в принципе
Пароли не безопасны, приватный ключ в токене - токен не покидает (не касается passkey, тут синхронизацию apple/google/Microsoft прикрутили. Как - не интересовался)
пароли можно проверять, запрещая слова из словаря, даты, последовательность идущих подряд символов на клавиатуре и т.п.
А потом утекает база данных с паролями с сервера на сайте с выпечкой. А у пользователя один суперсложный пароль для всего
Какое-то непонятное желание сделать сложную систему
Но она сделана, она работает и превосходно перекрывает самые явные проблемы паролей. А главное, она не требует от пользователя никаких сложных действий. Единственное требование к пользователю - аппаратный токен, а им может быть твой смартфон. Увы, ресурсы в сети не очень активно разворачивают поддержку
Используй два
Чтобы узнать когда основной протеряют что второй немножко не актуальный
А потом утекает база данных с паролями с сервера на сайте с выпечкой. А у пользователя один суперсложный пароль для всего
Пользователь САМ очень хотел чтобы угнали сразу всё.
Потому что требованиями - ему имеют мозг, не очевидными с его точки зрения. Пример, есть система:
доступ к сети - через токен (спецВПН клиент), к нему нужен пароль для входа.
к ресурсам внутри этой сети - нужно 4 (обычно нужны 2) разных аккаунта (изне сети - никак). К ним своим пароли. При этом чтобы реально можно было работать - один из этих паролей надо прописывать в текстовый конфиг (это официальная рекомендация, видимо потому что гит еще запрашивать умеет пароль а вот система сборки - нет).
В некоторых случаях эти пароли надо вводит в консоли системы удаленного доступа (копипаст - не пройдет), ах да - там еще и автоблокировка если не используются.
Пароли выше - надо менять каждые 3 месяца. Прошлые нельзя.
На практике имеем и пароли в текстовых файликах на рабочем столе (притом что люди вполне понимают что дыра потенциально - но удобнее) и пароли вида (по струкуре):Habr$N1 (после обязательной замены - на Habr$N2 и так далее).
Ах да, откуда можно входить по VPN - тоже есть ограничения (при этом на хабре(!) один человек писал как он эту систему ограничений по IP обходил когда работал, не называя прямо компанию конечно же но называя достаточно деталей)
Мозги у людей - не бесконечной емкости (тем более что и так есть чем их загрузить), нужна безопасность - учитывайте почему люди правила нарушают (вовсе не всегда потому что ну тупые, иногда - просто работать надо)
Аппаратные токены конечно имеют право на существование как один из вариантов аутентификации, но вот не понимаю желания убрать пароли в принципе.
Потому что 'ключи от квартиры где деньги лежат' - очень хорошо интегрированный в мозги человека принцип. Возможно, даже на уровне биологической 'прошивки'. Человек хорошо общается с чем-то мелким и ценным. И к ключам (тем самым, от двери или сейфа) все давным-давно привыкли и знают, что с ними делать (в том числе, не оставлять там, где их злодей может прикарманить), иметь копию и так далее.
Конечно, пароли часто ставят примитивные, но это уже вопрос организационных мер (пароли можно проверять, запрещая слова из словаря, даты, последовательность идущих подряд символов на клавиатуре и т.п.).
А с аппаратным ключом - сравнимая надежность получается без всяких организационных мер, автоматически.
Какое-то непонятное желание сделать сложную систему, даже пожертвовав интересами пользователя.
С точки зрения использования - совершенно не сложная. Берем ключ, 'вставляем в скважину' - и готово, имем доступ куда хотели. Или альтернативно, 'берем пропуск, предъявляем и готово'. Эта система с паролями - сложная. Шпионский сценарий напоминает, если подумать.
Если у вас пароль в голове, то либо он простой, либо один на все аккаунты, либо все вместе.
Если у вас пароль в голове, то либо он простой, либо один на все аккаунты, либо все вместе.
Ну и что? Логины-то разные!
Либо в голове не пароль, а алгоритм его генерации.
в голове не пароль, а алгоритм его генерации.
Слава тебе, Саган, нашёлся таки ещё один разумный человек в этом всемирном балагане!
Либо в голове не пароль, а алгоритм его генерации.
PBKDF2 и его смысловые эквиваленты очень плохо в голове вычисляются. А все что проще - видимо, несколько недостаточно. Иначе бы этот самый PBKDF2 не нужно было придумывать.
Видимо имеется ввиду не алгоритм хеширования, а то как он был "придуман". Как пример берем домен+логин и разбавляем какими нибудь еще данными
Как пример берем домен+логин и разбавляем какими нибудь еще данными
...потом применяется какой-то хитрый самопальный алгоритм и получаем то, что используется в качестве пароля.
А PBKDF2 упомянут как нормальный вариант этого самопального алгоритма, который к тем же домен+логин+какие-то еще данные применяется.
Ну скажите тогда, какой у вас алгоритм генерации для условного habr и никнейма bonArt0, что-то мне подсказывает, что он такой же ненадёжный
Свой не скажу, но как пример - чередовать символы домена с логином и добавить какую нибудь соль типа даты рождения.
для условного habr и никнейма bonArt0
Например - hbaobnrArt012345
Использовал я приблизительно такой подход, хоть и упрощенный - префикс одинаковый, потом спецсимвол, потом часть из домена. И все было хорошо, пока не появился сайт, который пароль составленый по этому правилу не принимал. Потом на одном из сайтов была утечка и надо было придумать новое правило. А менять на всех сайтах, естественно, лень. И быстро стало такое месиво из разных правил, что уже и не запомнить, где какое.
Перешел на LastPass и генерирую случайные пароли, но хранение в чужом облаке + ограничения бесплатной версии напрягают. Надо искать варианты получше.
Потом на одном из сайтов была утечка и надо было придумать новое правило.
Все так, но есть ньюанс - алгоритм неуловимого джо никому не нужен. Если атака конкретно на вас, то да.
Но обычно параноики просто слишком многого о себе мнения )
И все было хорошо, пока не появился сайт, который пароль составленый по этому правилу не принимал
Именно поэтому я и топлю за снятие любых ограничений на пароли.
Есть такое: Cryptopass Оперсорсный и есть реализации для Линукса и Андроида. Утилита CLI для создания длинных(до 32 знаков), не поддающихся разгадыванию паролей. На основе тысяч итераций вычисления PKDBF2-SHA256 от домена с логином.
что-то мне подсказывает, что он такой же ненадёжный
Подозреваю, что в надежности данного способа сомневаться не приходится.
Или такое. Там "The generation of passwords is based on the combination of the key deviation function PBKDF2 and the hash algorithm BCrypt."
Вот только - если все равно приложением пользоваться, то обычный парольный менеджер ничуть не хуже. Точно так же есть некая база с параметрами, если мастер-пароль. И телодвижения при входе на сайт совершенно идентичны.
если все равно приложением пользоваться, то обычный парольный менеджер ничуть не хуже.
Только если в нем не хранятся пароли, вида 12345 ;)
То что Вы и я выше привели, это все таки не парольный менеджер, а менеджер правил создания паролей. Соответственно и функции у них абсолютно разные, только с первого взгляда похожие. Поэтому я храню "первичные" пароли от Cryptopass в менеджере паролей и меня такая "тавтология" абсолютно не напрягает. Если Вы пролюбите мастер пароль к менеджеру паролей или сам менеджер, то куку всем вашим паролям. А тут можно хранить "первичные" пароли менее тщательно, да хоть бы и один простой, легко запоминающийся вида 12345 на все пары юзер-домен. Все равно конечный результат вычисления у каждой пары будет разный, но детерминированный. Типа как seed фраза и адреса в криптокошельке. Лишь бы хранить их подальше от базы юзер-домен.
Перешел на LastPass и генерирую случайные пароли, но хранение в чужом
облаке + ограничения бесплатной версии напрягают. Надо искать варианты
получше.
В связи с тем, что моя карма разрушена и не могу отвечать чаще, чем раз в час, то отвечу тут.
Как корабль назвали, так он и поплывет: LastPass - "последний пароль" типа куку, уплыли из Ваших рук Ваши пароли. Этот несчастный LastPass сколько раз взламывали. И вообще как может прийти идея хранить пароли у чужого дяди в облаке?
Идеальный вариант, это KeepassXC закрытый мастер-паролем и файлом-ключом(ни в коем случае не железным ключом). Железный донгл, Юбик можно потерять, пролюбить, поломать. Тогда кабзда вашим паролям. Бесплатный, открытый и без ограничений. Вот его базу паролей уже можно смело класть куда угодно в сеть и синхронизировать с Вашими девайсами.
Потенциальная проблема с аппаратными токенами - как их использовать если токен рассчитан под круглую дырку а на устройстве - квадратная? А если на устройстве вообще дырок нет и ВСЕ взаимодействие включая зарядку - беспроводное? А если дырки вообще нет, потому что устройство - виртуалка и в лучшем случае там есть соответствующий хоть каким то стандартам виртуальный TPM. А с бекапом как? А с синхронизацией?
А если есть личности которым ну очень надо если криптография - то по своим, сертифицированными ими способам? И еще среду проверить.
А если на устройстве вообще дырок нет и ВСЕ взаимодействие включая зарядку - беспроводное?
NFC?
А если дырки вообще нет, потому что устройство - виртуалка и в лучшем случае там есть соответствующий хоть каким то стандартам виртуальный TPM
Тут уже сложнее, но usb-порт в виртуалку пробросить можно. И даже не порт, а конкретное usb-устройство
А с бекапом как?
Два токена
А с синхронизацией?
Извините, а с чем вы собрались синхронизировать свой хардварный токен? Но passkey - можно в рамках платформы, но если устройство-токен и устройство на котором осуществляется вход - различные устройства, как я понимаю понадобится Bluetooth
то по своим, сертифицированными ими способам?
Пусть строят свои методы какие только захотят и навязывают их внутри подконтрольных контуров. И не суют нос в мир за их пределами
А если на устройстве вообще дырок нет и ВСЕ взаимодействие включая зарядку - беспроводное?
NFC?
Да, и есть такие такие YubiKey'и и андроид например так умеет. Но из того что у меня например - не умеет ни одна машинка с десктопной ОС кроме гибридного ноута от Huawei. Я не считаю свои протребности уникальыми - значит нужно отдельно решение.
Извините, а с чем вы собрались синхронизировать свой хардварный токен?
Я могу зайти на условный github с кучи разных железок, разных. Сейчас проблема решается Bitwarden'ом (да - у Apple/Google экосистемам можно синхронизацию и можно Bitwarden тоже так умеет). Мне что - на каждый сайт прописывать каждый свой токен и помнить где что и какие у токены коннекторы?
Тут уже сложнее, но usb-порт в виртуалку пробросить можно. И даже не порт, а конкретное usb-устройство
Есть куча нестандартных немного ситуаций. Вот есть у меня Windows VM, в ней сайт, подключение по RDP, прописано 2 токена с USB-A/C. Внезапно надо подключится по RDP, с андроида(с DeX), куда будем втыкать? (штатный порт телефон-занят кабелем для DeX). Ах да, подключение не MS RDP клиентом (он кстати вообще в проброс умеет?) а aRDP Pro (он точно не умеет).
И вот такие проблемы - бесят.
Мне что - на каждый сайт прописывать каждый свой токен
Есть обоснованная причина использовать одновременно кучу разных токенов?
Bitwarden'ом
Как вариант в виде софт-токена он мне тоже нравится, FIDO2 он умеет. Это намного лучше чем даже самый сложный пароль
Есть куча нестандартных немного ситуаций
Стоп, мы вырабатываем решение под «стандартный случай», охватывающий потребности подавляющего большинства людей, или пытаемся охватить любые фантазии произвольного числа людей?
Потенциальная проблема с аппаратными токенами - как их использовать если токен рассчитан под круглую дырку а на устройстве - квадратная?
Стандартизировать токены а потом - дырки. Или наоборот. И настойчиво внедрять, чтобы все начали это все поддерживать.
<rant mode>
Вот не судьба было Микрософту еще -дцать лет назад потребовать, что если клавиатура хочет иметь иконку "Windows compatible" - то она должна иметь ридер смарт-карт? А сейчас - уже и NFC ридер неплохо бы требовать.
Наверняка бы уже от паролей избавились, а пользовались для авторизации карточками.
Забавнее всего если пожмотился и купил только один аппаратный токен а потом его потерял без создания копии.
ну так токен же не обязательно должен быть единственным ключом/фактором, в качестве бэкапа могут быть коды, аутентификатор, почта, смс...
наличие токена дает возможность более менее надежно логиниться в стремных условиях, когда очень надо, а уверенности что передаваемый код не будет перехвачен - нет...
Учитывая что в большинстве случаев эти коды шифруются на стороне клиента перед отправкой, и есть много возможностей ввести этот код его не высвечивая на экране - я считаю что такие ключи это больше энтерпрайз решение чем решение обычного человека. Не значит что обычный человек не может ими пользоваться, просто для обычного это вряд ли имеет смысл с точки зрения удобства, тем более если будут запасные факторы которые как раз снижают безопасность аккаунта давая больше точек входа.
Чем отличается пароль в БД, от пароля как второй фактор в БД?
Наверное тем, что это разные хранилища? И совсем необязательно хранить все необходимые данные в одном месте.... да ещё в открытом виде...
Чем отличается пароль в БД, от пароля как второй фактор в БД?
С точки зрения угона базы паролей у сервиса - не очень отличаются. Можно украсть как байты, которые про пароль так и байты, которые про второй фактор(кроме того, seed для стандартного TOTP не очень захэшируешь).
Но в начальном сообщении были passkey с друзьями, которые открытый/закрытый ключ и потому подбор байтов для входа, даже если знаешь байты из базы сервиса, сильно затруднен.
А вот с точки зрения атаки на сторону клиента - отличаются тем, что злодею надо как-то два секрета узнавать вместо одного, которые хранятся отдельно и один из них, с большой вероятностью - оффлайново, не на стороне сервиса и/или в специальном чипе, который спроектирован так, чтобы этот секрет оттуда достать было трудно.
Пароли должны умереть как класс
Ограничение на длину пароля должно умереть как класс. Если я качестве пароля хочу ввести строфу из Библи, третью заповедь Макаронного Монстра или 125-е изречение Мао Цзе Дуна, никто не должен мне запрещать.
Чтобы вы могли положить сервер пока он вычисляет хеши от гигабайтных паролей ? )
К тому же размер тела запроса обычно ограничен в nginx (опять же, чтобы не дудосили по чем зря).
А разве я что-то имел против ограничения на размер запроса?
А гигабайтный пароль на сервер вы с помощью телепатии будете передавать ?
Хеширование на стороне клиента только на первый взгляд выглядит замечательно, на практике же разнообразный геморрой - например поддержка браузерами и проблематичность сменить алгоритм/параметры хеширования в будущем.
А гигабайтный пароль на сервер вы с помощью телепатии будете передавать ?
Вооооот, до Вас, кажется, стало постепенно доходить, что в данном случае послужит естественным ограничителем.
Не очень понял что до меня должно дойти. То вы говорите, что нужны пароли без каких либо ограничений на длину, то ограничение в размер запроса "сойдет"
А что на сайте в этом случае показывать ? 413 Entity too long ? И пусть пользователь сам догадывается что пошло не так.
Это я к тому что разработчики могут даже не знать какое там ограничение на размер запроса стоит.
А "естественным" ограничителем может так же выступать используемая библиотека. Например в symfony/password-hasher максимальная длина 4096 (на данный момент) https://github.com/symfony/symfony/blob/3ce369d552f31db9c776a3cc9484f7d86259766e/src/Symfony/Component/PasswordHasher/PasswordHasherInterface.php#L25
Если пароль длиннее она его даже хешировать не будет, а кинет эксепшен.
C Passkey умудрились хорошую идею...сделать не очень хорошей
https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/
Да и в реализациях как менеджеров passkey (смотрим например как к Keepass'у требования предьявляли как правильно реализовывать и что реализовывать нельзя и что будет если они сделают как считают правильным) так и библиотек для сайтов/приложений (в результате чего имеем и запрос при входе на passkey от ресурсов если точно известно пользователю и он локально залогинен на passkey для этого ресурса и прикол (например у nextcloud так) что passkey может быть как заменой логина и тогда нужен второй фактор если он включен и вторым фактором если включен логин и пароль но не вместе, при этом этом - совсем не очевидно))
Возможно получится кое как доработать - e-mail ж допилили до более менее юзабельно вида кучей правок в стандарты, нормально безопасные и при этом юзабельные IM-клиенты тоже допилили - есть Matrix (притом что был Jabber который и ресурсов меньше жрет и быстрее во многом и умеет вообщем то тоже самое но...не сложилось, по куче разных причин(в том числе - зоопарк XEP'ов - пусть даже вроде бы ЭТУ проблему - исправили)
,Проверить наличие своих данных в утечке можно через сервис Leaked Password Checker.
Проверьтесь, и добавьте в базу ещё один пароль
Oh no! Your password has been leaked
Блин..
Это он на любой пароль выдаёт такой ответ?)
Нет, на другой пишет You are safe for now
зы. Но я тоже думал, что на любой введенный, мол, после ввода уже leaked )))
При открытии коробки пароль всегда мертв
"Здравствуйте! Такой пароль уже использует пользователь Вася. Пожалуйста, введите другой пароль."
... Это я к тому, что просто одинокий пароль бессмысленно проверять. Ну есть он в базе - и? А если это заведомо не от вашего аккаунта? Или вы хотите гарантированно иметь пароль, который будет заведомо уникальным среди всех пользователей всех сервисов мира?)
А какой шанс, что сгенерированный пароль хотя бы в 8 символов не будет уникальным среди пары десятков миллиардов раз?
Сайт реально подозрительный. Посылает на сервер пароль в открытом виде, даже хеширования на стороне браузера нет или возможности ввести сразу хеш
Про Инь Фо Ву уже шутили?
Через некоторое время Сисадмин воскликнул:
– Учитель, я подобрал хороший пароль, которого не может быть в словарях.
Инь Фу Во кивнул.
– Я ввёл его в Гугле, – продолжал Сисадмин, – и убедился, что в Сети такого сочетания нет.
– Теперь есть.
сервис Leaked Password Checker.
Ввёл старый пароль, утёкший несколько лет назад.
Пишет, что I am safe for now
Назойливая забота о безопасности привела к утрате 9-ти миллиардов паролей, айтишнички отлично поработали, сотням тысяч человек ограничен доступ к информации и общению, миллионы людей вынуждены приобретать недоделанные продукты.
Есть ли у кого ссылка на файл? Хакерские форумы не известны, да и в теме форума скрыта ссылка на скачивание.
Статья без ссылки на торрент с паролями, мельчает Хабр :)
magnet:?xt=urn:btih:4e3915a8ecf6bc174687533d93975b1ff0bde38a
Спасибо, интересно
Спасибо! Я в статье это ожидал. И уж точно не ожидал такую дичь, как ссылку на онлайн сервис "проверки пароля". Скачать текстовик и проверить свои "стандартные" пароли для всяких неважных сайтиков - это единственный способ правильной проверки. И спасибо добрым хакерам, которые всё это скомпилировали в одном месте. Утечка ведь не нова, это просто актуальный сборник. Тот кто его сделал заслуживает на плюсик в карму (реальную), т.к. невозможно больше скомпроментировать то, что уже и так скомпроментировано, а вот честным людям материал для проверки прямо на блюдечке поднесли.
А это точно оно, а не зип-бомба? А то файл-то, конечно, образовался, но что-то подозрительно, что он начинается на [почти] сплошные нули, прямо страшно до конца распаковывать.
Гитхаб Obsidian-Pentest/Hacking-all/Password.md
в торрентах пока не видел.
есть https://s3.timeweb.cloud/fd51ce25-6f95e3f8-263a-4b13-92af-12bc265adb44/rockyou2024.zip
качается/рвется, так что сам пока не взял, так что то это или нет - не могу проверить.
zip на 45GB. если оптимистично, то мне ещё час-два ждать.
Какой размер несжатого файла?
пока могу только по заголовку zip судить - там вроде 155978020956 байт, т.е. ~ 145.266GB
да, именно столько вышло.
сам файл в части простых паролей от rockyou2021 не особо отличается.
как и в том, заметная часть паролей в файле дважды - при слиянии не учли что часть файлов имела переводы строк cr/lf, а не lf, так что остались дубли с cr на конце.
добавилось много длинных паролей, а в начале откуда то куча нулей (примерно 8388663), а затем несколько десятков строк с паролями, начинающимися с \0, что вряд ли реально.
так что не очень аккуратно его сделали...
пытаюсь пережать в 7z, но судя по всему архив заметно меньше не станет
Хороший разбор. Похоже на очередную работу скрипт-кидди тогда... и ничего удивительного в этом нет.
Расходимя, посоны.
Файл выглядит примерно так:
!234LJGD@WSX
!234LJGD@wsx
!234LJGDADGJ
!234LJGDASDF
!234LJGDAdgj
!234LJGDAsdf
!234LJGDBGT%
!234LJGDBNM<
!234LJGDBVCX
!234LJGDBgt5
!234LJGDBnm,
!234LJGDBvcx
!234LJGDCBM>
!234LJGDCDE#
!234LJGDCVBN
!234LJGDCbm.
!234LJGDCde3
!234LJGDCvbn
!234LJGDDFGH
!234LJGDDGJL
!234LJGDDfgh
!234LJGDDgjl
!234LJGDERTYТо есть, как я и предполагал изначально (только комментарий не запостил), это просто перебор всех возможных комбинаций символов.
- Учитель, я подобрал хороший пароль, которого не может быть в словарях.
Инь Фу Во кивнул:
- Молодец.
- Я ввёл его в Гугле, - продолжал Сисадмин, - и убедился, что в Сети такого сочетания нет.
- Теперь есть.
пфф!! Я как-то натыкался за базу пин кодов от банковских карт. 10000 строк! Там были пин коды от всех моих карт. Даже от тех, которыми уже давно не пользовался.
Там даже были пинкоды от карт которые будут в будущем. Явно гдето существует машина времени!!!!
Просто когда задаете пин-код карте сверяйтесь с этой базой. Тогда ваш пин-код никто не подберет!
Вот у вас сарказм, а зайдет кто-нибудь из "литературы" и пиндыр, мой пин-код знают! ААААА)))
Уважаемые Гуманитарии, ваши пин-коды невозможно взломать!
Есть карты с шестизначным пином =).
Не нашëл там своего.Пришлось лезть в базу на 1000000 строк. Долго сверял.
Кто-то угонит мой аккаунт на Хабр(
Почему она не опубликована открыто? Любой жулик, уверен, её найдет, а я свои пароли проверить не могу (ну не посылать же их на сомнительный сайт).
Откроют почту и поймут что потратили жизнь зря..
Откуда берутся все эти базы с паролями? Это высокооплачиваемые айтишнки из до сих пор хранят пароли в открытом виде? Односторонние алгоритмы шифрования строки или приёмы шифрования пароль+индивидуальная_соль - уже сто лет известны.
Вы будете смеяться, но банки хранят ваши пароли в открытом виде. Они считают, что если уж кто-либо взломал банковскую систему и добрался до базы паролей, то весь банк уже скомпрометирован, и хакеру доступно гораздо больше, чем хеши паролей клиентов.
Скриншот же в статье показывает сообщение: некоторые пароли "впервые" честно сбрутфорсенные на RTX 4090 автора публикации. Даже если пароли хэшируются, там могут быть и md5/sha1, а может и не быть соли.
Проверить наличие своих данных в утечке можно через сервис Leaked Password Checker.
:рукалицо:
База данных-то где? )
База данных-то где? )
В вас/нас/в них - вы/мы/они её и наполним/s
ну на скриншоте же видно что ввести в поиск чтоб найти. Это прям топ1 в гугле будет)
но ладно есть такой случайный набор цифр, может поможет вам в поиске) urn:btih:4e3915a8ecf6bc174687533d93975b1ff0bde38a
UPD там так же появился такой комментарий:
Я cмог загрузить его, используя одну из предоставленных ссылок. Общий размер сжатого файла составил около 45 Гб. После извлечения это был несжатый файл .txt размером 150 Гб. Я удалил все строки с недопустимыми символами, длиной менее 6 символов и длиной более 22 символов, а также дублирующиеся строки. Пакет содержал огромное количество хэш-значений bcrypt и множество дубликатов. В итоге получился несжатый файл .txt размером 11,5 Гб, содержащий 955 742 504 уникальные записи длиной от 6 до 22 символов.
Таки я там смогу найти свои забытые пароли к кошелькам?
Интересно, откуда взялось ограничение в 22 символа...
получился несжатый файл .txt размером 11,5 Гб, содержащий 955 742 504 уникальные записи длиной от 6 до 22 сисимволовк
Который он куда-то выложил? Чтобы остальным не делать ту же работу.
Он нигде его не выложил?
Я удалил все строки с недопустимыми символами, длиной менее 6 символов и длиной более 22 символов
Ну, менее 6 ещё понятно, но более 22-то зачем было резать?
Спасибо за магнитик на исходник;)
...только 10 млрд.?
https://github.com/exploit-development/RockYou2024
RockYou2024: The Largest Password Compilation Leakmagnet:?xt=urn:btih:4e3915a8ecf6bc174687533d93975b1ff0bde38a
Грамотно окучивают. Все эти пароли не что иное чем обыкновенный микс с различных утечек. Множество дублей и много невалидных данных которые полученные видимо из заз несовпадения полей парсинга из за какого нибудь кастома БД.
Но главная ставка на количество. И вот уже понеслись новости, подхватили каналы и.т.д.
Куча народа побежало качать. И вроде бы вопрос - а почему бесплатно уже должен тригерить, но нет.
В наборах куча скриптов самых различных вариаций. Что то маскирутеся как парсер или интерсекторы на самом деле скрипты доступа. Запустили консоль с grep/findstr и вот исполняемый скрипт в оперативной памяти. На 2021 анализатор нашел удаленный рабочий стол, настройка задачь по таймеру и что то еще не помню.
Причем все октрыто. Но расскидано по кусочкам с рассчетом на то что пользователи будут грепать или интерсектерить данные
Браво.
как много сейчас сервисов, которым наплевать сколько раз пользователь ввёл не тот пароль? иначе я не понимаю смысла таких баз, если только не подбирать по ключевым словам (типа юзера зовут Иван Иванов, следовательно, ищем только похожие на ivanivanov и т.д.), в противном случае система просто заблокирует вам доступ к авторизации.
Безопасно ли проверять свой пароль через указанный сервис?
Нет, это непонятно кто вообще. haveibeenpwned можно доверять.
Посоветуйте опенсорсный браузерный вычислитель хэшей, который можно скачать html-файлом и пользоваться офлайн. Заранее спасибо.
https://gchq.github.io/CyberChef слева сверху кнопка скачать
Хакеры опубликовали базу с 9,9 миллиардами утёкших паролей