Войти в веб-службу REST

Question

Я пытаюсь разработать свой первый веб-сервис REST, и у меня есть большие сомнения в том, что процесс входа в систему разрешает пользователям выполнять некоторые действия, которые анонимные пользователи не могут сделать. Моя идея:

1. пользователи отправляют на имя пользователя службы и пароль (по HTTPS)
2. проверки службы в базе данных, если они присутствуют
3. , если это представляет сервис генерирует зашифрованный маркер (который содержит время для жизни (например, 10 минут) и идентификатор пользователя) и отправить его пользователю.
4. В запросе каждого пользователя служба проверяет, действителен ли токен : если он действителен, выполните запрос, заново создайте новый токен и отправьте обратно другому пользователю, не разрешающему действие.

Теперь возникает вопрос: «является ли хорошим подходом к обеспечению безопасности?» Если нет, пожалуйста, скажите мне альтернативу?

Большое спасибо!

Answer 1

У меня есть одна проблема с доверием, которое вы положили на токен. Этот токен может быть украден, даже если на нем есть TTL. Пара вещей, которые вы можете сделать, аутентифицировать с каждым запросом или сопоставлять токен с IP и портом (иначе это соединение). Таким образом, его нельзя украсть. Если это становится слишком сложным, просто требуйте учетные данные с каждым запросом.

При аутентификации пользователя обязательно соедините свои пароли int DB. Посмотрите, как правильно хранить пароли в БД.

Не у вас должен быть предоставлен пароль. Вместо этого пароль должен использоваться для шифрования дайджеста.

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

Так что со всем, что было принято во внимание, это то, что я рекомендую.

1. Не пропустите пароль в запросе.
2. Внедрите хэшированный дайджест, который использует сильное шифрование, такое как SHA-256.
3. Чтобы создать хэш хэша дайджест, выполните следующие действия: имя пользователя, pw, некоторые части запроса, если не все, и номер NONCE (номер, используемый один раз).
4. Клиент может генерировать NONCE самостоятельно, если они это делают, он должен основываться на времени, например, на отметке времени, чтобы вы могли проверить, что его недавний NONCE. Или вы можете отправить им NONCE, который вы создаете самостоятельно, в коде ошибки 401 Required Required. Возможно, NONCE может быть токеном из вашего исходного сообщения.
5. Для каждого запроса сервер будет хэшем тот же и убедитесь, что значение дайджест одинаков.

Что вы найдете, так это то, что другие веб-службы следуют чему-то подобному этому, но с разными именами. Точки таковы: не пропускайте пароль в сообщении, используйте дайджест для аутентификации сообщения и пользователя, используйте NONCE, чтобы дайджест не мог быть украден и повторно использован.

Answer 2

Войти в REST веб-службы

Ответ прост, вы не можете сделать такую ​​вещь, потому что REST является лицом без гражданства. REST - это машина для машинного общения, поэтому, если вы не хотите поддерживать сторонних клиентов, вам, скорее всего, не нужен REST. Ofc. вы можете реализовать его для своего собственного клиента ajax, но он не имеет огромных преимуществ в этом случае, особенно не на редко посещаемом сайте.

В этом случае вы должны использовать https и отправлять имя пользователя и пароль с каждым запросом в заголовке. У вас может быть кеш-сервер на стороне пользователя с именем пользователя + пароль -> пользовательские + разрешения, которые могут закрепить это. Это все. Забудьте токен, он нужен только сторонним клиентам.