Способ аутентификации на жабоскрипте

Взлетит. Устойчивость к man-in-the-middle такая же, как в случае с самосгенерированным сертификатом (т.е. никакой).

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

Да и с самосгенерированным сертификатом SSL слишком много нужно геморроя для того, чтобы перехватить трафик между сервером и клиентом, расшифровать, выдрать нужное, зашифровать обратно.

Окей, есть Алиса (клиент), Боб (сервер) и Чак (MiM).

Чак выдает себя за Боба. Алиса хочет авторизироваться. Чак запрашивает у Боба некий случайный ключ. Чак отправляет Алисе его же. Алиса прислюнивает в качестве соли хэш своего пароля и полученный хэш отправляет обратно (Чаку). Чак отправляет заслюненый хэш Бобу. Боб говорит: «Верно!», и отправляет Чаку ключ, который сохраняется в localStorage. Чак передает его Алисе.

И так, этот ключ теперь знают и Алиса, и Чак.

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

надо генерировать свои сертификаты и объяснить пользователю, что при запросе браузера на подтверждение, нужно жамкнуть «да».

А не проще купить сертификат?

Просто оставлю это здесь: https://hacks.mozilla.org/2014/10/passwordless-authentication-secure-simple-a...

Нет.

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

как сервер узнает значение ключа в случае localstorage без кук? светить ключ в урле? тогда теряется смысл подхода. Проблема в том, что от кук не так просто избавиться. По крайней мере мне не очевиден способ замены кук при помощи localstorage - только если что-то вычислять как-то, но что мешает другому так сделать?

как сервер узнает значение ключа в случае localstorage без кук?

Ключ хранится в БД. Точно так же, как и в случае кук. Передаем серверу через вебсокет или POST-запросом — разницы никакой, т.к. в случае с куками та же ситуация: ключ идет открытым текстом.

мне не очевиден способ замены кук при помощи localstorage

Элементарно: то, что раньше хранилось в куках, теперь хранится в localstorage.

Ты придумал нечто похожее на CSRF-токен

3-4 доллара жалко?

SSL для бедных?) Но зачем.

Но зачем столько телодвижений? Чак может просто мониторить траффик между Алисой и Бобом в поисках ключа. Собственно никакого профита от такой системы нет.

А по теме - бред. В чем смысл сего действа? Если кто-то прослушивает линию, то он спокойно читает все эти твои странные манипуляции. К чему это шаманство? Можно прислать ключ, можно прислать промежуточный ключ, а потом ключ, можно прислать 10 промежуточных ключей, а потом ключ.. в определенный момент ты все-равно отправишь «итоговый» ключ и именно его возьмет себе злоумышленник предварительно покрутив у виска.

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-to...

Ну насчет передавать ключ через-POST неудобно, в случае кук проще: значение прицеплено в заголовках. В общем такое применение localStorage то-же самое что и с куками, только вид сбоку. Хотя localStorage современно, молодежно, но не даёт существенных плюсов.

Интересен вариант, когда значение ключа не передаётся по каналам связи. Это не будет работать в случае передачи шифрованного ключа - 3-ей стороне нчито не мешает этим воспользоваться. Нужен шифрованный канал для передачи токена, а это то-же самое что стандартный шифрованный канал.

Хочешь без шифрования канала? Передавай шифрованный контент, ключом, который в localStorage. Это будет работать, при условии, что значение ключа знает только оконечный браузер и сервер. Это можно реализовать.

Осталось за малым: клиенты для шифрования на сервере и в браузере. Какая нибудь реализация «рыбных» шифров или мифический GPG-js.

Тебе и xtraeft: затем, что черезжопно это — скакать туда-сюда (то на https, то обратно). Да и полдня же тратить, чтобы https поднять на новом компьютере... Нафиг оно нужно?

А покупать SSL-сертификаты ради внутренней морды управления железякой — бред!

Полезного по теме: юзай что-нить типа этого https://github.com/digitalbazaar/forge Или, как вариант, передавать хешированные пароли https://github.com/blueimp/JavaScript-MD5 , можешь передавать на страницу соль, чтобы захешировать ею пароль, и только после этого отправлять на сервер. Тогда ты защитишь не сессию пользователя, но пароль (можно и логин).

Дык, просто я от CGI перехожу к вебсокетам. Можно, конечно, и к вебсокету куку прислюнить, но что-то нет желания: можно же напрямую отправлять данные!

И еще: ведь SSL-аутентификация по сути точно такая же! И ее точно также M-I-M может взломать!!!

клиенты для шифрования на сервере и в браузере

На сервере-то фигня, а вот в браузере... Да и смысл все шифровать? Нужно лишь при установке соединения сделать проверку свой-чужой, и все.

юзай что-нить типа этого https://github.com/digitalbazaar/forge

