6 способов: как добавить security для Rest сервиса в Java

[dea]

Еще более безопасным можно сделать этот подход если генерировать пару ключей на клиентской стороне с использование javascript библиотек таких как forge. Такой подход позволяет вообще не пересылать приватный ключ по сети, а сразу генерировать на клиентской стороне, что значительно уменьшает риск скомпрометировать этот ключ.

а по https:// обратиться разве не проще?

[vedenin1980]

Проще, но https (точнее у протоколов, которые он использует, SSL или TLS) есть свои уязвимости, позволяющие совершать на него атаки типа man-in-the-middle. Особенно в случае если используется самоподписанные сертификаты. Подробнее про атаки на SSL или TLS можно посмотреть хотя бы в википедии. В любом случае полезно знать разные варианты реализации безопасности в приложении, поэтому эту статья для меня очень интересно было прочитать, в первый раз вижу что все варианты разложены по полочкам.

[yahan]

Да так лучше (я про генерацию ключа на стороне клиента), но надо не забывать про атаку Man in the middle. При приеме открытого ключа, обязательно надо убедиться что он действительно от владельца.

[Borz]

зачем это в способе три? «На стороне сервера фильтр получает значение из этого хидера, расшифровывает токен, парсит его или разберает на составляющие и решает давать или нет доступ клиенту»
разве не лучше будет использовать токен от HTTP-сессии веб-сервера и брать данные на стороне сервера из сессии?

[aparamonov]

Чем лучше? :)
Вариант с зашифрованным токеном и данными авторизации в куках/хидере выигрывает в его stateless — не нужен synchronized cache/backing store — меньше кода, и нагрузка на сервер, проще система сама по себе.

[darkazazello]

MD5 уже не является надежным алгоритмом хеширования и рекомендуется к шифрованию паролей. Пруфы гуглятся по «decrypt md5 opencl»

[lehaalexx]

Я так и написал

Логин и пароль шифруются MD5 алгоритмом и его достаточно сложно расшифровать.

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

Пруфы гуглятся по «decrypt md5 opencl»

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

[darkazazello]

Брутфорсом очень быстро сейчас подобрать хеш md5. Даже одна видеокарта перебирает миллиард хешей за секунду.

[zencd]

А почему в п.4 вы поменяли направление общения и у вас уже сервис обращается к клиенту? Нужен скорее обратный пример. И мд5 — это не шифрование.

[zencd]

Уточню: общение в пункте №4 инициируется всё-таки клиентом, но кто этот клиент, имеет ли он право совершать операцию — в этом сценарии это никого почему-то не интересует. Зато сервер шифрует свой ответ о_О

[lehaalexx]

Суть состоит в том что любой может обратится к рест сервису и получить беспорядочный набор символов, а точнее шифрованный ответ от сервера и только владелец приватного ключа сможет его расшифровать.

Любой клиент может совершать операцию, но расшифровать может только один

[lehaalexx]

В четвертом примере конечно же надо использовать не MD5, а к примеру javax.crypto пакет, MD5 только для Digest.

[solver]

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

[lehaalexx]

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

[lehaalexx]

Да, спасибо, что напомнили про SSO. Можно еще использовать OpenAm или Spring CAS. Это номер 7.