Зачем 2FA в SaaS?

Двухфакторная аутентификация защищает учетные записи пользователей от компрометации паролей: украденный пароль без второго фактора бесполезен. Для SaaS это снижает риск утечек данных, повышает доверие клиентов и уменьшает объем инцидентов безопасности, требующих ручного расследования. Практическая польза: TOTP (Time-based One-Time Password) легко интегрируется на стороне сервера и клиента, имеет низкую стоимость внедрения и совместим с существующими авторизаторами (Google Authenticator, Authy, Microsoft Authenticator).

Что с recovery codes?

Команда go run ./cmd/gencodes -count 10 > recovery.txt Пояснение Recovery codes — резервные одноразовые строки (обычно 8–12 символов), которые пользователь сохраняет для восстановления доступа, если потерял устройство. Генерируйте 8–12 кодов длиной 8–12 символов, храните их хешированными в базе (bcrypt/SHA256+pepper) и помечайте как использованные при применении. Показ конкретных recovery кодов выдавайте только один раз при создании и предлагайте пользователю скачать их как зашифрованный файл или сохранить в менеджере паролей. package main import ( "crypto/rand" "encoding/hex" "fmt" ) func genCode() string { b := make([]byte, 6) // 6 байт -> 12 hex chars rand.Read(b) return hex.EncodeToString(b) } func main() { for i := 0; i < 10; i++ { fmt.Println(genCode()) } } Ожидаемый вывод 9f2b1c3d4a5e bfa12c34d5e6 ... Типичная ошибка и фикс panic: crypto/rand: read error Fix: проверьте окружение CI и контейнеры на предмет доступности криптографического энтропийного источника. Для...

Команда go run ./cmd/webauthn-demo Пояснение WebAuthn (FIDO2) предоставляет аутентификацию без пароля с помощью ключей/биометрии. Это более сильный метод, чем TOTP, но сложнее по UX и поддержке устройств. Для SaaS целесообразно предлагать WebAuthn как опцию наряду с TOTP: TOTP для мобильных аутентификаторов и WebAuthn для аппаратных ключей и встроенных биометрических решений. В Go используйте библиотеку github.com/duo-labs/webauthn. WebAuthn требует HTTPS, корректного хранения credential ID и public key, а также защита от replay-атак. // упрощённый flow 1. Регистрация: Generate challenge -> send to client -> client registers -> сохраняем credentialID + publicKey 2. Аутентификация: Generate challenge -> client подписывает -> Verify with stored publicKey Ожидаемый вывод Server listening on https://localhost:8443 Registration OK Authentication OK Типичная ошибка и фикс error: invalid signature Fix: проверьте, что clientData.challenge совпадает с серверным challenge и что publicKey...

как обеспечить синхронизацию времени для TOTP?

Синхронизация времени критична для TOTP: коды зависят от времени сервера. Используйте NTP (chrony или systemd-timesyncd) и мониторьте offset. На большинстве Linux-серверов запускайте timedatectl status и проверяйте, что System clock synchronized: yes. Для контейнерных сред убедитесь, что хост-система синхронизирована, так как контейнеры наследуют системное время. В сложных сетевых окружениях учитывайте окно ±1 шага (30 секунд), но не расширяйте окно слишком сильно — это уменьшит безопасность.

что делать при компрометации totp_secret?

Если секрет скомпрометирован, немедленно инвалируйте его: пометьте аккаунт как требующий повторного включения 2FA, сгенерируйте новый секрет и выведите пользователю процесс перенастройки (QR + новый seed). Проводите инцидент-репорт и, если возможно, уведомляйте пользователя. Для предотвращения последующих атак используйте ротацию ключей KMS и контроль доступа по IAM, чтобы минимизировать людей/сервисов, имеющих доступ к дешифровке секретов.

почему хранить recovery codes хешированными?

Recovery codes выполняют функцию второго фактора на случай потери устройства и потому должны храниться как одноразовые секреты: хранение в открытом виде рисковано. Хеширование (bcrypt или SHA256 + salt/pepper) позволяет проверить введённый код без хранения его в открытом виде. При использовании bcrypt храните также метаданные использования (timestamp, ip) и помечайте код как использованный при применении.

где логировать события 2FA и какие метрики собирать?

Логируйте включение/выключение 2FA, неудачные попытки валидации, использование recovery codes и события ротации секретов. Из метрик собирайте: rate попыток валидации по юзеру и IP, долю пользователей с включённой 2FA, время активации 2FA после регистрации. Экспортируйте эти метрики в Prometheus и настраивайте оповещения для аномалий: всплески неудачных валидаций или рост использования recovery codes указывают на атаки или проблемы UX.

2FA в SaaS на Go: TOTP с нуля

go run ./cmd/genseed

package main

import (
	"crypto/rand"
	"encoding/base32"
	"fmt"
)

func main() {
	b := make([]byte, 20) // 20 байт ~ 160 бит
	_, err := rand.Read(b)
	if err != nil {
		panic(err)
	}
	enc := base32.StdEncoding.WithPadding(base32.NoPadding)
	seed := enc.EncodeToString(b)
	fmt.Println(seed)
}

JBSWY3DPEHPK3PXPB4Q6Y5R2LQ

panic: crypto/rand: read error

Fix: проверьте доступность /dev/urandom в контейнере или среде CI. В Dockerfile используйте базовый образ с поддержкой криптографических источников, например golang:1.22, и не отключайте системные устройства.

go run ./cmd/genqr -user alice@example.com -issuer "Acme SaaS" -secret JBSWY3DPEHPK3PXPB4Q6Y5R2LQ > qr.svg

package main

import (
	"flag"
	"fmt"
	"net/url"
	"os"

	qrcode "github.com/skip2/go-qrcode"
)

func main() {
	user := flag.String("user", "user@example.com", "account name")
	issuer := flag.String("issuer", "Acme SaaS", "issuer")
	secret := flag.String("secret", "", "base32 secret")
	flag.Parse()
	if *secret == "" {
		fmt.Fprintln(os.Stderr, "secret required")
		os.Exit(2)
	}
	u := url.URL{
		Scheme: "otpauth",
		Host:   "totp",
		Path:   fmt.Sprintf("/%s:%s", url.PathEscape(*issuer), url.PathEscape(*user)),
	}
	q := u.Query()
	q.Set("secret", *secret)
	q.Set("issuer", *issuer)
	q.Set("algorithm", "SHA1")
	q.Set("digits", "6")
	q.Set("period", "30")
	u.RawQuery = q.Encode()
	svg, err := qrcode.New(u.String(), qrcode.Medium)
	if err != nil {
		panic(err)
	}
	fmt.Println(svg.ToString(false))
}

<svg xmlns="http://www.w3.org/2000/svg" width="256" height="256">...</svg>

panic: token too long

Fix: проверьте правильность кодирования Base32 и отсутствие padding. Используйте base32.StdEncoding.WithPadding(base32.NoPadding) при генерации seed, и не добавляйте пробелы в secret при передаче в флаг.

go run ./cmd/validate -secret JBSWY3DPEHPK3PXPB4Q6Y5R2LQ -code 123456

package main

import (
	"flag"
	"fmt"

	"github.com/pquerna/otp/totp"
)

func main() {
	secret := flag.String("secret", "", "base32 secret")
	code := flag.String("code", "", "6-digit code")
	flag.Parse()
	valid := totp.Validate(*code, *secret)
	if valid {
		fmt.Println("OK")
	} else {
		fmt.Println("INVALID")
	}
}

OK

INVALID

Fix 1: Убедитесь, что секрет совпадает с тем, что в приложении пользователя (без пробелов и в верхнем регистре).
Fix 2: Если валидность частично нестабильна, проверьте синхронизацию времени на сервере (NTP). На Linux запустите timedatectl status и проверьте offset; исправьте через systemd-timesyncd или chrony.

psql -c "ALTER TABLE users ADD COLUMN totp_secret bytea;"

// псевдокод записи
ciphertext, err := EncryptWithKMS(ctx, plaintextSecret)
if err != nil { return err }
db.Exec("UPDATE users SET totp_secret = $1 WHERE id = $2", ciphertext, userID)

// считывание
ciphertext := ...
secret, err := DecryptWithKMS(ctx, ciphertext)

ALTER TABLE

и при вставке/обновлении — количество изменённых строк

ERROR: column "totp_secret" of relation "users" already exists

Fix: проверьте текущую схему; при миграциях используйте idempotent-скрипты или migration tool (например, golang-migrate) с версионированием. Если KMS не настроен — приложение не сможет дешифровать секреты; держите fallback для dev окружения отдельно, не смешивайте с prod-ключами.

gh workflow run ci.yml --ref main

# пример job snippet для GitHub Actions
jobs:
  test:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v4
      - name: Run unit tests
        run: go test ./... -v
        env:
          KMS_TEST_KEY: ${{ secrets.KMS_TEST_KEY }}

ok	github.com/yourorg/yourrepo	0.24s

и успешный прогон workflow в GitHub Actions с green status

error: missing required secret KMS_TEST_KEY

Fix: добавьте секрет в Settings → Secrets для репозитория или используйте привязанный к CI temporary credentials. Для локальной разработки используйте отдельный dev KMS, не храните prod-ключи в CI.

go run ./cmd/gencodes -count 10 > recovery.txt

package main

import (
	"crypto/rand"
	"encoding/hex"
	"fmt"
)

func genCode() string {
	b := make([]byte, 6) // 6 байт -> 12 hex chars
	rand.Read(b)
	return hex.EncodeToString(b)
}

func main() {
	for i := 0; i < 10; i++ {
		fmt.Println(genCode())
	}
}

9f2b1c3d4a5e
bfa12c34d5e6
...

panic: crypto/rand: read error

Fix: проверьте окружение CI и контейнеры на предмет доступности криптографического энтропийного источника. Для long-running servers убедитесь в правильной настройке контейнерного рантайма, чтобы /dev/urandom был доступен.

go run ./cmd/webauthn-demo

// упрощённый flow
1. Регистрация: Generate challenge -> send to client -> client registers -> сохраняем credentialID + publicKey
2. Аутентификация: Generate challenge -> client подписывает -> Verify with stored publicKey

Server listening on https://localhost:8443
Registration OK
Authentication OK

error: invalid signature

Fix: проверьте, что clientData.challenge совпадает с серверным challenge и что publicKey сохранён в правильном формате. Убедитесь, что сервер работает по HTTPS с корректным сертификатом (self-signed для dev — добавить исключение в браузере).

2FA в SaaS на Go: TOTP с нуля | KtoHto

2FA в SaaS на Go: TOTP с нуля

Комментарии (0)

Что вы изучите

Требования

Зачем 2FA в SaaS?

Шаг 1: генерация seed

Шаг 2: QR код

Шаг 3: валидация TOTP

Шаг 4: хранение и ротация seed

Шаг 5: мониторинг и CI интеграция