Loading article…
passwdは、 Unix、Plan 9、Inferno、およびほとんどのUnix系オペレーティングシステムで使用されるコマンドで、ユーザーのパスワードを変更するために使用されます。ユーザーが入力したパスワードは、鍵導出関数を通してハッシュ化された新しいパスワードが生成され、保存されます。保存されるのはハッシュ化されたパスワードのみで、セキュリティ上の理由から入力されたパスワード自体は保存されません。
ユーザーがログオンすると、ログオン処理中にユーザーが入力したパスワードが同じ鍵導出関数にかけられ、生成されたハッシュ値が保存されているバージョンと比較されます。ハッシュ値が一致すれば、入力されたパスワードは正しいとみなされ、ユーザーは認証されます。理論的には、2つの異なるパスワードが同じハッシュ値を生成する可能性があります。しかし、暗号学的ハッシュ関数は、同じハッシュ値を生成するパスワードを見つけることが非常に困難で、実際には不可能になるように設計されているため、生成されたハッシュ値が保存されているハッシュ値と一致すれば、ユーザーは認証されます。[ 1 ]
passwd コマンドは、ローカル アカウントのパスワードを変更するために使用できます。また、ほとんどのシステムでは、NIS、Kerberos、LDAPなどの分散認証メカニズムで管理されているパスワードを変更するためにも使用できます。
このファイルは、システムにログインする可能性のあるユーザー/etc/passwd、または実行中のプロセスを所有するその他のオペレーティングシステムのユーザーIDに関する情報を含む、テキストベースのデータベースです。
多くのオペレーティングシステムでは、このファイルは、より一般的なpasswd名前サービスの多くの可能なバックエンドの1つにすぎません。
このファイル名は、当初の用途の一つである、ユーザーアカウントのパスワード検証に使用されるデータを格納する機能に由来しています。しかし、現代のUnixシステムでは、セキュリティ上重要なパスワード情報は、シャドウパスワードやその他のデータベース実装を用いて、別のファイルに保存されることが多くなっています。
この/etc/passwdファイルには通常、システム上のすべてのユーザーが読み取り可能なファイルシステム権限（ワールド読み取り可能）が付与されていますが、変更できるのはスーパーユーザー、または特定の目的の特権コマンドを使用するユーザーのみです。
この/etc/passwdファイルはテキストファイルで、1行に1つのレコードがあり、各レコードはユーザーアカウントを記述しています。各レコードはコロンで区切られた7つのフィールドで構成されています。ファイル内のレコードの順序は通常重要ではありません。
レコードの例は次のとおりです。
jdoe : x : 1001 : 1000 : John Doe、1007号室、(234)555-8910、(234)555-0044、メール: /home/jdoe : /bin/sh左から右の順にフィールドは次のとおりです。[ 2 ]
jdoeユーザー名: ユーザーがオペレーティングシステムにログインする際に入力する文字列。ログイン名。ファイルにリストされているユーザー間で一意である必要があります。x: ユーザーのパスワードを検証するために使用される情報。形式はシャドウパスワードファイルの対応するフィールドと同じで、さらに「x」に設定すると実際のパスワードがシャドウファイルにあることを意味するという慣例があります。これは現代のシステムではよくあることです。[ 3 ]1001ユーザー識別番号。オペレーティングシステムが内部的に使用する番号です。ユーザーを一意に識別するため、一意である必要があります。1000:ユーザーの主要グループを識別するグループ識別番号。このユーザーによって作成されたすべてのファイルは、最初はこのグループからアクセス可能です。John Doe,Room 1007...: Gecos フィールド、人物またはアカウントを説明するコメント。通常、これはユーザーのフルネームと連絡先の詳細を含むカンマ区切りの値のセットです。[ 4 ]/home/jdoe: ユーザーのホームディレクトリへのパス。/bin/sh: ユーザーがシステムにログインするたびに起動されるプログラム。対話型ユーザーの場合、通常はシステムのコマンドラインインタープリタ（シェル）のいずれかです。/etc/shadowハッシュ化されたパスワードデータへのアクセスを、特権の高いユーザー以外には制限することで、パスワードのセキュリティレベルを高めるために使用されます。通常、そのデータはスーパーユーザーが所有し、スーパーユーザーのみがアクセスできるファイルに保存されます。[ 5 ]
システム管理者は、ハッシュ化されたパスワードのリストを権限のないユーザーが読み取れないようにすることで、ブルートフォース攻撃の可能性を減らすことができます。これを実現する最も簡単な方法は、passwdデータベース自体をrootユーザーのみが読み取れるようにすることです。しかし、これではユーザー名とユーザーIDのマッピングなど、ファイル内の他のデータへのアクセスが制限され、既存の多くのユーティリティや機能が動作しなくなります。解決策の一つは、パスワードハッシュを他のデータとは別に、誰でも読み取れるpasswdファイルに格納する「シャドウ」パスワードファイルを使用することです。ローカルファイルの場合、これは通常LinuxやUnixシステム、またはBSDシステムで/etc/shadow行われ、いずれもrootユーザーのみが読み取れます。（従来の「全能のroot」セキュリティモデルを採用しているシステムでは、rootユーザーは他の方法で情報を取得できるため、データへのrootアクセスは許容範囲内とみなされます。）最近のUnix系オペレーティングシステムはほぼすべて、シャドウパスワードを使用しています。/etc/master.passwd
シャドウパスワードファイルは、攻撃者がハッシュ化されたパスワードにアクセスするという問題を完全に解決するものではありません。なぜなら、一部のネットワーク認証方式は、ハッシュ化されたパスワードをネットワーク経由で送信する（場合によっては平文で、例えばTelnet [ 6 ]）ため、傍受される可能性があるからです。テープや光メディアに書き込まれたシステムバックアップなどのシステムデータのコピーも、ハッシュ化されたパスワードを不正に入手する手段になり得ます。さらに、正当なパスワードチェックプログラムで使用される関数は、悪意のあるプログラムが迅速な認証チェックを実行できないように記述する必要があります。
特定のシステムでパスワードシャドウイングが有効になっているかどうかに関わらず、passwd ファイルはすべてのユーザーが読み取り可能であり、さまざまなシステムユーティリティ ( grepなど) が動作できます (たとえば、システム上に存在するユーザー名がファイル内に存在することを確認するため)。一方、書き込みができるのはルートユーザーのみです。パスワードシャドウイングがない場合、これは、システムへの権限のないアクセスを持つ攻撃者が、すべてのユーザーのパスワードのハッシュ化された形式を取得できることを意味します。これらの値を使用して、オフラインで総当たり攻撃を実行できます。ハッシュ化されたパスワードに対して、考えられるパスワードを比較的迅速にテストできますが、異常な数のログイン試行失敗を検出するように設計されたシステムセキュリティ対策に警告を発することはありません。特にハッシュにソルトが使用されていない場合は、これらのハッシュ化されたパスワードをレインボーテーブル (一意のハッシュからパスワードを返すために特別に作成されたデータベース) で検索することもできます。
シャドウパスワード方式が使用されている場合、ファイル内の各ユーザーのパスワードフィールドには、ハッシュ化されたパスワードの代わりに「 」や「 」/etc/passwdなどの文字が表示され、通常は以下のユーザー情報が含まれています。*x/etc/shadow
$id$salt$hashedは、 crypt (C)によって生成されたパスワードハッシュの印刷可能な形式です。ここで、$idは使用されるアルゴリズムです。NetBSD などの他の Unix ライクなシステムでは、値が異なる場合があります。キーストレッチングは、パスワードの解読の難易度を上げるために使用され、デフォルトでは、修正された MD5 の 1000 ラウンド、[ 7 ] Blowfish の 64 ラウンド、SHA-256 または SHA-512 の 5000 ラウンドが使用されます。[ 8 ] Blowfishの場合、または SHA-256 および SHA-512 の場合、ラウンド数は を使用することで変更できます$A$rounds=X$。ここで、「A」と「X」は、アルゴリズム ID とラウンド数です。一般的な ID 値には、次のものがあります。[ 9 ]シャドウファイルのフォーマットはシンプルで、基本的にパスワードファイルと同じです。つまり、ユーザーごとに1行、各行に順序付けられたフィールドがあり、フィールドはコロンで区切られています。多くのシステムでは、シャドウファイル内のユーザー行の順序が、パスワードファイル内の対応するユーザーの順序と完全に一致する必要があります。
パスワードシャドウイングが導入される以前は、Unixユーザーのハッシュ化されたパスワードは、/etc/passwdファイル内のレコードの2番目のフィールド（上記で説明した7つのフィールドの形式内）に保存されていました。
パスワードシャドウイングは、1980年代半ばのSunOSの開発、 1988年のSystem V Release 3.2、 1990年のBSD 4.3 Renoで初めてUnixシステムに登場しました。 [ 12 ] しかし、以前のUNIXリリースから移植を行ったベンダーは、必ずしも新しいパスワードシャドウイング機能をリリースに含めていなかったため、それらのシステムのユーザーはパスワードファイル攻撃にさらされていました。
システム管理者は、パスワードを各接続システム上のファイルではなく、 NISやLDAPなどの分散データベースに保存するように設定することもできます。NISの場合、シャドウパスワード機構はNISサーバー上で依然として使用されることがよくあります。その他の分散メカニズムでは、さまざまなユーザー認証コンポーネントへのアクセスに関する問題は、基盤となるデータリポジトリのセキュリティ機構によって処理されます。
1987年、オリジナルのShadow Password Suiteの作者であるジュリー・ハウは、コンピュータへの不正侵入を経験し、、、およびコマンドを含むShadow Suiteの最初のリリースを作成しましたlogin。SCO passwdXenixオペレーティングsuシステム向けに作成された最初のリリースは、すぐに他のプラットフォームに移植されました。Shadow Suiteは、Linuxプロジェクトの最初の発表から1年後の1992年にLinuxに移植され、初期の多くのディストリビューションに含まれ、現在も多くのLinuxディストリビューションに含まれています。
従来は、認証方式ごとにパスワードを変更するコマンドが異なっていました。例えば、NIS パスワードを変更するコマンドはyppasswdでした。そのため、ユーザーはシステムごとに異なるパスワード変更方法を把握する必要があり、また、異なるバックエンドで同じ機能を実行する様々なプログラムでコードの重複が発生していました。現在では、ほとんどの実装で passwd コマンドが1つだけ用意されており、パスワード変更場所の制御はプラグイン認証モジュール(PAM)を介してユーザーには透過的に行われます。例えば、使用するハッシュの種類はpam_unix.soモジュールの設定によって決まります。デフォルトではMD5ハッシュが使用されてきましたが、現在のモジュールではblowfish、SHA256、SHA512などのより強力なハッシュも使用できます。
/etc/passwd