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

О сложности пароля


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

Здравствуйте, Евгений. Мой вопрос не о продуктах Вашей лаборатории. По крайней мере, если и касается, то лишь косвенно. Так же он касается, косвенно, продукции компании Google.

Вопрос в следующем.

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

Я прикладываю фото пароля, он уже устарел, я его отозвал.

post-17944-0-67570400-1486829502_thumb.png

Так же вот результаты формы.

post-17944-0-00901000-1486829513_thumb.png

Меня интересует вот что. Если, согласно результатам теста пароля, он достаточно стойкий, то как же тогда рекомендации по поводу внедрения в пароли верхнего регистра, цифр и спецсимволов? Насколько мне известно, методом перебора, да, сложно взломать сложный пароль. А если заранее известно количество символов в пароле, известно составляющее пароль, то есть нижний регистр, отсутствие цифр, спецсимволов? Разве это не добавляет шансы на успех при взломе? Если это и так, а я уверен, что это так, почему же в Вашей форме пробы устойчивости, нет возможности показать "зрителю" отличие пароля, скажем с цифрами и без, с присутствием спецсимволов и без? Да суть не в этом, мне интересно, Ваше мнение по поводу: всё таки это достаточно сложный пароль или при задании условий брутфорса (я их указал выше) шансы на взлом будут более успешными? Меня просто, поразила тупость разработчиков, умудрившихся впарить 16 обычных, латинских букв.

Я долго думал куда всё это написать. Из всех нормальных, умных людей, ну ей Богу, на ум пришли только Вы. Хотел написать на хабр, там нло прилетает на раз, В тостере: модерация там, жесть. В сам Google: проще съездить пешком на Марс, чем дождаться ответа на запрос.Так что вот, как то так.

С уважением, Ярослав.

post-17944-0-67570400-1486829502_thumb.png

post-17944-0-00901000-1486829513_thumb.png

  • Согласен 1
