Как правильно составить алгоритм безопасной авторизации?

Question

[SemihalDevs]

Всем привет. Перерыл кучу сайтов в поисках примера безопасной авторизации на PHP, но так и не нашел ничего толкового (либо материал уже устарел).
Но все же набросал кое-какой алгоритм.. Знатоки, пожалуйста, подскажите, где его проблемные места и как их решить.
И так:

1. Ввод пользователем логина и пароля
   
2. Хеширование пароля на стороне клиента. Примерно так: sha1(sha1(password, login) + randomKey). randomKey генерируется случайно при каждой новой авторизации, для того, что бы передавать на сервер постоянно разный хеш (защита от перехвата).
   
3. На сервер отправляем полученный хеш и randomKey
   
4. Сверяем на сервере хеш клиента и и sha1(хэш_с_сервера + randomkey)
   
5. Если авторизация успешна, то записываем в куки некий "ключ" сессии.
   

Далее, допустим по ключу 123 ($_SESSION['123']) мы будем получать необходимые данные о пользователе (логин, заход последний и т.д.)

Собственно, вот такой, не сложный алгоритм. Но вопрос стоит в этом: как защититься от перехвата сессий (привязка по IP спасает ровно до того момента, пока не сменится IP :( ).
И какие есть более глобальные проблемы, у такого алгоритма?

Answer 1

[Андрей]

Может Вам что-то подобное реализовать :
https://en.wikipedia.org/wiki/Salted_Challenge_Res...

Answer 2

[Юрий Ярош]

Ну, во первых, стоит разобраться в чём же разница между аутентификацией и авторизацией - со стороны подобный вопрос выглядит довольно нелепо. Во вторых, если https считать небезопасной средой - можно пробросить ключики по Диффи-Хелману и шифровать трафик AES'ом, но это для полных параноиков, и ещё HMAC-SHA256 можно прикрутить... sha1(sha1(whatever)) с точки зрения криптографии полный "пэ". Обычно бэкенды принято делать stateless и всю инфу хранить в рамках пользовательской сессии, просоленной и пошифрованной. А, непосредственно, сами пароли в BCrypt / SCrypt etc.

Аутентификация в таком случае может выглядеть следующим образом
1. Происходит обмен ключами
2. Человек отправляет свой логин-пароль на сервак по шифрованному каналу
3. В ответ получает объект пользовательской сессии, который сохраняет в куках
Сессия представляет собой не что иное как сериализированный шифрованный объект с "солью" которая прописана на всех запущенных экземплярах бэкенда - таким образом куда бы запрос не пришёл, он везде обрабатывается одинаково, и отпадает потребность в session-storage.
4. Опционально, в рамках пользовательской сессии заводятся CSRF-токены.
5. Опционально, весь траф нужно эскейпить, включая всякие там JSONP и прочее. Ангуляр вообще с коробки требует весь JSONP префиксить таким чудом ")]}',\n"