Jak ustawić hasła użytkownika wyświetlane w systemie Linux jako zwykły tekst?

28

Wiemy, że hasła użytkowników są zapisywane /etc/passwd, ale w sposób zaszyfrowany, więc nawet root nie może ich zobaczyć:

jane:x:501:501::/home/jane:/bin/bash
fred:x:502:502::/home/fred:/bin/bash

Jak pokazano powyżej, :x:reprezentuje hasło.

Czy istnieje sposób (możliwa konfiguracja), aby zapisać hasło w postaci /etc/passwdzwykłego tekstu i aby root mógł je zobaczyć?

password

— użytkownik78050
źródło

10

Nie. I to jest funkcja. Nie ma też żadnego rzeczywistego powodu, ponieważ konto root nie potrzebuje hasła użytkownika, aby uzyskać dostęp do swoich plików. W jakich okolicznościach chcesz tego?

— HalosGhost

1

Jestem tylko ciekawy, dlaczego administrator (root) systemu nie widzi haseł innych użytkowników?

— user78050,

5

@ user78050, ponieważ użytkownik root nie ma powodu, aby znać hasła innych użytkowników, a zezwolenie na to byłoby poważnym zagrożeniem bezpieczeństwa.

— David Z

16

Ponieważ narusza najprostszą zasadę bezpieczeństwa w branży: „nigdy nie przechowuj haseł w postaci zwykłego tekstu”. Gdy zabezpieczenia są dobrze wykonane, tylko użytkownik powinien znać swoje hasło, nikt inny. Ponadto nie ma absolutnie żadnego powodu, aby to robić. Nie mogę wymyślić żadnej sytuacji administracyjnej, w której użytkownik root mógłby poznać hasło innego użytkownika.

— HalosGhost

3

Użyj „metody szyfrowania” MD5, a następnie przełam hasła przy użyciu tęczowych tabel .

— Cristian Ciupitu,

58

Pozostałe dwie odpowiedzi powiedziały - poprawnie! - że jest to zły pomysł ™ . Ale powiedzieli ci również, że jest to trudne , wymagające zmiany wielu programów.

To nieprawda. To jest bardzo łatwe. Musisz tylko zmienić jeden lub dwa pliki konfiguracyjne. Uważam, że należy to podkreślić, ponieważ powinieneś być tego świadomy podczas logowania do systemów, nad którymi nie masz kontroli. W rzeczywistości nie wprowadzą hasła w postaci zwykłego tekstu /etc/passwdlub /etc/shadowprzejdzie do innego pliku. Uwaga: Nie testowałem ich, ponieważ wolałbym nie mieć hasła w postaci zwykłego tekstu.

Edytuj /etc/pam.d/common-password(aby złapać zmienione hasło) lub /etc/pam.d/common-auth(aby złapać login) i dodać… pam_exec expose_authtok log=/root/passwords /bin/cat
Edytuj oba i przełącz z pam_unix na pam_userdb za pomocą crypt=none. Alternatywnie, możesz umieścić je tylko jako wspólne hasło (pozostawiając również pam_unix), aby po prostu rejestrować hasła po ich zmianie.
Możesz usunąć shadowopcję (jak również wszelkie mocne opcje skrótu) z pam_unix, aby wyłączyć plik cienia i wrócić do tradycyjnych haseł szyfrujących. Nie zwykły tekst, ale John the Ripper naprawi to za ciebie.

W celu uzyskania dalszych informacji sprawdź Przewodnik administratora systemu PAM .

Możesz także edytować kod źródłowy PAM lub napisać własny moduł. Musisz tylko skompilować PAM (lub moduł), nic więcej.

— derobert
źródło

1

Przypuszczam, że hasła do zwykłego tekstu zostały zapisane /root/passwords.

— Faheem Mitha,

Btw. bardzo dobrze wiedzieć, jak to jest łatwe i gdzie muszę patrzeć, jeśli boję się skompromitowanego systemu.

— erik

8

@erik Zadaniem pytającego jest wybranie dowolnej odpowiedzi, która uzna za najbardziej przydatną jako odpowiedź zaakceptowana. Prawdopodobnie dobrze, że OP stwierdził, „nie rób tego!” najbardziej pomocny… Ponadto, aby być jasnym, nie jest to jedyny sposób na kradzież haseł w zainfekowanym lub złośliwie administrowanym systemie. Więc nie możesz po prostu spojrzeć na konfigurację PAM, aby ustalić, czy jesteś bezpieczny.

— derobert

3

Zakłada się to raczej przy założeniu, że dystrybucja używa PAM, w żadnym wypadku nie wszyscy.

— Vality

1

