Podlodka #388 – Авторизация и аутентификация - podcast episode cover

Podlodka #388 – Авторизация и аутентификация

Sep 03, 20242 hr 15 min
--:--
--:--
Listen in podcast apps:

Episode description

Сколько факторов аутентификации нужно использовать, чтобы учетные записи ваших пользователей были в безопасности? Зачем сбрасывать пароль каждые 30 дней? Есть ли методы аутентификации, которые, с одной стороны, достаточно безопасные, а с другой – удобные даже для вашей бабушки? Никита Хромушкин из Авито провел для нас максимально подробную лекцию про то, насколько проклято текущее состояние дел в аутентификации и какое светлое будущее нас ждет, когда человечество откажется от паролей! Партнёр эпизода – облачная платформа Yandex Cloud, которая проводит большую конференцию Yandex Scale для тех, кто создаёт цифровые решения. Генеративные нейросети, речевые технологии, сервисы для работы с данными и обеспечения безопасности, serverless‑подход – об этом и многом другом 25 сентября расскажут эксперты и партнёры облачной платформы. Участие бесплатное, приходите офлайн в МХАТ им. М. Горького или смотрите в онлайн-трансляции. Зарегистрироваться можно по ссылке: https://lnnk.in/aRpI Реклама. ООО "Яндекс.Облако", ИНН 7704458262, erid:2SDnjd7SVQN Также ждем вас, ваши лайки, репосты и комменты в мессенджерах и соцсетях!
 Telegram-чат: https://t.me/podlodka Telegram-канал: https://t.me/podlodkanews Страница в Facebook: www.facebook.com/podlodkacast/ Twitter-аккаунт: https://twitter.com/PodlodkaPodcast Ведущие в выпуске: Евгений Кателла, Егор Толстой Полезные ссылки: Неслучайный генератор случайных одноразовых кодов Тинькофф банка https://habr.com/ru/articles/462071/ OWASP Authentication Cheat Sheet (Про ошибки аутентификации и общие рекомендации) https://lnnk.in/htmx OWASP Multifactor Authentication Cheat Sheet (Факторы, плюсы, минусы, рекомендации, risk-based MFA) https://lnnk.in/hvmu NIST Digital Identity Guidelines / Authentication and Lifecycle Management (Про запрет использования секретных вопросов) https://lnnk.in/duq3 OWASP Password Storage Cheat Sheet (Про безопасное хранение паролей, bcrypt, work factor) https://lnnk.in/aNp7 OAuth 2.0 Authorization Code Grant Type - Fully Visualized (Article with Infographic) (Статья с инфографикой / sequence-диаграммой про OAuth) https://lnnk.in/aMqe OAuth Playground (Authorization Code with PKCE) (Интерактивная площадка для тестирования OAuth+PKCE) https://lnnk.in/aSpL OWASP Testing for OAuth Weaknesses (Руководство по тестированию уязвимостей OAuth) https://lnnk.in/aOp7 OWASP Authentication Testing (Руководство по тестированию аутентификации) https://lnnk.in/evl8 Open Policy Agent (Фреймворк политики безопасности) https://www.openpolicyagent.org/ Rego Sandbox for Open Policy Agent (Песочница для языка Rego) https://play.openpolicyagent.org/ FTC Data Breach Response Guide for Businesses (Гайд для бизнеса на случай утечки паролей) https://lnnk.in/aPpT Book: OAuth 2 in Action (Книга по OAuth2, возможна устаревшая с 2017) https://www.manning.com/books/oauth-2-in-action Book: Cryptography by Damir Sharifyanov (Книга по основам криптографии для новичков) https://lnnk.in/aQpU OWASP Testing Multi-Factor Authentication (Руководство по тестированию многофакторной аутентификации) https://lnnk.in/hxmj OWASP Testing for Bypassing Authorization Schema (Про тестирование обхода схем авторизации) https://lnnk.in/exl2 OWASP Testing for Cookies Attributes (Атрибуты Cookies: Secure, HTTP only, Path, Expires) https://lnnk.in/hzl9

Transcript

Всем привет! С вами подка с подлодка Егор Толстой, это я и Женя Кателла. Всем привет! Я уже мне кажется в несколько выпусков, рассказывал историю своего переезда из Нидерландов в Великобританию. Когда вместо того, чтобы просто легко, спокойно пересечь границу, я попал на 8-часовой допрос антитеррористического подразделения и мне ее величезо короля, после которого у меня изъяли всю технику на неделю, где вся техника – это

ноутбук, телефон, Apple Watch, Nintendo, блин, свич и остальное. И в итоге я оказался в новой стране и в новом городе хрен бы с ним что без техники. Я остался как оказалось без какой-либо возможности залогиница в привычные мне аккаунты в Google, в Amazon, я не знаю, короче вообще во всех абсолютно сервисах, потому что как оказалось, что если у тебя нет доступа ко второму фактору,

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

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

дело на бакенде и так далее. Сразу предупрежу, что это выпуск не про то, как выбирать безопасный пароль, хотя про это мы тоже, наверное, поговорим и не про то все-таки в каком пароль менеджере ваших пароль хранить, вот мы именно будем говорить про авторизация. И в гостях у нас Никита Хромушкин, Никита Изовита, технический руководитель, юнита АВИТ-АИД, в которой в том числе

входят и авторизация Никита Пред. Привет, привет. Да, я Никита Изовита. Душор к структуру чуть-чуть сложнее, к манда авторизации она вот рядом же, как получается, но в глуб лист тогда не будем прямо сейчас. Ну да, так получилось, что я пришел во ВИТ-а 2,5 уже почти три года назад, пришел тем рядом на проект Мультипрофеля. Мы делали возможным использовать несколько профилей

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

продукт менеджеры и многие другие. Однако всем им нужны надежные инструменты для разработки, о том, как создавайте фравы решения и как сделал разработку быстрее и безопаснее, расскажет эксперты олочный платформа Yandex Cloud на ежегодной конференции Yandex SK. Спикеры представят более трестидо-кладов, пить мальчиских треках, в которых подробно обсудят генеративные не рассейтии, сервисы для работы с данными и обеспечения безопасности инфраструктурной проекты,

и сервис архитектур. В каждом треке спикеры поделятся технологическими анонсами и практически мерекомендациями. Например, в докладах расскажут о новых и аинструментах для разработчиков «Ахаус-инжениринги», а также о том, как сервис позволяет реализовать подходы low-code

и low-obs на практике. Конференции пройдет 25 сентября, умхад и мени горького, также будет онлайн тратсляция, а обязательно приходите в афлайн, потому что за кулисами конференции будут нандрактивные инсталляции, посвященные продуктом, например на MLStendy можно будет сыграть тематически облачные D&D, ну и, конечно, жены творкинг. Участи бесплатное, достаточно зарегистрироваться на сайте, скейл.yandex.cloud. Приходите по ссылке в описании, чтобы детально

знакомиться с программой и зарегистрироваться. Ну а теперь к выпуску. Кстати, вот раз мы начали говорить про авторизацию Вавита. Вообще, кажется, с первого взгляда, что логика в авторизацию Вавита должна быть какой-то незнайлиментарный. Ну типа, водишь логин, водишь пароль, нажимаешь кнопочку «Окей, пароль, совпал с тем, что лежит в базе, супер чувак ты злогинен». Можешь вообще рассказать буквально в общих чертах, в чём ключевые сложности и почему всё там, на самом деле, кажется

чуть-чуть сложнее. Пароль не лежит в базе. Пожалуйста, не храните пароль, а мы к этому потом ещё предам давай расскажу про авторизацию Вавита. Смотрите, вот есть 100 миллионов пользователей, но грубо говоря, всё население интернета-грев. И среди них есть очень разные ребята, с очень разное потребностями, которые очень по разному входе. Там есть частники, которые пользуются соцсетями, которые пользуются пародом, пользуются вторым фактором, есть разные вариации бизнеса, которые

тоже по разному входят по итогу. В какой-то момент у нас был метод логин на тысячу строк, 40 ифов, и всё было очень сложно плохо. Сейчас всё хорошо, мы его от рефактали по деде, разнесли на юскейсы, всё стало классно, но это одна страна. Ещё одна страна, это нагрузка. По сути, все авторизованные запросы на авитопрохот через нашу сервису, их порядка 8 миллионов

запросов минуты сейчас. То есть, вот есть, условно, есть 10 миллионов пользователей, которые пользуются авита, и они генерировать 10 миллионов авторизованных запросов в минуту, ну вот прям сейчас, вот прям сидят, или там что-то делают, там нажал кнопочку посмотреть, но между телефона, между телефона можно посмотреть, если это авторизован, поэтому

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

есть под с микросервисом, у него лядашком есть под с экспороксидор Эдиса, и вот под с микросервисом с ним всё хорошо, сайт каркантынир, он начинает тротлется по сепил, то есть проблема прям совсем выше него порядка пошты, тут мы поняли, что в первых уже на схеме

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

просторой вселенной и всё так вот, мы точно понимаем, что с точки зрения dvx там есть что лучше, мы сосредоточно о том, чтобы оно стабили на их хорошо и быстро работало, и на том, чтобы оно было максимально безопасно, то есть наша задача это защитить пользователей от взломов,

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

пожалуйста, чем они отличаются. Угу, всё правильно, на самом деле 90% людей, когда говорит авторизация, имеет виду вход, и это термин аутентификация. И я сам в процессе, вот пока мы будем писать под каст, наверняка буду путаться, называйте аутентификацию авторизации, прошу за это простить меня, но и заодно даю индульгенцию всем, кто ошибается в терминологии, ничего страшного.

Давай попробуем эти терминопрояснить идентификация, идентификация это когда тебе говорят, ты кто, представься, ну или в виде ямаю, в виде на мышцелефона, если вы вот так говоришь, привет, я Егор, вот это идентификация, у тебя не спрашивают паспорт, тебя не спрашивают,

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

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

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

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

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

предварительной аутентификации? О, что если я скажу, что у аутс широко используем термон, базовая это про авторизацию и совершенно не обязательно про аутентификацию. Объясню, ты делаешь запрос в какой-нибудь соцсеть в Google со своего сервиса, то есть ты делаешь, ты разработчик сервиса, а ты делаешь запрос в Google за именем пользователя.

