Как реализовать собственную аутентификацию\авторизацию для сайта?

Question

[Boniface]

Всем привет! Подскажите, пожалуйста, какие могут быть проблемы с безопасностью, если сделать авторизацию следующим образом...

Есть сайт. Клиент написан на angular.js а сервер на node.js. Для авторизации клиент передает на сервер логин и пароль. В ответе от сервера при успешной авторизации приходит md5 hash, назовем его access token. Этот токен хранится на сервере в redis в сессии пользователя. На клиенте токен сохраняется в localstorage.

Все последующие запросы идут с access token в заголовке с id пользователя. Да, еще у токена есть время жизни, если оно истекает то пользователь должен опять отправить логин и пароль для авторизации.

Все запросы идут через https. Какие есть дыры в такой реализации?

Answer 1

[maxaon]

Основных проблемы две:
1. Как генерируется токен, хранится и удаляется. Есть ли привязка к IP и др.
2. Угон токена через xss или другим способом, поскольку можно напрямую его читать. Наиболее рациональным подходом будет хранить в куки с флагом httponly. Для параноидальности еще можно разбить токен на две части. Одна в куке, другая отправляется вручную в запросе/заголовке.

Но еще лучше использовать http digest аутентификацию.

Comments

[Boniface]

Токен генериться когда клиент проходит аутентификацию (передает логин и пароль), алгоритм MD5. Храниться в redis. Привязки к ip нет.

С куками не хочу работать. По моему они устарели, есть же localstorage. А старые браузеры мне не нужно поддерживать.

Не могли бы вы пояснить, чем куки безопаснее хедера? Ведь куки так же ходят между клиентом и сервером...

[Mikhail Osher]

httponly куки доступны только по протоколу HTTP. Никаких вам document.cookie.

[maxaon]

Поддерживаю @Miraage. Вы, или злоумышленник, не сможете ее прочитать из JS. Этим вы оградите пользователя и себя от части векторов атак.

[Boniface]

Спасибо за совет! А еще есть бреши в такой схеме по мимо localstorage?

[maxaon]

ru.wikipedia.org/wiki/OWASP

Answer 2

[Hostwell]

Элементарно