Русский
Русский
English
Статистика
Реклама

Регистрация

Перевод Радости обладания коротким емейл-адресом

22.09.2020 12:22:19 | Автор: admin
Если у вас есть короткий емейл-адрес у популярного емейл-провайдера, вы непременно будете получать горы спама, а также немало предупреждений о том, что разные случайные люди пытаются получить к нему доступ. Если имя вашего емейл-адреса короткое и достаточно привлекательное, из-за этой возни учётная запись перестаёт быть надёжной для повседневных коммуникаций, потому что важные письма будут погребены под горой остальных. Однако у этой ситуации есть и неожиданная сторона: случайные люди периодически используют ваш адрес так, как будто он принадлежит им, при этом частенько с достаточно чувствительными онлайн-сервисами.

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

Такие короткие имена учётных записей называют OG, что расшифровывается, как original gangster [или original gametag / прим. перев.]. Эти учётки ценятся достаточно высоко в определённых кругах, члены которых пытаются взломать их для личного пользования или перепродажи. Отсюда и постоянные напоминания.

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

Что меня поражает, так это количество финансовых и иных чувствительных сервисов, к которым я мог бы получить доступ, будь я злоумышленником. У моего адреса есть учётные записи, которых я не собирался заводить, в таких сервисах, как H&R Block, Turbotax, TaxAct, iTunes, LastPass, Dashlane, MyPCBackup и Credit. Я уже потерял счёт количеству банков, провайдеров интернета и веб-хостингов, в которые я могу залогиниться.

Меня не устаёт поражать, какое количество других пользователей Gmail и других крупных вебмейл-провайдеров решили использовать мой адрес в качестве запасного, на случай, если они потеряют доступ к своему почтовому ящику. Почти наверняка они просто поленились и вбили название моего адреса, пришедшее им на ум, когда их спросили насчёт резервной почты видимо, не полностью понимая потенциальные проблемы такого подхода. Когда я проверял в последний раз, мой адрес был зарегистрирован в качестве запасного в десятке учёток на Yahoo, Microsoft и других Gmail-адресов и соответствующих им сервисов обмена файлами.

Если по какой-либо причине мне захочется заказать еду или доставку лекарств, мне пригодятся мои фантомные учётные записи в Chewy, Coupaw и Petco. Если сломаются какие-то компоненты гриля Weber, я обеспечен ими по гроб жизни. Письма от Weber, которые я периодически получаю, напоминают мне о статье, которую я много лет назад написал для The Washington Post о компаниях, отправляющих письма с адресов типа [companynamehere]@donotreply.com, не задумываясь о том, что такой домен кому-то может принадлежать. Некоторые поступали таким образом, часто с забавными результатами.

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

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

В конечном счёте я понял, что лучше не задавать таких вопросов. Многократно я тратил несколько минут, пытаясь понять, создавались ли емейл-адреса, использующие мой адрес в качестве резервного, людьми или какими-нибудь спам-ботами. И потом я отправлял им письма, если это были люди, с разъяснениями о том, почему это плохая идея, и с вопросами о том, что подвигло их на такие действия.

Возможно потому, что название моей почты на Gmail связано с хакерами, некоторые ответы оказывались достаточно неприятными. Несмотря на то, что к письму я прикладывал подробную инструкцию по тому, как исправить ситуацию, одна женщина из Флориды наорала на меня КАПС ЛОКОМ, заявив, что я пытаюсь её обмануть, и что её муж-полицейский скоро меня найдёт. Увы я до сих пор получаю уведомления каждый раз, когда она заходит в свою учётку на Yahoo.

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

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

Что более важно, убедитесь, что пользуетесь наиболее безопасным вариантом многофакторной авторизации из всех, что предлагает ваш провайдер. Это могут быть одноразовые коды, отправляемые по почте, телефонные звонки, SMS или мобильное приложение, или более надёжная двухфакторная авторизация или 2FA (что-то, что у вас есть, и что-то, что вы знаете) ключи безопасности или пуш-уведомления.

Одноразовые коды, отправляемые по емейлу, SMS или через приложение, считаются менее надёжными с точки зрения безопасности, потому что их можно обойти с применением разнообразных и хорошо проработанных сценариев атаки, от подмены SIM до мобильных вирусов. Поэтому имеет смысл пользоваться наиболее надёжными вариантами многофакторной авторизации. Однако всё равно учтите, что даже если посещаемый вами сайт предлагает только SMS и/или телефонные звонки, это всё равно надёжнее, чем простой пароль, на который вы полагаетесь для защиты вашей учётной записи.

