Аутентификация маркера остатка с HTTP-заголовком

Это существующая система с экраном входа в систему, теперь я предоставляю некоторые услуги в качестве службы REST. Я создаю систему входа в систему аутентификации для этой службы Rest (jersey). Пользователь отправляет имя пользователя-пароль, затем сервер возвращает токен, рассчитанный как:

sha1(username+password+currenttime(or any random number))

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

Учитывая, что HTTPS будет использоваться несколько вопросов;

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

другое дело, для первого запроса, поскольку это существующая система, у меня нет пользовательских паролей в моей БД, но сохраняйте их соленую хэшированную версию. Который, я думаю, небезопасно, чтобы дать всем клиентам этот соленный алгоритм, чтобы отправить мне хэш их паролей, поэтому я сравниваю хеши, но не пароли. делает это смысл =

Ответ 1

1/2- Я бы предложил POSTing имя пользователя/пароль для сервера, который затем может вернуть токен в теле. Для меня имеет смысл: вы на самом деле не храните много на сервере, поэтому PUT будет неправильным, а параметр запроса не имеет смысла. Предполагаемые заголовки должны быть несколько согласованными между запросами, поэтому они также не имеют смысла. Когда вы действительно обмениваетесь использованием токена, не стесняйтесь использовать параметр запроса или заголовок. Не имеет значения.

3- Я бы выбрал несколько более длинный алгоритм хэширования (sha256?)

Ответ 2

Я обычно передавал токен в HTTP-заголовке.
Если вы используете POST или PUT, это не имеет значения.
Что-то еще, что я хотел бы предложить, чтобы предотвратить атаки типа типа воспроизведения, было бы включать в себя каждый раз запрос POST. Затем сервер будет отслеживать последнее использованное nonce и предотвращать выполнение любых запросов, которые использовали ранее использованный nonce.