SVN зашифроване зберігання паролів


109

Я встановив SVN на машині Ubuntu, і я не можу щось обхопити.

Кожен раз, коли я забуваю щось із терміналу, я отримую цю помилку щодо збереження незашифрованого пароля:

-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <[...]> Subversion Repository

can only be stored to disk
unencrypted!  You are advised to
configure your system so that
Subversion can store passwords
encrypted, if possible.  See the
documentation for details.

You can avoid future appearances of
this warning by setting the value of
the 'store-plaintext-passwords' option
to either 'yes' or 'no' in
'/home/[...]/.subversion/servers'.
-----------------------------------------------------------------------

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

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

Дякую!



1
Це питання полягає в тому, як приховати попередження, якщо ви не хочете зашифрувати пароль. Це питання стосується того, як налаштувати систему, щоб правильно шифрувати пароль.
outis nihil

Відповіді:


44

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

Дивіться: http://blogs.collab.net/subversion/2009/07/subversion-16-security-improvements/


14
Представлені сховища шифрування були GNOME Keyring або Kwallet, але оскільки я не використовую жодного інтерфейсу робочого столу на своєму сервері, я гадаю, що про шифрування не виникає сумніву. Правильно?
трезник

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

5
Я не можу повірити, що svn не передбачає хешований pw, як htpasswd або подібний.
d -_- b

17
@sims Hashing добре, якщо ви хочете ПЕРЕВІРИТИ правильність пароля. Клієнт збирається надіслати пароль серверу, тому хешування недостатньо. Ви повинні зберігати його у двосторонній спосіб.
Notinlist

6
Ви можете отримати його без перекомпіляції на основі ubuntuforums.org/showthread.php?t=1348567 . Просто встановіть це на ~ / .subversion / config [auth] зберігання паролів = gnome-keyring
fikr4n

6

Шифруючи пароль, ви не зможете домогтися відмови (інші користувачі можуть використовувати ваш хеш як ви) через дозволи файлів ОС. Однак у більшості компаній встановлено підривну роботу, використовуючи пароль свого домену або якусь форму пароля SSO. Шифруючи пароль, ви хоч би замаскували когось із доступу користувачів до інших облікових записів.

Я б все ще переймався силою шифрування. Якщо пароль субверсії пов'язаний з іншими важливими обліковими записами, хтось може перевірити міцність шифрування, щоб зламати пароль.

Найкраще встановити клієнт-підривник, щоб вимкнути збережені паролі та змусити ледачих розробників кожного разу перевіряти автентичність.


13
Чи буде остання пропозиція "найкращою", залежить від інших факторів. Що робити, якщо розробники, зіткнувшись з обтяжливим процесом фіксації / оновлення, почнуть менше використовувати SVN, і, як результат, деталізація синхронізації з іншими стає грубішою? Що робити, якщо вони розпочнуть фальсифікацію способів зберігання своїх паролів в іншому місці та автоматизовану процедуру аутентифікації?
LarsH

2

Я зберігаю облікові дані на зашифрованому диску. (Хоча, доки encfs встановлено, облікові дані все ще є простими текстами для мого облікового запису)

$ ls -nl ~/.subversion/
total 20K
-rw-r--r-- 1 1000 1000 4.2K 2009-07-10 13:00 README.txt
lrwxrwxrwx 1 1000 1000   31 2009-10-14 14:31 auth -> ~/crypt/subversion/auth/
-rw-r--r-- 1 1000 1000 5.7K 2009-07-10 13:00 config
-rw-r--r-- 1 1000 1000 3.6K 2009-07-10 13:00 servers

Використання git-svn означає, що мені потрібні облікові дані набагато рідше, тому це може бути не надто обтяжливим, щоб не зберегти їх взагалі.

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