Если база данных утечёт, именно от алгоритма хеширования паролей будет зависеть, получит ли атакующий рабочие учётные данные за несколько часов или не получит ничего полезного вообще. Разберём, что нужно знать разработчику, чтобы оказаться во втором сценарии.
Первое, что нужно зафиксировать: пароли хешируются, а не шифруются. Это принципиальное различие, которое часто путают.
Самая дорогая ошибка моего B2B SaaS имела ровно одну строчку
```python
# app/config.py
TENANT_ID = "tenant-1"
```Когда у меня был один тенант, всё работало корректно. На втором — половина админ-сущностей (врачи, услуги, прайс-листы) начала пропадать из интерфейса клиента. Не «не сохраняться» — а появляться в БД с чужим tenant_id. Я полтора дня смотрел на эту мистику, прежде чем понял: 30 endpoint’ов берут tenant_id из closure из config, а не из user.tenant_id. Очевидно в ретроспективе. Совершенно невидимо во время первого пилота.
В литературе и самых сложных современных системах есть «лучшие» ответы на многие вопросы. Если вы разрабатываете встроенные приложения, то предлагают использовать STROBE и модный современный криптографический стек для аутентификации полностью из одиночных SHA-3-подобных функций губки. Советуют использовать NOISE для разработки безопасного транспортного протокола с формированием общего ключа аутентификации (AKE). Говоря об AKE, есть около 30 различных парольных AKE на выбор.
Но если вы разработчик, а не криптограф, то не должны делать ничего такого. Следует придерживаться простых и обычных решений, которые легко поддаются анализу — «скучных», как говорят люди из Google TLS.
Читать полностью »
Мы возвращаемся к самому краткому введению в криптографическую теорию от Владимира ivlad Иванова. Это вторая половина лекции — первую часть мы опубликовали несколько дней назад. К ней даже можно присылать пуллреквесты на гитхабе.
Под катом — расшифровка и часть слайдов.