@msw Odpowiedziałem, ponieważ wydaje się, że powszechne jest przekonanie, że uruchomienie Linux-a z hasłami w postaci czystego tekstu jest trudne (Bobby, ku swojemu, naprawił swoją odpowiedź; Anthon wciąż sprawia, że to brzmi ciężko). To niebezpieczne przekonanie, ponieważ zachęca do ponownego użycia hasła. Gdybym właśnie napisał odpowiedź „właściwie, łatwo jest edytować plik lub dwa, ale nie powiem ci”, to nikt by w to nie uwierzył. Po co słuchać mnie (w owym czasie) znacznie wyżej głosowanych, dokładniejszych odpowiedzi? Zrozumienie wymaga powiedzenia, jak to zrobić. (Chociaż nie są to przykłady kopiowania i wklejania. Myśli wciąż trzeba używać.)

— derobert

34

Ojej, dobra, zacznijmy od samego początku ...

Wiemy, że hasła użytkowników są zapisywane w / etc / passwd, ale w sposób zaszyfrowany

Nie, one były przechowywane w /etc/passwd, i to było dość dawno temu. Obecnie hasła są przechowywane przez większość czasu w tak zwanym pliku cienia/etc/shadow .

ale w sposób zaszyfrowany, więc nawet root ich nie widzi:

Wiem, że czasami jest używany zamiennie, ale mieszanie nie jest szyfrowaniem . Szyfrowanie jest z samej definicji odwracalne, co oznacza, że możesz przetłumaczyć zaszyfrowaną rzecz z powrotem na formę czystego tekstu. Hashowanie jest zaprojektowane tak, aby nie było odwracalne w żaden sposób (z wyjątkiem brutalnej siły). Oryginalna postać czystego tekstu mieszanego elementu nie powinna być możliwa do odzyskania.

Hasła w pliku cienia są przechowywane jako skróty.

jak pokazano powyżej: x: reprezentuje hasło

W xtym przypadku jest to tylko symbol zastępczy dla starszego pola hasła. Te xśrodki, że hasło można znaleźć w pliku shadow.

Czy istnieje sposób (możliwa konfiguracja), aby zapisać hasło w pliku / etc / passwd w postaci zwykłego tekstu i aby root mógł je zobaczyć?

Tak, jest to rzeczywiście możliwe, ale z niektórych powodów nie jest to dobry pomysł. Odpowiedź Deroberta wyjaśnia dość prosty sposób na zrobienie tego .

Ale dlaczego to nie jest dobry pomysł? Z prostego, ale bardzo ważnego powodu: bezpieczeństwa. Proponuję przeczytać następujące pytania:

Podsumowując, załóżmy, że: W firmie istnieje serwer, wszystkie konta użytkowników są zabezpieczone hasłami, a dane na tych kontach użytkowników są szyfrowane tym samym hasłem. Włamywacz z zewnątrz uzyskuje dostęp do serwera, ale nie może uzyskać dostępu do żadnych ważnych danych, ponieważ są one nadal szyfrowane na kontach użytkowników.

Załóżmy teraz, że hasła będą przechowywane jako zwykły tekst. Łamacz nagle uzyskałby dostęp do wszystkiego , ponieważ hasła można odczytać. Ale jeśli są przechowywane jako wartości mieszane, są prawie bezużyteczne dla nikogo oprócz ludzi z dużą ilością zasobów, aby wykonać atak brutalną siłą.

— Konstabl
źródło

2

W obronie OP dotyczącej szyfrowania i mieszania strona podręcznika crypt z glibc mówi: „Jeśli sól jest ciągiem znaków rozpoczynającym się od znaków, "$id$"po których następuje ciąg zakończony przez "$": $id$salt$encrypted to zamiast używania maszyny DES, ididentyfikuje zastosowaną metodę szyfrowania , a następnie określa sposób interpretacji reszty ciągu ».

— Cristian Ciupitu

1

Interesujące, ale nie odpowiada na główne pytanie, jak robi to odpowiedź deroberta.

— erik

6

@erik Czasami właściwą odpowiedzią na pytanie jest „nie rób tego”, nawet jeśli jest to technicznie możliwe. To jest jeden z tych czasów.

— Gilles „SO- przestań być zły”,

1

Sugeruję zmianę tego wiersza: „Nie, nie ma innego sposobu niż zmiana wielu aplikacji i sposobu ich działania”. Pozostawia to wrażenie, że nie jest łatwo (a przynajmniej łatwo zrobić coś funkcjonalnie równoważnego).

— derobert

2

@Bobby To doskonała odpowiedź, ale nie doskonała odpowiedź. Aby była to doskonała odpowiedź, należy zmienić tę część, że „nie jest to łatwo możliwe”, ponieważ wyraźnie tak jest, jak pokazano w odpowiedzi deroberta.

— Michael Dorst,

10

Po pierwsze, zaszyfrowane hasła nie są /etc/passwd, ale są /etc/shadow. Jednym z powodów jest to, że /etc/passwdjest publicznie czytelny (dzięki czemu można np. Znaleźć informacje o polu GECOS dla innego użytkownika), a zwłaszcza w przypadku starszych schematów szyfrowania może pozwolić na ataki typu „brute force” na zaszyfrowane hasło.