Возможно, вы отложили вопрос включения многофакторной авторизации в важных для вас учётках, и если это так, посетите сайт twofactorauth.org, чтобы узнать, можете ли вы усилить безопасность своих записей.

Как я уже отмечал в одной из предыдущих статей, "Включите многофакторную авторизацию до того, как за вас это сделают мошенники", люди, не пользующиеся преимуществами дополнительной защиты, могут обнаружить, что им гораздо сложнее будет восстановить доступ к своим данным, когда их учётную запись взломают поскольку воры всё чаще включают многофакторную авторизацию, привязывая учётку к устройству, которое они контролируют.
Подробнее..

Интернет вещей по-русски. Процедура активации OpenUNB

28.02.2021 12:13:00 | Автор: admin

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


Чтобы сделать протокол защищенным, нужно разделять между двумя сторонами некоторую информацию, неизвестную третьим лицам. Это реализуется через разделения одинакового ключа. Для защиты от повторов этого недостаточно. Необходимо, чтобы эти две стороны разделяли еще некоторую информацию, которая даже не должна быть секретной, а может быть известна всем.


В обычных, двусторонних системах такая информация вставляется в передаваемый информационный пакет. Грубо говоря, пакеты нумеруются. В экономичных система передачи типа Интернета вещей такой метод расточителен. В таких системах выгоднее вести счетчики времени на двух сторонах отдельно, а не передавать его в пакете. В стремлении к совершенству, так и было сделано в OpenUNB.


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


В OpenUNB активация устройства производится пользователем. Также необходим доверенный канал между пользователем и сервером сети. Схема взаимодействия представлена ниже:


image


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


В стадии "запрос на активацию" пользователь должен по служебному каналу отправить на сервер запрос на активацию, в котором передается идентификатор DevID активируемого конечного устройства. Если активация возможна, то сервер сообщает об этом. Далее пользователь делает "запуск процедуры активации на устройстве". Это может быть пакет по радио-интерфейсу или другому, удобному. Это также может быть нажатие кнопки "активация" или просто включение питания устройства. После этого события устройство передает "служебный пакет активации", в котором содержится номер текущей активации.


Если сервер правильно (совпадает имитовставка MIC) получает сообщение обо активации от устройства по каналу OpenUNB, то он индицирует пользователю "подтверждение успешной активации". После этого пакеты данных могут передаваться защищенно.


Рассмотрим подробно процедуру со стороны устройства и со стороны сервера.


Со стороны устройства процедура выглядит так:


  1. проверяется текущее значение счетчика активаций Na. Если счетчик активаций уже достиг максимально возможного значения, то данное устройство больше не может использоваться, и выключается;
  2. увеличивается значение счетчика активаций: Na = Na + 1;
  3. вырабатывается ключ активации Ka;
  4. вырабатывается ключ расчета имитовставки Km для эпохи Ne = 0;
  5. формируется служебный пакет активации, в поле MACPayload которого содержится текущее значение счетчика активаций Na, а в качестве адреса указывается DevAddr0 = CRC24(DevID). При этом поле MACPayload передается в открытом виде (не шифруется), а поле имитовставки MIC рассчитывается на ключе Km для номера Nn = 0. Сформированный служебный пакет активации должен быть отправлен MAX_PKT_TX_NUM раз подряд для повышения вероятности его доведения;
  6. устройство считает активацию успешно завершенной и может передавать пакеты полезных данных.

Напомним формат пакета OpenUNB:
image


Сервер по приему пакета активации ищет адрес из пакета в списке адресов активированных устройств. Для каждого из найденных совпадений:


  1. сохраняется полученное значение счетчика активаций устройства Na. Если для данного устройства ранее уже осуществлялась успешная активация, то сервер должен дополнительно проверить, что текущее значение Na больше чем значение Na, полученное при предыдущей успешной активации. Если эта проверка завершается неуспешно, то сервер переходит к следующему найденному устройству;
  2. вырабатывается ключ активации Ka;
  3. вырабатывается ключ расчета имитовставки Km для эпохи Ne = 0;
  4. для пакета проверяется совпадение имитовставки MIC на ключе Km для номера Nn = 0.

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


Детали работы процедур активации OpenUNB смотрите в первоисточнике на сайте Сколтеха.