В этот момент пользователь авторизует тебя, получать доступ к его имени. Аутентификация здесь не происходила, но пользователь, когда-то было аутентифицируем в Google, то есть всегда есть какая-то предварительная аутентификация, давай, скажем, еще есть, в стабле с клиентскими сертификатами и МТЛС, авторизации между микроссировой с вами. С сертификат же в какой-то момент выписывается. То есть тоже, как бы авторизация происходит без аутентификации, но в момент

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

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

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

там система авторизации по токенам, похважает это на правду, или это я уже вы думал. Как будто бы да, но момент в описании о токена, но спорная штука. То есть, в целом, если это этот токен выписываешь просто кому-то потом выкидываешь в интернет, но наверное, да, но наверное, то так не будешь делать.

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

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

Ничего, мы, короче, дождемся, комментаторов на YouTube, которые в этот момент нас уже закопали, скорее всего, и уже объяснили в очень длинном комментарии, почему почему всё на самом деле

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

Вот есть, значит, человек водит пароль, потом человек водит кот в SMS, потом человек водит кот в почте. Сколько факторов? Три. Я умею считать, я молодец. Хорошо, если задать вопрос, сила какого фактора? В правде. В безопасность какого фактора. Подожди, сила в правде, а безопасность нет у нас. Жень, черт, сколько сломалась? Нет, это наша акназад. Простите. В общем, кот в SMS, кот в почте, это два варианта второго фактора. И есть такая теория, согласно УАЗ-орг, что безопасность не суммируется.

То есть это как с вычислительной сложности. Оатен, пылесо, оатен, ровно, оатен. Ты не будешь считать двойку. Поэтому, у вас грубо говоря, человек, который захочет взломать, как он защищенный кодом SMS, он в том числе готов достать кот из почта. И, ну, условно, что это примерно одинаково стоит. Давай поговорим чуть-чуть про факторы. Подожди, секунду. А можно вот это мысли, точнее, я не до конца понял. Сейчас, извини, ну, чисто на практике.

Если у меня один кот приходит на телефон, а другой кот приходит на почту, которая находится физически на другом девайсе, то усилие из лумышняку надо приложить кратно больше, чтобы достать их. Ну, в два раза. Ну, некратно, да. Ну, наверное, ну, все ладно, понял. Сейчас, я не совсем понял, я сейчас попробую... Ну, короче, я допустим, использовал пароль, пасфорт 1 на 9.1. Меня ломанули, почту мы взломали, такие сейчас мы к тебе зайдем, короче, куда-нибудь.

И тут у меня авторизация по SMS-ке еще включено. А телефон они у меня не украли, если мы с Кому не перехватили, получается, что все стало сложнее. Для них сильно, кратно, радикально. Течка моя пароля, я никак не поможет сломать. Да, но они в 10 раз. Не в 10. Сумас типа, не на порядок, что? В этом плане. Не на порядок. Ааааа... На порядок, это если тебе нужно приложить лицо, чтобы войти в твой профиль. Ну да, неплохо. Но если это пойдет в приведушку этого опуска... Хорошо.

Так, короче, давай, видимо, пойдем дальше. Я пока не понимаю, где разница между лицом и кодом. Все погнали. Хорошо, давай по порядку. Давай по факторам на аутентификации. Записываем выпуск про авторизацию, мы говорим, будем больше часть времени про аутентификацию. Ты не на дело, что надо еще проще. Итак, факторы. Вот они, слева на право. Первый фактор, это что-то, что ты знаешь. Это какой-то секрет. Например, пароль или пинкот. Вот, еще раньше были такие. Извини, пожалуйста, или ориентир.

Да. Сверчков, кто-нибудь подставит, одеюсь, в этот момент. Очень хорошо. Раньше еще были секретные вопросы. Давай до сих пор, где это может встретить. Но с 2023 года, голоса регулятора США запретил секретные вопросы. Сказал, что они не безопасны, и их нельзя использовать. В принципе, на сайтах, может быть, даже ссылочку, какой-нибудь приложим. Что восстановление пароля по секретному вопросу, плиравнявается к аутентификации, ты не знаешь пароль, но ты знаешь ответ на секретный вопрос.

Ты пошел восстановивать пароль, все, профит. Поэтому восстановление пароля должно быть так же безопасно, как и непосредственно влагин, то бешево-танификация. А секретный вопрос на восстановление это плохо. Вот так вот. Дальше у нас есть второй фактор. Второй фактор – это что-то, что у тебя есть. Например, у тебя есть симкарта, на симкарту приходят SMS. И когда ты будешь кота за SMS, то на самом деле подтверждаешь не владение аккаунта.

Ты подтверждаешь владение симкарты с номером телефона, который привязан к SMS. Ещё для примера может прийти в пуши. Тот же самый кот – давайте вопрос. Чем подтверждаем владение, если кот пришел в пуши? Установка и конкретного приложения, типа авторизованным инсталом приложения. Грубо говоря, наличим у тебя пушто-кена. Да, верно. Ну да. Сразу видно, кто здесь мобильный разработчик. Было дело, да. С ожидаешь, владение пушто-кена. Хорошо.

И третье фактор – это Samsung UR, то есть какой-то, что ты такое? Вот это вот биометрия лицо или палец? Или вот что-то ещё, сечат как лаза. Вот такие варианты. Образят с ДНК. Надеюсь, что через несколько лет в гуке, чтобы авторизоваться надо плюнуть монитор, но на кое-что, короче, третье фактор прошёл молодец. Хорошо. Это сделает человек, который посмотрит этот выпуск на YouTube, и который вы слышит, что мы тут что-то разгоняда про биски, то при этом не хрена, не знаем про них.

Я всё при мне биски знаю, подожди. Токин? Взим биски. Токин? Хорошо. Есть ещё по спеке УАСП. Я буду никогда салаться. По спеке УАСП есть ещё два фактора, которые я незаметно для пользователя. Скорее всего, где-то они существуют. То есть они в реальном мире по-менему. Но с большой вредности вы не будете их использовать у себя в приложениях, но рассказать надо. Сам вверх, ЮР, геолокация где-то. Это может быть айпишник, это может быть геолокация.

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

Это скорее про то, что ты не бот, что твое движение мышки по экрану, оно будет корево. Короче, что оно укладывается какие-то паттерны, которые может сделать только человек и не может сделать какой-то другой агент. Ну типа такого. Типа такого, что ли? Да. То есть вот галочка, капча, которая тупа галочка, которая всем кажется очень странным. Но вот она же, по сути, примерно так и работает.

То есть она по неким поведению с компаторным, а потом по тому, как ты до этой галочки ведёшь мышкой, определяешь что-то человек. Вот это прикол. Только что в баклоге появилась новая тема, а зацепить выпуска прокапча, мне кажется будет фигенно. Ну слушай, капча это отдельный большой продукт. То есть его делают разные гелипятта, разработывают так, чтобы делать людям не очень больно и не опускать роботов. Но по итогу людям это все равно больно.

Но вот как минимизировать эту боль, это вообще очень интересно задача. Капча как бизнес по размерке до дассетов. Вот такой выпуск тоже надо записать. Это отдельный разговор, Сарян. Пока мы до геликой не ушли, можно сейчас уточню, потому что я кажется начал понимать то, что ты говорила раньше. Правильно понимаю, что кто от Тезис, который ты говорил, что если мы просто добавляем второй похожий фактор, у нас общая как бы сложность, защищенность безопасность, как угодно, это можно назвать не растёт.

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

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

Очевидно, ты если это будешь делать, ты, наверное, для какой-то цивилий ты будешь делать. Но мы его виды так иногда делаем. И мы знаем, ничего мы это делаем. И мы иногда отправляем котни в СМСки, она почту, иногда и в СМСки, и на почту. Это отдельная большая штука. Короче, в теории это должно работать, примерно как вычислить иная сложность. На практике, ну понятно, можно комбинировать несколько способов второго фактора и добиться увеличения безопасности.

Но нет, оно не будет кратное, и на порядок оно не будет. Нет, понятно. То есть просто, чтобы взломать конкретный фактор, просто нужно использовать фундаментальные разные подходы. В случае с паролем тебе нужно взять пароль, а в случае с СМСка, тебе нужно украсть телефон. А в случае с лицом тебе нужно... Украсть лицом? Да. Мы по бомбиюм еще про пароль с СМСки. Так. В общем, тебе не обязательно украсть телефон. А вообще... Так. А есть еще какие-нибудь еще экзотические, там, шестые седьмые факторы?

Например, не то, чем ты владеешь или там то, что у тебя есть, а кто-то, кто тебя знает, подтверждает, что ты это ты и это служит тоже фактором. Такая типа, братан-бейстофрезейшен. Не слышал, но вариант интересный. Было слово, когда есть компания, есть сотрудник, и там компания добавляет сотрудник в свой там личный кабинет, чтобы сотрудник мог какие-то делать. Можно сказать, что это братан-бейстофрезейшен. Опять, а вот эти кэшен-блин, я даже тут проиграл. Ладно, окей.

Так, давай тогда мы прошлись, потому какие вообще факторы есть. Давай теперь в каждый закопаемся по подробнее, помем какие вот у каждого плюсы минусы подводные камни, что надо использовать, что не надо использовать, что работает, что не работает, короче, погнали. Погнали. Сейчас будет боль. Сейчас будет прям боль-боль. Ты сказал плюсы минусы подводные камни. Ну вот давай пароли. У пароли нет плюсов. Люди используют простые пароли, чтобы их легче запоминать проще вводить.

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

Есть сервис их хранилище пароли, встроенный в Google, в iCloud, есть он паспорт отдельный. И я не буду говорить, что один лучше другого или что-то еще в целом атака стыли, которые нужны, чтобы уменьшить боль от пароли. Сам по себе это концепция хранилище пароли. Но ее могло бы не выйти, если бы не было пароли. Я верю, что скоро на столько цветлой будущих, где пароли не будет. А вот кстати, раз мы про это заговорили, объясни, пожалуйста.

Ночерта вообще разные сервисы требует регулярно обновлять пароли. Вообще, какую вам дело до того менял, я паролили не менял. Зачем я за чем это происходит? Сервисы забудут о безопасности, а их пользователи. Сервисы, они не то, чтобы вредно ей хотят сделать тебе плохо. Они хотят, чтобы тебя не взломали. И вот ты рассказал ситуацию неприятно, в которую ты попал, где тебя пришлось регистрировать новые аккаунты.

