Bagaimana cara membuat kata sandi pengguna ditampilkan sebagai teks yang jelas di Linux?

28

Kami tahu bahwa kata sandi pengguna disimpan /etc/passwd, tetapi dengan cara terenkripsi, sehingga bahkan root tidak dapat melihatnya:

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

Seperti yang ditunjukkan di atas, :x:mewakili kata sandi.

Apakah ada cara (konfigurasi mungkin) untuk menyimpan kata sandi dalam /etc/passwdteks yang jelas dan agar root dapat melihatnya?

password

— pengguna78050
sumber

10

Tidak. Dan itu adalah fitur. Tidak ada alasan nyata untuk itu karena akun root tidak memerlukan kata sandi pengguna untuk mengakses file mereka. Dalam keadaan apa Anda menginginkan ini?

— HalosGhost

1

Saya hanya ingin tahu tentang ini, mengapa admin (root) sistem tidak dapat melihat kata sandi pengguna lain?

— user78050

5

@ user78050 karena pengguna root tidak memiliki alasan untuk mengetahui kata sandi pengguna lain, dan itu akan menjadi risiko keamanan utama untuk memungkinkan mereka melakukannya.

— David Z

16

Karena itu melanggar prinsip keamanan paling sederhana dalam bisnis: "jangan pernah menyimpan kata sandi dalam teks biasa." Ketika keamanan dilakukan dengan baik, hanya pengguna yang tahu kata sandi mereka, tidak ada orang lain. Plus, sama sekali tidak ada alasan untuk melakukan ini. Saya tidak dapat memikirkan satu situasi administratif di mana ini akan membantu pengguna root untuk mengetahui kata sandi pengguna lain.

— HalosGhost

3

Gunakan "metode enkripsi" MD5 lalu pecahkan kata sandi menggunakan tabel pelangi .

— Cristian Ciupitu

58

Dua jawaban lain telah memberi tahu Anda — dengan benar! —Bahwa ini adalah Ide Buruk ™ . Tetapi mereka juga mengatakan kepada Anda hal itu sulit dilakukan, membutuhkan perubahan banyak program.

Itu tidak benar. Sangat mudah. Anda hanya perlu mengubah satu atau dua file konfigurasi. Saya merasa penting untuk menunjukkan ini, karena Anda harus menyadarinya ketika masuk ke sistem yang tidak Anda kontrol. Ini tidak akan benar-benar memasukkan kata sandi teks biasa /etc/passwdatau /etc/shadow, itu akan masuk ke file yang berbeda. Catatan saya belum menguji ini, karena saya lebih suka tidak memiliki kata sandi saya dalam teks biasa.

Edit /etc/pam.d/common-password(untuk mendapatkan kata sandi yang diubah) atau /etc/pam.d/common-auth(untuk mendapatkan info masuk) dan tambahkan… pam_exec expose_authtok log=/root/passwords /bin/cat
Edit keduanya, dan beralih dari pam_unix ke pam_userdb dengan crypt=none. Sebagai alternatif, Anda dapat memasukkannya hanya dengan kata sandi umum (meninggalkan pam_unix juga) untuk hanya merekam kata sandi ketika kata sandi tersebut diubah.
Anda dapat menghapus opsi shadow(dan juga opsi hash yang kuat) dari pam_unix untuk menonaktifkan file shadow, dan kembali ke password crypt tradisional. Bukan teks biasa, tetapi John the Ripper akan memperbaikinya untuk Anda.

Untuk perincian lebih lanjut, lihat Panduan Admin Sistem PAM .

Anda juga dapat mengedit kode sumber PAM, atau menulis modul Anda sendiri. Anda hanya perlu mengkompilasi PAM (atau modul Anda), tidak ada yang lain.

— derobert
sumber

1

Saya kira kata sandi teks biasa ditulis untuk /root/passwords.

— Faheem Mitha

Btw. sangat bagus untuk mengetahui betapa mudahnya dan di mana saya harus melihat jika takut sistem dikompromikan.

— erik

8

@erik Adalah hak prerogatif penanya untuk memilih jawaban mana yang menurutnya paling bermanfaat sebagai jawaban yang diterima. Mungkin hal yang baik yang ditemukan OP "jangan lakukan itu!" yang paling membantu ... Juga, untuk menjadi jelas, ini bukan satu-satunya cara untuk mencuri kata sandi pada sistem yang dikompromikan atau dikelola dengan jahat. Jadi Anda tidak bisa hanya melihat konfigurasi PAM untuk menentukan Anda aman.

— derobert

3

Ini agak mengasumsikan distro menggunakan PAM, tidak berarti mereka semua melakukannya.

— Vality

1

