Comments
Вы перечисляете основные угрозы, но они не решаются с помощью нового метода авторизации.
Более того, хранить приватные ключи на компьютере, это тоже что встречать каждого трояна с хлебом и солью, они уже давно умеют вытаскивать все из разных менеджеров для хранения паролей, с такой же легкостью будут и ключи вытаскивать.
Конечно сейчас трояны могут и куки собирать, но куки обычно имеют время жизни довольно ограниченное и чаще всего привязаны к ip и\или user agent'у.
Так же я не вижу особых проблем для проведения атак типа MITM.

Сейчас можно и на основе cookie организовать похожую защиту, сервер передает соль (например на основе айпи + соль или рандома) для авторизации клиенту, клиент шифрует (например md5) свой пароль и соль сервера, генерируя куку, по которой получает доступ.
проблема кукисов в том что их можно с помощью XSS вытащить :)
SessionID и ChannelID с помощью XSS вытащить нельзя
А это неважно. Просто традиционно идут путем нашли XSS -> украли Cookie -> подменили сессию.
А потом все начинают думать, что HTTP Only Cookie или привязка сессии к IP не позволят использовать XSS.

Но никто же не мешает просто написать скрипт, который будет сразу делать все что надо, а не красть какие-то куки. Или еще лучше — подключить Shell of The Future

Так что проблема Cookie не в том, что их можно через XSS утащить. И преимущество SessionID/ChannelID не в том, что их нельзя утащить через XSS.

XSS это проблема совершенно другого рода и она заключается в том, что атакующий получает возможность отправлять любые запросы из браузера пользователя и получать ответы с того же домена. Никакие новые методы аутентификации вам против XSS не помогут, если только вы не используете дополнительную проверку (SMS, ввод пароля и т.д.) при каждом запросе. Но дополнительная аутентификация при каждом запросе допустима (и насколько я вижу, используется) только в очень критичных приложениях (в основном онлайн-банкинги). Никто не будет пользоваться твиттером, если на каждый клик нужно будет ввести пароль.
Вот я и не понимаю чем переход на TLS ChannelID будет лучше, также через XSS можно продолжать выполнять запросы используя ChannelID пользователя. Единственный аргумент что ChannelID в отличие от cookie нельзя украсть, получается бессмысленный.
Данный метод решает совершенно другую задачу.

deus ошибочно заявляет, что:
>> проблема кукисов в том что их можно с помощью XSS вытащить :)

Проблема не в этом. Проблема в том, что:
а) Cookie, как и OAuth токены передаются по сети
б) Кража cookie или токена позволяет украсть сессию

Именно эти два пункта вместе являются проблемой. У предложенного метода отсутствует недостаток б), поэтому кража того, что передается по сети, не позволяет злоумышленнику увести сессию.

Не надо смешивать все в кучу. Данный метод нужен для защиты от прослушивания канала. В контексте данной статьи возможность украсть cookie через XSS совершенно неважна.
автор сам сравнил с куками :)
я так
смотря на историю с session_id кажется что это все хоть и звучит красиво, на практике никем не будет поддерживаться :(
хотя вот OCSP Stapling вроде входит в жизнь
Если используется обычный TLS, то передаваемые по сети cookie проблематично перехватить. Если TLS не использовать, то и новое расширение TLS ChannelID работать не будет. Если закладываться на то что можно перехватывать по сети данные защищенные TLS, то и наверное в ChannelID смысла не много, т.к. там используется те же алгоритмы шифрования.

Мне если честно не очень нравится что идет некоторое смешение канальной логики и логики веб сервера. Cookies позволяют например для одного фактического соединения использовать разные cookies для разных приложений, например mysite.com/app1 и mysite.com/app2. ChannelID у этих двух приложений видимо будет общим. Хотя я сейчас подумал на уровне приложений это можно поддерживать нормально.

Для меня эта новая фича выглядит как Mutual TLS (т.е. с клиетским сертификатом, только таким который генерируется автоматически). Так что можно и сейчас использовать что-то настолько же безопасное.
Ну, если менеджер шифрует базу паролей, то, по идее, их не так просто вытащить, разве не так?
Зашифровать можно каким то ключем\паролем и пользователю придется вводить его каждый раз, при логине куда то.
Тогда вытащить не просто, но тоже можно.
А в других случаях, вытащить сложности не представляет, достаточно подделать алгоритм расшифровки менеджера (на сколько я могу знать, почти все «хорошие» трояны сейчас имеют такие алгоритмы).
Генерация ключевых пар, а также выработка сессионных ключей должна производится в смарткарте. Это может быть TPM или отторгаемый носитель и в этом основная идея Google. В случае наличия трояна на устройстве, троян конечно сможет организовать несанкционированое подключение с этого устройства к серверу, используя возможности TPM или в момент когда подключен отторгаемый носитель, но украсть ключи он не сможет.

Кроме того, организация MITM после первичного обмена открытыми ключами невозможна.
Практически во всех мобильных устройствах есть SIM-карты. Там несколько лет назад собирались хранить все данные и файлы пользователя, чтобы телефоны предоставляли голое взаимозаменяемое железо. Так вместо этого лучше поручить симке выполнять функции смарткарты, все равно ее внутренности простаивают и невзламываемы. Правда, производители довольно консервативны…
Пробовал использовать session_id как идентификатор, столкнулся с проблемами в safari :(
Все разработчики многофакторной аутентификации и форм, в которых браузеры не сохраняют пароли, должны умереть.
Only those users with full accounts are able to leave comments. Log in, please.