Ваш разбор, почему Max не станет WeChat, - это редкий случай, когда каждый тезис опирается на логику, опыт и реальные цифры. Конкуренция, R&D, эффект масштаба и самодостаточность китайского интернета - всё на месте. Вы правы: нельзя "назначить" победителя в цифровой гонке. Назначение вместо отбора - всегда утопия. Max, надутый искусственным ростом через госструктуры и лишённый рыночного фидбэка, - это не платформа. Это цифровая имитация.
По поводу зумеров и миллениалов, живущих в телефонах, не соглашусь. Интернет - не телевизор 2.0, а пространство для работы, учёбы, творчества. Но если ты не звезда TikTok или Instagram - лимит нужен. Час-два в день на цифровую прокрастинацию - максимум. Иначе это не жизнь в интернете, а прозябание в иллюзии занятости.
Мой день - это десятки виртуальных машин, несколько рабочих станций на растоянии вытянутой руки, серверы по всему миру. А все соцсети и мессенджеры - на отдельной маленькой ВМ, которая почти всегда выключена. Почему? Потому что в России системный провал - в управлении временем. На Западе вокалисты пашут в студиях, программисты коммитят в GitHub, дизайнеры шлифуют прототипы, а не презентации. У нас же, к сожалению, часто тратят часы на скроллинг и "движуху", не создавая ничего.
Личная дисциплина определяет системный результат. Если команда Max тратит больше времени на PR, чем на архитектуру и код - в итоге получим красивую обёртку без ядра. Без боли роста и конкуренции не бывает зрелого продукта. Max - это симулякр. А симулякры не выигрывают. Они лишь имитируют прогресс, пока настоящие системы меняют правила игры.
Согласен - Nikto это скорее динозавр в мире веб-сканеров. Он остался в BRS как "костыль по дружбе" - для случаев, когда надо быстро пробежаться по олдскульным админкам без JS и CDN. На замену уже идёт связка: BRS-XSS + Nuclei + ML-пайплайн, которые покрывают всё от DOM XSS до WAF-обходов. Так что Nikto у нас на пенсии - просто иногда зовём его на разогрев 😄
Пользователь видит только поле для логина и пароля.
После отправки формы запрос уходит на сервер Matrix (Synapse), где middleware берёт на себя обработку.
Middleware (на Deno):
Проверяет логин/пароль через Synapse.
Если 2FA включена, middleware:
CB2FA: Отправляет запрос в Matrix-комнату (например, "Подтвердить вход для @user:example.com? y/n"). Ждёт ответа от доверенных лиц.
Если 2FA не пройдена, middleware возвращает Synapse ошибку "Invalid credentials", которую клиент показывает как "Ваши данные неверны".
Backend (Matrix-комната и приложение):
CB2FA: Бот в комнате собирает голоса (y/n) и передаёт результат middleware. Всё происходит в зашифрованной комнате с E2EE.
Обработка ошибок:
Если пароль неверный, CB2FA отклоняет запрос, пользователь видит одну и ту же ошибку: "Ваши данные неверны".
Это делает невозможным для атакующего понять, на каком этапе он провалился.
Примерный флоу для пользователя
Сценарий 1: Используешь CB2FA:
Вводишь логин/пароль.
Middleware отправляет запрос в комнату: "Подтвердить @user? y/n".
Доверенные лица отвечают "y", ты получаешь доступ.
Если ответили "n" или никто не ответил, опять же "Ваши данные неверны".
Сценарий 2: Атакующий:
Пробует подобрать логин/пароль.
Даже если угадал, без CB2FA или подтверждения из приложения доступ не получить.
Ошибка всегда одна: "Ваши данные неверны", и он не знает, что не так.
Плюсы этого подхода
Обман атакующего:
Единая ошибка и отсутствие видимого второго фактора делают систему устойчивой к разведке (reconnaissance). Атакующий не знает, что атаковать дальше — пароли, TOTP, или пытаться манипулировать сообществом.
Простота для пользователя:
Нет лишних шагов вроде ввода кодов. CB2FA вообще не требует действий от пользователя.
Высокая безопасность:
Даже если пароль скомпрометирован, без второго фактора доступ невозможен.
По умолчанию доступ к системе разрешает или запрещает администратор. В структурах, где "любой пользователь в чате" может предоставить доступ, такие подходы тоже существуют, но мы говорим о другом аспекте.
Представим, что вы - администратор, а я пытаюсь войти в систему. Пока вы не подтвердите мой доступ, я не смогу войти. По мере роста команды вы можете делегировать мне право подтверждать доступ новым пользователям. Тогда любой, кто хочет присоединиться, должен связаться с вами или со мной для подтверждения - по любому каналу связи: телефону, Telegram, WhatsApp или другим.
Мы говорим о надстройке над стандартной двухфакторной аутентификацией (2FA), которую мы называем Community-Based Two-Factor Authentication (CB2FA). Это не замена классической 2FA (хотя в некоторых случаях может использоваться как единственный механизм, в зависимости от структуры), а дополнительный уровень защиты - последний рубеж. Вы можете продолжать использовать привычные методы аутентификации, но для критически важных систем CB2FA добавляет надежности.
Особенно это актуально для Matrix. В отличие от стандартных решений, где 2FA часто требует интеграции сторонних сервисов, наша надстройка полностью реализована внутри сервера, без внешних зависимостей. Простыми словами: зачем использовать приватность Matrix, если я сам раскрываю связь своего аккаунта с номером телефона или почтой? CB2FA устраняет эту проблему, обеспечивая контроль доступа без компрометации личных данных.
Вы соверешенно правы, и все правильно поняли. При всей моей личной любви к опенсорсу, если кто то то не понял - ну вы меня понимаете, подкачают пусть знания. Ну и естесвенно это не наша реальная комерческая модель которую мы релизуем в своих проектах, а опенсор что бы было легче и понятнее куда двигаться сообществу. Я сегодня или завтра напишу и статью и выложу еще код, я заканчиваю еще несколько серьезных решений которые закроют вообще все проблемы и дырки матрикса. Я вообще очень верю в этот протокол, так как именно как протокол - он практически идеален.
Спасибо, верно подметили! Действительно, в ряде корпоративных решений (Cisco Expressway, Microsoft Teams, Zoom и др.) TURN или аналогичная функциональность уже встроены. В статье акцент был на случаях, когда всё собирается самостоятельно - Matrix, WebRTC, Jitsi и т.п., где выбор стоит напрямую. Но для комплексных VoIP-платформ - этот слой часто уже “вшит” и работает прозрачно для интегратора.
Вы описываете не техническую уязвимость, а социальную модель доверия, которая существует в любой системе восстановления доступа. Ссориться с доверенными лицами — плохая идея не только в CB2FA, но и в жизни.
CB2FA не исключает резервных путей:
можно назначить несколько комнат,
разных участников,
fallback-механизмы (например, временные коды или подключение админа).
Это так же, как с мультисиг-кошельками или DAO-голосованиями: если доверие потеряно — пересобирается структура.
В централизованных системах вы теряете доступ, если у вас нет SMS или почты. В CB2FA вы сами формируете круг доверия. Это гибче.
Если кратко — именно в этом и смысл. Второй канал связи не фиксирован и никому не известен, включая атакующего. Он не прописан в системе, не хранится в базе и не передаётся по сети.
Авторизовать может:
коллега за соседним столом,
жена по звонку,
друг в Telegram,
даже охранник у турникета — если вы так договорились.
CB2FA не навязывает канал, а использует любую доступную вам надёжную коммуникацию вне текущего цифрового контекста. Хотите — используйте Matrix, хотите — Discord, хотите — голосом или жестом.
Система просто ждёт подтверждение из доверенной комнаты. Откуда и как инициируется голос — не важно. Важно то, что вы сами выбираете, кому доверять, и как именно подтверждать вход.
В этом и есть сила: второй фактор полностью отделён от первого и не предсказуем извне.
Даже затрудняюсь что либо ответить) Что можно не так сделать отпраляя в чат Y или N? ) После отправки N - пользователь может повторить запрос повторно, нажмете Y)
Ваш разбор, почему Max не станет WeChat, - это редкий случай, когда каждый тезис опирается на логику, опыт и реальные цифры. Конкуренция, R&D, эффект масштаба и самодостаточность китайского интернета - всё на месте. Вы правы: нельзя "назначить" победителя в цифровой гонке. Назначение вместо отбора - всегда утопия. Max, надутый искусственным ростом через госструктуры и лишённый рыночного фидбэка, - это не платформа. Это цифровая имитация.
По поводу зумеров и миллениалов, живущих в телефонах, не соглашусь. Интернет - не телевизор 2.0, а пространство для работы, учёбы, творчества. Но если ты не звезда TikTok или Instagram - лимит нужен. Час-два в день на цифровую прокрастинацию - максимум. Иначе это не жизнь в интернете, а прозябание в иллюзии занятости.
Мой день - это десятки виртуальных машин, несколько рабочих станций на растоянии вытянутой руки, серверы по всему миру. А все соцсети и мессенджеры - на отдельной маленькой ВМ, которая почти всегда выключена. Почему? Потому что в России системный провал - в управлении временем. На Западе вокалисты пашут в студиях, программисты коммитят в GitHub, дизайнеры шлифуют прототипы, а не презентации. У нас же, к сожалению, часто тратят часы на скроллинг и "движуху", не создавая ничего.
Личная дисциплина определяет системный результат. Если команда Max тратит больше времени на PR, чем на архитектуру и код - в итоге получим красивую обёртку без ядра. Без боли роста и конкуренции не бывает зрелого продукта. Max - это симулякр. А симулякры не выигрывают. Они лишь имитируют прогресс, пока настоящие системы меняют правила игры.
Согласен - Nikto это скорее динозавр в мире веб-сканеров. Он остался в BRS как "костыль по дружбе" - для случаев, когда надо быстро пробежаться по олдскульным админкам без JS и CDN. На замену уже идёт связка:
BRS-XSS+Nuclei+ML-пайплайн, которые покрывают всё от DOM XSS до WAF-обходов. Так что Nikto у нас на пенсии - просто иногда зовём его на разогрев 😄Frontend (Matrix-клиент, например, Element):
Пользователь видит только поле для логина и пароля.
После отправки формы запрос уходит на сервер Matrix (Synapse), где middleware берёт на себя обработку.
Middleware (на Deno):
Проверяет логин/пароль через Synapse.
Если 2FA включена, middleware:
CB2FA: Отправляет запрос в Matrix-комнату (например, "Подтвердить вход для @user:example.com? y/n"). Ждёт ответа от доверенных лиц.
Если 2FA не пройдена, middleware возвращает Synapse ошибку "Invalid credentials", которую клиент показывает как "Ваши данные неверны".
Backend (Matrix-комната и приложение):
CB2FA: Бот в комнате собирает голоса (y/n) и передаёт результат middleware. Всё происходит в зашифрованной комнате с E2EE.
Обработка ошибок:
Если пароль неверный, CB2FA отклоняет запрос, пользователь видит одну и ту же ошибку: "Ваши данные неверны".
Это делает невозможным для атакующего понять, на каком этапе он провалился.
Примерный флоу для пользователя
Сценарий 1: Используешь CB2FA:
Вводишь логин/пароль.
Middleware отправляет запрос в комнату: "Подтвердить @user? y/n".
Доверенные лица отвечают "y", ты получаешь доступ.
Если ответили "n" или никто не ответил, опять же "Ваши данные неверны".
Сценарий 2: Атакующий:
Пробует подобрать логин/пароль.
Даже если угадал, без CB2FA или подтверждения из приложения доступ не получить.
Ошибка всегда одна: "Ваши данные неверны", и он не знает, что не так.
Плюсы этого подхода
Обман атакующего:
Единая ошибка и отсутствие видимого второго фактора делают систему устойчивой к разведке (reconnaissance). Атакующий не знает, что атаковать дальше — пароли, TOTP, или пытаться манипулировать сообществом.
Простота для пользователя:
Нет лишних шагов вроде ввода кодов. CB2FA вообще не требует действий от пользователя.
Высокая безопасность:
Даже если пароль скомпрометирован, без второго фактора доступ невозможен.
Приватность:
Никаких внешних сервисов, всё внутри Matrix.
По умолчанию доступ к системе разрешает или запрещает администратор. В структурах, где "любой пользователь в чате" может предоставить доступ, такие подходы тоже существуют, но мы говорим о другом аспекте.
Представим, что вы - администратор, а я пытаюсь войти в систему. Пока вы не подтвердите мой доступ, я не смогу войти. По мере роста команды вы можете делегировать мне право подтверждать доступ новым пользователям. Тогда любой, кто хочет присоединиться, должен связаться с вами или со мной для подтверждения - по любому каналу связи: телефону, Telegram, WhatsApp или другим.
Мы говорим о надстройке над стандартной двухфакторной аутентификацией (2FA), которую мы называем Community-Based Two-Factor Authentication (CB2FA). Это не замена классической 2FA (хотя в некоторых случаях может использоваться как единственный механизм, в зависимости от структуры), а дополнительный уровень защиты - последний рубеж. Вы можете продолжать использовать привычные методы аутентификации, но для критически важных систем CB2FA добавляет надежности.
Особенно это актуально для Matrix. В отличие от стандартных решений, где 2FA часто требует интеграции сторонних сервисов, наша надстройка полностью реализована внутри сервера, без внешних зависимостей. Простыми словами: зачем использовать приватность Matrix, если я сам раскрываю связь своего аккаунта с номером телефона или почтой? CB2FA устраняет эту проблему, обеспечивая контроль доступа без компрометации личных данных.
Вы соверешенно правы, и все правильно поняли. При всей моей личной любви к опенсорсу, если кто то то не понял - ну вы меня понимаете, подкачают пусть знания. Ну и естесвенно это не наша реальная комерческая модель которую мы релизуем в своих проектах, а опенсор что бы было легче и понятнее куда двигаться сообществу. Я сегодня или завтра напишу и статью и выложу еще код, я заканчиваю еще несколько серьезных решений которые закроют вообще все проблемы и дырки матрикса. Я вообще очень верю в этот протокол, так как именно как протокол - он практически идеален.
Спасибо, верно подметили! Действительно, в ряде корпоративных решений (Cisco Expressway, Microsoft Teams, Zoom и др.) TURN или аналогичная функциональность уже встроены. В статье акцент был на случаях, когда всё собирается самостоятельно - Matrix, WebRTC, Jitsi и т.п., где выбор стоит напрямую. Но для комплексных VoIP-платформ - этот слой часто уже “вшит” и работает прозрачно для интегратора.
Вы описываете не техническую уязвимость, а социальную модель доверия, которая существует в любой системе восстановления доступа.
Ссориться с доверенными лицами — плохая идея не только в CB2FA, но и в жизни.
CB2FA не исключает резервных путей:
можно назначить несколько комнат,
разных участников,
fallback-механизмы (например, временные коды или подключение админа).
Это так же, как с мультисиг-кошельками или DAO-голосованиями: если доверие потеряно — пересобирается структура.
В централизованных системах вы теряете доступ, если у вас нет SMS или почты. В CB2FA вы сами формируете круг доверия. Это гибче.
Вы посмотрели код?
Если кратко — именно в этом и смысл. Второй канал связи не фиксирован и никому не известен, включая атакующего. Он не прописан в системе, не хранится в базе и не передаётся по сети.
Авторизовать может:
коллега за соседним столом,
жена по звонку,
друг в Telegram,
даже охранник у турникета — если вы так договорились.
CB2FA не навязывает канал, а использует любую доступную вам надёжную коммуникацию вне текущего цифрового контекста.
Хотите — используйте Matrix, хотите — Discord, хотите — голосом или жестом.
Система просто ждёт подтверждение из доверенной комнаты. Откуда и как инициируется голос — не важно.
Важно то, что вы сами выбираете, кому доверять, и как именно подтверждать вход.
В этом и есть сила: второй фактор полностью отделён от первого и не предсказуем извне.
Даже затрудняюсь что либо ответить) Что можно не так сделать отпраляя в чат Y или N? ) После отправки N - пользователь может повторить запрос повторно, нажмете Y)
Подправил, опечатка была сорян: https://github.com/EPTLLC/brs
Не судите строго я только начинаю на хабре.