Комментарии 23
"В 1961 ... В то время пароли хранились в открытом виде на листочке. "
2024 год - пароли хранятся в открытом виде на листочке.
Чем сложнее пароль, тем выше вероятность оказаться на листочке.
> Чем сложнее пароль, тем выше вероятность оказаться на листочке.
Нет. Просто требуется агитация и стимулирование... анальное.
На заре трудовой карьеры, довелось мне работать в компании с гостайной. И тетеньки предпенсионного возраста САМИ себе создавали пароли по 16 символов, с большими и мелкими буквами, спецсимволами, цифрами. И не слова, как генерилка для випнета, а конкретно так рэндомная смесь. И ничего не записывали (за это и увольнение, и возможно, статья). Я поинтересовался у начальника, как такого добились? Несколько лет назад группа хакеров тиснула крупную сумму денег. По нынешним временам - как сотни миллионов. Хакеры набрутфорсили пароль одной дурочки, которая использовала 8 символов и какие то словарные сочетания. Большую часть хакеров и меньшую часть суммы нашли. На суде даже хакеры признались, что тетенька не с ними, ни копейки не получила, никто ее не знает, просто смогли подобрать пароль именно к ее учетке. Тетенька присела на 5-7 лет. Потому что в журнале ознакомления с парольной безопасностью стоит ее роспись. Он изучала требования, прошла тестирование, подписалась что будет исполнять требования... но не выполнила своего обещания. Вследствие халатности, государство понесло крупный урон. Получите, не обляпайтесь!
Дурочку вывели из кабинета в наручниках прямо с работы. Все коллеги видели и прекрасно знали продолжение истории. Одна пострадала, но зато сотни других сотрудников стали использовать пароли сложнее, чем требовалось в регламентах по ИБ.
Могли упомянуть magic link. Но давайте объективно, логины и пароли до сих пор нормально использовать. Заходить каждый раз в почту менее удобно, чем вставлять креды из парольного менеджера. Да и magic link менее безопасный способ. Потому что при компрометации почты аккаунт 100% смогут захватить. Если говорить про вход только с помощью OTP, то потеря девайса = потере доступа к аккаунту. А включать восстановление по почте будет очередным костылём
Совершенно непонятно почему девайс не может куда-то ключ бэкапировать. На sd карту к примеру. Что тут такого сложного в реализации? Ну т.е. если пользователь как-то и карту потерял, то пусть сходит уже в банк ножками, а не банк как-то тоже может ему помочь. В ручном режиме и за отдельные деньги.
Про Magic link есть в статье.
Если говорить про вход только с помощью OTP, то потеря девайса = потере доступа к аккаунту
Не всегда. Даже скорее наоборот, если мы говорим про TOTP. Многие вендорные приложения-аутентификаторы (Google, Microsoft) умеют бекапить в облако, а Authy и Ente Auth апрори облачные, последний ещё и бекапиться умеет в открытые форматы. Пользуюсь именно последним. Так что потеря устройства не сильно большая проблема нынче.
А включать восстановление по почте будет очередным костылём
Тоже так считаю. Поэтому считаю лучшей компромиссной реализацией следующую:
Вход по логину и паролю с запоминанием устройства (чтобы не выходило требование про второй фактор), они будут записаны в KeePass (его база в облаке, а файл-ключ только оффлайн в зашифрованном диске, копия на флешке судного дня);
TOTP записан в Ente Auth;
Восстановление только по резервным кодам, которые записаны в сервисе хранения секретов. Я, правда, не придумал ничего лучше, как поднять Ansible Vault на VPS'ке для шифровки одного-единственного файла. Так и смотрю коды по SSH, благо требуется это очень редко.
Есть способы много проще, есть много безопаснее, а этот мой пайплайн где‑то посередине.
Плюсы: кросс-платформа, яйца лежат в разных корзинах
Минусы: нет защиты от раскаленного паяльника в жопе. Да я уже и на этапе бутылки всё выдам под чистýю...
Далее в таблице можно посмотреть, какие браузеры поддерживают WebAuthn. Красный цвет — отсутствие поддержки, зеленый — полная совместимость, а горчичный — частичная поддержка.
Сколько ни смотрел - не увидел в таблице этих цветов
А еще где-то по дороге к дню сегодняшнему (и в статье) потерялись клиентские X.509 TLS/https сертификаты. Которое, в общем, тоже 'без паролей'. И которые с минимальной доработкой браузеров можно было бы заставить работать приблизительно по той же схеме, что в WebAuthn применяется.
Но про них по каким-то причинам решили забыть, оставив только где-то в недрах защищенного межсервисного взаимодействия.
Клиентские сертификаты это было бы очень здорово! Но — дорого (если нужна валидация стандартными CA), или хлопотно / небезопасно (если использовать самоподписную CA).
если нужна валидация стандартными CA
Не нужна. Т.к. пользы от этого конкретному сайту - довольно мало.
или хлопотно / небезопасно (если использовать самоподписную CA).
Как будто в WebAuthn сильно отличается. Точно так же публичная часть ключевой пары шлется на сервер и после этого он начинает верить, что обладатель приватной части - это владелец учетки. Только не подписывая, а просто запоминая:
If the validation process succeeded, the server would then store the
publicKeyBytesandcredentialIdin a database, associated with the user.
Точно так же можно было сделать и с X.509 сертификатами. Хочешь сделать учетку - браузер делает Certificate Request, сайт его подписывает, отдает сертификат браузеру, браузер складывает его в локальное хранилище и в следующий раз этот сертификат можно предъявить для захода в учетку.
Насколько я знаю, в WebAuthn не нужно прописывать свою CA в списки доверенных на каждом клиентском устройстве. А с самоподписанными клиентскими сертификатами — нужно. Что и хлопотно (если только это не организация казарменного типа, где используются только выданные в пользование устройства, с групповыми политиками и т.п., а всякая вольность типа личного планшета недопустима), и небезопасно (сторожевые системы современных ОС очень возбуждаются на самподподписные CA в списке доверенных; а если заткнуть им рот, то есть шанс пропустить чужую CA — и здравствуй, MiTM).
Ну так на доверенность CA, подписавшего клиентский сертификата на стороне клиента можно более-менее не обращать внимание. Пускай сервер разбирается, верит он предъявляемому или нет. Клиенту важно, чтобы серверный сертификат был тот (т.е вот все то, что сейчас в стандартном соединении https делается).
И вносить в глобальный системный список 'доверяем для всех подряд целей' все эти серверные само подписанные CA тоже совершенно не обязательно.
Нужно только браузер доработать (А для WebAuthn его еще как доработали), чтобы описанный сценарий срабатывал как надо и тупо показывать "Сертификат XYZ, пописан тем сайтом, на котором вы сейчас находитесь для учетки ABCD, предъявить для авторизации?"
Серьёзная проблема регистрации только по webauthn. Одно устройство - один аккаунт. На компьютере windows hello, на андроиде подтверждение от сканера отпечатка пальца, на айфоне face id. Представляете создавать и иметь новый аккаунт в телеграмме при переходе на другое устройство?
Всё ещё невозможно использовать биометрию для авторизации. Все сканеры отпечатков пальцев отдают не чистую биометрию, а токен результат сравнения заранее зарегистрированного пальца и отсканированного. У face id скорее всего тоже так. Только когда получится хранить в базе данных биометрию (конечно, в максимально безопасном формате) и сравнивать её с восходящей от пользователя, тогда это будет настоящая замена пароля и появится возможность входить на разных устройствах.
Да, можно использовать физические ключи, но этим не лень заниматься 5% пользователей.
"В 1961 году ... ПК тогда было мало" - дальше читать не стал. В 1961 г. ЭВМ были ламповые
"Прекол" пароля в том, что его можно поменять. Сетчатку, походку и сердцебиение поменять сложнее.
Избавляемся от паролей