Комментарии 16
Еще более безопасным можно сделать этот подход если генерировать пару ключей на клиентской стороне с использование javascript библиотек таких как forge. Такой подход позволяет вообще не пересылать приватный ключ по сети, а сразу генерировать на клиентской стороне, что значительно уменьшает риск скомпрометировать этот ключ.
а по https:// обратиться разве не проще?
0
Проще, но https (точнее у протоколов, которые он использует, SSL или TLS) есть свои уязвимости, позволяющие совершать на него атаки типа man-in-the-middle. Особенно в случае если используется самоподписанные сертификаты. Подробнее про атаки на SSL или TLS можно посмотреть хотя бы в википедии. В любом случае полезно знать разные варианты реализации безопасности в приложении, поэтому эту статья для меня очень интересно было прочитать, в первый раз вижу что все варианты разложены по полочкам.
-3
Да так лучше (я про генерацию ключа на стороне клиента), но надо не забывать про атаку Man in the middle. При приеме открытого ключа, обязательно надо убедиться что он действительно от владельца.
0
зачем это в способе три? «На стороне сервера фильтр получает значение из этого хидера, расшифровывает токен, парсит его или разберает на составляющие и решает давать или нет доступ клиенту»
разве не лучше будет использовать токен от HTTP-сессии веб-сервера и брать данные на стороне сервера из сессии?
разве не лучше будет использовать токен от HTTP-сессии веб-сервера и брать данные на стороне сервера из сессии?
0
MD5 уже не является надежным алгоритмом хеширования и рекомендуется к шифрованию паролей. Пруфы гуглятся по «decrypt md5 opencl»
+2
Я так и написал
Я не утверждаю что этот метод самый надежный, скорее наоборот, но он есть и возможно кому-то пригодится.
Логин и пароль шифруются MD5 алгоритмом и его достаточно сложно расшифровать.но это не значит, что невозможно. Это понятно что брутфорсом подобрать можно, но не так быстро. Время зависит от сложности пароля.
Пруфы гуглятся по «decrypt md5 opencl»— гуглятся только те, что есть в базе.
Я не утверждаю что этот метод самый надежный, скорее наоборот, но он есть и возможно кому-то пригодится.
0
А почему в п.4 вы поменяли направление общения и у вас уже сервис обращается к клиенту? Нужен скорее обратный пример. И мд5 — это не шифрование.
0
Уточню: общение в пункте №4 инициируется всё-таки клиентом, но кто этот клиент, имеет ли он право совершать операцию — в этом сценарии это никого почему-то не интересует. Зато сервер шифрует свой ответ о_О
0
В четвертом примере конечно же надо использовать не MD5, а к примеру javax.crypto пакет, MD5 только для Digest.
0
В качестве общего образования пойдет.
Но на практике, все что сложнее второго пункта, обычно заменяется на SSO, что-то вроде Jasig CAS.
Но на практике, все что сложнее второго пункта, обычно заменяется на SSO, что-то вроде Jasig CAS.
+1
В наших проектах применялся пятый и шестой, так же. Четвертый, тоже имеет право на жизнь. Третий немного надуманный и в практике, на реальных проектах его не встречал. Но как я уже написал в конце, это лишь стартовая точка, чтобы натолкнуть читателей на собственные решения или выбрать из существующих.
0
Да, спасибо, что напомнили про SSO. Можно еще использовать OpenAm или Spring CAS. Это номер 7.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
6 способов: как добавить security для Rest сервиса в Java