Перейти к содержанию

Рекомендуемые сообщения

Опубликовано

Пароли никто не любит. Их долго вводить, трудно запоминать, а все эти условия «нужны цифра, буква в верхнем регистре и рог единорога» делают задачу создания пароля еще сложнее. Но если использовать везде один и тот же пароль или ограничиваться простыми короткими паролями, вас рано или поздно взломают. Как сочетать удобство ввода, запоминаемость и стойкость ко взлому? Интересный, хотя и неоднозначный способ — использовать в пароле эмодзи, те самые смайлики 😁 и прочие значки 🔐, которые мы щедро рассыпаем в чатах и постах в соцсетях.

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

Чем хороши эмодзи в паролях?

Эмодзи очень много, поэтому пароль может быть вдвое короче. Когда злоумышленники пытаются подобрать пароль из букв, цифр и знаков пунктуации, для каждого символа пароля им нужно перепробовать менее сотни вариантов. Но стандартизованных эмодзи в Unicode более 3600, и, если в пароль добавить смайлик, то для каждого знака придется перебрать уже около 3700 вариантов. Так что по сложности подбора пароль из пяти разных смайлов эквивалентен обычному паролю из девяти символов, а семь эмодзи — вспомним комбинаторику — тянут уже на серьезный пароль из 13 «обычных» символов.

Некоторые новые эмодзи из стандарта Unicode

Некоторые новые эмодзи из стандарта Unicode

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

 

Посмотреть статью полностью

Опубликовано

Осспаде, как же плохо у Стана. Серьёзно, откуда он? Почему его постоянно публикуют?

 

Quote

Эмодзи очень много, поэтому пароль может быть вдвое короче.

Почему вдвое? Смотри, Стан: 🏳️‍🌈 Это флаг ЛГБТ. Он занимает не 2 символа. Смотрим: https://emojipedia.org/rainbow-flag#technical

  • первые 2 символа юникода - это белый флаг
  • ещё один символ юникода - это технический символ, который связывает воедино то, что справа и слева от него
  • последний символ юникода - радуга

Итого длина не 2, а 4. Но и это ещё не всё. Если считать в байтах, то ещё больше. Мы знаем, что UTF-8 (говорим "юникод", подразумеваем "utf-8" - любого спроси) кодируется переменной длиной от одного до четырёх байт на символ. В смысле в UTF-8 один символ может занимать как 1 байт, так и 4 байта. К примеру буква "ф" (русская, маленькая) в UTF-8 будет занимать 2 байта. Желающие могут вооружиться тем же Питоном и проверить:

 

len('ф') # длина строки
1
len(bytearray('ф', 'utf-8')) # длина в байтах
2

 

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

 

len('🏳️‍🌈')
4
len(bytearray('🏳️‍🌈', 'utf-8'))
14

 

Итого на 4 символа юникода пришлось 14 байт!

 

То есть как не считай, не бьётся твоё утверждение с "вдвое". Ни по байтам, ни по символам. Но это ладно, это я тебе прощаю. Важно тут совсем другое. Смотри какая штука:

Screenshot_20231027_195509.thumb.png.d021e64f881575ea819f7404698472dd.png

Это всё - один и тот же символ. Но где-то он отображается как один флаг, а где-то - как белый флаг и радуга (символ склейки не отображается визуально вовсе). Разные программы по-разному рисуют символ, потому что где-то уже есть новый набор, где-то ещё нет. А ведь это всё у меня в пределах одной ОС на одном компе. В итоге высока вероятность, что пользователь будет вводить символ флага в одном приложении и будет его видеть. А потом в другом и получит 2 символа (визуально). И обалдеет, и будет переживать и не будет понимать, что всё в порядке, просто другое приложение ещё не имеет нужной версии либы с эмодзи. И пойдём дальше. Где-то введёт беременного мужика, а в другом месте этот символа ни одним изображением, ни тремя - не будет. И что делать?

 

И даже это ещё не всё, но этого уже достаточно для того, чтобы не использовать эмодзи. Вторая проблема в том, что хоть эмодзи закодирован пятью символами, хоть сотней - вообще пофигу, т.к. для хранения используется хеш. Важно то, что один эмодзи - это всё равно один символ. И когда эмодзи будут популярны, их точно также будут использовать для создания радужных таблиц. И этот ЛГБТ флаг всё равно будет равен одному символу пароля. Эмодзи - это просто ещё один алфавит и воспринимать его надо именно так.

 

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

 

