LINUX.ORG.RU

Авторизация с OpenPGP

 , , , ,


0

2

Привет!

Есть идея для сервиса, в котором нужно чтобы контент пользователя шифровался на клиенте, а хранился на сервере. Использовать думаю OpenPGP (gnupg, openpgp.js). Подскажите, пожалуйста, не упускаю ли я из виду что-то очевидное.

Регистрация. Для нового пользователя на его клиентской стороне генерируются публичный ключ, приватный ключ с парольной фразой. Ключи отправляются на сервер, парольная фраза в голове пользователя. Без парольной фразы приватный ключ бесполезен, по этому вместе с публичным может хранится на сервере.

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

Вопрос 1: насколько описанное в предыдущих абзацах правильно? Не упускаю ли что-то очевидное, может какой-то очевидный изъян есть у такого подхода? По-моему в tutanota как-то похожим образом авторизуют пользователей, но могу и ошибаться.

Вопрос 2: как при таком раскладе можно сделать авторизацию для REST API (для сторонних клиент-приложений)? Подпись можно при каждом post-запросе так же проверять, но наверно это будет дорого по ресурсам серверу. При авторизации на сайте подпись-то сервер один раз проверяет за N времени, а тут при каждом запросе придется.

Вопрос 3 (в продолжение 2): если с rest api не выйдет, есть идея сделать websocket api. Клиент на открытии ws подтверждает подписью свою личность и получает token, с этим token только в рамках этого соеденения сервер будет принимать «инструкции от клиента». Есть ли тут вариант как-то вклиниться между клиентом и сервером? Если, допустим, кто-то еще откроет соединение под видом этого же пользователя, можно требовать снова подписью подтвердить личность.

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

★★★

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

Вся затея тогда превращается в тыкву.

как при таком раскладе можно сделать авторизацию для REST API

Выдавать сессионный токен. (И не называй HTTP API RESTом, оно у тебя им не будет, инфа соточка, ты даже не знаешь что это такое и о оригинальной публикации не слышал).

есть идея сделать websocket api

Чтобы усложнить жизнь клиенту, потому что школьник где-то слышал звон.

Но можешь расслабиться, у тебя все-равно ничего не получится, потому что ты бездарь и лентяй. Вместо того чтобы ознакомится с матчастью предметно, ты приполз на уютненький.

anonymous ()

А и совсем забыл.

Для нового пользователя на его клиентской стороне генерируются публичный ключ, приватный ключ с парольной фразой.

Какой дебил это доверит Васяну не понятно. Гикам ничего не мешает шифровать локально и хранить в облаках уже сейчас. Твой сервис не решает проблемы, поэтому не нужен и не заработает.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.