Почему там кода так дофига? Если больше двух страниц жабокода нужно будет, то нафиг такой способ! Это ж извращение!!!

Или, как вариант, передавать хешированные пароли https://github.com/blueimp/JavaScript-MD5

Во, это уже поближе.

В общем, похоже, проще всего будет действительно отсылать с сервера "соль", хэшировать ею логин и хэш пароля, это отправлять на сервер, а там уже сверять пары "хэшированный логин"-"хэшированный хэш пароля".

О, я придумал. Ты отправляешь на страницу соль, юзер вводит логин, пароль, и с помощью какой-нибудь хитрой хэш функции получает некий ключ (все на клиенте) - это будет его идентификатор сессии. Ты можешь время от времени отправлять соль заново (хоть каждый запрос), тогда похищенная злоумышленником сессия будет быстро устаревать (или вообще никогда не будет актуальной).

Минус - на сервере должны лежать незахешированные пароли, или соль пароля тоже надо будет передать (а то ты не сможешь аналогичный ключ у себя получить).

Ну, это почти то же самое. Просто уменьшается количество проверок. В принципе, да: проще.

Итак, результирующая схема (сервер хранит логин в явном виде, а пароль в виде хэша):

• сервер отсылает "соль" клиенту, а сам, стыкуя вместе логин и хэш пароля и хэшируя их этой "солью" получает ключ сессии;
• клиент этой "солью" тоже вычисляет ключ сессии и отсылает серверу;
• сервер проверяет — если ОК, то позволяет, скажем, минут 5-10 сессии продержаться, иначе — шлет лесом;
• по истечению таймаута опять повторяем вычисление нового ключа.

Я не разбирался с вебсокетами больше после публикаций о проблемах с его безопасностью, так что не могу быть объективным в этом плане. Прагматизм остался - зачем тратить на него внимание пока не утрясли безопасность. Но что-то мне подсказывает что и не следует еще доверять вебсокету. Следовательно остаются стандартные схемы.

Шифрование для сервера и браузера не фигня для сервера: нужна схема, адекватно и одинаково работающая на обеих сторонах и желательно в стиле mcrypt

Почему там кода так дофига?

Реализация SSL (вроде).

Ну, это почти то же самое.

Да, но в первом случае защиты сессии не было вообще, а тут какая-никакая.. в общем-то нормальная вполне.. :)

Да и полдня же тратить, чтобы https поднять на новом компьютере...

Полдня?

А покупать SSL-сертификаты ради внутренней морды управления железякой — бред!

Это да, тем более к ip ты его не привяжешь.

тогда уж ключи должны генериться одноразовые, а не с таймаутом...

Рабочая конечно схема, но в ней контент доступен третьей стороне по каналу передачи, если это не критично-тогда зачем это все? , то с одноразовыми ключами терпимо. Но если ключ перехвачен, то ничто не мешает по нему удовлетворить запрос. Так что рано радоваться... Только шифрованный канал.

подсмотрят хеш твоего пароля и будут его подставлять, защиты 0, передавай уж сразу открытым текстом :)

если это не критично-тогда зачем это все?

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

Когда куки угоняют - тот же принцип. Потому нет разницы, где ты ключик хранишь, в куке или в строке запроса.

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

Спасибо, это тоже пригодится.

устойчивость метода к атаке man-in-the-middle.

нулевая, mitm может поменять весь твой хитрый javascript на заглушку, шлющую пароль напрямую ему. Кстати, именно поэтому каждый сайт, где можно залогиниться, обязан использовать HTTPS не только на странице логина, но и вообще по всему сайту.

Но с https постоянная проблема: надо генерировать свои сертификаты и объяснить пользователю, что при запросе браузера на подтверждение, нужно жамкнуть «да».

startssl, не? Какое подтверждение?

mitm может поменять весь твой хитрый javascript на заглушку, шлющую пароль напрямую ему

Йок! И действительно. Что-то об этом я совсем не подумал!

Но чертовы сертификаты настраивать... А, ладно, понастраиваю. Можно вообще постоянно на https сидеть, и вебсокет тоже SSL'ем шифровать, раз уж все равно придется сертификаты генерировать.

Обычно для аутентификации на веб-сервисе я пользовался следующим алгоритмом: после нажатия на кнопочку login пользователь перебрасывался на https-страничку ввода логина-пароля, <…> и если все ОК, отсылал пользователю куку и возвращал его на нешифрованную страничку.

Так давно уже ни один нормальный сайт не делает. Так было модно в начале нулевых и только из экономии ресурсов (полное шифрование требовало больше). А сейчас то зачем так поступать? Ну ок, пароль от MIM защитишь, а остальные данные нет. Кукисы и прочее всё будет ему доступно.