Реализованные процедуры активации и другие процедуры безопасности доступны в исходниках здесь.


Наш бессменный мастер Интернета вещей deef137 всегда на связи и готов помочь с вопросами по коду.

Подробнее..

Интернет вещей по-русски. Безопасность в OpenUNB

08.03.2021 14:16:44 | Автор: admin

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


Для иллюстрации актуальности я приведу в пример протокол CRISP, кстати, отечественной разработки. Наличие такой разработки, доведенной уже до статуса методических рекомендаций Технического комитета по стандартизации "Криптографическая защита информации", подтверждает практическую непригодность обычных "тяжелых" протоколов безопасности для Интернета вещей. Они оказываются слишком ресурсоемкими.


Различных радио-протоколов Интернета вещей сейчас наплодилось огромное множество, но в сфере LPWAN не везде разработчики протокола передачи берут на себя тяжелую ношу защиты информации. Можно долго спорить, нужно ли вообще включать защиту в радио-протокол LPWAN, а не перекладывать ее на вышележащие уровни, но если предложенная схема хороша, то стоит надеяться на большую вероятность внедрения стандарта в индустрию. Главный тезис: вообще без защиты в Интернете вещей сейчас уже нельзя. И она должна быть на уровне.


Так же рассуждали и разработчики OpenUNB, ставя во главу угла энергоэффективность и встроенную безопасность информации. Тем, кто еще ничего не знает про OpenUNB, я советую прочитать предыдущие статьи на эту тему:



а также изучить первоисточник на сайте Сколтеха.


Сегодня мы рассмотрим механизм криптографической защиты передаваемых данных (шифрование, контроль целостности и подлинности).


Чтобы обеспечить базу безопасности, у каждого устройства и сервера должно быть что-то общее, секретное, которое никто не знает. В OpenUNB это секретный ключ шифрования K0, имеющий длину k, равную 128 или 256 бит. Весь остальной протокол должен быть сделан так, чтобы этот базовый, основной ключ не стал бы известен никому никаким образом, а информация при этом была защищена. Поэтому базовый ключ претерпевает такое множество преобразований в своем стремлении встретиться с информацией.


Ключ K0 используется только для формирования (порождения) рабочих ключей, которые непосредственно используются в процедуре криптографической защиты данных. (Чтобы лучше понимать последующее повествование, прочитайте статьи о канальном уровне: первую и вторую). Хотя, я думаю, специалисту по безопасности все должно быть понятно и так.


В недрах устройства и сервера OpenUNB есть счетчик активаций Na и счетчик эпох Ne, которые остаются примерно одинаковыми в процессе работы системы. Сначала вырабатывается ключ активации:


$ Ka = CTR (K0, Na || 0^{n/2-16}, 0^k).$


Потом уже по ключу активации вырабатываются рабочие ключ шифрования Km и ключ имитозащиты Ke:


$ Km = CTR (Ka, 0x02 || Ne || 0^{n/2-32}, 0^k),$


$ Ke = CTR (Ka, 0x03 || Ne || 0^{n/2-32}, 0^k).$


Для криптографических преобразований разработчики OpenUNB рекомендуется использовать блочный шифр Магма, который имеет длину блока n = 64 бита и длину ключа k = 256 бит, определенный в стандарте ГОСТ Р 34.12-2015.


Шифрование выглядит так:


$ EncryptedMACPayload = CTR (Ke, Nn || 0^{n/2-16}, MACPayload),$


где Nn номер пакета, а выработка имитовставки так:


$MIC = CMAC24 (Km, P),$


где значение вектора P зависит от длины блока n и длины поля MACPayload. Пусть len
однобайтная целочисленная беззнаковая переменная, равная длине полезных данных
MACPayload в битах (переменная len может принимать значения 16 или 48), тогда:


если len = 48 и n = 64, то


$P = DevAddr || MACPayload || Nn || 0^{2n-len-48} || len;$


в остальных случаях


$P = DevAddr || MACPayload || Nn || 0^{n-len-48} || len.$


Процедура CMAC24 здесь это криптопреобразование "режим выработки имитовставки" согласно ГОСТ.


Далее эти поля вставляются на свои места. Напомним схему формирования пакета:
image


Более подробно, со всеми деталями, вы можете прочитать о безопасности в OpenUNB в первоисточнике.


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


Как всегда, исходники крипто-преобразований от deef137 доступны на Github.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru