"Системный администратор выключил автоматические обновления, чтобы серверы не перезагружались посреди дня."
А нафуа?
Средствами GPO можно настроить расписание установки обновлений. А так же задать диапазон времени для перезагрузки.
Если управления GPO через DC нет, то, кажется м локальными политиками можно достаточно тонко настроить. Или пошаманить со скриптами, включающую службу BITS в определенное время и отключающую после перезагрузки.
Так, прекращение работы приложения - это не причина невозможности управления домофонами, а следствие. Вернее, это явления одного порядка.
Прежде всего разорвалась связь домофонов с облачными серверами. И приложений с облачными серверами. Потому что сервера лежали под 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. Контент передается уже по симметричному шифрованию.
А почему? А потому что пользоваться ассиметричным шифрованием для большого объема информации (или для большого количества малых фрагментов) даже современные компьютеры позволить себе не могут.
И, кроме того, возникает вопрос: а кто будет контролировать (удостоверять) появление новых пользователей с их ключами?
Иначе легко сказать "Я Вася Пупкин, знаю и Гоголя и Пушкина, а всю вашу шоблу на вертеле вертел". И заняться выдачей фейковых ответов, вместо адреса Боба сообщая адрес того-кого-нельзя-называть.
Ох, уж эти сказочки! Ох, уж эти сказочники!
"Системный администратор выключил автоматические обновления, чтобы серверы не перезагружались посреди дня."
А нафуа?
Средствами GPO можно настроить расписание установки обновлений. А так же задать диапазон времени для перезагрузки.
Если управления GPO через DC нет, то, кажется м локальными политиками можно достаточно тонко настроить. Или пошаманить со скриптами, включающую службу BITS в определенное время и отключающую после перезагрузки.
В общем, решения есть на любой вкус.
Какой сисвдмин, такой и результат.
Скоро на сушу попрут.
Так, прекращение работы приложения - это не причина невозможности управления домофонами, а следствие. Вернее, это явления одного порядка.
Прежде всего разорвалась связь домофонов с облачными серверами. И приложений с облачными серверами. Потому что сервера лежали под 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:
И, кроме того, возникает вопрос: а кто будет контролировать (удостоверять) появление новых пользователей с их ключами?
Иначе легко сказать "Я Вася Пупкин, знаю и Гоголя и Пушкина, а всю вашу шоблу на вертеле вертел". И заняться выдачей фейковых ответов, вместо адреса Боба сообщая адрес того-кого-нельзя-называть.