Comments 8
Хм, 1000 просмотров - 0 коментариев. Надо было про эмиграцию писать...
Вы же видите +2 и 26 закладок - добро пожаловать на Хабр! Коменты будут, только если нарушена какая-то "великая справедливость". Тут просто "эмиграция" не поможет. Надо "10 советов для удачного релокейшна" и в статье сделать только 9 пунктов. Тогда сразу набегут обсуждать, как правильно писать англитив :)
Да с удовольствием. Хорошая статья, но раз уж разговор о безопасности, то есть пара моментов. У вас пароль передается как параметр входной. Это небезопасно, т.к. http запрос может быть перехвачен (да, даже если https, при скомпрометированном SSL сертификате). Лучше всегда с клиента передавать хеш пароля, а не сам пароль, в идеале как base64(username:passwordHash) в заголовке Authorization. Так же вижу, что пароль сравнивается с паролем из БД. Получается вы храните исходные пароли в БД. Это небезопасно, т.к. БД могут украсть, лучше уменьшить ущерб и хранить в БД поперченные хеши паролей, а при сравнении перчить хеш пароля от клиента. Ещё больше повысить безопасность поможет соль (например время, округленное до минуты) с одноразовым перцем, полученного с сервера и созданного с учётом User Agent, добавленные в хеш на стороне клиента. Таким образом у злоумышленника будет всего минута, если он перехватит одноразовый перец. Надеюсь, было интересно.
Спасибо за коммент, действительно интересно
1. По поводу хеширования пароля base64 - буду применять.
2. В данном примере используется InMemoryUserDetailsManager(Нет БД). Для сравнения ипсользуется закодированный пароль(BCrypt strong hashing function) из userDetails. Поэтому для сравнения применяется passwordEncoder:
if (passwordEncoder.matches(password, userDetails.password))3.По поводу использования соли - интересно, надо поизучать.
Сапсибо, интересно!
По поводу хэшей и солей - в Spring Security стандарт PasswordEncoderFactories.createDelegatingPasswordEncoder()
Он по умолчанию юзает BCryptPasswordEncoder, с которым не надо приседаний с перцем и солью - все встроено.
Правильно понял - между серверами в хедерах просто предается secret и сравнивается чз equals?
У вас есть ссылка на то, что это "так используется" или сами делали?
У Google вижу все сложнее: https://developers.google.com/identity/protocols/oauth2/service-account
https://stackoverflow.com/questions/37854185/server-to-server-communication-in-microservices
Нашел Best Practice - Publisher/Subscriber approach
Или без авторизации с проверкой ip
Так понимаю - если по простому без асинхронности, то подойдет любая простая проверка, в том числе и подход выше
Security микросервисов с помощью Spring, OAuth2, JWT и Service Account