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

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ć?

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.

1. 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

2. 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.

3. 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.

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:

• Jaka jest dobra analogia do wyjaśnienia, dlaczego hasła powinny być szyfrowane dla laika?
• Jak bezpiecznie hashować hasła?
• Dlaczego powinienem hash hasła?
• Dlaczego zaszyfrowanie hasła jest tak ważne?
• Dlaczego funkcje skrótu są jednokierunkowe? Jeśli znam algorytm, dlaczego nie mogę obliczyć z niego danych wejściowych?

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łą.

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.

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.}