Является ли эта процедура входа на мой сервер rest-api несколько безопасной? - PullRequest
0 голосов
/ 21 февраля 2020

Поскольку это не бюджетный хобби-проект, я не могу позволить себе сертификат. Допустим, https не вариант. Но, по крайней мере, я могу использовать RSA. Несмотря на то, что это хобби-проект, я хочу обеспечить максимально возможную безопасность в отношении паролей, а сейчас я забочусь только о таких важных данных, как пароли.

Логин:

Client -> Server: I want to log in.
Server -> Client: Here is the public key.
Client -> Server: *username and encrypted pw*
Server -> Client: Great. Please create a keypair and send me a public key.
Client -> Server: Here is a public key
Server -> Client: *encrypts session id with the clients public key* Here is your session id!
Client: *decrypts session id with private*
Client: *deletes the keypair*

Ведение буквально все, что требуется для входа в систему:

Client -> Server: I want to send a chat message! *encrypts sessionId with public key*
Server: *decrypts sessionId with private* Ok, your message has been sent!

Или как насчет этого другого подхода?

У нас есть две пары ключей:

key1: The servers main key. Private is on server. The same for everyone.
key2: The session key. Private is on client. Generated on login by client.

Клиент отправляет остальные -запрос с одним аргументом в формате json и содержит каждый необходимый параметр. Зашифровано с использованием: key1

Ответ покоя будет зашифрован с помощью ключа 2.

Было бы это безопасно?

1 Ответ

0 голосов
/ 23 февраля 2020

Поскольку это не бюджетный хобби-проект, я не могу позволить себе сертификат. Давайте просто скажем, что https - это не вариант.

, когда дело доходит до этого - вы можете просто создать свой собственный CA (центр сертификации), которому доверяют в рамках проекта, и вы хороши для go.

Существует также несколько способов получить бесплатный доверенный сертификат (например, Letsencrypt)

Обычная причина невозможности использования TLS - медленное низкоуровневое оборудование (например, Arduino), где асимметрия c операции будут занимать очень много времени (невозможно использовать RSA). Или школьный образовательный проект. В противном случае вы можете пересмотреть.

Будет ли это безопасно?

Short - нет. Долго - зависит - защищен от чего?

Если вы проверяете стандарт TLS , протокол делает много вещей (проверяет доверие к сертификату, создает и подписывает эфемерные пары ключей, согласование ключей сеанса, настройка каналов, ..) и по уважительным причинам. Использование ярлыков заставит ваш протокол использовать разные векторы атаки, которые будут смягчены на каждом шаге или уровне.

Для начала - ваш протокол (первая версия) будет уязвим для атаки MiM (человек посередине). Любой может представить ложный сервер. Используя прямое доверие (фиксированная пара ключей сервера - я полагаю, это другой подход?), Вы смягчаете это, но другие проблемы остаются нерешенными.

Клиент отправляет запрос rest с одним аргументом в формате json и содержит каждый необходимый параметр. Зашифровано с использованием: key1

Теоретически это может работать при передаче правильно зашифрованных сообщений , если все сделано правильно . Вы не указали много подробностей, поэтому мы не можем оценить другие факторы (например, повторную атаку, целостность, ..)

Передача зашифрованных сообщений по незащищенному каналу - это уже рассматривается в сквозном зашифрованном протоколы обмена сообщениями (например, протокол передачи сигналов). Вы можете взглянуть на тезисы / использовать протоколы, чтобы обезопасить себя, если вам действительно нужно пропустить TLS.

...