Но смотри, это менее больно, чем если бы твои аккаунты все взломаты, и с них наделали бы не хорошие петеллов. Это понятно, но чем регулярно обновление пароли мешает злому? Ты никогда не знаешь, в какой момент ты паролю течет. Поэтому, если ты делаешь регулярную ротацию чего угодно, то меньше шансов, что это что угодно будет скопрометировано. Потому что типа ты сам его забывать будешь постоянно, и он никуда, ладно, это же шутки за 300. Блин, здесь интересный философский вопрос, на самом деле.

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

Ты сегодня не залоги, ниже, что пока не добавишь на номер телефона. Вот где, ну, это шансовский вопрос, давай в дареко сильно глубоко они будем ее заходить. Но мне просто интересно, где находится сейчас границ, точки зрения людей, которые... Тебя, как человек, который занимается разработкой именно систематризации всего вокруг этого. Где находится грани, где нужно принудить пользователя, прям типа, обезопасить свой аккаунт или наоборот, где можно чуть под отпустить вожжий и сказать чувак.

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

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

А мы в свою очередь сделаем так, чтобы тебе было менее больно проходить второй фактор. Например, мы запомним твою устройство, и мы не будем спрашивать тебя каждый раз с этого устройства. Понял, понял. Мне сложилось, короче, металли на модель, что если речь идет, условно, про marketplace, где я могу что-нибудь продать, то если меня взломали, то это могут использовать, чтобы кого-то обмануть. А если речь идет про, скажем, Amazon, где я могу допустим только купить что-нибудь, то вообще пофиг.

Ну, если меня взломают, сам дурак с моего акканта на покупает, кто-нибудь себе чего-нибудь, никто не пострадает, кроме меня. Прости, но тоже не сработает. Ты потом пойдешь в Amazon, скажешь, верните бабки. Amazon будет разгребать, потратить деньги на сапорт, на какие-нибудь клеймы, когда ты идешь в банку, спаливаешь транзакцию.

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

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

Почему? Например, я в приказности я представляю ситуацию, когда то, что сервис какой-то вы нуждает пользователя регулярно менять пароли, приводит к тому, что пользователь не сгенерирует один раз сложный пароль. А будет наоборот, менять нем всего лишь одну цифру или наброс валица к более простому паролю, для того, чтобы не сильно думать, не сильно заморачиваться при попытке его заменить.

То есть, короче говоря, вот если какие-то исследования, которые показывают, что это действительно работает, а не просто каргокульт. А что это каргокульт? Базово пароли это очень плохой способ обеспечить безопасность, поэтому вот обновляй хоть каждый день, но все равно плохой способ.

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

Давай, давай, про эсмазки. Говорим второй фактор, я сейчас сказал, заставай своих пользователей, подключай второй фактор, о чем все подумали? Все подумали про эсмаз. Эсмаз, это не самый хороший способ второго фактора, а эсмазки это боль. У меня есть плюс и минус, а давай про них поговорим.

Я готов сразу первый минус, накинаюсь, я опять же, как релокант из одной страны, в другую столкнулся с тем, что переезжаю в другую страну, тебе, наверное, нужен новый сотый оператор и новый номер, а старый надо закрыть, чтобы не платить 80 евро в месяц за него. И тут стало не тревиальное задача понять, а в каких же сервисах я использовал его, как вторую фактора авторизации, чтобы случайно не лишиться аккаунтов там.

И я потратил литер или 4 часа, пытаюсь разными дезуктивными способами вычислить, а вообще где я этот номер использовал? Проходился по истории эсмазок, по истории Иван Пасфер, по истории Мэйлов, и я уверен, я пропустил несколько мест, я потерял доступ к этим аккаунтом, и это бесит. А у меня два телефона и четыре симпки. А мог бы один телефон с четырьмя симпками купить? И с антеннами? Такой, с антеннами, если ты везаром, я понял. Да, могу. Слушай, у какого оператора 80 евро в месяц на одну симку?

У водофона в Нидерландах, но там сложно, там у нас семейный просто тариф, на двоих, там, поэтому вот так. Привет, талакантом. У большинства операторов есть функция, что за какую-то очень маленькую денежку, раз в полгода, тебе продлевают симку. То есть вот у меня сейчас есть грузинская симка, армянская симка, и они живут и не протухают за, условно, один ларьев полгода. Я как бы выключил активный тариф и перешал на вот такое режим удержания. В Теледва он тоже есть.

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

Давай про плюса, то есть плюсы, то есть какие-то СМС-типы. Очевидные привычные сценарий, стандарт индустрии, так сказать, все пользуются, все привыкля, есть сервис провайдера, есть АПИ, СДК, Бери, подключай, радуйся, все понятно. Есть автоподстановка СМС-ак на смартфонах, парси СМС-ка достается из неё код и подставляется в импот-в приложении. 10 лет назад такой фича не было, и я помню, какие-то пилио сам руками вот полы интересно. Люди ругались, мол зачем тебе доступка СМС-ком.

Потом что еще люди научились оптимизировать дяной СМС-ак и сложность кода. То есть вот есть мой любимый пример тенков, кода, формата 771, давно при чем это они используют, не знаю, уже 10 как. Я не вижу, чтобы это менялось, наверное, на безопасности не жалуются, мне было бы интересно, но обзнать статистику, то есть как-то вот сравнивали, не сравнивали. По идее, я не вижу, чтобы это прям было сильно менее безопасно. На этом плюсы кончились.

То есть, нет, последнее, то что я назвал, то даже не плюс, это тоже касты. Типа к наличию, просто есть наличие СМС-ак, дальше мы с ними вот что-то делаем, то есть мы там укращиваем, делаем проще в водимами, делаем автоподстановку, но наличие СМС-ак все еще есть, вы этого есть куча минус. Ты забыл самый главный плюс благодаря этому, благодаря наличии такого фактора, ты себя чувствуешь нужным, потому что тебе кто-то шлёт СМС-ки, это очень приятно.

Блин, можно не надо, пожалуйста, что есть. Рассушь зашла речь, есть такая прикольно веселая штука как СМС-бомбинг, ты можешь заказать пронк с по-модругу, ты можешь скачать толзу и сделать это сам. В общем, это софтин, которая по ИПА и дергает разных сервисов и отправляет одному конкретному человеку на один конкретный номер, но стоит СМС-ак со разных сервисов, потом чтобы человек там пошёл. Вот, будет ли тебе приятно? Сторо-разболее приятно, чем если одна СМС-ка придёт. Пожалуй, че видно?

Кстати, я вспомнил, что я где-то видел статью про не случайную генерацию, случайных однажовых кодов Тинкола. Сейчас, кажется, нашёл какой-то статью на хабре про это, и я её приложу к ссылкам к уйпуску. Класс, я сам почитаю. Интересно. Ну, ладно, симки у всех есть, и в большинстве сервисов есть потребность знать номер телефона пользователя, то есть есть вот связь, телефон, пользователь.

Мы как сервис, как разработчик приложений, у нас есть телефон, но, очевидно, давайте отправлять на него СМС-ки, всё будет хорошо. Нет, не хорошо. Во-первых, конверсия низкая, ой СМС-к. Это 80%, 50%, сильно по-разному, у разных сервисов. Я сейчас сходу не вспомню, какая конверсия во вид. И, наверное, я бы даже не сказал, если бы помню, почему так? Давай попробуем перечислить вариации, почему СМС-ка может не дойти.

Но, во-первых, у тебя может быть телефон непод рукой, или разряжен, выключен, забыт в другой стране вот этого. Или лежать в контератеревистическом подразделении. Как это надо смотреть? Да, в телефону тебя могут отжать. Давай так скажем, в разных сценариях. Пойдёт тому, отправлять на него СМС-ку не всегда значит, что она дойдёт. Бывает плохое покрытие с этого сети. Человек сидит в подвале, живёт в деревне, тоже, как угодно. Бывают внезапно проблемы с отправкой на стороне оператора.

Крупные сервисы умеют джанглировать операторами, через которых и не отправляют СМС-ки. Типа, буквально, начались проблемы у кого-нибудь в одного из операторов. Дежурный инженер Мониторлинга, Дёргий Трубильник, и весь трайфик СМС-ок при направляется на другую оператору. То есть мы как бы, мы как сервис, решаем проблем вот того, что операторам что-то прилегло. Есть отдельная боль, повторная отправка СМС. Это когда ты не получаешь СМС-жмёшь кнопку отправьте мне и пожалуйста ещё раз.

Потом тебе приходят обе одновременно в перекутанном порядке. То вводишь одну из них, оказывается, что это неправедная обе зашкваливаются. И ты сидишь ещё пару минут, жидёшь, когда тебе можно будет приятт прохть. Хозяйки на заметку. Можно номер циферкой, класс типа это первое, а это второе. И тогда даже если они придут в перекутанном порядке, то там будет циферка типа второе. Ты будешь знать, что нужно ввести вторую. Так никто не делает, но я бы очень хотел. Потом люди ошибаются при воде.

То есть почему ещё может быть низкая конверсия? Да, у КСМС-ка дошла человек, смобтот в телефон, там шести циферный код с разными цифрами. Человека в три подхода вводят в четыре по одной, две циферки. В итоге вводят неправедно, ошибаются, всё провал. Потом человек идёт, пишет в сапорт типа вёл код с ССМС, точно вёл праведный, а мне тут ругается вот в магите. И это кастына сапорт. Это реальные кастына сапорт, люди реально так делают. Давай дальше по минусам. Это дорого. ССМС-ки это дорого.

Представь, что ты делаешь стартап. И ты хочешь, что вам стартапе 10 тысяч реестраций в день. Ну, звучит классно. То есть, к тебе приход 10 пользователей, ты потом как-нибудь зарабатывать на них будешь. Ну это причём, ну то есть это звучит хорошо, но это не космический много. То есть 10 тысяч реегистраций в день, это не миллион. И вот давай попробуем посчитать, сколько ты потратишь на эти реегистрации. И если для каждой реегистрации будешь подтверждать номер КСМС. Ну вот, нагад.

То есть сколько денег в год закладывать на ССМС, на сценале реегистрации? Я не знаю, рубельно верная ССМС стоит перед ним. Наверное, что-то в этом духе нет? Нет, нет. Давай, так, для каких-то не очень крупных, огромных сервисов, там дешевле двух с половиной не будет. В принципе, это вот самый минимум. Получается, 25 тысяч в день, 750 и уйолки палки. Ну 10 миллионов получается. Ну получается. То есть что это за деньги? На эти деньги можно, наверное, разработчиков задержать.

