Пароли первого дня до сих пор остаются одной из самых недооценённых дыр в корпоративной безопасности. Один слабый или не сменённый стартовый пароль уже приводил и к доступу к платформе с данными 64 млн соискателей, и к взлому инфраструктурных систем с дефолтным кодом 1111. Для российских IT-команд сигнал простой: онбординг сотрудников давно пора рассматривать как часть attack surface, а не как рутинную HR-операцию.
Об этом пишет The Hacker News, разбирая типичную практику, которая в компаниях считается почти нормой: новичку отправляют временный пароль по почте, SMS или передают голосом, чтобы он смог зайти в корпоративные системы в первый рабочий день. На бумаге это выглядит как временная мера. На практике такие учётные данные нередко живут дольше запланированного, пересылаются между несколькими людьми, повторно используются для разных сервисов или вообще не меняются после первого входа.
Проблема не в самом факте временного доступа, а в том, как он организован. Email и SMS удобны, пока всё идёт по плану, но любой перехват, форвард или вход с небезопасного устройства превращает стартовый пароль в готовый пропуск внутрь компании. Голосовая передача кажется безопаснее, но быстро упирается в операционные издержки: нужно синхронизировать время, подключать менеджеров, подрядчиков или HR, а каждое лишнее звено увеличивает шанс, что пароль где-то запишут, отправят не туда или просто оставят без контроля. В загруженном IT-отделе безопасность здесь часто проигрывает скорости.
Самый неприятный сценарий начинается дальше. Временные пароли почти никогда не проектируют как надёжные долгоживущие секреты: они проще, предсказуемее, иногда генерируются пачками для ускорения онбординга. Если процесс не принуждает сотрудника немедленно сменить пароль, если интеграция с IAM настроена криво или если никто не отслеживает статус первичного входа, временная учётка превращается в постоянную. Для атакующего это один из самых дешёвых путей в систему: не нужно искать zero-day, достаточно найти забытый стартовый доступ, который никто не закрыл.
В материале приводится показательный кейс из ноября 2023 года. Тогда иранская хактивистская группа Cyber Av3ngers атаковала Municipal Water Authority of Aliquippa в Пенсильвании. Точкой входа стали программируемые логические контроллеры, защищённые дефолтной учётной записью с паролем 1111. Злоумышленники получили контроль над удалённой бустерной станцией, обслуживающей два тауншипа. Угроза качеству водоснабжения тогда не реализовалась, но инцидент оказался достаточно серьёзным, чтобы CISA отдельно призвала другие объекты сменить стандартные креды и убрать PLC из открытого интернета. История старая и неприятно знакомая: пароль задумывался как установочный, а остался боевым.
Второй пример ближе к корпоративной реальности, где под ударом уже не промышленная автоматика, а HR-tech. В 2025 году исследователи обнаружили, что к AI-платформе найма McHire, используемой McDonald's и разработанной Paradox.ai, можно было получить доступ через старую административную учётную запись, где и логин, и пароль были 123456. Через такой аккаунт удалось попасть в тестовое окружение «ресторана» и просмотреть чаты, связанные более чем с 64 млн заявок на работу. После ответственного раскрытия Paradox.ai закрыла проблему и обновила политики безопасности, но сам факт показателен: тестовые, дефолтные и «временные» учётные данные удивительно живучи, особенно когда система быстро растёт и обрастает интеграциями.
Для российских разработчиков, админов и CISO тут нет никакой экзотики. В локальных компаниях та же логика встречается повсюду: корпоративная почта, VPN, AD, MDM, Jira, Git-хостинг, BI, кадровые сервисы, внутренние порталы. Чем больше систем нужно выдать человеку в первый день, тем выше соблазн упростить схему: сгенерировать один понятный пароль, отправить в мессенджер, попросить сменить «потом». Особенно опасно это в распределённых командах, в аутсорсе и в средах с подрядчиками, где граница между личными и корпоративными устройствами размыта. В такой конфигурации пароли первого дня становятся не временной мерой, а системной уязвимостью процесса.
На этом фоне The Hacker News пересказывает позицию вендора Specops, который продвигает подход без передачи стартового пароля как такового. Смысл в том, чтобы новый сотрудник сам создавал свой пароль через защищённую процедуру подтверждения личности, а не получал готовый секрет по небезопасному каналу. Конкретно Specops предлагает такую механику в составе uReset: пользователь получает ссылку на регистрацию через личную почту, SMS или опцию сброса пароля на доменном устройстве, проходит верификацию по личному email или номеру телефона и сразу задаёт пароль, соответствующий корпоративной политике. Это, разумеется, ещё и маркетинг продукта, но тезис по существу верный: самый безопасный временный пароль — тот, который никому не пришлось пересылать.
Практический вывод для бизнеса звучит прозаичнее любой рекламной подачи. Если в компании до сих пор существует «стартовый пароль», который можно переслать, повторно использовать или забыть отключить, значит в онбординге уже есть лишний риск. Следующий логичный шаг для зрелых IT-команд — убрать ручную раздачу секретов, жёстко принуждать к первичной смене учётных данных, отслеживать неактивированные аккаунты и отдельно чистить legacy-доступы в HR- и внутренних сервисах. Чем активнее рынок автоматизирует найм и доступы, тем дороже будет обходиться иллюзия, что временные пароли живут только один день.