Разработка системы аутентификации между клиентом, сервером и базой данных CouchDB

Question 1

Я создаю саморазмещаемое приложение, которое полагается на CouchDB для хранения своих данных. Клиент (React) может получить доступ к базе данных, которая проксируется сервером Express по адресу myapp.com/database. Сервер также должен иметь доступ к базе данных. Вот что я могу придумать для первого процесса запуска:

Создать базы данных
Сгенерировать случайный секрет JWT и сохранить его где-то
Создать функции валидаторов для данных и разрешений
Закончить админскую партию, создав учетную запись администратора (учетные данные сгенерированы случайным образом и сохранены где-то с секретом)

Когда приложение запускается:

Удалить из _users всех end_user
Сгенерировать UUID экземпляра и сохранить его в памяти.

Процесс регистрации пользователя (который может произойти только один или два раза на сервере):

На клиенте отправить запрос PUT /api/users с именем пользователя и паролем
При получении этого запроса сервер генерирует безопасный хэш и соль, используя password-hash-and-salt, и затем сохраняет их в app_users (коллекция, доступная только пользователю-администратору – контроль через приложение на Node)

Базовый процесс входа

На клиенте отправить запрос PUT /api/sessions
На сервере, получив запрос, создать нового _users с сгенерированным случайным паролем с ролью end_user и в качестве _id users/:uid/:username (где uid – это UUID, сгенерированный при запуске сервера)
Сохранить сгенерированный пароль в памяти
Всё ещё на сервере, подписать JWT на 1 неделю, который включает имя пользователя и ID экземпляра, и вернуть его клиенту
Поставить таймаут на 1 неделю на удаление созданного _user.

Основные операции с базой данных:

На клиенте отправить запрос к /database/posts (например), с токеном сессии в заголовках
На сервере перехватить запрос, прочитать заголовок сессии, проверить его и затем получить базу данных, сохраненную в (3) процесса входа. Заменить заголовок Авторизации на закодированный в Base64 password:username.
Если у пользователя нет действительного токена, не проксировать, а вернуть 401.

Этот процесс позволяет сделать несколько вещей:

Убедиться, что клиент никогда не знает ни одного пароля базы данных
Клиент CouchDB будет отправлять в заголовке кодировку Base64 имени пользователя/пароля. Это избегает отправки пароля/имени пользователя в каждом запросе и, таким образом, уменьшает потенциальную поверхность атаки.
Это позволяет создавать настраиваемые политики сессий, такие как истечение через 1 неделю или, возможно, правила для паролей (например, минимальная энтропия)
Клиенту не нужно долго хранить пароль в памяти.

Насколько безопасным был бы этот поток аутентификации?

Question 2

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

Первое решение этой проблемы – обеспечить использование TLS с защищенным шифром. Шифрование SSL/TLS теперь поддерживается с версии CouchDB 3.0. Гораздо лучше избавиться от небезопасной аутентификации через URI Basic HTTP, которую CouchDB использовал по умолчанию (http://user:[email protected]).

Разработка системы аутентификации между клиентом, сервером и базой данных CouchDB

Вопрос или проблема

Ответ или решение

1. Начальная настройка

Создание баз данных:

Генерация секрета JWT:

Валидаторы для данных и разрешений:

Создание учетной записи администратора:

2. Запуск приложения:

3. Процесс регистрации пользователя:

4. Процесс входа в систему:

5. Основные операции с базой данных:

Дополнительные улучшения безопасности:

Заключение