Может быть, даже не одного. Я уж не знаю, сколько там сейчас в России разработчики зарабатывают в наносекунду. Но кажется, что можно даже не одного. И можно много-много классных фич напилить этим разработчикам. А ты тратишь эти деньги на регистрацию. Потом бывает еще ССМС-плудинг, когда приходит конкурент. И склики в ответство бюджет. То есть, правдает фейк в ССМС в регистрации на несуществующие номера. Номеров этих у него даже на руках нет. То есть он их просто перебирает.

И вот он тратит твои денежки в твоем стартапе. Не хороший такой конкурент. И это очень частое штука, которую находят репорт от любителя в акбаунте. То есть есть такие waithead-хакеры, которые приносят ССМС-плудинг, довольно часто в разные крупные сервисы. Как контролировать? Ну давай, вот ты хочешь побороть ССМС-плудинг в своем сервисе? Что будешь делать? Какую лимет будешь вставлять? На номер телефона. Но тогда вот этот вот негодяй может перебирать номера.

У него их нет на руках, но он просто их перебирает. На айпишник. Ну тогда мы можем поблочить какой-нибудь подъезд, могу квартиранного дома, или весь дом. И при этом мы ничего хорошего не сделаем, то что негодяй может легко поменять айпишник. Можно попробовать связаться на какой-то фингер-принт, тема с идеей, что ты еще, но опять же, если это генерится на клиенте, то легко поменять. Если это отправляется в заголовках, то же легко поменять, легко перебирать.

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

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

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

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

Ты сказал, что ты платишь за то, чтобы твой номер не ушёл на продажу из-за неактивности. Ну вот как ты думаешь, насколько это распространённая ситуация? Думаю, довольно распространённая, потому что в телегу периодически входит номера из старой телефонной книжки. Я вижу, что это какие-то другие люди, не те, кому этот номер принадлежал раньше. Да-да-да, в телеграме приходит в дамбляне, а мол, такой-то ваше присоединился в телеграм.

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

И вот допустим, проходит 5 лет, какой процент таких телефонов у этого сервису? Так, блин, ты сложные загадки задаешь. Но давай подумаем, через как от в ныр дают. По-моему, у меня что-то там 6 месяцев не активности, поэтому я раз в 3 месяца, чтобы предохраниться, отправляю... Полгода не активности, потом полгода он отлеживается в общем-полед. После этого сразу ведет на продажу. Так, но тогда... Блин, не знаю, не справдывается уникам математическом модель в голове. Жень, давай выручай.

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

Кто на YouTube это видел. Давай скажем, что за пять лет суммарно будет 20%. 20%. Это смысле номера, вот какой-то сервис, кто-то кто зарегался с номером, эти номера станут неволидными и передуть кому-то другому. Да. Омога. Очень много. И да, ты можешь об этом не задумываться, когда ты делаешь им випишку, типа, в первый год у нас это точно не палит. Но это точно становится проблемой, когда твою продукцию становится уже взрелом при насящем денежке, твой стартап вырастает.

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

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

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

Что, потеорий, это и вводить, просить, водить код из МЛА и из СМС-кода. Никак безопасно снювелищивает, а на практике, то, ну, увеличивает, получается ровно. Вот в этом случае. Все так. Все так. С одной стороны, ты можешь заниматься актуодизаций номеров. Ты можешь, чтобы заниматься с оттогоми операторами. Все крупные банки это делают, все крупные сервисы это делают. Ты можешь заниматься актуодизаций с одной стороны.

И с другой стороны ты можешь накручивать дополнительные способы, как проверить, что человек, который входит, это он. Окей. Давай еще проминусы СМС-к. На самом деле мы сейчас можем полчасащик говорить про МИС-к. Если хочется, к чему-то более позитивного перейти, то и скажи. Нет, мне нравится, давай еще разберем минусы. Хорошо. Что, если я тебе скажу, что еще 10 лет назад, восстановить симку в салоне связи было очень-очень легко и за этим не очень следили.

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

Там в какой-то момент уголовку вел из-за этого штука и стал сильно сильно лучше. Но если очень надо, то существуют все равно разные опции, то есть все равно люди в салоне связи имеют физически такую возможность. Ещё кроме того, существуют черные наториусы, которые могут сделать тебе доверенность, что мол, вот тот владелец этой симки, тебе разрешают прийти в салон связи и ее восстановить. Поэтому это все ещё может быть проблемой, но с этим больятся. Ну, вот как больятся?

Например, операторы не доставляют о самойски. В первый раз в утке после перевыпуска симки. Не доставает о самойски от банков. То есть тебе код на списание, код на транзакцию, на подтверждение транзакции. Тебе не придётся в первый сутки после смена симкарта. Ровно в целях безопасности здесь. Потом есть ещё хорошие пример белая инвации. Белая ин сделал для второй фактор челец e-mail при восстановлении симкарты в салоне связи.

То есть это как бы бесплатно я настройка, которая закопана в приложении белая инвуслогах. Её не очень просто найти. Но кто сейчас это услышал, кобилай им, прям советую пойти и подключить себе эту услу. Как это должно работать? Человек, который приходит в салоне связи восстановлении симку. Он должен будет называть код и списьма, которая ему придёт на почту, которая указана в его контракте. Блин, пойди объясни бабуля. Какую ей надо подключить услу. И всё равно есть сонженерия. Потом ещё пример.

Я пример буквально недавний. Я перевыпустил симку и теньков. Тоже уже упомянутый. Вместо кодов 3DS, вместо вот кодов подтверждений транзакции, стал присылать sms с текстом. Не можем вам отправить код для подтверждения операции. Позвоните по номеру, и там 8700 н. Я звоню, там я вновь пред записанная голосовушка робот, говорит Дмитрий, ну смотри, что это. Здравствуйте, я Дмитрий, расскажите мне про свою боль. Я точно знаю, что это Дмитрий, вам как бы не живой.

Нет смысла человек, который когда-то записывал эту голосовушку, вам живой, в смысле, что я с роботом разговаривали сейчас. Я как бы немножко подбешиваюсь от этого, проговали в условами через рот. Так и так, пришла sms с кодов 3DS, пришло, не можем вам отправить код. Позвоните, и это должен Дмитрий говорить. Сейчас я вас переключу на коллегу. Я сначала думал, будет ли этот коллег и живой. В общем, оказалось живой. Ну, лет привет, я Дмитрий. Думаю, хорошо. Привет Дмитрий.

Я ему опять повторяю все то же самое, что уже рассказал на том алжедмитрию. Вот и Дмитрий мне говорит, ага. Ты значит, менял симку. Давай говорить видео звонок. И дальше мы с Дмитрием настоящим. Идем в видео звонок в приложении. И он на меня смотрит, что я это я. Так говорит, я вижу, что это ты, все я тебе включаю. Это пример, как банк, общается с оператором, взаимодействуется оператором. Узнает о том, что было какое-то действие с симкарты, например, перевыпуск.

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

То есть, это может быть, блин, выгроз, какая-нибудь просто файлом, раз в сутки, которые люди, аналитики сами там разбирают. Это может быть интеграция, через какие-нибудь хуки по репиая, я не знаю, как интегрирован танков. Поэтому я не могу сказать. Окей. Так, есть еще какие-то крупные проблемы с МСК? Да. Есть. Извините, есть еще несколько. Что, если я скажу, что все современные сутовые сети работают на протоколе родом из 80-х и этот протокол дыряменький.

То есть, буквально вот все сети вплоть до 5G, работают поверх протоколы ССС7. В нем нет шифрования, очень просто авторизация. И давай скажем, что можно в Даркнете за 1 000 долларов купить атаку под ключ, где тебе перенаправят СССК, данные его тренгуляции, жертвы, даже записи звонков могут сделать. Как-то очень дешево. Я почему-то думал, что это гораздо более дорогая штука. Даже если логически подумать, если что-то такое стоит 1000, то, по сути, это значит, что это знание.

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

Это не было. Это не было. Это не было. Я не знаю. Я не знаю, как взломать в контакте твоей бывшей. Это мы после выпуска разберемся. Это же не знаю. Да, ладно. Но, подождите, а за что ты выбрал 1000 долларов? Да. Нет, да. Я не знаю, как взломать в контакте твоей бывшей. Это мы после выпуска разберемся. Я тоже не знаю. Ну ладно, ну, дождь, а за что ты выбрал 1000 долларов? Ну там по СМСку переходите. Ну, я не уверен, что тогда в контакте я... Ну это правда, да. Вот по СМС.

Ладно, все, проехали, не будем взламывать ничего контакте. Не надо, ребят, не взламывайте ничего, никогда самое лучшее, что вы можете сделать. Если вы хотите кого-то взломать, вы можете зарегистливаться на Hacker One, как Whitehead Hacker, найти там вакуумных компаний, знакомятся с выплатами, призовыми пойти, найти какие-нибудь уязвимость у крупных компаний их зарепортить. Тем самым вы нанесете добровое, заработаете денежков и, наверное, прокачаетесь. Вот мой совет всем Хacker.

Второй вариант — это найти какие-нибудь CTF и тоже в команде весело позламываться какие-синтетические штуки. Да. Так, окей, ладно, все смотрим, мы поняли, что СМС Кодэ это, короче, вообще, максимально проклятая штука, и даже, даже, даже, короче, если забыть про все остальные уязвимости, короче, еще баксов — все нет второго фактора. Но ты говорил, что с Пымы СМС Кодэ весть еще там те же самые пуши. Вот с ними это все нормально. Сейчас подожди.

Ты говоришь про тысячу баксов, мы забываем, что есть соцом-женере. Соцом-женере гораздо дешевле. Ну, реально, компинация цельового пробива, плюс фишенговых страниц, плюс прямого контакта, даёт людям конверсия 70%. Это мы с вами тут все-таки умно и тишные седимы, и думаю, что нас это не коснется, и надо так думать. Очень для действийчной бывает соцом-женере, и гораздо дешевле чем-то тысячу долларов. Бросеника.

По умому выпуск про ССМС Кодэ весть, если вы хотите, или не знаю, все там 7 лет существования подкаста записают, но пока так и не добрались. Возможно, когда они быть, когда они уйдем эксперты, ваид эксперты. Если ваид хайкера, который занимается соцом-женере, точно есть исследователя. Разводят, но по доброму. Во-первых, существует аудитор.

