Да, кстати, такое иногда наблюдаю.
Я правда думал что это из-за изменений в работе СМС-обменников межпровайдерных, которые из-за нового регулирования в РФ криво начали работать. Но это действительно у меня так одно с другим совпало, похоже.
Ну собственно да, как и у любого мобильного чата у него основной смысл — заменить обмен СМСками на обмен его, шифрованными, сообщениями через интернет, и через то экономить денег.
Дальше уже в плюс фичи — групповые чаты, секьюрность, вот это вот всё.
Кстати, глава разработки TextSecure — небезызвестный Moxie Marlinspike. Достаточно забавный кадр.
Ах, ну да. И ещё он умеет шифровать СМСки и сообщения в хранилище на телефоне, если это кому-то друг важно.
Многопользовательские чаты есть.
Скорее бы iOS-версия — и заживём.
Кроме того, вот тут утверждается, что собеседник всегда верифицируется, даже по СМС. На то что тулзы для верификации все есть, вроде уже указали.
Для передачи сообщений используется Google Play Services, но поскольку все передаваемые через интернет сообщения зашифрованы end-to-end — расшифровать их всё равно не представляется возможным. (А у Гугла зато инфраструктура бесплатная и отказоустойчивая).
С какой-то ревизии CyanogenMod TextSecure используется в качестве штатной СМСочницы.
В общем я не знаю, в каком там смысле автор замену Скайпу искал, но TextSecure это сейчас мой основной мобильный мессенджер, и полёт пока нормальный.
Ну где-то это я и имел в виду.
«Соблюдение план-графика любой ценой» это же и есть недостаток управления.
Хотя казалось бы, тезис о том, что «план это объект управления», и его соответствие реальному состоянию дел должно быть приоритетнее его неизменности — этот тезис должны бы вколачивать на первом курсе любой управленческой школы, эмбиэй-шмембиэй…
Мне одному кажется, что весь этот зрелищный факап произошёл по вине тех людей, которые планировали эту миграцию? И у которых были только очень приблизительные представления о сроках, буферах, методе критической цепи и прочих методах, которые только и позволяют не накостыливать экстренные решения в последний момент ценой техники безопасности?
Ну то есть представим, что все железки встали в строй за неделю до миграции, а не в последний день. Ну и там что специалисту дали отоспаться, прежде чем что-то куда-то подключать, ломая логические тома…
А кстати отдельный файл с хинтами для анализатора — оно окей или не окей?
Мне кажется, что вполне нормально, и никакие опенсорсные определения не нарушаются. Просто лежит такой отдельный конфиг для тех, у кого есть ещ1 и вот эта вот приблуда.
А я вот понимаю, но практически в любых сегментах был бы готов платить больше за подобное качество сервиса.
Только чего-то мало в каких нишах у меня есть подобная опция:(
Ну, у них вроде постгрес используется для хранения, в нём есть FTS со встроенным стеммингом русского. И оно работает более-менее неплохо, я пару раз его прикручивал к разным вещам.
Так что тут вопрос меньше в лицензировании, и больше — именно в приоритизации задач программистов.
Всё так.
Даже больше того, нет необходимости домешивать id клиента в секрет для подписи, достаточно просто иметь (и проверять при запросах) поля ip: или useragent: в токене.
Другое дело, что лично я считаю привязку авторизации к IP-адресу очень неудобным механизмом, чисто из собственного опыта постоянной работы из всяких удалённых мест.
Да, любой чистый stateless-механизм этому подвержен.
В итоге добавляем айди сессии с привязкой к данным в памяти сервера. Теряем в масштабировании, но сохраняем плюсы «изкоробочной» защиты от CSRF, дружелюбность к произвольным клиентским API и возможность иметь авторизацию «одну-на-всех» и на отдельном хосте.
(Если что — JWT ни в коем раз не «серебряная пуля» для авторизации. И я её «адвокатирую» в первую очередь из интереса попробовать технологию на прочность, постучав её об вдумчивых и проницательных критиков.)
Про общее число запросов — замечание валидное, но применимое в первую очередь для серверно-наполняющихся веб-страниц.
Мобильные приложения с API через JWT дружатся гораздо проще, чем с куками. Никаких лишних запросов в этом случае нет, потому что авторизацию так и так проверять, и обновлять если сессия сдохла.
Ну и многие веб-приложения можно свести к вязанке статики и получению данных по тому же API, что и для мобильных аппов (и мы пару таких приложений делаем в данный момент, например). Тут тот же случай, что и с мобильными приложениями — сам код приложения, шаблоны-картинки-несвежие данные скорее всего уже на клиенте, в кеше, а с сервера нужны только данные, которые подгружаются асинхронно.
И опять-таки клиент отдаёт на сервер то, что знает про сессию, в первом же запросе. И если она протухла — получает отлуп и просьбу перевойти. А поскольку в токене есть ещё и дата протухания, в отличие от сессионной куки — по идее можно ещё и заранее протухание предвидеть в большинстве случаев, и не делать лишнего запроса с отлупом. (Я так никогда не делал, впрочем. Наверное, стоит попробовать.)
Ну, если у атакующего есть XSS, то он в любом случае может отправить любой запрос к нашему серверу от имени угнанного клиента. Этот вариант поэтому исключим из рассмотрения.
В итоге, единственное что сможет сделать атакующий с токеном и не сможет с http-only кукой — это отправить его к себе на сервер.
Соответственно, он получит:
1) возможность прочитать, что там за id и прочие claims в неё зашито. Это он и так бы смог через XSS узнать в любом случае, выцарапывая данные из оттуда, где там они в модели есть.
2) возможность проводить оффлайн-атаку. В подбор серверного секрета я не особо тут верю, он может и должен быть достаточно длинным. SHA256 на одном современном процессоре даёт что-то типа 100 мегабайт в секунду — можно прикинуть количество лет, которое все процессоры земли будут подбирать единственную коллизию «в лоб».
Для более слабых хешей (в частности MD4) существует осуществимая атака по перебору прообразов под заданную подпись — в случае SHA256 она вроде как тоже нереальна, но на всякий пожарный в JWT предусмотрена возможность перетыкать шифроалгоритмы.
Ну, JWT-токен может точно так же иметь уникальный id, указывающий на сессию, по которому статус этого конкретного соединения можно поднять из какого-нибудь редиса.
То есть с этой точки зрения подписанные куки и JWT ничем не отличаются вообще.
Сложный кастомный механизм — это достаточно спорно, по крайней мере `JWT.decode` и `JWT.encode` есть, похоже, для любого языка вообще.
Мне кажется правильным выносить JWT-авторизацию в какую-то прослойку моего фреймворка (типа Rack middleware), который берёт на себя валидацию токена из заголовка запроса и выдаёт отлуп при несовпадении. Там же и какую-то key derivation function можно разместить при необходимости, которая берёт скажем общий секрет и текущую дату, и из них делает актуальный ключ. (И, соответственно, проверяет токен несколькими секретами за последние пару дней, последовательно. Выбор конкретной KDF обосновать сейчас никак не могу, не задумывался над этим.)
Это не очень много кода, достаточно прозрачного. Надо будет гем сварганить как-нибудь на досуге.
PS. Сам предвкушаю продолжение дискуссии со стороны многомудрого Chikey
Выше по треду была приведена ссылка на веб-шелл, зашитый в картинку png.
И да, когда люди говорят про отдельный сервер под статику, они наверняка имеют в виду и отдельный домен тоже (static.example.com, например).
Я правда думал что это из-за изменений в работе СМС-обменников межпровайдерных, которые из-за нового регулирования в РФ криво начали работать. Но это действительно у меня так одно с другим совпало, похоже.
Дальше уже в плюс фичи — групповые чаты, секьюрность, вот это вот всё.
Кстати, глава разработки TextSecure — небезызвестный Moxie Marlinspike. Достаточно забавный кадр.
Многопользовательские чаты есть.
Скорее бы iOS-версия — и заживём.
На сайте в три клика находится вот это: support.whispersystems.org/customer/portal/articles/1473575-is-it-secure-can-i-trust-it-
Кроме того, вот тут утверждается, что собеседник всегда верифицируется, даже по СМС. На то что тулзы для верификации все есть, вроде уже указали.
Для передачи сообщений используется Google Play Services, но поскольку все передаваемые через интернет сообщения зашифрованы end-to-end — расшифровать их всё равно не представляется возможным. (А у Гугла зато инфраструктура бесплатная и отказоустойчивая).
С какой-то ревизии CyanogenMod TextSecure используется в качестве штатной СМСочницы.
В общем я не знаю, в каком там смысле автор замену Скайпу искал, но TextSecure это сейчас мой основной мобильный мессенджер, и полёт пока нормальный.
«Соблюдение план-графика любой ценой» это же и есть недостаток управления.
Хотя казалось бы, тезис о том, что «план это объект управления», и его соответствие реальному состоянию дел должно быть приоритетнее его неизменности — этот тезис должны бы вколачивать на первом курсе любой управленческой школы, эмбиэй-шмембиэй…
Ну то есть представим, что все железки встали в строй за неделю до миграции, а не в последний день. Ну и там что специалисту дали отоспаться, прежде чем что-то куда-то подключать, ломая логические тома…
Мне кажется, что вполне нормально, и никакие опенсорсные определения не нарушаются. Просто лежит такой отдельный конфиг для тех, у кого есть ещ1 и вот эта вот приблуда.
Только чего-то мало в каких нишах у меня есть подобная опция:(
И шифруются они, скорее всего, при помощи cryptsetup, а не Truecrypt.
Вообще же туториал хороший, так держать.
Так что тут вопрос меньше в лицензировании, и больше — именно в приоритизации задач программистов.
Весь кайф этой штуки именно в поиске же, но в последний мой подход к Слаку с падежами он не дружил.
(В саппорт писал, они в курсе. Более того, у них даже серверщик из наших. Но фича в приоритет так и не попала, насколько я понял.)
Автор сделал крутую штуку, давайте все поможем ему чем можем.
Даже больше того, нет необходимости домешивать id клиента в секрет для подписи, достаточно просто иметь (и проверять при запросах) поля ip: или useragent: в токене.
Другое дело, что лично я считаю привязку авторизации к IP-адресу очень неудобным механизмом, чисто из собственного опыта постоянной работы из всяких удалённых мест.
В итоге добавляем айди сессии с привязкой к данным в памяти сервера. Теряем в масштабировании, но сохраняем плюсы «изкоробочной» защиты от CSRF, дружелюбность к произвольным клиентским API и возможность иметь авторизацию «одну-на-всех» и на отдельном хосте.
(Если что — JWT ни в коем раз не «серебряная пуля» для авторизации. И я её «адвокатирую» в первую очередь из интереса попробовать технологию на прочность, постучав её об вдумчивых и проницательных критиков.)
Мобильные приложения с API через JWT дружатся гораздо проще, чем с куками. Никаких лишних запросов в этом случае нет, потому что авторизацию так и так проверять, и обновлять если сессия сдохла.
Ну и многие веб-приложения можно свести к вязанке статики и получению данных по тому же API, что и для мобильных аппов (и мы пару таких приложений делаем в данный момент, например). Тут тот же случай, что и с мобильными приложениями — сам код приложения, шаблоны-картинки-несвежие данные скорее всего уже на клиенте, в кеше, а с сервера нужны только данные, которые подгружаются асинхронно.
И опять-таки клиент отдаёт на сервер то, что знает про сессию, в первом же запросе. И если она протухла — получает отлуп и просьбу перевойти. А поскольку в токене есть ещё и дата протухания, в отличие от сессионной куки — по идее можно ещё и заранее протухание предвидеть в большинстве случаев, и не делать лишнего запроса с отлупом. (Я так никогда не делал, впрочем. Наверное, стоит попробовать.)
В итоге, единственное что сможет сделать атакующий с токеном и не сможет с http-only кукой — это отправить его к себе на сервер.
Соответственно, он получит:
1) возможность прочитать, что там за id и прочие claims в неё зашито. Это он и так бы смог через XSS узнать в любом случае, выцарапывая данные из оттуда, где там они в модели есть.
2) возможность проводить оффлайн-атаку. В подбор серверного секрета я не особо тут верю, он может и должен быть достаточно длинным. SHA256 на одном современном процессоре даёт что-то типа 100 мегабайт в секунду — можно прикинуть количество лет, которое все процессоры земли будут подбирать единственную коллизию «в лоб».
Для более слабых хешей (в частности MD4) существует осуществимая атака по перебору прообразов под заданную подпись — в случае SHA256 она вроде как тоже нереальна, но на всякий пожарный в JWT предусмотрена возможность перетыкать шифроалгоритмы.
Я что-то упустил?
То есть с этой точки зрения подписанные куки и JWT ничем не отличаются вообще.
Сложный кастомный механизм — это достаточно спорно, по крайней мере `JWT.decode` и `JWT.encode` есть, похоже, для любого языка вообще.
Мне кажется правильным выносить JWT-авторизацию в какую-то прослойку моего фреймворка (типа Rack middleware), который берёт на себя валидацию токена из заголовка запроса и выдаёт отлуп при несовпадении. Там же и какую-то key derivation function можно разместить при необходимости, которая берёт скажем общий секрет и текущую дату, и из них делает актуальный ключ. (И, соответственно, проверяет токен несколькими секретами за последние пару дней, последовательно. Выбор конкретной KDF обосновать сейчас никак не могу, не задумывался над этим.)
Это не очень много кода, достаточно прозрачного. Надо будет гем сварганить как-нибудь на досуге.
PS. Сам предвкушаю продолжение дискуссии со стороны многомудрого Chikey
И да, когда люди говорят про отдельный сервер под статику, они наверняка имеют в виду и отдельный домен тоже (static.example.com, например).
Вы не могли бы пояснить свой тезис про утекание секретного ключа с сервера?