Второй фактор

Приложение-аутентификатор

Сотрудник подключает приложение сам на /totp: вводит логин и пароль, сканирует QR-код, вводит код из приложения. Дальше приложение предлагается как основной способ подтверждения — оно не стоит денег, не зависит от оператора связи и не уязвимо к подмене SIM.

Три решения, каждое закрывает конкретную дыру:

• Секрет попадает в хранилище только после ввода кода. Иначе прерванная регистрация оставила бы учётную запись с фактором, которого нет ни в одном приложении, — человек оказался бы заблокирован ровно там, где портал должен помогать.
• Замена уже подключённого приложения требует кода из прежнего. Без этого укравший пароль просто привязал бы своё устройство и обошёл второй фактор целиком.
• Первое подключение — тоже не по одному паролю, если есть чем подтвердить: у сотрудника с телефоном в каталоге запрашивается код из СМС. Без телефона остаётся пароль — это принятый риск начальной регистрации, и такие подключения отмечены в журнале (confirmed_by: password_only).
• QR рисуется на сервере и встраивается в страницу. Ни внешних запросов, ни ссылки с секретом в адресной строке, которая осела бы в журналах прокси и истории браузера.

Ключ показывается и текстом, группами по четыре символа: камеры может не быть, а подключить приложение всё равно нужно.

Потеря устройства. Если телефон утерян, замена подтверждается запасным способом — тем же, которым сотрудник восстанавливает пароль. Когда запасного способа нет (телефон не заполнен в каталоге), привязку снимает администратор в интерфейсе управления — со вторым фактором и записью в журнал. Для инсталляций без интерфейса администратора есть команда на узле:

sspr totp list                          # кто подключил приложение
systemctl stop sspr
sspr totp revoke -user ivanov -reason "утерян телефон, заявка 1234"
systemctl start sspr

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

Ключ безопасности (FIDO2 / WebAuthn)

Рутокен, JaCarta, YubiKey, отпечаток или PIN устройства — как второй фактор. В закрытом контуре это предпочтительнее push-уведомлений: ключ не требует ни интернета, ни телефона, ни оператора, и его нельзя перехватить. Реализована ровно нужная часть стандарта, без внешних библиотек: регистрация с аттестацией none (доверие к производителю ключа продукт не проверяет) и проверка подписи ES256/RS256 средствами стандартной библиотеки Go; разбор CBOR — свой, минимальный, под фаззингом.

Сотрудник подключает ключ сам (/fido): пароль, подтверждение имеющимся способом, касание ключа. Ключей может быть несколько; администратор видит их и удаляет при утере. Идентификатор стороны и адрес страницы берутся из web.public_url — браузер не примет IP-адрес, порталу нужно доменное имя.

Код на почту

Третий фактор после приложения и СМС — код письмом на адрес из каталога, через SMTP заказчика (smtp: в конфигурации; та же почта — для напоминаний). В закрытом контуре корпоративная почта есть у всех, а СМС-шлюза может не быть. Для восстановления забытого пароля канал выключен по умолчанию (allow_for_reset): почта обычно открывается тем же паролем, который восстанавливают, — включать это должен заказчик осознанно.