У всякой крупной компании есть, а удет безопасности, когда приходят внешние подлячки для устраиваться свои безопасники, правильные фишного ввесы, на кое-что звони, еще какой-нибудь делают штуку. Поэтому такое есть. Еще есть аналитика, оттежа позитив технологию, тоже можно почитать. Окей, ладно, спасибо, что я помню про соц-мженере, и закопал уже и так закопанные СМС. Давай под другим фактором. Давай. Пуши. То есть, когда упорпуши, давай про них поговорим.

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

Там 60-80% норма, и я бы сказал, что доставляемость у пуши, даже ниже, чем у СМС. Пуши идут обычно в перемешку с маркетингом. В итоге мы получаем отписки вот всех пушей. То есть, мы отправляем кодо для входа, мы отправляем какой-нибудь маркетингу рассылку, не упусти. Человек бесяц говорит, но нафиг ваша распродажа выключает пуши. Все, мы не можем ему прислать вторую фактор в пуши. Потом еще пришел допустим пуш, и ты понимаешь, я нам нажал. Открылась приложение, пуш пропал. А какой там был код?

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

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

А я, как бы я не залоги, не. Но я вижу все сообщения, то есть я в привьюшке. Тогда еще мне кажется, секюрити на этом, в Айвас не позволяло, но секюрити настройки, скрывать все, что я написано в пушах, пока ты там явно не подтвердишь, что это ты, это ты. И короче, вот пришлось удалить приложение и установить заново. Только после этого у меня перестали приходить сообщение на мой Skype, в котором я уже там месяц как раз логинился. Супер странное фигня.

Но при этом я знаю, что очень многие, но не очень многие на некоторой сервисе, правда, не очень хорошо, не очень правильно, отрабатывают от пушей. И это на самом деле кейс он такой, не прям популярный, но он не супер редкий. Бывает. Дыра получается. Спушаемый куч в проблазям. Тебе нужно делать регулярное их обновление по штуокинов. То есть, не все это знают, когда интервью пуши, что пуштокин может обновиться, тогда тот пуштокин, который ты хранишь в базе, он все.

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

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

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

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

Он тебе дает токин, ты дает токин, дает баканду, и баканд потом может ходить специальные, какой-нибудь либо Apple, либо Google, либо там, кто еще бывают мобильные вендеры. Сервис с этим токином, говорить, вот на этот девайз, отправь, пожалуйста, вот такой-то пуш.

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

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

Чтобы по экономии денег, но придется поразрабатывать, придется обрабатывать ситуацию, когда пушь не доходит, и по итогу все равно будет отправлять СМСК, и все равно будут все те же самые проблемы. Давай посмотрим еще какие вопции существуют. Есть вопция про, например, вход по QR-коду. Все видели, допустим, WhatsApp или в Яндексе, у тебя есть приложение, это в приложении, аутентифицирован. Сканируешь QR-код приложением, и становишься аутентифицирован, допустим, на доступе. Нормальный флол.

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

Из плюсов еще гарантированная, быстрая доставляемость. Чайля с канал твоего взаимодействия с приложением. То есть у тебя есть какой-то API между клиентом и бокандом. Вот и ты через них пускаешь трафик, ты не зависишь от мобильных операторов, ты не зависишь от фейрбейза. По сути, это упираешься в надежность своей инфраструктура и в навещии интернетов упадет ли. Минус все-таки не подходит для первого входа. Но тебе нужно, чтобы пользователь был в моменте уже в приложении аутентифицирован.

Еще есть интересное наблюдение, где еще это поменяется. Есть европейские наубанки, револют N26. И у них подтверждение транзакции, сделано не кодом в SMS, а кнопкой в приложении. То есть у тебя открывается окно в броузере, стандартная 3.0. А кнопка, как у всех, в нем нет полиинкота. Ты не можешь никуда ввести код. Там написано чувак открой приложения, нажми кнопку. Ты открывай в приложении, нажимаешь кнопку, транзакция пошла. Классно.

Есть, кстати, вот ты сказал, что не подходит для первичной аутентификации. И это на самом деле не всегда так. Мне очень понравилось, как эту проблему решили в Нидерландах. У Нидерландов есть прям правительственный сервис. Называется дихеде, но переводится как типа цифровой ID. Это отдельное мобильное приложение, в котором ты один раз аутентифицируешься. И дальше ты его используешь по вот этой штуке с куаркодом, для того, чтобы логинется на других каких-то сайтов.

То есть еще раз есть один праваедер, который у тебя один раз аутентифицирован, но когда ты заходишь впервые на какой-то новый правительственный, или не только правительственный сайт, ты используешь вот эту штуку, для того, чтобы подтвердить, что ты это ты. И вот это прям офигенно было сделано. Мне очень нравилось, очень круто, очень комфортно. Это звучит классно. Как будто бы это похоже на o-ouse в оконой идее Flow. Все равно ты первый раз должен, будешь залогенится в приложении.

Но да, звучит клёво. Только в одном приложении они в 10, вот в этом главное отличия. Звучит прикольно. В итоге вариант хороший, но скорее всего единственными основным не может быть. И значит, что если у тебя есть фолбак в асомэску, то у тебя безопасность асомэске. Извините. Какие еще есть варианты? Есть вариант, разрешающий проблем о локантов. TimeBased.tp. Ты вот такое приложение, Google Authentifika, тоже Duo Mobile и так далее. Прикольно. Штука. Давай расскажу, как это работает.

Там единственный момент, когда происходит какое-то взаимодействие между приложением и твоим сервисом, этот момент регистрации. То есть ты исканируешь приложением CoreCode. В CoreCode строчка вида, там как депринку. Тпраус, двериточие, два слашают, ты вот такой слэйш, потом там название твоего сервиса и секретный ключ. В этот секретный ключ он в приложении запоминается и потом он используется для генерации CoreCode.

То есть есть секретный ключ, есть метка времени, текущего и генерируется с их помощью CoreCode, там 6 значной обычно. Пользователь этот код вводит, потом сервис, в котором этот код вводит. Он генерирует точно так же CoreCode с помощью секрета и метки времени. И сравнивается введеном. Там есть обычная перекрытия, какое-то код действует минуту, метка времени, это текущая минута. Плюс обычно есть некая перекрытия, там плюс-мену 5 секунд в обе стороны, чтобы синхронизация часов работала.

В смысле, чтобы в случае расцентрона часов все продолжала работать. И по итогу 0 взаимодействия между клиентом и сервисом в момент, когда код генерации вводится. Код соответственно генерируется даже в офлайне. То есть если у тебя мобила без симки, что угодно, то все равно код будет с генерирован. И он будет генерировану кодовенно. Ты не ждешь, когда он тебе придет. Ты можешь его сразу достать и с приложением.

Вот единственное взаимодействие, это обмен секретным ключом, когда сканируешь CoreCode приложение в первую раз. И это бесплатно для сервисы, бесплатно для пользователя. И это достаточно безопасно. Есть нюанс, что момент обмена секретным ключом, но он все-таки вот такой. Но опять же ты его передаешь на через интернет. Ты его передаешь через CoreCode через камеру Device. Ну, CoreCode может куда-то у тебя еще.

То есть когда регистрируетесь, когда регистрируетесь, то это у то поприложение, не сохраняйте этот CoreCode. Ну вот, какие минусы здесь? Это штука не пройдет проверку бабушкой. Ты попробуй объяснить бабуля, что это такое. Но будь скачать, пожалуйста, приложение Google Authentificator. Отсканируй, пожалуйста, CoreCode для обмена секретными. Вот. И еще когда тебе надо будет код, вести, найди, пожалуйста, приложение Google Authentificator, про себя, в смартфоне. И его открывай каждый раз.

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

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

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

Охранить пароли в One-Post, это не страника. Ну, а же страника. Но, другой стороны, пароли – это первый фактор. Это все-таки уже второй фактор. То есть это как бы то, чем ты владеешь, ты же подтверждаешь, «О, кстати, кстати, чем подтверждаем владение». Вот, по идее, как раз ты когда все это хранится локально, то по сути подтверждается это, кстати, о чем, правда. Изначальным ключом. Да. Кто-то урвел использовать это того, чтобы заситапить. Все так. ТТП. Все так.

Ты же подожди, что ты владение строчкой, которая была зашита в ТТК-РКОД, когда ты его сканировал. И, да, если ты его коди уж куда-нибудь в облак, то ты уже не владеешь по сути, получается. Ну, вот такое. В общем, здесь каждый сам решает. Ну и потом, соцненье релью все равно возможно. Давай поговорим про опции, где соцненье релья невозможно. UBK. Нет, это не будет опция, которая проще для бабузя, но это будет наиболее безопасная опция. Чем что, это такое?

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

Как это выглядит, вот UBK. На нем кнопочка у тебя курсор стоит в каком-то инпуте. UBK генилирует строку, подписывая ее. И отправляет сообщение через точку разделенную шифротекст. Хэш, подпись. И дальше сервис проверяет, что этот текст подписан вот этим вот UBK. Потому что с помощью публичного ключа ты можешь проверить подпись чього угодно. Соответственно, подпись возможно с только с помощью секретного ключа. Секретный ключ никогда не покидает UBK.

Ты своим сервисом проверяешь публичным ключом, который ты можешь вообще выкинуть в открытый доступ и, пожалуйста, бесплатно в момент токтоннификации. Но стоит 30-60 баксов, как найдешь. Вот, и тут начинается опять минус, опять с бабушкой. Давай, бабуль, купи, пожалуйста, токен за 30-60 баксов. Таскаи его, пожалуйста, всегда с собой не потеряй. В такаи его, пожалуйста, в UB каждый раз. Или держи один из стотов занятым. Вот, с помощью меня могу ковляну всего три стота.

И, в общем, только два у меня есть. Один всегда занятый. Вот, но это, пожалуй, самая секьюраная, что сейчас есть. Здесь много единственного опция. Это отнимет UBK. И вот если отнимет UBK, то все жопа. Получается, что самстанн дью Хэв у тебя уже уточили. Это не приятно. Окей, я сейчас поменаю, вообще, когда я поснилась поезу UBK. UBK, наверное, только для личных задачей. Так когда-то думал заморочиться.