Samo przechowywanie haseł w postaci zwykłego tekstu nie jest konieczne i wymagałoby aktualizacji programu do obsługi haseł i bibliotek odczytywających /etc/shadowinformacje w celu sprawdzenia poprawności haseł. A potem musisz mieć nadzieję, że wszystkie narzędzia korzystają z bibliotek współdzielonych, aby uzyskać dostęp do tych informacji, zamiast być statycznie powiązanym z czymś, co nie rozumie przechowywania zwykłego hasła.

Jeśli byłaby to opcja w konfiguracji zestawu, to zawsze byliby głupi ludzie, którzy włączyliby go niewłaściwie. Podczas gdy wciąż pracują na ekranach CRT i nadają to w taki sposób, że można je łatwo odebrać z zewnątrz budynku, gdy patrzą na informacje.

Poza tym ludzie używają tego samego lub podobnego hasła w wielu systemach, więc nie jest dobrym pomysłem, aby jakiekolwiek hasła były czytelne dla ludzi. Ponieważ jakiś sysadmin może spróbować swoich w innych systemach, wie, że użytkownik ma konto.

Muszą być bardziej interesujące rzeczy, których działanie można zbadać w twoim systemie.

— Anthon
źródło

3

/etc/shadownie przechowuje zaszyfrowanych haseł, przechowuje skróty haseł. Tak, funkcja jest wywoływana crypt, a strona podręcznika mówi „zaszyfrowany”, ale jeśli nazwiesz rybę rowerem, to nie da mu kół. Pamiętaj, że możliwe byłoby utworzenie /etc/shadowhasła do sklepu w innym formacie bez ponownej kompilacji programów (przynajmniej w Linuksie i Solarisie): metody uwierzytelniania są zawsze łączone dynamicznie. Przechowywanie haseł jako zwykłego tekstu byłoby okropnym pomysłem, ale jest możliwe przy odrobinie pracy .

— Gilles „SO- przestań być zły”,

@ gilles Właśnie użyłem terminologii OP, ale masz rację, że skrót jest bardziej odpowiednim terminem.

— Anthon

3

Podstawowym powodem (dlaczego jest to zły pomysł) jest to, że żaden użytkownik (root, administrator lub inny) nigdy nie powinien mieć dostępu do hasła użytkownika.

Po prostu dlatego, że hasło jest sposobem uwierzytelnienia. Jeśli znam hasło innego użytkownika, znam jego dane uwierzytelniające (nazwa użytkownika + hasło), dzięki czemu mogę zalogować się jako ten użytkownik , podszywając się pod niego (lub on lub on).

Wszelkie działania, które wykonam, gdy jestem zalogowany jako ten użytkownik, za drugiego użytkownika będą ponosić odpowiedzialność. I nie tak powinno działać uwierzytelnianie.

Działania mogą być katastrofalne, takie jak usuwanie całej gamy ważnych plików, kasowanie dysków twardych, kasowanie kopii zapasowych, zamykanie planów energii jądrowej itp.

Lub po prostu nielegalne. Wyobraź sobie instytucję bankową, w której ja (administrator) mam dostęp do wszystkich haseł. Za pomocą hasła kasjera mogę zlecić przeniesienie miliona dolarów z konta bankowego prezydenta na konto bankowe mycie okien. Następnie użyj nadrzędnego hasła kasjera, aby zatwierdzić transakcję. Następnie zatwierdź czek z konta do czyszczenia okien na moje własne konto bankowe w banku.

Potem jadę na długie wakacje na Bahamy ...

W tym widoku mieszanie haseł i korzystanie z oddzielnych plików cienia można postrzegać jako sposób na egzekwowanie tej reguły (żaden użytkownik nie powinien mieć możliwości podszywania się pod inną).

I jak skomentował @ Miral ^* , istnieje wyjątek od sutego, że dopuszczając personifikację (i rodzaje odrzucenia powyższego argumentu), prowadzi również dziennik jej użycia (więc zmienia zasady na „tylko administratorzy mogą podszywać się pod innych, ale dziennik jest przechowywany ”).

^{* Przykład bankowy prawdopodobnie nie był najlepszy. W każdym środowisku, w którym bezpieczeństwo ma kluczowe znaczenie, zwykle potrzeba więcej sposobów uwierzytelnienia i autoryzacji niż tylko jedno hasło.}

— ypercubeᵀᴹ
źródło

Wadą tego argumentu jest to, że użytkownik root może podszywać się pod każdego innego użytkownika w systemie, bez konieczności znajomości swojego hasła. Tak proste jak su otheruser.

— Miral

@Miral masz rację, nie brałem tego pod uwagę. I chociaż użycie sujest zarejestrowane, su nie rejestruje tego, co faktycznie się dzieje, gdy użytkownik podszywa się pod inną osobę. A złośliwy root może zawsze zmieniać dzienniki, aby ukryć działania przed przyszłymi śledczymi.

— ypercubeᵀᴹ