Wyłącz przechowywanie haseł svn w postaci zwykłego tekstu dla wszystkich użytkowników


9

Domyślnie Subversion pozwala użytkownikom zapisać hasło w postaci zwykłego tekstu w ~/.subversion/auth/svn.simple. Badam opcje przechowywania zaszyfrowanych haseł w svn , ale przynajmniej ASAP chcę całkowicie wyłączyć możliwość przechowywania haseł dla wszystkich naszych użytkowników. Używamy Subversion 1.6.17.

Mogę to wyłączyć w katalogu domowym użytkownika za pomocą pliku konfiguracyjnego.

~ / .subversion / servers :

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

Jednak użytkownik może zmienić plik konfiguracyjny, jeśli chce. Czy nie ma ogólnosystemowego pliku konfiguracyjnego SVN? Kilka opcji, które widziałem:

opcja 1

W 1.8-dev skrypt konfiguracyjny Subversion akceptuje opcję --disable-plaintext-password-storage, aby ominąć logikę, która przechowuje hasła w postaci zwykłego tekstu i hasła certyfikatów klienta.

Wolę nie aktualizować do wersji rozwojowej.

Opcja 2

/etc/subversion/config

AFAIK, ten plik konfiguracyjny jest używany tylko wtedy, gdy użytkownik nie ma pliku konfiguracyjnego w swoim katalogu domowym.

Opcja 3

Dodaj zadanie cron, aby usunąć pamięć podręczną uwierzytelniania użytkownika ~/.subversion/auth/svn.simple. Tak więc, nawet jeśli zmienią swój plik konfiguracyjny svn, to nasze zadanie cron zabiłoby wszystkie zapisane hasła. Jednak nawet uruchamianie go co minutę nie gwarantuje, że nasz system tworzenia kopii zapasowych nie pobierze plików zawierających hasła w postaci zwykłego tekstu.

Pomysły?


Czy kontrolujesz serwer? Dlaczego nie użyć klucza SSH plus lub protokołu Kerberos zamiast uwierzytelniania za pomocą hasła?
Mikel

tak, jestem administratorem.
Banjer

Odpowiedzi:


6

Nie możesz

Cokolwiek zrobisz, użytkownicy mogą go ominąć i zapisać swoje hasło w zwykłym pliku tekstowym. Jeśli wyłączysz tę funkcję w pliku binarnym klienta, pobierze lub skompiluje innego klienta. Z reguły, jeśli skonfigurujesz wstrętne środki bezpieczeństwa (takie jak konieczność wpisywania hasła do każdej operacji svn), użytkownicy będą ominąć je w sposób, który pogorszy bezpieczeństwo. (Na przykład, napisanie skryptu opakowania zawierającego hasło. Które pozostawią czytelne dla całego świata.) Więc nie rób tego.

Powtórzmy: nie można, przy pomocy samych środków technicznych, uniemożliwić użytkownikom przechowywania hasła w pliku. Możesz tego zabronić, ale jeśli utrudni to ich życie, i tak to zrobią.

Jeśli martwisz się kradzieżą laptopa lub kopii zapasowej, zaszyfruj katalog domowy użytkowników. Chroni to zarówno hasła, jak i dane. Jeśli cały katalog domowy jest zaszyfrowany, hasło szyfrowania jest zwykle takie samo jak hasło logowania, ze względów użyteczności. Pamiętaj, aby mieć zasady tworzenia kopii zapasowych haseł (np. Zapieczętowaną kopertę), ponieważ utraty hasła szyfrowania nie można odzyskać.

Jeśli martwisz się o ponowne użycie hasła, nałóż losowe (stąd unikalne) hasło, które wpisują raz na zawsze do swojego klienta. Oczywiście mają prosty proces zmiany haseł.


Świetne punkty dookoła. Z pewnością widziałem, jak użytkownicy omijają stosowane przez nas protokoły, aby ułatwić im życie. Będę musiał zobaczyć, co jeszcze oferuje svn w zakresie uwierzytelniania, które nie denerwuje użytkowników, na przykład oparte na kluczach.
Banjer

0

BTW nawet przed zaszyfrowaniem czegokolwiek, zadbałbym o uprawnienia do plików: z ciekawości sprawdziłem własną konfigurację i okazało się, że jest to świat czytelny. W przypadku pliku zawierającego jasne hasło wygląda mi to na lukę bezpieczeństwa.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.