Но в итоге, короче, единственная мысль на Риспадине UBK было, когда компания вынуждала это делать. По сути, так и бывает. То есть все эти косты, все эти сложности, они могут окупиться. Если это делает компания. Но и компания не обломно потратить немножко денег. Но сотрудников дополнения к нему отбоку за 2000 долларов купить ему еще свество за 30 долларов. Вроде не проблема. Но для личных целей, ну такое. Кажется, что все вариант хреновы. И в принципе, можно на этом подкасты вершать.

Но в общем, есть одна опция, которую можно использовать для личных целей. С безопасностью уровня UBK. Давай приняю расскажу. Но поговорили, что порой ли это боль и плохо. Давай представим, что будет, если разработчики железа и софта. То есть, кто у нас Google, Apple, Microsoft, разработчики, бравзеров, ну, Мазила, в частности, Google опять же, кто же Apple опять же, Microsoft опять же. И разработчики систем для безопасного входа, то бешью бики, вот они все объединятся и скажут, Пороля это плохо.

Мы сейчас сделаем так, что пороли будут ненужены. Мы сделаем светлой будущая, в котором будет безопасный вход без пороля для всех ввели. Вот и они сделали это достаточно давно. Уже на самом деле больше 5 лет назад, иначе это. Вот и они сделали новый стандарт аутентификации в вебе. Ну так и называется веб аутентикейшн. Вот представь, ты его излагенишься в вебе на диск топе, приложив лицо к мобилке, которая лежит у тебя рядом. Как тебя? Красиво. И это все черезнотивные крайнейчики.

Тебе как разработчику приложений, не нужно даже сильно много вокруг этого делать. У тебя появляются разные нативные экраны, которые сами дают инструкцию пользоваться. То есть вот на макбуке я могу сейчас зайти в Google, Vendex. И злогинец не в вводя пороль. Просто приложив падец. И у меня будет экран, макбучный стандартный макос в скей, что в молдну приложит, тачай идеи, все будет хорошо. Я прикладываю и не в вводя пороль, не вводя СМС, оказываюсь злогиненным в веб-докси.

Так, ну в чем по двух, тогда раз все так хорошо? Ну по двух в том, что сложно объяснить бабуля, наверное. И в том, что это очень новая технология и очень непонятный паттерн для пользователей. То есть, ну с одной стороны, это есть уже в многих в Google, Facebook, Apple, Microsoft, Paypal, У Yandex, УВК, Майлеру. Есть вот этот веб-докси, он по-разному называется, но по сути, в технологии веб-докси.

Yandex пошел дальше всех, и в конце успешно о сценарии входа по СМС, Yandex предбогает подключить быстрый вход. Янекс называется, это быстрым входом. Ну буквально, вот я вошел по СМС и у меня крайний человек водится, а хочешь не вводить СМС, вот давай подключи быстрый вход. И там нарисовано, ну, standard, вот этот печаток пальца, ты нажимай конечно кнопку, появляйся системная кошка, нажмай кошепалет и все. Следующий раз ты заходишь в Yandex в веб-докс по пальцу.

Классно, буквально, не обязательно даже в логину водить. То есть система, она активно запоминает в том числе логин. У тебя как бы есть пару логин и пару ключей. Да, под капотом это работает через осимметричное шифрование. Через подписание некого челленджа, то есть сервер присылает строку, клиент ее подписывает к летным ключам. Сервы в публичном ключом проверяют, что это он, что это тот клиент.

И, ну да, в момент регистрации, когда я первый раз приложил палец, на сервер Yandex увлетел публичный ключ моего устройства. Моей пары ключей, которых раница на моем устройстве. И Yandex их у себя там запомнил, запомнил вот в личный ключ. И в следующий раз может проверить. Какие тут есть плюс и минус? Ну, душе, давай сначала, вот как ты думаешь, какой это фактор. Второй и перейти. Так, кажется, второй. Почему? Ты же палец прикладываешь?

Да, но я прикладываю палец, подтверждаю, что я просто владею этим девайсом. Я запрещаю. А, хотя подожди. Я думал, ты подтверждаешь, что ты это владелец этого биометрического, как это сказать, фигра принта своего. Но с другой стороны, ты же подтверждаешь только то, что фигра принт, который ты занёс надевайс на этот конкретный, что у тебя есть к нему доступ. Блин, сложно? Ты подтверждаешь, что это твой палец, это мой ноутбук, роче, или твой телефон?

Ага, давай на водку, ты можешь вместо пальца ввести пароль отайклавда. Какой будет фактор? Первый. Ну да, а в итоге ты что-то подтверждаешь, когда вот проходишь этот веплот интекеишно. Какой фактор? Клажно. То, что ли, ладно, владение, я парой ключей. Да, я гордый, я был прав. Слушай, но при этом все равно же, ведь прикладывается лицо и депалиться. Я сейчас немножечко обманул, потому что в этом сценарии ты не можешь ввести пароль отайклавда, тебе все-таки нужно именно сделать лицо и депалиться.

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

В Apple Education подтвердаем владение парой ключей. Собственно, и в GBK тоже, мы подтверждаем владение парой ключей. Ну, у тебя все-кредный ключ однозначно вяжет на этом устройстве, никуда не уйдет с него. Поэтому по сути транзитивно подтверждаешь владение GBK, как физическим устройством. Ну, суть та же. То есть ты подтверждаешь владение парой ключей, и получается, что Apple Education он по уровня безопасности такой же, как в GBK.

То есть, в GBK ты доживаешь того же уронной безопасности, но тебе не нужно покупать физическое устройство, затокать им USB-Port. Это суперклассно. Вот такие дела. То есть получается, осталось подождать лет, я не знаю, пять, и наши проблемы идут. Ну, я верю. То есть, я сейчас есть трудности. То есть, я сказал, что можно с мобилки, которые даже рядом пройти. У тебя может не будет сканера отпечатков пальцев на ноутбуке. Тебя может не быть даже ноутбуков, а может быть desktop, стационарник.

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

И люди забывают, какому телефону они прикладывали лиц. То есть, человек начинает логинец. И он не помнит, где у него лежит, это пара ключей. Но он не знает, про пару ключов. Он просто не помнит, как он захотел. Поэтому конверсия этого способа сейчас не очень высокая, даже ниже, чем мой самосок. Хорошо говорят, заходят на мобилках, когда у тебя, ну, сценарий неразвивный. То есть ты, как бы, входишь по лицу в вебе на мобилке. Здесь конверсия повышит.

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

Но пока мы еще не там, давай такую подобьем, промежуточную черту. И поймем, какие факторы, когда все-таки лучше используют. Как тебе, не знаю, как владельцы у кого-то сервиса сделать, быстрый выбор между тем, что тебе надо поддерживать. Или надо вообще поддержать сразу все, и дать пользователи выбора. Ну, здесь не будет универсального ответа. Это же зависит от того, кто твой пользователь. И насколько ты сможешь ему объяснить, сможет ли он использовать ТОТП.

Если ты делаешь какой-то пет проект для наудитовливой айтишников, выбор очевиден ТОТП и веопологдикейшно. Если ты делаешь продукт для бабушки, то боюсь, что и самаясь. К сожалению, есть еще знаешь какой момент. Вот мы проговорили, что, по сути, у любой интернативы на всех сервисах, на всех, вот, все примеры, что я прибел. Даже для веопологдикейшон есть способ откатиться до SMS. В случае, если ты не можешь пройти, вот это вот хороший безопасный способ.

Поэтому у тебя безопасность не вышет с SMS по сути. И здесь речь будет только об удобстве. Гитха предлагает SMS в качестве фолбека для ТОТП. Яндекс и Google предлагают SMS в качестве фолбека для веопотинтикиейшон. Давай про себя. Я подключил ТОТП веопотинтикиейшон везде к демок и я выпидел второй фактор через SMS везде к демок. То есть я везде где-то не где я дотянулся, убрал телефон. Google теперь ругается, очень сильно говорит Гитха и ты в опасности. Ты можешь потерять доступ к аккаунту.

Я помню твою историю из начала. Да, мне страшно. Но одновременно с этим мне чуть-чуть более безопасно себя чувствую. Вот, еще из советов, да, наш совет, который можно просто безусловно примет. Включите второй фактор для восстановления симки. Если пользователь Белаяном, если пользователь с другим оператором, который дает такую возможность, включите второй фактор для восстановления симки, это чуть-чуть добавит безопасности. Окей, спасибо большое, что все подбил звучит как довольно хороший план.

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

Если ты откроешь любую статью про аутентификацию, там точно будет секванс диаграмма. Сложно, но давай попробуем. Где сможем объяснить, где не сможем не объяснить. Додим ссылочек. Давай вернемся к нашей истории про 8 миллионов авторизованных запросов минуту и тротленок с редкарк-контенера с экспруксидородисом. О чем это вообще то, что у нас была древняя схема с совершенно ID? То есть, когда человек логинется, бакант ему выписывает со всем на куку, совершенно ID.

Кук хранится в проузере, отправляется вместе с ЧТТП запросами. То есть это и ЧТТП он для секьюр, кук, который про нее даже джевоскриптовый кот ничего не знает. Запрос полетает, но бакант запрос полетает в IP и Gateway. Дальше IP и Gateway должен к этим то образом преобразовать эту куку в, ну, крово говоря, User ID. User ID набор еще каких-то атрибутов и пойти дальше с этим запросом в микросервесах.

И что будет тебя не было историю, что каждый микросервес со всем на куку, как-то распаковывает, преобразует в User ID. Что делает аппетит? В Аппиге идет в сервисессии, сервисессии идет в Redis и из Redis достает по ключу совершенно ID. Если очень упрощен, то вот так. То есть это некий просистент на хранилище, в момент, когда пользователь логинется моему вписовым токен, то есть он на куку, и потом каждый раз ее достаем из Redis. И эта схема не очень хорошо штабируется.

В какой-то момент все равно упираешься. И Redis в какой-то момент становится ботолняком и микросервес дальше скидать уже сложно становится. Поэтому мы от совершенно ID перешли к JSON-ваптокно. Это GVT, это такой формат, который уже лет 10, как существует, годы 2014, кажется, и в принципе это уже такой стандартный факт в индустрии. Но у него есть минусы. Вот что это значит?

