web-dev-qa-db-ja.com

Linuxでユーザーパスワードをクリアテキストとして表示する方法

ユーザーのパスワードは/etc/passwdに保存されますが、暗号化されているため、rootもパスワードを見ることができません。

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

上記のように、:x:はパスワードを表します。

パスワードを/etc/passwdにクリアテキストで保存し、ルートがそれらを見ることができるようにする方法（可能な構成）はありますか？

password
28
user78050

他の2つの答えは、正しく、！これは悪いアイデア™だと言っています。しかし、彼らはまた、やるのが難しいので、たくさんのプログラムを変更する必要があると言っています。

それは真実ではない。それは非常に簡単です。 1つまたは2つの構成ファイルを変更するだけで済みます。これを指摘することは重要だと思います。自分が制御していないシステムにログインするときは、これに注意する必要があるからです。これらは実際にはプレーンテキストのパスワードを/etc/passwdまたは/etc/shadowに入れません。別のファイルに入力されます。プレーンテキストのパスワードを使用したくないので、これらはテストしていません。

  1. /etc/pam.d/common-password（変更されたパスワードをキャッチする）または/etc/pam.d/common-auth（ログインをキャッチする）を編集して、… pam_exec expose_authtok log=/root/passwords /bin/catを追加します。

  2. これらの両方を編集し、crypt=noneを使用してpam_unixからpam_userdbに切り替えます。あるいは、パスワードが変更されたときにパスワードを記録するために、それを共通パスワードにのみ（pam_unixも残して）置くことができます。

  3. Pam_unixからshadow（および強力なハッシュオプション）オプションを削除してシャドウファイルを無効にし、従来の暗号化パスワードに戻すことができます。プレーンテキストではありませんが、リッパージョンが修正します。

詳細は PAMシステム管理ガイド を確認してください。

PAMのソースコードを編集したり、独自のモジュールを記述したりすることもできます。 PAM（またはモジュール）をコンパイルするだけでよく、それ以外は必要ありません。

58
derobert

よし、よし、最初から始めよう...

ユーザーのパスワードは/ etc/passwdに保存されていますが、暗号化されています

いいえ、それらは/etc/passwdに格納されています。これはかなり前のことです。今日、パスワードは保存されます いわゆるシャドウファイルに 、ほとんどの場合/etc/shadow。

しかし、暗号化された方法で、ルートでさえそれらを見ることができません：

私はそれが時々交換可能に使用されることを知っています、しかし ハッシュ は 暗号化 ではありません。暗号化は、その定義により可逆的です。つまり、暗号化されたものをクリアテキスト形式に戻すことができます。ハッシュは、（ブルートフォースを除いて）いかなる方法でも不可逆であるように設計されています。ハッシュされたものの元のクリアテキスト形式は、回復可能ではありません。

シャドウファイルのパスワードはハッシュとして保存されます。

上記のように：x：パスワードを表します

この場合のxは、レガシーパスワードフィールドのプレースホルダーにすぎません。 xは、パスワードがシャドウファイルにあることを意味します。

/ etc/passwdにパスワードを平文で保存し、ルートがそれらを見ることができるようにする方法（可能な構成）はありますか？

はい、これは確かに可能ですが、いくつかの理由でお勧めできません。 Derobertの回答では、かなり簡単な方法で説明しています 。

しかし、なぜそれが良い考えではないのですか？まあ、単純ですが非常に重要な理由からです。セキュリティです。私はこれらの質問を読むことをお勧めします：

ただし、要約すると、次のように想定します。社内にサーバーがあり、すべてのユーザーアカウントはパスワードで保護されており、これらのユーザーアカウントのデータは同じパスワードで暗号化されています。外部からのクラッカーはサーバーにアクセスしますが、ユーザーアカウントで暗号化されているため、重要なデータにはアクセスできません。

次に、パスワードがプレーンテキストで格納されると仮定します。パスワードが読み取られるため、クラッカーは突然everythingにアクセスできるようになります。しかし、それらがハッシュ値として保存されている場合、ブルートフォース攻撃を実行するためのリソースが豊富な人々を除いて、それらはほとんど役に立ちません。

35
Bobby

まず、暗号化されたパスワードは/etc/passwdではなく、/etc/shadowにあります。これの理由の1つは、/etc/passwdが一般に読み取り可能であるため（たとえば、別のユーザーのGECOSフィールド情報を見つけることができます）、特に古い暗号化スキームでは、暗号化されたパスワードに対するブルートフォース攻撃を可能にする可能性があります。

パスワードをプレーンテキストで保存するだけでは必要ありません。パスワードプログラムとライブラリを更新し、/etc/shadow情報を読み取って有効なパスワードを確認する必要があります。そして、すべてのユーティリティがプレーンテキストのパスワードストレージを理解しないものに対して静的にリンクされるのではなく、共有ライブラリを使用してその情報にアクセスすることを期待する必要があります。

これが設定の構成のオプションである場合、不適切にスイッチを入れる愚かな人々が常にいます。また、彼らはまだCRT画面で作業しており、情報を見ながら建物の外から簡単に拾えるようにこれを放送しています。

それとは別に、人々は複数のシステムで同じまたは類似のパスワードを使用する傾向があるため、パスワードを人間が読めるようにすることはお勧めできません。一部のシステム管理者は他のシステムで再試行できるため、ユーザーがアカウントを持っていることを知っています。

もっと興味深いことがあるはずです。システムでの動作を調査できます。

10
Anthon

（これが悪い考えである理由の）基本的な理由は、他のユーザーのパスワードにアクセスできるユーザー（root、adminなど）が存在してはならないということです。

単にパスワードが認証の手段だからです。他のユーザーのパスワードを知っている場合は、その資格情報（ユーザー名+パスワード）を知っているので、ログインできますそのユーザーとして、彼（またはそのユーザー）になりすまします。

そのユーザーとしてログインしたときに私が行うすべてのアクションには、他のユーザーが責任を負います。そして、それは認証が機能する方法ではありません。

重要なファイル全体を削除する、ハードディスクを消去する、バックアップを消去する、原子力計画をシャットダウンするなど、アクションは悲惨なものになる可能性があります。

または単に違法です。私（管理者）がすべてのパスワードにアクセスできる銀行を想像してみてください。キャッシャーのパスワードを使用して、大統領の銀行口座から窓口クリーナーの銀行口座への100万ドルの移動を注文できます。次に、キャッシャーの上位パスワードを使用して、トランザクションを承認します。次に、ウィンドウクリーナーの口座から自分のオフショア銀行口座への小切手を承認します。

それから私はバハマで長期休暇に行きます...

このビューでは、パスワードのハッシュと個別のシャドウファイルの使用は、このルールを適用する手段と見なすことができます（ユーザーが別のユーザーになりすますことはできません）。

そして@Miralがコメントしたように*、suの例外があります。これは、なりすましを許可している間（および上記の引数を破棄した場合）、その使用のログも保持します（したがって、「管理者のみが他者になりすますことができますが、ログは保持されます」）。

*銀行の例はおそらく最高ではありませんでした。セキュリティが重要な環境では、通常、1つのパスワードだけではなく、より多くの認証と承認の手段が必要です。

3
ypercubeᵀᴹ