Так, прекращение работы приложения - это не причина невозможности управления домофонами, а следствие. Вернее, это явления одного порядка.
Прежде всего разорвалась связь домофонов с облачными серверами. И приложений с облачными серверами. Потому что сервера лежали под DDoS.
А открыть при помощи электронного ключа можно было по простой причине: домофон, как и большинство СКУД-терминалов, имеет кэш. Т.е. ему не обязательно каждый раз обращаться к серверам, чтобы проверить корректность ключа. Т.к. ключами пользовались не все, то кэш не переполнялся и не сбрасывался.
А зачем смарту для NFC подключение к провайдеру по Wi-Fi?
Это домофон должен быть подключен к определенному провайдеру. А по Wi-Fi или по шнурку - без разницы.
Сейчас даже многие платежные системы позволяют смартом расплачиваться без доступа к Интернету и даже без доступа к сотовому оператору. Но не Мир-пэй. Там требуется постоянная проверка токенов. Так что, в момент оплаты они могут потребовать актуализацию.
Возможно, что инфраструктура разбита на сайты доступности. И подключение к облачным серверам возможно только с конкретных IP конкретного провайдера. Как раз с целью недопущения конкурентов.
Вот сначала делают всё возможное, чтобы сократить число провайдеров (а мелких - совсем убить), а потом начинают рвать волосы на ж..., что нет резервирования.
А при чем тут кластер и то, на чьей стороне проверяется сертификат?
ВасяПупкин при том, что в централизованной системе априори полагается доверие к серверу аутотентификации. Во-первых, что он ошибочно не позволит кому либо аутентифицироваться под чужим логином, Во-вторых, что БД хешей паролей достаточно защищена, а сами хеши криптостойки.
Как достичь такого же уровня доверия (и возможно ли это в принципе) в децентрализованной пиринговой сети - вот в чем вопрос.
Задача решается простая - полностью ликвидируется доступ к несоленому хешу, чтобы исключить атаку повторением.
А я откуда знаю? Разумеется, он находится не на кластере обработчиков запросов, а где-то глубже в сети.
Но у них централизованная сеть. Т.е. регистрацией и аутентификацией занимается некий единственный центр, а не размазано это по всей пиринговой сети.
Как это нет? Вы прошли регистрацию, зарегистрировали пользователя ВасяПупкин. Возможно, привязали почту, телефон, включили двухфакторную аутентификацию. Теперь, при вводе логина/пароля система будет знать, что в нее входит подтвержденный пользователь (не физлицо, а владелец аккаунта) ВасяПупкин.
Т.е. данные для аутентификации где-то хранятся и где-то обрабатываются и подтверждаются. Но как сделать это в открытых пиринговых сетях, где централизованной регистрации нет, а децентрализованное хранение опасно, как его не защищай?
Кстати, пришла такая идея в голову по поводу централизованного хранения хешей паролей:
Хеши хранятся на отдельном сервере, куда нет прямого доступа пользователя. Т.е. запросы принимаются только от backend-серверов и не напрямую к СУБД, а через некоторое API.
При попытке подключения пользователя на этом отдельном сервере создается идентификатор неоткрытой сессии, являющийся одновременно "солью" с ограниченным временем годности".
Пользователь хеширует пароль, приписывает соль, снова хеширует. Передает логин, соль и дважды хешированный пароль.
Всё это передается на сервер аутентификации. Если соль еще не протухла (идентификатор неоткрытой сессии не исчерпал срок действия), тот по логину находит хеш пароля, приписывает соль, хеширует и сравнивает с тем, что пришло. И выдаёт либо отлуп, либо сессионный билет.
Таким образом, несоленый хеш никогда не покидает сервер аутентификации. Исключение - запись его в ходе регистрации. Но это уже другая история, не связанная с хранением хешей паролей.
Осталось решить вопрос, как защитить сессионный билет при работе по HTTP.
У Хабра кластера, похоже, нет - мелковат будет. Хотя, одна точка входа еще не гарантирует, что за ней нет распараллеливания потоков на несколько веб серверов (хотя, при одном входе это почти бессмысленно).
А вот Яндекс, Мэйл.ру, Амазон, Гугл и другие гиганты имеют из 2-3-4 точки входа на сайты. У Гугла их, как минимум, 6.
Это делается как для балансировки нагрузки, так и для повышения отказоустойчивости.
Эта обработка (выполняется даже быстрее) по большей части возлагается на кластер специально обученных серверов. Клиент только генерит сеансовый ключ и шифрует его переданным сервером открытым ключом.
В случае пиринговой сети уже каждому клиенту придется постоянно и шифровать и расшифровывать сообщения. А клиенты бывают разные!
Не нашел цифр по шифрованию AES-ключа, но проверка ЭЦП на 64-битном XEOM 3,1 GHz занимает от 100000 до 10000000 тактов процессора. Что существенно.
Думаю, слабые клиенты будут не рады.
P.S. А еще есть такая штука, как распространение новых ключей взамен протухших.
Надо освежить в памяти задачу о византийских генералах-предателях. Суть - выработка согласованного решения в условиях злонамеренного искажения информации частью узлов.
К исходной задаче это отношение имеет слабое. Но всё равно полезно.
И тем не менее, в HTTPS ассиметричное шифрование RSA применяется только во время "рукопожатия" с целью выработки сеансового ключа AES. Контент передается уже по симметричному шифрованию.
А почему? А потому что пользоваться ассиметричным шифрованием для большого объема информации (или для большого количества малых фрагментов) даже современные компьютеры позволить себе не могут.
И, кроме того, возникает вопрос: а кто будет контролировать (удостоверять) появление новых пользователей с их ключами?
Иначе легко сказать "Я Вася Пупкин, знаю и Гоголя и Пушкина, а всю вашу шоблу на вертеле вертел". И заняться выдачей фейковых ответов, вместо адреса Боба сообщая адрес того-кого-нельзя-называть.
Нет, похоже, это Вы не понимаете, что предлагаете просто вложить в эту систему готовую DDoS атаку на саму себя.
Даже DHT-запросы в торрент-клиентах вызывают кратковременные сетевые штормы. Но они затрагивают только каналы связи, а не клиентские машины, т.к. вычисление хешей даже по SHA-1 - достаточно легковесная процедура.
А вот аутентификация по открытому ключу - это уже серьезно будет нагружать компьютеры и устройства пользователей. И это будет работать примерно так:
Алиса хочет связаться с Бобом, но не знает его адреса.
Алиса посылает запрос "Где Боб" Кэрол и Тренту, удостоверив его своей цифровой подписью (эту нагрузку пока что можно игнорировать).
Но Кэрол и Трент уже забыли, кто такая Алиса (не имеют её публичного ключа).
Они начинают рассылать запросы "Кто такая Алиса?" по всем своим знакомым, подписывая своей ЭЦП (вот появилась первая нагрузка на промежуточные узлы).
Знакомые, допустим, знают Кэрол и Трента (имеют их публичные ключи). Но чтобы убедиться, что сообщение пришло от них, должны расшифровать их ЭЦП и удостовериться в их целостности и непротиворечивости.
Допустим, они знают Алису и могут сообщить Кэрол и Тренту ее публичный ключ.
Кэрол и Трент, слегка успокоившись, приступают к обработке запроса Алисы.
Но они тоже не знают, где Боб. Так что поиск с шифрованием/расшифровыванием запросов продолжается.
В конце концов TTL первоначального запроса исчерпывается или все же находится кто-то, кто знает и где Боб и запрашивающего.
Тогда он отвечает и отправляет ответ обратно, подписывая своей ЭЦП.
Ответ проходит уже без поиска пути назначения, но всё равно узлам по всей цепочке надо удостовериться, что информация пришла от того, от кого надо. Т.е. опять тягомотина с расшифровыванием и шифрованием.
Наконец, информация о Бобе приходит к Алисе.
Та, радостная, шлет ему сакраментальное "Hello Bob!"
Но Боб тоже успел забыть, кто такая Алиса.
И шлет по всем своим знакомым запрос "Who is fu***ng Alice?"
Достаточно знать сам хеш пароля. А он уже будет известен.
Обычно де при аутентификации передается пара (логин, хеш пароля). Но этот метод уязвим перед "атакой повтором". Перехватив один раз передаваемый хеш, можно затем передавать самому.
Для противодействия этому применяют динамическое соление. Каждый раз, при аутентификации клиенту передается некая случайеая "соль". Она дописывается к хешу пароля м снова хешируется. При получении такого двойного хеша сервер тоже берет хранимый хеш пароля, дописывает к нему "соль", если она еще не "протухла" и снова хеширует. Потом сравнивает с тем, что пришло.
Т.е. таким образом передается всегда разный хеш. Это помогает от перехвата.
Но не помогает, если тот-кого-нельзя-называть получит доступ к устройству с хранящимся несолёным хешем пароля.
Так, прекращение работы приложения - это не причина невозможности управления домофонами, а следствие. Вернее, это явления одного порядка.
Прежде всего разорвалась связь домофонов с облачными серверами. И приложений с облачными серверами. Потому что сервера лежали под DDoS.
А открыть при помощи электронного ключа можно было по простой причине: домофон, как и большинство СКУД-терминалов, имеет кэш. Т.е. ему не обязательно каждый раз обращаться к серверам, чтобы проверить корректность ключа. Т.к. ключами пользовались не все, то кэш не переполнялся и не сбрасывался.
А при чем тут приложение "Домофон ПИК", транслирующее видео с домофона на смартфон хозяина квартиры через облачные сервера?
При этом, звонящий по домофону (обычным кнопочным набором) вообще телефон иметь не обязан.
И где домофон и где шлагбаум? Радиус действия сигнала NFC - до 10 см. Так что, для управления шлагбаумом, тем более со смарта, он вряд ли пригоден.
А зачем смарту для NFC подключение к провайдеру по Wi-Fi?
Это домофон должен быть подключен к определенному провайдеру. А по Wi-Fi или по шнурку - без разницы.
Сейчас даже многие платежные системы позволяют смартом расплачиваться без доступа к Интернету и даже без доступа к сотовому оператору. Но не Мир-пэй. Там требуется постоянная проверка токенов. Так что, в момент оплаты они могут потребовать актуализацию.
Возможно, что инфраструктура разбита на сайты доступности. И подключение к облачным серверам возможно только с конкретных IP конкретного провайдера. Как раз с целью недопущения конкурентов.
А другую вселенную руки Мантрида успешно переработали.
Это яйца инопланетных форм. Вот будет веселуха, когда пробирки на Земле откроют.
Вот сначала делают всё возможное, чтобы сократить число провайдеров (а мелких - совсем убить), а потом начинают рвать волосы на ж..., что нет резервирования.
Совсем страх и совесть потеряли.
Я у себя недавно менял брелоки. Вместе с записью информации - 1000р. А раньше было вообще 500.
Домофоны не странные. Скорее всего, они могут работать и по NFC через облако и от ключа - магнитного, брелока Em-Marine или "таблетки" RW1990.
Но жильцы же умные! Зачем им покупать брелоки или что там используется, если и от смартика всё работает?
А при чем тут кластер и то, на чьей стороне проверяется сертификат?
ВасяПупкин при том, что в централизованной системе априори полагается доверие к серверу аутотентификации. Во-первых, что он ошибочно не позволит кому либо аутентифицироваться под чужим логином, Во-вторых, что БД хешей паролей достаточно защищена, а сами хеши криптостойки.
Как достичь такого же уровня доверия (и возможно ли это в принципе) в децентрализованной пиринговой сети - вот в чем вопрос.
Задача решается простая - полностью ликвидируется доступ к несоленому хешу, чтобы исключить атаку повторением.
А я откуда знаю? Разумеется, он находится не на кластере обработчиков запросов, а где-то глубже в сети.
Но у них централизованная сеть. Т.е. регистрацией и аутентификацией занимается некий единственный центр, а не размазано это по всей пиринговой сети.
Как это нет? Вы прошли регистрацию, зарегистрировали пользователя ВасяПупкин. Возможно, привязали почту, телефон, включили двухфакторную аутентификацию. Теперь, при вводе логина/пароля система будет знать, что в нее входит подтвержденный пользователь (не физлицо, а владелец аккаунта) ВасяПупкин.
Т.е. данные для аутентификации где-то хранятся и где-то обрабатываются и подтверждаются. Но как сделать это в открытых пиринговых сетях, где централизованной регистрации нет, а децентрализованное хранение опасно, как его не защищай?
Кстати, пришла такая идея в голову по поводу централизованного хранения хешей паролей:
Хеши хранятся на отдельном сервере, куда нет прямого доступа пользователя. Т.е. запросы принимаются только от backend-серверов и не напрямую к СУБД, а через некоторое API.
При попытке подключения пользователя на этом отдельном сервере создается идентификатор неоткрытой сессии, являющийся одновременно "солью" с ограниченным временем годности".
Пользователь хеширует пароль, приписывает соль, снова хеширует. Передает логин, соль и дважды хешированный пароль.
Всё это передается на сервер аутентификации. Если соль еще не протухла (идентификатор неоткрытой сессии не исчерпал срок действия), тот по логину находит хеш пароля, приписывает соль, хеширует и сравнивает с тем, что пришло. И выдаёт либо отлуп, либо сессионный билет.
Таким образом, несоленый хеш никогда не покидает сервер аутентификации. Исключение - запись его в ходе регистрации. Но это уже другая история, не связанная с хранением хешей паролей.
Осталось решить вопрос, как защитить сессионный билет при работе по HTTP.
У Хабра кластера, похоже, нет - мелковат будет. Хотя, одна точка входа еще не гарантирует, что за ней нет распараллеливания потоков на несколько веб серверов (хотя, при одном входе это почти бессмысленно).
А вот Яндекс, Мэйл.ру, Амазон, Гугл и другие гиганты имеют из 2-3-4 точки входа на сайты. У Гугла их, как минимум, 6.
Это делается как для балансировки нагрузки, так и для повышения отказоустойчивости.
Не сойдутся подписи с кем?
Мы же не знаем публичного ключа Боба заранее. И если кто-то нам подсунет фейковый адрес и публичный ключ, мы поверим ему.
Эта обработка (выполняется даже быстрее) по большей части возлагается на кластер специально обученных серверов. Клиент только генерит сеансовый ключ и шифрует его переданным сервером открытым ключом.
В случае пиринговой сети уже каждому клиенту придется постоянно и шифровать и расшифровывать сообщения. А клиенты бывают разные!
Не нашел цифр по шифрованию AES-ключа, но проверка ЭЦП на 64-битном XEOM 3,1 GHz занимает от 100000 до 10000000 тактов процессора. Что существенно.
Думаю, слабые клиенты будут не рады.
P.S. А еще есть такая штука, как распространение новых ключей взамен протухших.
Надо освежить в памяти задачу о византийских генералах-предателях. Суть - выработка согласованного решения в условиях злонамеренного искажения информации частью узлов.
К исходной задаче это отношение имеет слабое. Но всё равно полезно.
И тем не менее, в HTTPS ассиметричное шифрование RSA применяется только во время "рукопожатия" с целью выработки сеансового ключа AES. Контент передается уже по симметричному шифрованию.
А почему? А потому что пользоваться ассиметричным шифрованием для большого объема информации (или для большого количества малых фрагментов) даже современные компьютеры позволить себе не могут.
Т.е. никакого подтверждения на право делать запросы не требуется?
Зашибись! Вот поэтому и появляются всякие фейковые DHT-агрегаторы, раз никто ничего не контролирует.
UPD:
И, кроме того, возникает вопрос: а кто будет контролировать (удостоверять) появление новых пользователей с их ключами?
Иначе легко сказать "Я Вася Пупкин, знаю и Гоголя и Пушкина, а всю вашу шоблу на вертеле вертел". И заняться выдачей фейковых ответов, вместо адреса Боба сообщая адрес того-кого-нельзя-называть.
Криптография с открытым ключом, а не хеширование?
Нет, похоже, это Вы не понимаете, что предлагаете просто вложить в эту систему готовую DDoS атаку на саму себя.
Даже DHT-запросы в торрент-клиентах вызывают кратковременные сетевые штормы. Но они затрагивают только каналы связи, а не клиентские машины, т.к. вычисление хешей даже по SHA-1 - достаточно легковесная процедура.
А вот аутентификация по открытому ключу - это уже серьезно будет нагружать компьютеры и устройства пользователей. И это будет работать примерно так:
Алиса хочет связаться с Бобом, но не знает его адреса.
Алиса посылает запрос "Где Боб" Кэрол и Тренту, удостоверив его своей цифровой подписью (эту нагрузку пока что можно игнорировать).
Но Кэрол и Трент уже забыли, кто такая Алиса (не имеют её публичного ключа).
Они начинают рассылать запросы "Кто такая Алиса?" по всем своим знакомым, подписывая своей ЭЦП (вот появилась первая нагрузка на промежуточные узлы).
Знакомые, допустим, знают Кэрол и Трента (имеют их публичные ключи). Но чтобы убедиться, что сообщение пришло от них, должны расшифровать их ЭЦП и удостовериться в их целостности и непротиворечивости.
Допустим, они знают Алису и могут сообщить Кэрол и Тренту ее публичный ключ.
Кэрол и Трент, слегка успокоившись, приступают к обработке запроса Алисы.
Но они тоже не знают, где Боб. Так что поиск с шифрованием/расшифровыванием запросов продолжается.
В конце концов TTL первоначального запроса исчерпывается или все же находится кто-то, кто знает и где Боб и запрашивающего.
Тогда он отвечает и отправляет ответ обратно, подписывая своей ЭЦП.
Ответ проходит уже без поиска пути назначения, но всё равно узлам по всей цепочке надо удостовериться, что информация пришла от того, от кого надо. Т.е. опять тягомотина с расшифровыванием и шифрованием.
Наконец, информация о Бобе приходит к Алисе.
Та, радостная, шлет ему сакраментальное "Hello Bob!"
Но Боб тоже успел забыть, кто такая Алиса.
И шлет по всем своим знакомым запрос "Who is fu***ng Alice?"
Развлекуха продолжается.
How do you like this Elon Musk?
А зачем узнавать пароль?
Достаточно знать сам хеш пароля. А он уже будет известен.
Обычно де при аутентификации передается пара (логин, хеш пароля). Но этот метод уязвим перед "атакой повтором". Перехватив один раз передаваемый хеш, можно затем передавать самому.
Для противодействия этому применяют динамическое соление. Каждый раз, при аутентификации клиенту передается некая случайеая "соль". Она дописывается к хешу пароля м снова хешируется. При получении такого двойного хеша сервер тоже берет хранимый хеш пароля, дописывает к нему "соль", если она еще не "протухла" и снова хеширует. Потом сравнивает с тем, что пришло.
Т.е. таким образом передается всегда разный хеш. Это помогает от перехвата.
Но не помогает, если тот-кого-нельзя-называть получит доступ к устройству с хранящимся несолёным хешем пароля.