Это значит, что клиент, когда он логинется, мы ему отдаем JSON-вапток, с его user ID, подписанную, нашим секретным ключом, и гадышкомпотпись. Или ему склеиваем эти штуки в строку, там чуть сложнее, там есть заголовок JSON-инав, в котором описывается формат потом Payload JSON-инав, у us user ID потом подписанную. Но, судя такая, то есть мы грузок уволяем не храним у себя этот токен. Мы его храним у клиентов в куке. Вот так просто. Мы перекладываем из нашего Redis, грузок уволя в клиента.

Но да, мы у себя все равно персистентно это храним, но что нам это дает? Возможно, достать user ID, гарантированно верный, провели в подпись. Мы берем от Payload с этой user ID, проверяем, подпись, что вот это подпись, соответствует этой user ID. И после этого мы можем даже не ходить ни в какой Redis. В чем профит, в том, что это все делается на мале. Тебе не нужно ходить в базу данных. В чем минус?

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

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

Если у тебя поток таких сбросов сессии приличный, то у тебя оперативки просто не хватит. Это могут быть миллионов в день, таких сбросов сессии. И миллионов в день довольно сложно хранить в инмаморе. Поэтому мы делаем, что мы делаем стеки совершенно. И мы храним в инмаморе сброшены сессии тех пользователей, которые идут в конкретный под конкретного сервису сессии. Дальше интересный вопрос, как мы туда это доставляем. Сейчас подожди, а что такое стеки совершенно еще раз? Да, надо рассказать.

Это способ был на серовке трайфика, когда ты делаешь так, что у тебя один тот же клиент попадает в один тот же под микросервису, своими запросами, последовательно, он кинул 10 запросов, они все попали в один под. Он пришел завтра, попал в тот же самый под, или другой специально для него поднятый. То есть это история про то, что у нас в поди живет cash, или конкретно упорзывать по сути. Дальше стоит вопрос, как туда этот каждый доставить. Есть процесс сброса сессии.

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

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

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

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

А ты очень правильно сказал, что уаус это стандарта в авторизации. Это здесь не ошибся. Потому что я на рандоме говорю сейчас эти слова и видишь иногда попадаю. Ну же, оно базово, что это такое. Я как клиент, как держатель, например, пирозданных, разрешаю сервису какому-то посмотреть моё имя в Google. Это я авторизую сервис на просмотр своего имени в стороннем проведор. То есть есть айдентийте правойдор, это Google. Это внешний сервис, который предоставил до уставки ресурсов. Есть ресурс.

Это какой-то скуг доступных от реботов. Например, имя пользователя. Возраст что-то ещё. И есть наш сервис, которому пользователь дает авторизацию на доступ к своему ресурсу в айдентийте проведор. А дальше сверху мы добавляем ресурс, который называется ID-токен. Это уже получается опыно ID-конект. Это такая маленькая надстройка на 2 ауса для аутентификации. Давай, например, это уже Google. Ты когда разрабатываешь приложение, это запрашиваешь скоб у пана ID. И тогда ты получаешь в ответе ID-токен.

И ты этот токен можешь просцировать однозначно с пользователем. То есть Google так бы гарантирует, что это ID-токен будет уникальный. И ты можешь его, у себя в базе прикопать и понимал аутентифицировать пользователь. То есть прикол в чем? Ты когда получаешь доступ к имени, допустим, Егоров. То есть, у тебя Егоров может быть очень много в твоем сервисе. Только один. Только один. Только один. Делай в сервис для Егоров. Смотрим. Нет. Для одного. Для Егора. Для Егора. Хорошо.

Короче, история про то, что ты, исполнил УАВС, получаешь ID-шник пользователь, и его можешь просцировать. Понимал, можешь выдать свой непоследственно токен, с которым пользователь потом будет ходить к тебе на твою сервис. И знаю, что вот на словах у АУС схеми без секванс диаграмма прямо становится совсем сложно. То есть, вот есть, да, я сказал, ID-тите-провайдер, есть пользователь, есть сервис, между ними есть спочек запросов. Я сейчас очень хочу рассказать про пиксе, про AK ForeCode Exchange.

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

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

Слушай, а если какие-то прямо сейчас известные очевидные минусы, у того, чтобы вообще использовать у Ауст. Слушай, ну, базово, ты говоришь, что ты доверяешь уровня безопасности, которые обеспечат идентийте правойдер. Например, Google, соответственно, если ты доверяешь, что, «окей, если ты хочешь контролировать это сам, то у меня «окей».

Потом какие-то есть история двигал, допустим, в России зачастую, если ты оперируешь телефонам, пользователь, тебе нужно с ним отдельную аферту заключать, и, по итогу, ты как бы не можешь всё достать из «Оусправедора», тебе нужно номер телефона, у него пользователя отдельно спрашивать, и, ну, это легало истории. А да, легало истории, вот, спецназм. Отключили уже в России вход через Google, вход через Apple, вот, пожалуйста, есть определенный минус.

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

А ещё, когда мы с тобой обсуждали Тейзис, ты хотел вы рассказать про ещё два протокола, наверное, авторизации, с членными названиями «Рубак и Абак». Там ещё есть опа. Слушай, это не совсем под такого. Это, блин, это даже преддаже долго рассказывает, наверное, сложно будет. Рубак – это roll-based авторизации, контрол, roll-based авторизации, контрол. Прошет. Это про то, что у тебя есть пользователь с РОДИО администратор, ему можно всё. Есть пользователь с РОДИО ему можно в буху счёт. Всё.

Как ты им клюминитироваешь это? Ну, это даже не протокол. Это классификация, я типа контроля доступа. Понял. Нет как раз про авторизацию. То, что мы сейчас начали обсуждать, это как раз про авторизацию. Абак атрибут бейс, аксесс-контрол. Есть какие-то атрибуты пользователя. И по ним твои системы решают, что пользователя можно. В во многих сервисах нельзя удалить профиль, на котором есть денежки в кошельке. Леговая история. Просто это абак. Вот. И у нас вовито тоже есть такой абак.

Вопрос, можно про атрибут бейс, это смысле именно про какое-то вычисляемое свойство или стоит, какое-то ко которому подляется, можно сделать, действие или нет. Или как? Ну, я просто почему? Я подумал, у меня сложилась типичная картинка там, как в каких-нибудь облаках типа там, аВС или Google облака. У тебя на любой ресурс обычно есть роли, какой-нибудь там в Google не знаю, там BigQuery о унир, какой-нибудь.

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

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

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

Вот это так скажем это обязательно извини на Наташа. Это для тебя вот это про то, как занзебар в опу вставь нарезку в начале выпуска были ладно, Наташа, тебя было на опу хорошо. Что такое опа? опа это опа подвеси agent. Это такой, сейчас как вы попросили. топов mind state of the art лучше в мире опынсорстная система для описания политика. через опа можно сделать и туда как Хоть к микроссервису, хоть к нвой, хоть к кубу, хоть на уровне ML2. Очень интересная штука. И у опы есть свой язык.

Изык называется рейго, пишется рейго, R-I-D-O. Читается по их мнению рейго. Есть опция, что это такой стандаловым дайман. Есть опция, что это либо, например, для Голанга есть СДК, на которой можно подключить микроссервис. И, по сути, это на этом декларативном языке рейго. Писываешь политики доступа, они могут быть на основании, рейноснования от рябутов, на основании комбинации, с какой-нибудь логикой, прикольно декларативная штука. Буду делать петпроекция в стализации, какой-нибудь сложный.

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

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

Блин, звучит очень прикольный, я потом обязательно после выпуска пойду, посмотрю ссылочки, прямо интересно к этому выглядит. Хорошо. Окей, про протоколы и про модели мы немного поговорили, а теперь давай прям вот такую прям совсем, совсем прикладную штуку. Вот представь, что наш слушатель приходит работать там, тех летом в какой-нибудь не знаю, продуктовую компанию, условные бобито и начинаю делать там новый marketplace.

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

Поэтому я не вижу ничего плохого в том, чтобы использовать встроен в фрэмворг, механика, афтонтификации, авторизации буквально, а то спринк секьюлите, ты подключаешь парочку гинов, Господи, давненькая на Джайвине кодел. Подожди, на Джайве, спринк только с котленом, ну вот мы тут серьезные люди собрались, какая Джава, все, давай, на котлене. И в курокотлен в сердечке, котлен ванглав. Котлен сердечки Джава в продакшине. Ну тоже факт, мне нужно было сделать.

На самом деле, с 17 года я кодел на котлене. В 22-м году я перешел в Вита, и здесь котленом обилке, Голанк на Бакенде, но в коридоре я всем говорю, что котлен – это лучший язык для боканда. Это мы любим. Да, это выпуск не мог стать еще лучше, только что стал. Это я не сейчас придумал, ребята разработчики могут подтвердить. Итак, о чем речь? Берешь спринк, берешь бины яму, он короче все конфигурлежь, берешь хейбер-нэйт, не строчки, не пишешь почти.

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

Я так чему можно использовать то, что встроено в ваш frame work, то есть спринк скилють, ларабель, вот intcation, ларабел, наверное, так правильнее, что ребята меня потом загрозут. Все сам. IFR не работал, ретурный лэр. Нет, ничего такого в Голанге, поэтому ребята, давайте... Ты в Голанге в целом ничего нет. Давай в планете тебе. Просто в Голанге все как бы явно. Все явно, и ты все контролируешь. Все хорошо.

Поэтому там есть какие-то супернеск уровня в этой штуке, но по сути ты контролируешь все сам, пишешь код весь сам, извините. Я не могу советовать использовать сторонние правой драйлотнификации. Есть вот OutZero, есть Holi, и не могу советовать ровно, потому что причине, что это vendor. И, во-первых, оно платное. То есть, если у вас в день 10.000 пользователей, на вашем сервисе это вы будете платить 1000 баксов. Ну, реально, это, ну окей, не 1000, там 850 по-моему, не принципиально.

То есть это, ну, тупо денег стоит, разработать даже на раннем этапе, проще самим. К тому же, это вот зарубежный вендер, который может что-то нехорошее сделать с вашим сервисом. Например, сказать, до свидания. Мы больше вас не обслуживаем вместе со всеми вашими пользователями. Вы идете куда-нибудь подальше? Можно использовать CakeLow, он опенсорственный, можно сделать его, то есть можно поднять self-hosted, для внутренних пользователей нормально.

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