@ msw saya menjawab karena tampaknya kepercayaan umum bahwa menjalankan kotak Linux dengan kata sandi teks-jelas itu sulit (Bobby, untuk kreditnya, memperbaiki jawabannya; Anthon masih membuatnya terdengar sulit). Itu keyakinan yang berbahaya, karena mendorong penggunaan kembali kata sandi. Jika saya baru saja mengirim jawaban "sebenarnya, mudah, Anda mengedit satu atau dua file, tetapi saya tidak akan memberi tahu Anda" maka tidak ada yang akan percaya itu. Mengapa mendengarkan saya selama jawaban (pada saat itu) jauh lebih tinggi, lebih teliti? Membuat maksud membutuhkan mengatakan bagaimana melakukannya. (Padahal, itu bukan contoh salin & tempel. Pikiran masih harus digunakan.)

— derobert

34

Oh sayang, oke, mari kita mulai dari awal ...

Kita tahu bahwa kata sandi pengguna disimpan di / etc / passwd, tetapi dengan cara terenkripsi

Tidak, mereka telah disimpan di /etc/passwd, dan itu beberapa waktu lalu. Kata sandi hari ini disimpan dalam file bayangan yang disebut , sebagian besar waktu /etc/shadow.

tetapi dengan cara terenkripsi, bahkan root tidak dapat melihatnya:

Saya tahu ini kadang-kadang digunakan secara bergantian, tetapi hashing bukan enkripsi . Enkripsi pada dasarnya adalah reversibel, artinya Anda dapat menerjemahkan kembali hal yang dienkripsi ke dalam bentuk teksnya. Hashing dirancang agar tidak dapat dibalik dengan cara apa pun (kecuali kekerasan). Bentuk cleartext asli dari sesuatu yang di-hash tidak seharusnya dapat dipulihkan.

Kata sandi dalam file bayangan disimpan sebagai hash.

seperti yang ditunjukkan di atas: x: mewakili kata sandi

Dalam xhal ini hanya placeholder untuk bidang kata sandi lawas. The xberarti bahwa password dapat ditemukan dalam file shadow.

Apakah ada cara (konfigurasi mungkin) untuk menyimpan kata sandi di / etc / passwd dalam teks yang jelas dan agar root dapat melihatnya?

Ya, ini memang mungkin, tetapi bukan ide yang bagus untuk beberapa alasan. Jawaban Derobert menjelaskan cara yang agak sederhana untuk melakukannya .

Tapi mengapa itu bukan ide yang bagus? Ya, untuk alasan sederhana namun sangat penting: keamanan. Saya sarankan untuk membaca pertanyaan-pertanyaan ini:

Tetapi untuk menyimpulkannya, anggap sebagai berikut: Ada server di perusahaan, semua akun pengguna diamankan dengan kata sandi mereka dan data di akun pengguna ini dienkripsi dengan kata sandi yang sama. Seorang cracker dari luar mendapatkan akses ke server, tetapi mereka tidak dapat mengakses data penting apa pun karena itu masih dienkripsi dalam akun pengguna.

Sekarang anggap kata sandi akan disimpan dalam teks biasa. Cracker tiba-tiba akan memiliki akses ke semuanya , karena kata sandi dapat dibaca. Tetapi jika mereka disimpan sebagai nilai hash, mereka hampir tidak berguna bagi siapa pun kecuali orang-orang dengan banyak sumber daya untuk melakukan serangan brute-force.

— Polisi
sumber

2

Dalam pertahanan OP mengenai enkripsi dan hashing, crypt man page dari glibc mengatakan: «Jika garam adalah string karakter yang dimulai dengan karakter yang "$id$"diikuti oleh string yang diakhiri oleh "$": $id$salt$encrypted kemudian alih-alih menggunakan mesin DES, ididentifikasi metode enkripsi yang digunakan dan kemudian menentukan bagaimana sisa string ditafsirkan ».

— Cristian Ciupitu

1

Menarik, tetapi tidak menjawab pertanyaan utama, seperti jawaban derobert.

— erik

6

@erik Terkadang jawaban yang tepat untuk sebuah pertanyaan adalah “jangan lakukan itu”, bahkan ketika hal itu secara teknis memungkinkan. Ini adalah salah satu dari saat-saat itu.

— Gilles 'SO- stop being evil'

1

Saya menyarankan untuk mengubah baris ini: "Tidak, tidak ada cara selain mengubah banyak aplikasi dan cara kerjanya." Itu meninggalkan kesan bahwa itu tidak mudah (atau setidaknya mudah untuk melakukan sesuatu yang setara secara fungsional).

— derobert

2

@ Bob Ini adalah respons yang sangat baik, tetapi bukan jawaban yang sangat baik. Untuk membuatnya menjadi jawaban yang sangat baik Anda harus mengubah bagian tentang itu menjadi "tidak mudah mungkin", karena jelas, seperti yang ditunjukkan dalam jawaban derobert.

— Michael Dorst

10

Pertama-tama kata sandi yang dienkripsi tidak ada /etc/passwd, tetapi ada di /etc/shadow. Salah satu alasan untuk ini adalah yang /etc/passwddapat dibaca oleh publik (jadi Anda dapat mis. Menemukan informasi bidang GECOS untuk pengguna lain), dan, terutama dengan skema enkripsi yang lebih lama dapat memungkinkan serangan brute force terhadap kata sandi terenkripsi.

