> Эта схема подразумевает генерацию после успешной проверки сессионного идентификатора, Эта схема подразумевает что клиент и сервер где-то внутри себя знают пароль и могут сделать одинаковые вычисления и сравнить что вышло, не более того. Про HTTP или какие-то сессии я вообше тут не издал ни звука, то что у вас HTTP-оз головного мозга и поэтому вы в принципе не способны представить ничего кроме http и типичной организации сессии в нем - это уже на вашей совести.
> по которому пользователь сможет работать на сайте. Если не используем SSL,
На самом деле, в случае HTTP ключевой дыркой будет то что алгоритм не реализован в браузере или еще какой-то монументальной сущности которая не заменяется атакующим вотпрямщасеймомент. Т.е. алгоритм придется догружать откуда-то сбоку, например на JS, а это FAIL. Если пассивный сниффер будет полностью обломан таким протоколом, то вот активный может просто вгрузить юзеру _другой_ код, например не считающий sha512() а просто отсылающий пароль на немного другой сервер плэйнтекстом, как его юзер ввел. При том юзеру не очень видно что JS сделал ;)
> то никто не мешает перехватить данный идентификатор и притвориться этим пользователям
> не проходя вообще фазы аутентификации.
Вообще, такой протокол очень даже может мешать таким потугам. Подумайте о том что в принципе так можно авторизовывать вообще все запросы юзера. Новый запрос - новый рандом от сервера - новый ответ - шлем нафиг, если вычисления не совпали. То что в рамках стандартного http и привычных вам механизмов это не совсем удобно - второй вопрос.
Тем не менее, похожие по смыслу алгоритмы реально применяются для аутентификации по паролю без отсылки этого пароля и даже его хеша. Обеспечивается защита от "replay", т.е. если сервер кинул рандом, юзер ответил а некто подсмотрел это, в следующий раз авторизоваться на сервере подсмотревший не сможет, потому что сервер кинет другой рандом. А посчитать ответ не зная пароля - опаньки, потому что sha512(password+random1) ничего не говорит о том каким должен быть sha512(password+random2).