Мы сейчас начали с ротнотефикацией. Если вам надо будет потом колбасить какие-нибудь сложные, там логические цепочки, как пользователи, что-то разрешитель не разрешить. И вы захотите обновлять эти правила, ещё как-нибудь в рантайме без ресторт-всервисов, то вот можно опа. Слушай, а насколько во фреймворках популярных поддерживают все аутентификации с пользованием вот те дополнительных факторов, которые мы перечислиали, там веба, усмодной или ватапешке? Очень хороший вопрос.

Я слышал, что в исполнях секиулятии есть такие опции. Но скорее всего придётся сильно много разрабатывать уже кастомного. Скорее всего, придётся делать интеграцию, ну с кидем не будет самая с правойдером. Нет, ну у тебя будет наверняка какой-то СДК. Это правойдера, которая отправила эта самая ски. Ты наверняка достаточно для какой-то, всё-таки насконсегулишь у себя, но походить придётся. А у меня другое вопрос был, немножко другую сторону.

Понятно, что если мы там говорим только про совсем запуск, чего-то, но вопрос не сразу актуальный, но надо ли сразу на будущее думать про какое-то там супер скейлабилете?

Короче, у меня какой вопрос был, у меня это весь выпуск голая крутится, что как только у тебя в сервисе появляется необходимость проверить пользователь авторизованный или нет, это же получается, что весь трафик, который идёт по всем грубо-гарям микроссерусам, он же сначала должен пройти через один ботлнек авторизации или вот антификации. И получается, что это будет самое-самое-самое-нагруженное место. Вот типа об этом надо заранее как-то думать.

Ну конечно, мы же проговорили как раз про совершенно иди и про Джейсенка-покс. Ну если ты делаешь что-то сразу масштабируемая классная большую, при этом тебе не очень сильно важно отзывать быстро, отзывать сессии, то используясь в отель сразу. И будет тебе счастье, ты можешь на буквально на этом же IPG-TV, ты можешь проверить валидность токину, достать из него из токин этот user ID и дальше его использовать в микроссервисе. Ну то есть подставить его куда-то взаголовки. Вот здесь такое решение.

Типа, если ваш фермер ворка с коробки предлагает совершенно иди, у вас не планируется каких-нибудь миллионов запросов в минуту. И вам в общем-то пофиг ты используете. У него есть плюсы, быстрый водзов сессии, более безопасно. Ну и потом, если сконпрометируют ЖВТ, там же куча информации внутри в Пылоде. И это значит, что тебе нужно каждый раз думать, если ты не можешь его использовать так же, как сессию, ты не можешь у него положить что-то, что ты не можешь отдать на клиент просто так.

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

Что нам как владельцем сервиса с этим делать? Плакать. Ну для начала, давай, до того как утекла, что нужно делать. Давай об этом поговорим. До того как утекла, но хранить пароль в виде не обратимого ха-ша из которого нельзя пароль восстановить. Когда ты этот хэш реализуешь, добавлять к паролю некую случайную родомную соль, я тут недавно еще знал, что есть перец, соль перец, куки сбискиц.

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

И получается как это, ахап-катров, у полфготов. Потом нужно, наверное, еще рассказать про то, что алгоритм хэширование должно быть какой-то хороший. То есть МД5 плохо, шо один тоже плохо. Базова даже не потому, что там коллизия, а потому что хэш короткий и быстро считается, то есть они были разработаны для быстрого хэшеживания, для того чтобы взять слепок файла и не сравнить насколько целый файл после передачи.

Они не более предназначены для того, чтобы обеспечивать какой-то крептостоикость для паролий. И вот именно скорость работы МД5 и шо один позволило составить так называемые радужные таблицы, в которых есть вот соответствия хэшпород для куча-куча разных пароль. Поэтому, если базовывать и клави использовали МД5 без соды, то бета считает, что пароли в открытом виде слита плохо.

Поэтому совет в провете, какую способ хэширование использовать, если это что-то, что раньше считало безопасным, и сейчас не очень, то можно прямо поверхно вернуть какой-то современный хороший безопасный способ билет. И вот у вас сейчас допустим МД5 или шо один билет. Прям поверх фигачите бакрипт, там 10 раундов и сохраняете в базе. Кстати, внезапно бакрипт уже тоже как бы не топов Майнд, по версии у вас он вегася.

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

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

Ну и еще лучше не использовать пароль, не хранить парузы использовать в Apple integration. Это было бы идеально. А еще до того, как у вас уйти клаба за парули, нужно принуждать своих пользователей использовать туфы. Ещё один вопрос. Тот вопрос, который ты его разодавал, где тот баланс заставляет пользователей использовать туфы, не заставляет вот заставлять. Почему? Потому что ты хочешь свою же попу уберечь от того, что у тебя у текла база парули и за это всё сломалось. Так, ладно.

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

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

Скорее всего, он понадобится. Но это прямо не хорошо. Вот потом, что нужно разобраться с последствиями, разгрести все это. Вы забновить работу сервис, опустить хороших пользователей. Пробестить, наверное, разспективу. Почему так произошло? И сделать так, чтобы в следующий раз это не произошло. А ещё можно... Я когда готовился к этому вопросу, я прочитал интересную статейку гайд для бизнеса от Федеральной торговой полата США.

Из них прям есть, у них есть страничка, где они пишут, что вам нужно делать, если у вас уйтик ты пороля. Вот, наверное, это ссылочку тоже приклеит он. Лучше не уйтикайте пороли. Пороли не уйтикайте, пожалуйста. Окей, это лучшая рекомендация, которая можно было дать. И последний вопрос. А что вообще стоит почитать и посмотреть тем, кому стало очень интересно, кто не знает, работает со вторизацией или аутентификацией. Хочет побольше закопаться в доме. Я все-таки мытрекомендации.

Я не знаю, кто там. Томми, которые или по теме или что-нибудь ещё. У вас пчет-шит. И все статейки у вас про авторизацию, аутентификацию. Как пентезть, эти авторизацию, аутентификацию. Мне кажется, что это прям хорошая кладь, и знаний потом. Вот у Ауус поиграться с песочницей, посмотреть на разные флоу, посмотреть на секвансы диаграмма, как это работает. Кочетать там же у вас про алгоритмах и ширование. Очень занимательная чтива. Вот как-то так. То есть какую-то прям к мигу про авторизацию.

Я сейчас не посоветую. Окей. Но учитывая, что мы спокойно наговорили выпуске 2 сплое в начице про авторизацию. И там ещё есть много тема, которых можно поговорить. Я советую никит подумать. Подумай, подумай, может быть, когда-нибудь это том из для араиля напишешь ты. О, нет. То, что я смазванец. И там уже точно меня раскрыли в комментариях. Я уверен, поэтому нет. Я не могу себе этого подводить. Но спасибо. И на этом пора подводить черту этому выпуску.

Выпуск получилось, мы уже, во время переведлений, обсудили, что прям, короче, вот ровно, ровно то, что я от выпуска про авторизацию ожидал. Теперь каждый, кто мне будет говорить, что пилить свой пет-проект, или вообще, заик, не отца, где имать про авторизацию, вы договорились, дружище, короче, иди, качай вот этот выпуск подлодки. Там Никита, из авита, всё прям, разложил идеально.

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

Вебаус – это наша светлая, беспарольная будущее, точка сингулярности, мир, без пароля, и короче, всё когда-нибудь станет хорошо. Поговорили про то, какие из этих факторов, каких случаях лучше использовать. Дальше копнули немного в техническую реализацию, поговорили про Сэшена-Идии, про ДжВТ, про то, как работает под капотом OAUS, какие модели авторизации бывают, и как и из них вы можете использовать, когда будете реализовать свой продукт.

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

Поэтому Никита, спасибо тебя огромное за то, что пришел к нам, и не просто рассказал там свой доклад, который у тебя очень классный, был выложен где-то на ютубе, и ссылку на него обязательно приложили, а намного подробнее закупался в тему. Короче, было очень кайфолосто бы поговорить. Спасибо, что позвали. И я бы тесли вот одно конкретное мысли подытожить. Я бы сказал, что безопасность, это всегда про баланс, сколько должен заплатить ломышленник, чтобы получить доступ к аккаунту.

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

Может быть на самом деле стандартная формочка логин-паруль вам подойдет. Поэтому совершенно не обязательно тратить большие ресурсы на то, чтобы разработать самую безопасную мили в стране аутентификации. Это всегда про баланс безопасности, денег, которые будет стоить в злом. И удобство пользоваться. Спасибо. Ты подвел черту гораздо лучше, чем это сделала. Я мне мыслючу понравилась. Женя? И... Да. Да, Игорь. Давай. А может быть я вопрос? Погнали.

А что тебе нравится больше, чем уровень безопасности в этих наших айтишечных сервисах? В 2004 году такой высокий, что без доступа к твоим девайсам никто не может зайти. Не в твоей телеграм, не в твоей банке, не в твоей телефон. Вообще ничего не могут сделать. Никто включая даже тебя самого. Больше этого, дорогие друзья, мне нравится переставлять восемь семкартов в своем телефоне. Пытай понять, это какой из них придет или не придет.

СМС, а еще больше мне нравится, когда вы вот если дослушали до этой части, нажали паузу и даже не дослушивайте, что я говорю. Пошли, я не знаю, в своё рабочие чат, например, да, давайте сегодня по рабочей чатам поговорим. Вы пошли в своё рабочий чат, в слак открыли, зашли в дженерал, где сидят все, и скидываете ссылку на этот выпуск подлотки и пишите, что эти почуваки смотрите, как надо делать авторизацию, а не то, что у нас.

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

Вот, поэтому мне очень нравится, когда вы так делаете, что мне очень нравится, когда вы твитет и ретвитите нас, когда вы подписывайтесь на наш телеграм-канальчик, в телеге, где ещё могу быть телеграм-канальчики. Потому что там мы периодически собираем вопросы к следующим выпускам и вашинпут здесь реально лажен.

И всё, наверное, в целом, больше мне в этой жизни... В чат-то, в чат-то, залитайте, накидывать в feedback, если вдруг что-то сказали не так, обязательно приходите и накидайте нам по нам, потому что мы и любим, поспорите. Да, обязательно расскажите, какие факторы мы забыли, и где, короче, наврали, почему мы поролись закопали, а пороли надо откапывать, особенно на YouTube-чик приходите, там, рассказывайте. Вот, короче, на этом, наверное, всё, всем спасибо и всем пока. Пока-пока.

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

This transcript was generated by Metacast using AI and may contain inaccuracies. Learn more about transcripts.