Вимкнути зберігання паролів у простому форматі svn для всіх користувачів


9

За замовчуванням Subversion дозволяє користувачам зберігати свій пароль у простому тексті в ~/.subversion/auth/svn.simple. Я досліджую варіанти зберігання зашифрованих паролів у svn , але як мінімум і якнайшвидше, я хочу повністю відключити можливість зберігання паролів для всіх наших користувачів. Ми запускаємо Subversion 1.6.17.

Я можу відключити це в домашньому каталозі користувача через конфігураційний файл.

~ / .subversion / сервери :

[global]
# Password / passphrase caching parameters:
store-passwords = no
store-plaintext-passwords = no

Однак користувач може змінити конфігураційний файл, якщо захоче. Хіба не існує конфігураційного файлу svn для всієї системи? Я бачив кілька варіантів:

Варіант 1

У 1,8-розрядний сценарій налаштування Subversion приймає опцію --disable-plaintext-зберігання паролів, щоб обійти логіку, яка зберігає паролі простого тексту та паролі сертифікату клієнта.

Я вважаю за краще не оновлювати до версії розробки.

Варіант 2

/etc/subversion/config

AFAIK, цей конфігураційний файл використовується лише тоді, коли користувач не має конфігураційного файлу, який уже знаходиться в домашній директорії.

Варіант 3

Додайте завдання cron, щоб видалити кеш-код користувача в ~/.subversion/auth/svn.simple. Отже, навіть якщо вони змінюють свій конфігураційний файл svn, наша робота cron знищить будь-які збережені паролі. Однак навіть запуск кожної хвилини не гарантує, що наша система резервного копіювання не захопить файли, що містять паролі простого тексту.

Ідеї?


Ви керуєте сервером? Чому б не використовувати ключ SSH плюс або Kerberos замість автентифікації пароля?
Мікель

так, я адміністратор.
Банджер

Відповіді:


6

Ви не можете.

Що б ви не робили, ваші користувачі можуть будь-коли обійти його і зберегти свій пароль у простому текстовому файлі. Якщо ви вимкнете цю функцію у двійковому портфелі клієнта, він завантажить або складе інший клієнт. Як правило, якщо встановити неприємні заходи безпеки (наприклад, вводити пароль для кожної операції svn), ваші користувачі обійдуть їх таким чином, що погіршує безпеку. (Наприклад, написання обгорткового сценарію, який містить їх пароль. Котрий вони залишать читатимуть світ.) Тому не робіть цього.

Повторюю: ви не можете лише за допомогою технічних заходів перешкодити користувачам зберігати свій пароль у файлі. Ви можете заборонити це, але якщо це ускладнить їхнє життя, вони все одно це зроблять.

Якщо вас турбує крадіжка ноутбука чи резервного копіювання, зашифруйте домашній каталог користувачів. Це захистить паролі, а також дані. Якщо весь домашній каталог зашифрований, пароль шифрування, як правило, такий же, як пароль для входу, з міркувань зручності використання. Не забудьте створити політику резервного копіювання пароля (наприклад, герметичний конверт), оскільки втрата пароля шифрування не підлягає відновленню.

Якщо ви стурбовані повторним використанням пароля, введіть випадковий (отже, унікальний) пароль, який він раз і назавжди введе у свій клієнт. Звичайно, простий процес зміни компрометованих паролів.


Чудові точки навколо. Я, звичайно, бачив, щоб користувачі обходили протоколи, які ми маємо, щоб полегшити їхнє життя. Мені доведеться побачити, що ще пропонує svn у способі аутентифікації, який не дратує користувачів, наприклад, на основі ключів.
Банджер

0

До речі, перед тим, як що-небудь шифрувати, я б подбав про дозволи файлів: просто перевірив мою власну установку з цікавості, і виявив, що це читається у всьому світі. Для файлу, що містить чіткий пароль, мені здається, що це отвір для безпеки.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.