Ссылка на комментарий
Поделиться на другие сайты

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

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



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

    • KL FC Bot
      От KL FC Bot
      Требования, которые онлайн-сервисы предъявляют при проверке своих пользователей, — будь то длина пароля, обязательное указание номера телефона или необходимость биометрической проверки с подмигиванием, зачастую регулируются индустриальными стандартами. Одним из важнейших документов в этой сфере является NIST SP 800-63, Digital Identity Guidelines, разработанный Национальным институтом стандартов и технологий США. Требования этого стандарта обязательны для выполнения всеми государственными органами страны и всеми их подрядчиками, но на практике это означает, что их выполняют все крупнейшие IT-компании и действие требований ощущается далеко за пределами США.
      Даже организациям, которые не обязаны выполнять требования NIST SP 800-63, стоит глубоко ознакомиться с его обновленными требованиями, поскольку они зачастую берутся за основу регуляторами в других странах и индустриях. Более того, свежий документ, прошедший четыре раунда публичных правок с индустриальными экспертами, отражает современный взгляд на процессы идентификации и аутентификации, включая требования к безопасности и конфиденциальности, и с учетом возможного распределенного (федеративного) подхода к этим процессам. Стандарт практичен и учитывает человеческий фактор — то, как пользователи реагируют на те или иные требования к аутентификации.
      В новой редакции стандарта формализованы понятия и описаны требования к:
      passkeys (в стандарте названы syncable authenticators); аутентификации, устойчивой к фишингу; пользовательским хранилищам паролей и доступов — кошелькам (attribute bundles); регулярной реаутентификации; сессионным токенам. Итак, как нужно аутентифицировать пользователей в 2024 году?
      Аутентификация по паролю
      Стандарт описывает три уровня гарантий (Authentication Assurance Level, AAL), где AAL1 соответствует самым слабым ограничениям и минимальной уверенности в том, что входящий в систему пользователь — тот, за кого себя выдает. Уровень AAL3 дает самые сильные гарантии и требует более строгой аутентификации. Только на уровне AAL1 допустим единственный фактор аутентификации, например просто пароль.
       
      View the full article
    • KL FC Bot
      От KL FC Bot
      Несколько месяцев мы с интересом изучали новую, очень элегантную схему криптомошенничества, жертв которой искусно и неторопливо побуждают установить вредоносное приложение для управления криптовалютой. Впрочем, «жертвами» их можно назвать условно, ведь разработчики этой схемы, словно цифровые Робин Гуды, нацеливают ее в первую очередь на… других воришек! Мы разберем схему обмана и способы защиты криптовалют в деталях.
      Первая приманка
      Все началось с того, что мне в Telegram пришло вполне тривиальное сообщение на криптотематику, пересланное от другого пользователя. Возможно, кто-то другой не увидел бы в этом ничего подозрительного, но… Как тимлид группы аналитиков веб-контента «Лаборатории Касперского» я насторожился и стал изучать пришедший спам детальнее. Текст в нем для ухода от детектирования был «обернут» в пятисекундный видеоролик сo скриншотом объявления о спешной, с огромным дисконтом продаже пары прибыльных криптопроектов и ссылками на них. Первая ссылка на предполагаемый объект продажи вела на небольшую, но реально работающую криптобиржу второго эшелона — вероятнее всего, для усыпления бдительности жертв. Но настоящая приманка скрывалась за второй ссылкой.
      Скриншот сообщения о продаже криптопроектов «обернут» в пятисекундный видеоролик. Повод насторожиться!
       
      View the full article
    • KL FC Bot
      От KL FC Bot
      В мае отгремел Всемирный день пароля, и на волне нашего и, надеемся, вашего интереса к парольной тематике мы проанализировали на устойчивость не «сферические пароли в вакууме», а реальные пароли из баз даркнета. Оказалось, что 59% изученных паролей могут быть взломаны менее чем за один час, и для этого понадобятся лишь современная видеокарта и немного знаний.
      Сегодня мы расскажем о том, как хакеры взламывают пароли и что с этим делать (маленький спойлер: пользоваться надежной защитой и автоматически проверять свои пароли на утечки).
      Как обычно взламывают пароли
      Начнем с важной ремарки: под фразой «взломать пароль» мы подразумеваем взлом его хеша — уникальной последовательности символов. Дело в том, что почти всегда пользовательские пароли хранятся на серверах компаний одним из трех способов.
      В открытом виде. Это самый простой и понятный способ: если у пользователя пароль, например, qwerty12345, то на сервере компании он так и хранится: qwerty12345. В случае утечки данных злоумышленнику для авторизации не потребуется сделать ничего сложнее, чем просто ввести логин и пароль. Это, конечно, если нет двухфакторной аутентификации, хотя и при ее наличии мошенники иногда могут перехватывать одноразовые пароли. В закрытом виде. В этом способе используются алгоритмы хеширования: MD5, SHA-1 и другие. Эти алгоритмы генерируют для каждой парольной фразы уникальное хеш-значение — строку символов фиксированной длины, которая и хранится на сервере. Каждый раз, когда пользователь вводит пароль, введенная последовательность символов преобразуется в хеш, который сравнивается с хранящимся на сервере: если они совпали, значит, пароль введен верно. Приведем пример: если в реальности ваш пароль qwerty12345, то «на языке SHA-1» он будет записываться вот так — 4e17a448e043206801b95de317e07c839770c8b8. Когда злоумышленник получит этот хеш, ему потребуется его дешифровать (это и есть «взлом пароля»), например, с помощью радужных таблиц, и превратить обратно в qwerty12345. Узнав пароль, хакер сможет использовать его для авторизации не только в сервисе, с которого утек хеш, но и в любом другом, где используется этот же пароль. В закрытом виде с солью. В этом способе к каждому паролю перед хешированием добавляется соль — случайная последовательность данных, статическая или формирующаяся динамически. Хешируется уже последовательность «пароль+соль», что меняет результирующий хеш, а значит, существующие радужные таблицы уже не помогут хакерам. Такой способ хранения паролей значительно усложняет взлом. Для нашего исследования мы собрали базу из 193 млн слитых паролей в открытом виде. Откуда мы ее взяли? Места надо знать. Нашли в сети даркнет — там они зачастую находятся в свободном доступе. Мы используем такие базы, чтобы проверять пользовательские пароли на предмет возможной утечки, при этом ваши пароли мы не знаем и не храним: вы можете подробнее узнать, как устроено изнутри хранилище паролей в Kaspersky Password Manager и как, не зная ваших паролей, мы сравниваем их с утекшими.
       
      Посмотреть статью полностью
    • kushnarenkoa
      От kushnarenkoa
      Добрый день! Зашифровали файлы в формат le0 и файлы с базами данных на Postgre SQL положили в архив с паролем. Как можно восстановить данные? И что нужно скинуть для понимания?
    • KL FC Bot
      От KL FC Bot
      Киберпреступники, промышляющие угоном паролей, постоянно придумывают все новые и новые способы доставки фишинговых писем. Например, они научились использовать легитимные функции Facebook* для отправки жертвам фейковых уведомлений о блокировке их бизнес-аккаунтов. Рассказываем, как работает эта схема, на что следует обращать внимание и какие меры стоит предпринять для защиты корпоративных учетных записей в соцсетях.
      Как происходит фишинговая атака на бизнес-аккаунты Facebook*
      Начинается все с того, что на электронную почту, привязанную к корпоративному аккаунту Facebook*, приходит письмо, действительно отправленное соцсетью. Внутри содержится угрожающая иконка с восклицательным знаком и тревожный текст: «Осталось 24 часа, чтобы запросить проверку. Узнайте почему».
      Письмо, действительно отправленное настоящим Facebook*, в котором содержится фейковое предупреждение о неприятностях с аккаунтом
       
      Посмотреть статью полностью
×
×
  • Создать...