Комментарии 19
Вы перечисляете основные угрозы, но они не решаются с помощью нового метода авторизации.
Более того, хранить приватные ключи на компьютере, это тоже что встречать каждого трояна с хлебом и солью, они уже давно умеют вытаскивать все из разных менеджеров для хранения паролей, с такой же легкостью будут и ключи вытаскивать.
Конечно сейчас трояны могут и куки собирать, но куки обычно имеют время жизни довольно ограниченное и чаще всего привязаны к ip и\или user agent'у.
Так же я не вижу особых проблем для проведения атак типа MITM.
Сейчас можно и на основе cookie организовать похожую защиту, сервер передает соль (например на основе айпи + соль или рандома) для авторизации клиенту, клиент шифрует (например md5) свой пароль и соль сервера, генерируя куку, по которой получает доступ.
Более того, хранить приватные ключи на компьютере, это тоже что встречать каждого трояна с хлебом и солью, они уже давно умеют вытаскивать все из разных менеджеров для хранения паролей, с такой же легкостью будут и ключи вытаскивать.
Конечно сейчас трояны могут и куки собирать, но куки обычно имеют время жизни довольно ограниченное и чаще всего привязаны к ip и\или user agent'у.
Так же я не вижу особых проблем для проведения атак типа MITM.
Сейчас можно и на основе cookie организовать похожую защиту, сервер передает соль (например на основе айпи + соль или рандома) для авторизации клиенту, клиент шифрует (например md5) свой пароль и соль сервера, генерируя куку, по которой получает доступ.
проблема кукисов в том что их можно с помощью XSS вытащить :)
SessionID и ChannelID с помощью XSS вытащить нельзя
SessionID и ChannelID с помощью XSS вытащить нельзя
prophet.ru/2010/12/httponly-cookies/
Хочу заметить, что сторонником использования cookie, я не являюсь.
Хочу заметить, что сторонником использования cookie, я не являюсь.
HttpOnly куки вроде нельзя при помощи XSS утащить?
НЛО прилетело и опубликовало эту надпись здесь
Вот я и не понимаю чем переход на TLS ChannelID будет лучше, также через XSS можно продолжать выполнять запросы используя ChannelID пользователя. Единственный аргумент что ChannelID в отличие от cookie нельзя украсть, получается бессмысленный.
НЛО прилетело и опубликовало эту надпись здесь
автор сам сравнил с куками :)
я так
смотря на историю с session_id кажется что это все хоть и звучит красиво, на практике никем не будет поддерживаться :(
хотя вот OCSP Stapling вроде входит в жизнь
я так
смотря на историю с session_id кажется что это все хоть и звучит красиво, на практике никем не будет поддерживаться :(
хотя вот OCSP Stapling вроде входит в жизнь
Если используется обычный TLS, то передаваемые по сети cookie проблематично перехватить. Если TLS не использовать, то и новое расширение TLS ChannelID работать не будет. Если закладываться на то что можно перехватывать по сети данные защищенные TLS, то и наверное в ChannelID смысла не много, т.к. там используется те же алгоритмы шифрования.
Мне если честно не очень нравится что идет некоторое смешение канальной логики и логики веб сервера. Cookies позволяют например для одного фактического соединения использовать разные cookies для разных приложений, например mysite.com/app1 и mysite.com/app2. ChannelID у этих двух приложений видимо будет общим. Хотя я сейчас подумал на уровне приложений это можно поддерживать нормально.
Для меня эта новая фича выглядит как Mutual TLS (т.е. с клиетским сертификатом, только таким который генерируется автоматически). Так что можно и сейчас использовать что-то настолько же безопасное.
Мне если честно не очень нравится что идет некоторое смешение канальной логики и логики веб сервера. Cookies позволяют например для одного фактического соединения использовать разные cookies для разных приложений, например mysite.com/app1 и mysite.com/app2. ChannelID у этих двух приложений видимо будет общим. Хотя я сейчас подумал на уровне приложений это можно поддерживать нормально.
Для меня эта новая фича выглядит как Mutual TLS (т.е. с клиетским сертификатом, только таким который генерируется автоматически). Так что можно и сейчас использовать что-то настолько же безопасное.
Ну, если менеджер шифрует базу паролей, то, по идее, их не так просто вытащить, разве не так?
Зашифровать можно каким то ключем\паролем и пользователю придется вводить его каждый раз, при логине куда то.
Тогда вытащить не просто, но тоже можно.
А в других случаях, вытащить сложности не представляет, достаточно подделать алгоритм расшифровки менеджера (на сколько я могу знать, почти все «хорошие» трояны сейчас имеют такие алгоритмы).
Тогда вытащить не просто, но тоже можно.
А в других случаях, вытащить сложности не представляет, достаточно подделать алгоритм расшифровки менеджера (на сколько я могу знать, почти все «хорошие» трояны сейчас имеют такие алгоритмы).
Генерация ключевых пар, а также выработка сессионных ключей должна производится в смарткарте. Это может быть TPM или отторгаемый носитель и в этом основная идея Google. В случае наличия трояна на устройстве, троян конечно сможет организовать несанкционированое подключение с этого устройства к серверу, используя возможности TPM или в момент когда подключен отторгаемый носитель, но украсть ключи он не сможет.
Кроме того, организация MITM после первичного обмена открытыми ключами невозможна.
Кроме того, организация MITM после первичного обмена открытыми ключами невозможна.
Практически во всех мобильных устройствах есть SIM-карты. Там несколько лет назад собирались хранить все данные и файлы пользователя, чтобы телефоны предоставляли голое взаимозаменяемое железо. Так вместо этого лучше поручить симке выполнять функции смарткарты, все равно ее внутренности простаивают и невзламываемы. Правда, производители довольно консервативны…
Пробовал использовать session_id как идентификатор, столкнулся с проблемами в safari :(
Все разработчики многофакторной аутентификации и форм, в которых браузеры не сохраняют пароли, должны умереть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Аутентификация по-новому, или суперкуки