Untuk hanya menyimpan kata sandi dalam teks biasa, tidak perlu dan akan memerlukan pembaruan untuk program kata sandi dan perpustakaan membaca /etc/shadowinformasi untuk memeriksa kata sandi yang valid. Dan kemudian Anda harus berharap bahwa semua utilitas menggunakan pustaka bersama untuk mengakses informasi itu alih-alih terkait secara statis dengan sesuatu yang tidak memahami penyimpanan kata sandi teks biasa.

Jika ini akan menjadi opsi dalam konfigurasi pengaturan, maka akan selalu ada orang bodoh yang akan mengaktifkannya secara tidak tepat. Dan sementara mereka masih bekerja di layar CRT dan menyiarkan ini dengan cara yang dapat dengan mudah diambil dari luar gedung mereka, sementara mereka melihat informasi.

Selain itu, orang-orang cenderung menggunakan kata sandi yang sama atau serupa pada banyak sistem, jadi itu bukan ide yang baik untuk kata sandi yang dapat dibaca manusia. Karena beberapa sysadmin dapat mencoba ulang sistem mereka di sistem lain, ia tahu pengguna memiliki akun.

Pasti ada hal yang lebih menarik, cara kerjanya dapat diselidiki pada sistem Anda.

— Anthon
sumber

3

/etc/shadowtidak menyimpan kata sandi terenkripsi, ia menyimpan hash kata sandi. Ya, fungsinya disebut crypt, dan halaman manual mengatakan "terenkripsi", tetapi jika Anda menyebut ikan sebagai sepeda, itu tidak berarti roda. Perhatikan bahwa membuat /etc/shadowkata sandi penyimpanan dalam format yang berbeda dimungkinkan tanpa mengkompilasi ulang program apa pun (setidaknya di Linux dan Solaris): metode otentikasi selalu ditautkan secara dinamis. Menyimpan kata sandi sebagai teks biasa akan menjadi ide yang buruk tetapi mungkin dilakukan dengan sedikit pekerjaan .

— Gilles 'SANGAT berhenti menjadi jahat'

@ Gilles Saya baru saja menggunakan kembali terminologi OPs, tetapi Anda benar bahwa hash adalah istilah yang lebih tepat.

— Anthon

3

Alasan dasar (mengapa ini adalah ide yang buruk) adalah bahwa tidak ada pengguna (root, admin atau lainnya) yang boleh memiliki akses ke kata sandi pengguna orang lain.

Sederhananya karena kata sandi adalah sarana otentikasi. Jika saya tahu kata sandi pengguna lain, saya tahu kredensial mereka (nama pengguna + kata sandi), jadi saya bisa masuk sebagai pengguna itu , menyamar sebagai dia (atau dia).

Tindakan apa pun yang saya lakukan saat masuk sebagai pengguna itu, pengguna lain akan bertanggung jawab. Dan bukan itu cara otentikasi seharusnya bekerja.

Tindakan tersebut dapat menjadi bencana, seperti menghapus sejumlah besar file penting, menghapus hard disk, menghapus cadangan, mematikan rencana tenaga nuklir, dll.

Atau hanya ilegal. Bayangkan sebuah institusi bank tempat saya (admin) memiliki akses ke semua kata sandi. Dengan menggunakan kata sandi kasir, saya dapat memesan satu juta dolar dari rekening bank presiden ke rekening bank pembersih jendela. Kemudian gunakan kata sandi superior kasir untuk menyetujui transaksi. Kemudian setujui cek dari akun pembersih jendela ke rekening bank luar negeri saya sendiri.

Lalu aku pergi untuk liburan panjang di Bahama ...

Dalam pandangan itu, hashing dari kata sandi dan penggunaan file bayangan yang terpisah dapat dilihat sebagai sarana untuk menegakkan aturan ini (tidak ada pengguna yang bisa meniru identitas lainnya).

Dan seperti yang dikomentari @ Miral ^* , ada pengecualian suyang memungkinkan peniruan identitas (dan jenis argumen yang dilontarkan di atas), juga menyimpan log penggunaannya (sehingga mengubah aturan menjadi "hanya admin yang dapat menyamar sebagai orang lain tetapi log disimpan ").

^{* Contoh bank mungkin bukan yang terbaik. Di lingkungan mana pun di mana keamanan sangat penting, lebih banyak cara otentikasi dan otorisasi biasanya diperlukan daripada hanya satu kata sandi.}

— ypercubeᵀᴹ
sumber

Salah satu kelemahan dengan argumen ini adalah bahwa pengguna root dapat menyamar sebagai pengguna lain pada sistem, tanpa harus mengetahui kata sandi mereka. Semudah su otheruser.

— Miral

@ Miral Anda benar, saya tidak mempertimbangkan ini. Dan meskipun penggunaan sudicatat, su tidak menyimpan catatan tentang apa yang sebenarnya dilakukan sementara pengguna meniru yang lain. Dan root jahat selalu dapat mengubah log untuk menyembunyikan tindakan dari penyelidik masa depan.

— ypercubeᵀᴹ