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

Что на самом деле представляют собой учётные данные

Логин, опубликованный в публичном каталоге VPN, — это договорённость о доступе между оператором и любым, кто прочитает страницу. Он может идентифицировать общий служебный аккаунт, а не человека, и оператор может наблюдать за подключением на шлюзе.

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

Повторное использование — известное значение, а не слабое

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

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

Если пароль уже использовался повторно

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

Меняйте учётные данные VPN через любой процесс, который документирует оператор, и учтите, что это отдельное действие от изменения собственного аккаунта. Держите оба изменения в одной заявке, чтобы никто не предположил, что одно покрыло другое.

Если вместо пароля раскрыт закрытый клиентский ключ, средство — отзыв. Смена пароля почты не удаляет скопированный ключ.

Проверьте тип учётных данных перед сменой

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

python3 -c 'import secrets; print(secrets.token_urlsafe(24))'
gpg --gen-random --armor 2 32
pass generate work/mail 24

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

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

Похожие статьи