CohortX
Блог

Как хранить пароли и ключи правильно

2 августа 2026 г. · 2 мин чтения · Read in English · Антон Молотило

Самая частая ошибка в учебных проектах

Открываешь репозиторий кандидата, а там в коде строка подключения к базе с настоящим паролем. Или ключ доступа к стороннему сервису.

Это моментально портит впечатление, потому что показывает: человек не думает о последствиях. И это исправляется за десять минут.

Правило

Всё, что является секретом, живёт в переменных окружения, а не в коде.

Секрет — это пароль, ключ доступа, строка подключения, признак сессии, любой токен.

Как это делается

Заведите файл с переменными в корне проекта:

DATABASE_URL=postgresql://user:password@localhost:5432/notes
API_KEY=abcdef123456

Обязательно добавьте его в список игнорируемых файлов. Это главный шаг, без него всё остальное бессмысленно.

В коде читайте оттуда:

import os
database_url = os.environ["DATABASE_URL"]

Квадратные скобки, а не безопасное получение со значением по умолчанию: пусть программа падает на старте с понятной ошибкой, если переменная не задана. Это лучше, чем работать неправильно.

Файл-образец

Рядом положите образец без значений:

DATABASE_URL=
API_KEY=

Этот файл, наоборот, кладут в репозиторий. Он говорит человеку, который открыл ваш проект: вот что нужно заполнить, чтобы запустить.

Мелочь, а сильно улучшает впечатление от репозитория.

На сервере

Переменные задаются в настройках площадки или в файле, доступном только нужному пользователю. Права на такой файл — только чтение владельцем.

В контейнерах передаются при запуске, а не встраиваются в образ: образ может попасть в общедоступное хранилище.

Как хранить пароли пользователей

Отдельная тема, где ошибки стоят дорого.

Никогда не храните пароли в открытом виде. Даже в учебном проекте.

Не шифруйте их. Шифрование обратимо, а это значит, что при утечке ключа утекут и все пароли.

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

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

Что делать, если ключ уже утёк

Порядок именно такой:

1. Смените ключ немедленно. До всего остального. Ключ, попавший в открытый репозиторий, считайте раскрытым: автоматические сборщики находят такие вещи за минуты.

2. Проверьте, не использовали ли его. Журналы доступа у сервиса обычно есть.

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

Порядок принципиален. Люди часто начинают с чистки истории и тратят на неё час, пока ключ продолжает работать.

Быстрая проверка своих проектов

Прямо сейчас откройте свои репозитории и поищите в них слова «password», «secret», «token», «key». Пять минут, а находки бывают неприятные — лучше найти самому, чем услышать об этом на собеседовании.

Хватит читать — пора делать

На CohortX можно найти команду под пет-проект и получить тот самый опыт, о котором спрашивают на собеседовании.

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