Ну и да, твоё "Эмодзи труднее вводить". https://emojipedia.org/ Пиши название и копируй. Не надо с альтом ничего тыкать. Это раз. Во всех популярных ОС есть emoji picker (то есть программа, где можно тыкать мышкой в таблицу с эмодзи и он будет копироваться). Это два. Ты опять не шаришь - это три.

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • KL FC Bot
      Автор KL FC Bot
      Прошедший 2025 год стал рекордным по числу атак на Android-устройства. Мошенники эксплуатируют несколько горячих трендов: интерес пользователей к ИИ-приложениям, желание обойти блокировки доступа к сайтам или проверку возраста на входе, стремление сэкономить при покупке смартфона, повсеместное распространение банковских и платежных сервисов, а также популярность NFC. Разбираемся в основных угрозах 2025–2026 годов и выясняем, как защитить свой Android-смартфон в новых условиях.
      Установка из посторонних источников
      Вредоносные установочные пакеты (файлы APK) всегда были основной угрозой для Android-устройств, несмотря на многолетние усилия Google по укреплению защиты Android. Используя sideloading — установку нового приложения из APK-файла вместо загрузки из магазина приложений — можно установить любые приложения, включая откровенно вредоносные. Ни внедрение Google Play Protect, ни различные ограничения прав для установленных неизвестно откуда приложений не уменьшили масштаб проблемы.
      По предварительным данным «Лаборатории Касперского» за 2025 год, число обнаруженных на Android мобильных угроз выросло почти вдвое. В третьем квартале их было на 38% больше, чем во втором. В некоторых нишах, таких как банковские трояны, рост еще серьезнее. В одной России опасный банковский троян Mamont атаковал в 36 раз больше пользователей, чем годом ранее, в целом по миру рост этой категории почти четырехкратный.
      Сегодня злоумышленники в основном распространяют вредоносное ПО через мессенджеры, пересылая вредоносные файлы в личных чатах и группах. Установочный файл имеет привлекательное имя («фото вечеринки.jpg.apk», «все товары распродажи.apk» и подобные), а сопутствующее сообщение объясняет, как установить пакет, обойдя ограничения и предупреждения операционной системы.
      После заражения нового устройства зловред нередко рассылает себя всем контактам жертвы.
      Также популярен спам в поисковых системах и e-mail-рассылках, заманивающий пользователей на сайт, внешне похожий на магазин приложений, где предлагается скачать «новое полезное приложение» ؙ— например, ИИ-ассистента. На самом деле происходит не установка из магазина приложений, а загрузка приложения в пакете APK. Ярким примером этих техник является Android-троян ClayRat, комбинирующий все перечисленное для атак на российских пользователей. Он распространяется через группы и через фальшивые сайты, рассылает себя контактам очередной жертвы через SMS, а затем ворует у жертвы ее переписку и историю звонков и даже фотографирует владельца фронтальной камерой смартфона. Всего за три месяца появилось более 600 сборок трояна.
      Масштаб беды таков, что в Google даже анонсировали запрет на распространение приложений от неизвестных разработчиков с 2026 года. Но спустя пару месяцев под давлением сообщества разработчиков сменили подход на более мягкий — вероятно, неподписанные приложения можно будет устанавливать только в каком-то «режиме суперпользователя». Поэтому можно ожидать, что инструкции от мошенников пополнятся описанием того, как в этот режим войти.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Экспериментами по обходу ограничений в ответах ИИ, установленными создателями языковых моделей, технологические энтузиасты начали заниматься практически с самого начала широкого распространения LLM. Многие из этих приемов были весьма оригинальны — например, сказать ИИ, что у вас нет пальцев, чтобы он помог дописать код, попросить его «просто пофантазировать», когда прямой вопрос приводит к отказу, или предложить ему принять роль умершей бабушки и поделиться запретными знаниями, дабы утешить скорбящего внука.
      Большинство таких трюков давно известны, и со многими из них разработчики LLM научились успешно бороться, но сама битва между ограничениями и попытками их обойти никуда не делась — уловки просто стали сложнее и изощреннее. Сегодня поговорим о новой технике джейлбрейка ИИ, которая эксплуатирует уязвимость чат-ботов… к поэзии — в самом прямом смысле этого слова. В свежем исследовании ученые показали, что формулирование промптов в виде стихов значительно повышает вероятность небезопасного ответа моделей.
      Эту технику они проверили на 25 популярных моделях от Anthropic, OpenAI, Google, Meta*, DeepSeek, xAI и других разработчиков. Ниже — подробности о том, какие ограничения есть у моделей, откуда у них вообще берутся запретные знания, как проходило исследование и какие модели оказались наиболее «романтичными» — в смысле, восприимчивыми к стихотворным запросам.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Новая недавно обнаруженная уязвимость WhisperPair позволяет превратить Bluetooth-наушники и гарнитуры многих известных фирм в трекинговые маячки для слежки за их владельцами, вне зависимости от того, подключены ли эти аксессуары к iPhone, Android-смартфону или даже ноутбуку. И несмотря на то, что технология, особенности реализации которой производителями гарнитур сделала возможной данную уязвимость, разработана в Google для Android-устройств, риски слежки оказываются куда выше у тех, кто использует уязвимые гарнитуры с устройствами под управлением других ОС — iOS, macOS, Windows или Linux — а владельцев iPhone это касается в первую очередь.
      Первичное подключение Bluetooth-наушников к Android-смартфонам стало проще и быстрее, когда Google внедрила технологию быстрого сопряжения Fast Pair, которую взяли на вооружение десятки производителей аксессуаров. Чтобы сопрячь со смартфоном новую гарнитуру, поддерживающую эту технологию, достаточно включить ее и поднести к смартфону. Если тот достаточно современный (произведен после 2019 года), на его экране всплывет окошко с предложением подключиться к гарнитуре и загрузить фирменное приложение для наушников, если оно существует. Одно касание — и дело сделано.
      К сожалению, многие производители гарнитур, видимо, неправильно прочитали инструкцию к этой технологии, поэтому их аксессуары можно за считаные секунды подключить к чужому смартфону, даже если гарнитура не находится в режиме сопряжения. В этом суть уязвимости WhisperPair, недавно найденной исследователями из Лёвенского университета и получившей номер CVE-2025-36911.
      Вредоносное устройство — обычный смартфон или ноутбук атакующего — транслирует запросы Google Fast Pair и пытается соединиться с BT-устройствами в радиусе 14 метров. Как выясняется, на эти запросы, даже не находясь в режиме сопряжения, откликаются многие наушники Sony, JBL, Redmi, Anker, Marshall, Jabra, OnePlus и даже Pixel Buds 2 от Google. На атаку в среднем требуется 10 секунд.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Миллионы ИТ-систем, включая индустриальные и IoT, начнут непредсказуемо вести себя 19 января. Среди возможных сбоев: проблемы в обработке карточных платежей, ложные срабатывания систем безопасности, некорректная работа медицинского оборудования, сбои систем автоматизированного освещения, отопления и водоснабжения и тысячи более безобидных ошибок. Правда, произойдет это в 2038 году, но это не повод расслабляться — времени на подготовку уже недостаточно. Причиной вороха разных проблем станет переполнение переменных, в которых хранится дата и время. Хотя первопричина ошибки проста и понятна, ее устранение потребует обширных и систематизированных усилий, причем как от государств и международных структур, так и от конкретных организаций и частных лиц.
      Негласный стандарт «эпохи» Unix
      Unix Epoch — это система отсчета времени, принятая в операционных системах Unix и ставшая популярной в ИТ-индустрии. Отсчет ведется с момента 00:00:00 UTC 1 января 1970 года, который принят за нулевую точку. Любой момент времени представляется как количество секунд, прошедших с этой даты. Для дат ранее 1970 года используются отрицательные значения. Этот подход был выбран разработчиками Unix для простоты — вместо хранения года, месяца, дня и времени по отдельности достаточно одного числа, с которым удобно проводить манипуляции вроде сортировки или определения промежутка между датами. Сегодня Unix Epoch используется далеко за пределами Unix-систем: в базах данных, языках программирования, сетевых протоколах, в смартфонах на iOS и Android.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Жизнь современного директора по ИБ (также известного как CISO, Chief Information Security Officer) — это не только борьба с хакерами, но и бесконечный квест под названием «соответствие требованиям». Регуляторы закручивают гайки, стандарты растут как грибы, и головной боли только прибавляется. И самое «веселое» тут то, что отвечать приходится не только за свой периметр, но и, фигурально выражаясь, «за того парня». За всю вашу цепочку поставок (supply chain), за всех подрядчиков и за весь тот «зоопарк» софта, на котором крутятся ваши бизнес-процессы. Логика тут железная и, увы, беспощадная: если дыра найдется у вашего поставщика, а проблемы начнутся у вас — спросят-то в итоге с вас! Распространяется эта логика и на защитное ПО.
      В былые времена компании редко задумывались, что там внутри ИБ-решений и продуктов, которые они использовали. Сейчас бизнес, особенно крупный, хочет знать: а что там внутри этой «коробки»? А кто код писал? А оно не обвалит нам какую-нибудь важную функцию или, например, вообще все (а то прецеденты всякие случались, см. случай с обновлением CrowdStrike 2024 года)? Где и как обрабатываются данные? Это абсолютно правильные вопросы!
      Проблема в том, что пока они часто повисают в воздухе. Почти все заказчики производителям доверяют, очень часто вынужденно, просто потому, что другого варианта нет. Конечно, более зрелый подход в нынешней киберреальности — проверять.
      На корпоративном языке это называется доверие к цепочкам поставок (supply chain trust), и решать эту задачку самостоятельно — та еще головная боль. Тут нужна помощь производителя. Ответственный вендор готов показывать, что под капотом решений, открывать исходный код партнерам и заказчикам для проверки — в общем, заслуживать доверие не красивыми слайдами, а «железобетонными» практическими шагами.
      Кто уже делает это, а кто застрял в прошлом? Отвечает свежайшее, фундаментальное исследование от коллег из Европы. Его провели уважаемый тестер AV-Comparatives, Экономическая палата Австрии (WKO), бизнес-школа MCI The Entrepreneurial School и юридическое бюро Studio Legale Tremolada.
      Короткий вывод исследования: эпоха черных ящиков в кибербезе закончилась. RIP. Аминь. Будущее — за теми, кто не прячет исходные коды и отчеты об уязвимостях и дает клиентам максимум выбора при настройке продукта. И в отчете четко написано, кто не только обещает, но и реально делает. Угадайте кто?
      Правильно, мы!
       
      View the full article
×
×
  • Создать...