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

Плохие парольные политики, и как их избегать | Блог Касперского


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

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

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

Что такое парольная политика

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

Правила, входящие в парольную политику, могут быть самыми разнообразными:

  • Длина пароля — то есть минимальное и максимальное количество символов, из которых должен состоять пароль.
  • Набор допустимых символов — должен ли пароль включать заглавные и строчные буквы, цифры, спецсимволы, эмодзи и так далее; или наоборот, не включать что-то из перечисленного.
  • Запрет на те или иные комбинации символов — скажем, на то, чтобы пароль содержал последовательность знаков, совпадающую с названием компании или логином пользователя.
  • Специфические запреты — например, пароль не может начинаться с единицы, содержать прямую последовательность цифр (борьба с 12345678), не должен совпадать по формату с какими-то легко угадываемыми вещами (дата, телефонный номер, номер автомобиля) и так далее.
  • Списки запрещенных паролей — таблицы исключений, которые в целом удовлетворяют всем прочим требованиям, но признаны небезопасными по тем или иным причинам: к примеру, запрет на использование паролей, уже фигурировавших в известных утечках.
  • Срок действия пароля — временной интервал, по истечении которого пользователь должен задать новый пароль.
  • Запрет на переиспользование паролей — то есть запрет менять пароль на один из уже использованных для данной учетной записи ранее.
  • Запрет на смену пароля по инициативе пользователя — такая опция может быть использована для борьбы с угонами учетных записей. То есть это защита от смены пароля злоумышленником.
  • Способ хранения пароля — в частности, явный запрет в организации на всеми любимые стикеры с паролями. Или рекомендация пользоваться менеджером паролей.
  • Санкции — если какие-то правила парольной политики не получается жестко задать в настройках программного обеспечения, можно принуждать пользователей следовать им с помощью тех или иных административных санкций.

 

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

Ссылка на сообщение
Поделиться на другие сайты

Господи, пример с SAP просто великолепен. Если что, SAP использовали в т.ч. в России, в т.ч. фирмы, которые вы хорошо знаете. Пока они из России не ушли.

Quote

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

И я даже сталкивался в реале с таким. Ввёл пароль в 128 символов и не смог залогиниться

Ссылка на сообщение
Поделиться на другие сайты
1 час назад, Umnik сказал:

Ввёл пароль в 128 символов и не смог залогиниться

Он принципиально надёжнее, чем сложный пароль из 25 символов? Насколько целесообразно заморачиваться?

Ссылка на сообщение
Поделиться на другие сайты
19 минут назад, Mrak сказал:

Насколько целесообразно заморачиваться?

Держать память в тонусе ;) Таких паролей штуки 10 и тренировка памяти :) 

В целом особого смысла от таких больших паролей нет, многие сервисы ограничивают длину пароля до 30-40 символов.
40.thumb.PNG.a36b4d034d6cd2ef862731f65d0dc06d.PNG

Изменено пользователем Friend
Ссылка на сообщение
Поделиться на другие сайты
13 hours ago, Mrak said:

Он принципиально надёжнее, чем сложный пароль из 25 символов?

Нет. Я просто решил тогда проверить. На сегодня 18+ символов вполне достаточно для хорошего пароля.

13 hours ago, Mrak said:

Насколько целесообразно заморачиваться?

Нет никакого смысла. Я просто могу, вот и всё :)

Ссылка на сообщение
Поделиться на другие сайты
1 час назад, Umnik сказал:

Нет никакого смысла. Я просто могу, вот и всё :)

