ユーザーアカウントに複数のパスワードを指定できますか?


21

1つのアカウントに2つのパスワードを割り当てたい。私が知りたいのは、1)これは可能であり、2)これのセキュリティへの影響は何ですか?

私がこれをしたいのは、私は現在いくつかのローカルテストで忙しくて、特定の状況では便利だと思ったからです。いくつかの調査の後、PAMと呼ばれるものを見つけましたが、インストール/構成の仕組みに関する情報を見つけるのに苦労しています。

Ubuntu 12.04を実行しています。


1
おそらくsudo、user1がuser2としてコマンドを実行できるようにセットアップするだけです。(sudorootとしてコマンドを実行するためだけではありません。任意のユーザーとしてコマンドを実行できます。)
cjm

回答:


16

はい、非常にまれですが、これは間違いなく実行可能です。

デフォルト/etc/password /etc/shadowベースの認証方法にはそのような設定がないため、自分で実装する代わりに、ユーザーの複数のパスワードをすでにサポートしているバックエンドに認証を委任する方が簡単です。

よく知られているものはLDAPであり、このuserPassword属性はRFC4519に従って複数値になっています

「userPassword」属性に複数の値が必要な例は、自動化システムによって生成された異なるパスワードをユーザーが毎月使用することが予想される環境です。期間の最終日や初日などの移行期間中に、2つの連続した期間の2つのパスワードをシステムで有効にすることが必要になる場合があります。

このRFCにもかかわらず、この設定を実際に受け入れるには、ほとんどのディレクトリサーバー実装でパスワードポリシーの構成を変更する必要があります。

Linux側では、それを禁止するものは何もありません(ここでは、指定testuserされたアカウントに属性値pass1と属性値の両方が与えられpass2userPasswordいます)。

$ uname -a
Linux lx-vb 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ grep VERSION /etc/os-release
VERSION="13.04, Raring Ringtail"
$ grep "^passwd" /etc/nsswitch.conf 
passwd: files ldap
$ ldapsearch -LLL -h localhost -p 1389 -D "cn=directory manager" -w xxxxxxxx "uid=testuser" userPassword
dn: uid=testuser,ou=People,dc=example,dc=com
userPassword:: e1NTSEF9b2JWYXFDcjhNQmNJVXZXVHMzbE40SFlReStldC9XNFZ0NU4yRmc9PQ==
userPassword:: e1NTSEF9eDlnRGZ5b0NhKzNROTIzOTFha1NiR2VTMFJabjNKSWYyNkN3cUE9PQ==
$ grep testuser /etc/passwd
$ getent passwd testuser
testuser:*:12345:12345:ldap test user:/home/testuser:/bin/sh
$ sshpass -p pass1 ssh testuser@localhost id
uid=12345(testuser) gid=12345 groups=12345
$ sshpass -p pass2 ssh testuser@localhost id
uid=12345(testuser) gid=12345 groups=12345
$ sshpass -p pass3 ssh testuser@localhost id
Permission denied, please try again.

そのような構成の技術的およびセキュリティ関連の意味を次に示します。

  • ユーザーアカウントは明らかに攻撃に対してより脆弱になりますが、ここで実際に重要なのは、パスワードの数と品質よりも高い品質と保護です。
  • ほとんどのユーティリティは、ユーザーが単一のパスワードを持っていると想定しているため、ユーザーがパスワードの1つを個別に更新することはできません。パスワードを変更すると、ユーザーのパスワード属性が1つになる可能性があります。
  • 複数の人がそれぞれのパスワードを使用して同じアカウントを共有できるようにすることが目標である場合、使用されたパスワードに基づいて実際にログインした人を識別するメカニズムはありません。

1
これがセキュリティに影響しない理由について詳しく説明してください。私の最初の印象は、特に一方のパスワードが他方のパスワードよりも著しく弱い場合、アカウントが侵害される可能性が高くなるということでした。
ジョセフR.

1
@JosephR。あなたは正しいです。提案を実装し、それを体験した後、返信を更新しました。
jlliagre

優れた答え、今では魅力のように機能します。ありがとう:)
aggregate116​​6877

7

/etc/shadowファイル内のユーザーに対して2つのエントリを作成しようとしましたが、機能しませんでした。最初に入力されたエントリは、使用されたパスワードエントリでした。

テストユーザーを作成しました。

$ useradd -d /home/newuser newuser

パスワードを「super123」に設定します。

$ passwd newuser

/etc/shadowファイルを手動で編集し、2番目のエントリを作成しました。

newuser:$6$....password #1...:15963:0:99999:7:::
newuser:$6$....password #2...:15963:0:99999:7:::

次に、2つのパスワードを使用してアカウントでログインを試みます。

su - newuser

の最初のエントリ/etc/shadowはgetが使用するものであり、2番目の位置のエントリは、これらを次のように反転すると機能しません。

newuser:$6$....password #2...:15963:0:99999:7:::
newuser:$6$....password #1...:15963:0:99999:7:::

次に、2番目のパスワードは機能しますが、最初のパスワードは機能しません。

sudoを使用

このアプローチは完全なハックであり、私が使用するのはsudo、部分的にsudo存在する理由です。

このエントリをsudoersファイル(/etc/sudoers)に追加すると、ユーザーjoeの許可により、ユーザーが何でもできるようになります。

joe ALL=(yourusername) ALL

私は実際にそれsudoができることを忘れていた.. +1
集計

4

これを行うことができる場合、おそらくするべきではありません。

PAMの構成はやや複雑であり、認証メカニズムについて1つの真実があります。正しい構成には有限のセットがありますが、安全でない構成には無限のセットがあります。これにより、物事を変えようとしても、何をしているのか正確にわからない場合は、物事を台無しにすることがほぼ確実になります。

セキュリティと「特定の状況で便利」のどちらかを選択する場合は、前者を選択します。


「利便性に対するセキュリティ」(これは完全に同意します)の+1ですが、私は経験のためだけでもすべてをテストしたいタイプなので、探している答えは100%ではありません。
集計

2

同じアカウントに対して、それぞれパスワード付きの2つの異なるユーザー名を設定できます。実行vipwして/etc/passwd手動で編集し、目的のアカウントの既存の行を複製し、ユーザー名を変更します(Gecosフィールド、ホームディレクトリ、シェルが好きな場合)。vipw -sでそのユーザーの行を実行して複製します/etc/shadow。新しいユーザー名でログインして実行passwdし、新しいユーザー名のパスワードを変更します。これで、同じアカウントに対して、異なるパスワードを持つ2つの異なるユーザー名を使用できます(ユーザーIDがアカウントを決定します)。

これはおそらく良い考えではありません。あなたがしようとしていることに応じて、他のアプローチがより適切かもしれません:

  • 別のアカウントを作成し、バージョン管理からコミットおよびチェックアウトしてファイルを共有します。
  • 別のアカウントを作成し、両方のユーザーアカウントが属するグループを作成し、共有するファイルへのグループ書き込みアクセスを許可します。
  • 別のアカウントを作成し、最初のアカウントにsudoを使用してそのアカウントとしてコマンドを実行する権限を付与します。

    user1 ALL = (user2) ALL
    
  • 1つの特定のコマンドの実行のみを許可するアカウントのSSHキーを作成します。

これをここhttp://askubuntu.com/questions/567139/2-password-1-account-loginにコピーしますか?
リンツウィンド14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.