Главное, чтобы потом такой пароль не вводить на устройстве, где еще не установлен менеджер паролей. Как-то сносил систему на макбуке, так для установки КПМ из эпстор сначала надо ввести 30 символов пароля от учетки эпла. Задолбался. С телевизором тоже так нарывался - рутуб надо было открыть с паролем, а на телеки менеджер паролей еще не придумали как ставить.

Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

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

    • domsalvatorr
      От domsalvatorr
      Привет,

      Я обращаюсь за помощью с проблемой, с которой столкнулся при попытке активировать лицензию Kaspersky Total Security. Я пользуюсь продуктами Касперского уже несколько лет и всегда был доволен их работой, но сейчас столкнулся с проблемой, с которой раньше не сталкивался.

      Недавно; Я приобрел новую лицензию на Kaspersky Total Security. После загрузки и установки последней версии программного обеспечения я приступил к активации с помощью предоставленного лицензионного ключа. Однако я получаю сообщение об ошибке «Неверный лицензионный ключ», несмотря на то, что ввел его правильно. Я дважды проверил ключ на наличие опечаток и убедился, что он действительно подходит для моей версии Kaspersky Total Security.

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

      Кроме того, я прочитал этот пост; https://forum.kasperskyclub.ru/topic/458019-heurtrojanmultigmlopsenbadurgena/     К сожалению, ни одно из этих действий не решило проблему. Буду очень признателен за любые рекомендации или предложения по решению этой проблемы. Если кто-то сталкивался с подобной проблемой или имеет какие-либо советы о том, как действовать, поделитесь своим мнением.

      Заранее благодарю вас за вашу помощь и содействие.
       
      Сообщение от модератора thyrex Перенесено из предложений по развитию клуба  
    • KL FC Bot
      От KL FC Bot
      В OpenSSH, популярном наборе инструментов для дистанционного управления *nix-системами, была найдена уязвимость, при помощи которой неаутентифицированный злоумышленник может выполнить произвольный код и получить root-привилегии. Уязвимость получила номер CVE-2024-6387 и собственное имя regreSSHion. Учитывая, что sshd, сервер OpenSSH, внедрен в большинство популярных ОС, многие устройства интернета вещей и другие девайсы вроде межсетевых экранов, описание уязвимости звучит как начало новой эпидемии уровня WannaCry и Log4Shell. На практике ситуация несколько сложнее, и массовой эксплуатации уязвимости, вероятно, не будет. Несмотря на это, все администраторы серверов с OpenSSH должны срочно позаботиться об устранении уязвимости.
      Где применяется OpenSSH
      Набор утилит OpenSSH встречается почти повсеместно. Это популярная реализация протокола SSH (secure shell), внедренная в подавляющее большинство дистрибутивов Linux, OpenBSD и FreeBSD, macOS, а также в специализированные устройства, например на базе Junos OS. Поскольку многие телевизоры, «умные» дверные глазки и видеоняни, сетевые медиаплееры и даже роботы-пылесосы работают на базе Linux-систем, в них тоже часто применяется OpenSSH. Начиная с Windows 10, OpenSSH есть и в ОС от Microsoft, правда, здесь это опциональный компонент, не устанавливаемый по умолчанию. Не будет преувеличением сказать, что sshd работает на десятках миллионов устройств.
       
      Посмотреть статью полностью
    • KL FC Bot
      От KL FC Bot
      Сегодня Telegram уже не просто мессенджер, а социальная сеть. Пользователи могут хранить неограниченное количество файлов, вести каналы, создавать ботов и даже покупать криптовалюту. Разумеется, все это дает мошенникам большое пространство для маневров.
      На этот раз киберпреступники придумали схему кражи Telegram-аккаунтов и криптокошельков с помощью фишингового бота. Детали новой схемы и рекомендации по защите своих криптоактивов — в этом материале.
      Как работает мошенническая схема
      Для начала определим целевую аудиторию мошенников. Если вы думаете, что под угрозой находятся все пользователи Telegram, — расслабьтесь. Киберпреступники сфокусированы на владельцах криптокошельков Telegram Wallet, которые совершают сделки по P2P-торговле (это когда пользователи могут покупать и продавать криптовалюту без посредников).
      Как только потенциальная жертва найдена, мошенники связываются с ней под видом легитимного покупателя или продавца, в зависимости от контекста. Одним из первых же предложений в переписке становится просьба пройти KYC-верификацию (Know Your Customer — «Знай своего клиента»). Это реальное требование Telegram Wallet, направленное на повышение уровня безопасности платформы. Пользователям на самом деле требуется предоставить свои реальное имя, номер телефона и адрес, чтобы совершать сделки. Но есть нюанс: мошенники отправляют ссылку на фейковый канал для прохождения KYC-верификации и угрожают заморозкой криптоактивов в случае, если жертва проигнорирует просьбу. Для большей убедительности криптомошенники упоминают выдуманные «требования регуляторов».
      Как определить, что канал принадлежит мошенникам: малое число просмотров поста, синтаксические ошибки и активный призыв перейти по ссылке
       
      Посмотреть статью полностью
    • KL FC Bot
      От KL FC Bot
      Последние недели в Сети активно обсуждают новые правила в политике безопасности Meta*. Компания-владелец Facebook**, Instagram** и WhatsApp** сообщила части своих пользователей, что с 26 июня их личные данные будут использованы для развития генеративного искусственного интеллекта Meta AI**.
      О каких данных идет речь, можно ли отказаться от их добровольной передачи и как обеспечить свою цифровую безопасность — в этом материале.
      Meta* собирается использовать контент из Facebook** и Instagram** для обучения своего ИИ?
      Meta AI** существует более девяти лет: подразделение, занимающееся развитием ИИ, компания открыла еще в 2015 году. Для обучения своих нейросетей Meta* нужны данные — и скоро источником знаний для ИИ может стать пользовательский контент крупнейших в мире соцсетей.
      Все началось в мае 2024 года, когда в Интернете стали массово появляться сообщения об очередном изменении политик безопасности Meta*: якобы компания с конца июня планирует использовать контент из Facebook** и Instagram** для тренировок генеративного ИИ. Но уведомления об этом пришли не всем, а лишь некоторым пользователям из Евросоюза и США.
      На волне поднявшегося негодования Meta* выпустила официальное заявление для жителей Евросоюза по этому поводу, но пока оно оставляет больше вопросов, чем дает ответов. Пресс-релиза, где бы черным по белому было написано: «Начиная с такого-то числа Meta AI** будет использовать ваши данные для обучения», не существует — но недавно появилась страница «Генеративный ИИ в Meta*», где подробно описано, какие данные и как компания собирается использовать для развития искусственного интеллекта. Снова без дат.
       
      Посмотреть статью полностью
    • KL FC Bot
      От KL FC Bot
      Не так давно мы писали о том, что злоумышленники научились использовать легитимную инфраструктуру социальной сети для доставки достаточно правдоподобных на вид предупреждений о блокировке бизнес-аккаунта — с последующим угоном паролей. Оказывается, уже несколько месяцев очень похожим образом атакуют аккаунты разработчиков на GitHub, что не может не волновать корпоративную службу информационной безопасности (особенно если разработчики имеют административный доступ к корпоративным репозиториям на GitHub). Рассказываем о том, как устроена эта атака.
      Угон аккаунтов на GitHub
      Жертвам этой атаки приходят письма, отправленные с настоящего почтового адреса GitHub. В письмах говорится, что команда GitHub ищет опытного разработчика, которому компания готова предложить привлекательные условия — зарплату $180 000 в год плюс щедрый соцпакет. В случае заинтересованности в этой вакансии получателю письма предлагается подать заявку по ссылке.
      Атака начинается с письма: GitHub якобы ищет разработчика на зарплату $180 000 в год. Источник
       
      Посмотреть статью полностью
×
×
  • Создать...