0

これが状況です-StackOverflow.comの他のデータベース/パスワードの質問とは少し異なります

2セットのユーザーがいます。1つは「プライマリ」ユーザーです。その他は「セカンダリ」ユーザーです。誰もが私のサイトへのログイン/パスワードを持っています（mysite.comと言ってください-それは重要ではありません）。

背景：プライマリユーザーは、サードサイト（www.something.com/PrimaryUser1など）にアクセスできます。すべてのセカンダリユーザーはプライマリユーザーに「属し」、他のサイトのサブパート（www.something.com/PrimaryUser1/SecondaryUser1など）にアクセスしたいと考えています。

mysite.comでは、プライマリユーザーは、www.something.com / PrimaryUser1にアクセスするために使用する資格情報を私に提供する必要があり、選択したセカンダリユーザーがアクセスできる「サブパーツ」を指定します。

Mysite.comは、プライマリユーザーのサイトへのセカンダリユーザーのサブアクセスの管理に役立ちます。セカンダリユーザーはプライマリユーザーのパスワードを「見る」ことはできませんが、私のサイトを介して、他のサイトの「サブパート」にアクセスできますが、制限されたサブパートにのみアクセスできます。

大雑把に言えば、私はOAuth（またはそのようなもの）を実装しています。

ここでの問題は、プライマリユーザーの資格情報を他のサイトにどのように保存する必要があるかということです。ここで重要な点は、mysite.comがこれらの資格情報を使用してセカンダリユーザーにアクセスを提供するため、それを読み取ることができなければならないということです。ただし、プライマリユーザーが（サイト所有者としての）自分の資格情報を読み取れないことを安心できるように保存したいと思います。

これは理論的なアプローチの問題だと思います。暗号化の世界でこれを助けることができるものはありますか？

追加されたテキスト：

ほとんどのpplは質問を完全に見逃しているので、ここでそれを説明する試み＃2を行います。

PrimaryUser1には、www.something.com/PrimaryUser1Siteへのユーザー名/パスワードがあります

彼は、2人のユーザー（SecondaryUser1とSecondaryUser2）にフォルダーへのサブアクセスを許可したいと考えています-www.something.com/PrimaryUser1Site/SecondaryUser1とwww.something.com/PrimaryUser1Site/SecondaryUser2

Mysite.comがこのサブユーザー管理を処理するため、PrimaryUser1がそこに移動し、Mysite.comに資格情報を提供します。MySite.comは、PrimaryUser1によって提供された資格情報を内部的に使用して、サブユーザーに制限付きアクセスを提供します。これで、SecondaryUser1とSecondaryUser2は、MySite.comを介してwww.something.com/PrimaryUser1Siteのそれぞれのフォルダーにアクセスできます。

ここで、PrimaryUser1が提供した資格情報をどのように保存すればよいかという疑問が生じます。

4

8 に答える 8

4

最初のルール：決してパスワードを保存しないでください！2番目のルール：追加のソルトを使用してパスワードのハッシュを計算し、これをデータベースに保存します。3番目のルール：ユーザー名（大文字）をsaltとして使用できますが、saltとしてもう少し追加することをお勧めします。（いくつかの追加テキスト、できれば長いもの。）4番目のルール：ハッシュアルゴリズムがどれほど安全であるかは関係ありません。遅かれ早かれ、それらはすべてハッキングされます。必要なのは時間だけです！5番目のルール：サイトのセキュリティは、その背後にあるものの価値に依存します。コンテンツの価値が高いほど、攻撃を受ける可能性が高くなります。6番目のルール：遅かれ早かれ、サイトがハッキングされているが、ハッキングされたパスワードではなく、コードのどこかにある抜け穴を介してサイトがハッキングされていることがわかります。最大のリスクは、強力なセキュリティを実装したことで、サイトが安全であると期待することです。7番目のルール：

セキュリティは幻想ですが、誰もそれを破らない限り、あなたは夢を見続けることができます！幻想を再構築する必要がある大まかな目覚めに常に備えてください。（つまり、定期的なバックアップを作成してください！（できれば毎日）。数か月前にサイトがハッキングされたことを発見した場合に備えて、先週のバックアップを上書きせず、毎週少なくとも1つのバックアップを保持するようにしてください。それ以来、あなたのバックアップは感染しています！

ここで、本当にパスワードを保存する必要がある場合は、ユーザー名とパスワードのハッシュを使用します。次に、ハッシュとソルトでもう一度ハッシュします。さらに良いことに、ソルトのリスト（単語のリストのみ）を作成し、新しいユーザーアカウントが作成されるたびに、ランダムなソルト単語を選択して、ユーザー名とパスワードのハッシュに使用します。ソルトのインデックスをユーザーアカウントに保存して、ユーザーが再度ログオンするたびにどちらを使用するかがわかるようにします。

そして：8つのルール：常にHTTPSを使用してください！ほとんどの人ほど安全ではありませんが、ユーザーに安心感を与えます。

テキストを追加したので、さらに回答を追加します。

user1にユーザー2への一時的なアクセスを許可するため、セカンダリユーザーテーブルが必要になります。（または、親ユーザーIDを使用してユーザーテーブルを展開します。また、アカウントの経過時間を追跡するためにタイムスタンプを追加します。ユーザー1は資格情報を作成でき、これは通常の方法で行われます。ユーザー名とソルトを組み合わせたハッシュを保存するだけです。この場合、追加のソルトとしてユーザー1のユーザー名を使用してください。ユーザー1がログオフするとき、または一定の時間が経過したときに、ユーザー2アカウントを無効にするようにしてください。また、ユーザー1がすべてのアカウントを再度有効にできるようにします。彼が作成したので、常に新しいアカウントを作成する代わりに、アカウントを再利用できます。

セキュリティは、プライマリユーザーまたはセカンダリユーザーに依存する問題ではありません。一般的に、それらを同じように扱います！セカンダリユーザーには、プライマリアカウントを追加のソルトとして使用できる追加のボーナスがあります。残りの部分は、もはや認証とは何の関係もありません。あなたが扱っているのは承認です。また、認証と承認には強い関係がありますが、これらを2つの異なるスタンドアロンの手法として扱う必要があることに注意してください。

ユーザー1がログオンすると、プライマリサイトへのアクセスが許可されます。彼がユーザー2へのアクセスを許可すると、ユーザー2は削減されたロールのセットを取得します。ただし、これはユーザー名やパスワードの保存とは関係ありません。たまたま特定のロールまたはグループのメンバーであるユーザーIDがあります。またはそうではありませんが、それらにはアクセスできません。

どちらも単なるユーザーであり、一方が他方よりも多くの権限を持っています。

于 2009-09-12T13:47:43.627 に答える
1

プライマリサイトとセカンダリサイトが合意する認証の種類によって異なります。それは認証、HTTP基本またはHTTPダイジェストを形成しますか？フォームまたは基本の場合、選択の余地はありません。パスワードを保存する必要があるため、パスワードを暗号化するしかありません。フォームとHTTPBasicの両方の認証中にクリアテキストを提示する必要があるため、パスワードハッシュを保存することはできません。暗号化されたパスワードの保存から生じる問題は、暗号化の誤った使用（つまり、IVまたはソルトを使用していないか、ストリーム暗号を正しく使用していない）が原因ですが、さらに重要なのは、キー管理が必要になることです。問題（パスワードの暗号化に使用されるキーの保存場所と、非対話型サービス/デーモンからのアクセス方法）。

サードパーティのサイトがHTTPダイジェストを受け入れる場合は、幸運があります。HA1から直接ダイジェスト応答を作成できるため、ダイジェストハッシュのHA1ハッシュ部分（つまり、のMD5 ）を保存できます。username:realm:password

ユーザーがセカンダリクレデンシャルをプロビジョニングする方法（つまり、最初にセカンダリサイトのユーザー名とパスワードを取得する方法）については触れませんでした。保護されたチャネル（つまり、クライアントからプライマリサイトへのHTTPS）を保護していると思います。

ところで、これは、認証がプライマリサイトとセカンダリサイトの間で行われ、セカンダリサイトのコンテンツがプライマリサイトに対して行われたHTTPリクエストを介してトンネリングされることを前提としています。そうではなく、セカンダリサイトが実際にブラウザから直接アクセスされる場合、セカンダリサイトは、OAuthなどのサードパーティのある種の事前認証されたトークンベースの承認をサポートする必要があります。クレデンシャル認証に依存し、クレデンシャルが実際にブラウザで必要なときにプライマリサイトにクレデンシャルを保存することには、多くの問題があり、話す価値さえありません。

于 2009-09-12T16:58:50.177 に答える
0

Stack OverflowのようにOpenIDを受け入れることを考えましたか？そうすれば、パスワードを保存する責任はまったくありません。

于 2009-09-12T13:27:46.540 に答える
0

これを説明するためのより良い方法があります:(

ただし、パスワードを安全に保存する方法を知りたい場合は、次のようにします。

ユーザー名：john、パスワード：pass

キー='!!@ ijs09789 **＆*';

md5（username.password.key）;

ログインしたら、md5（username.password.key）=がdb内のものと等しいかどうかを確認します。sha1やその他の暗号化方式を使用することもできます。

http://us.php.net/md5＆http://us.php.net/sha1 _ _

于 2009-09-12T13:29:32.093 に答える
0

これを行う方法は1つしかなく、おそらくユーザーにとっては面倒です。

公開鍵/秘密鍵を使用してユーザーのパスワードを暗号化できます。ユーザーは鍵を保持するため、鍵がサーバーに送信された場合にのみパスワードの暗号化を解除できます。これを簡単にする唯一の方法は、情報を自動送信するWebブラウザプラグインを用意することです。

どちらの方法でも、サーバーとの間の通信を常にパケットスニッフィングできるため、ほとんど意味がありません。

于 2009-09-12T13:30:26.947 に答える
0

パスワードを自分で保存する場合は、MD5やSHA-1などの一方向ハッシュアルゴリズムを使用するのが最善の方法です。このアプローチの利点は、ハッシュ値からパスワードを取得できないことです 。

正確にどのアルゴリズムを選択するかは、使用している正確な製品によって異なります。一部のフロントエンドツールは、一部のデータベース製品と同様に、これらの機能を提供します。それ以外の場合は、サードパーティのライブラリが必要になります。

編集

セカンダリユーザーは、独自のパスワードを持っている必要があります。なぜ彼らはそうしませんか？

于 2009-09-12T13:36:44.117 に答える
0

パスワードをデータベースに保存しないでください。ただし、すべてのパスワードのソルトおよびハッシュバージョンを保存してください。

これがあなたにとって中国人であるならば、この記事をチェックしてください。

于 2009-09-12T13:39:06.733 に答える
0

あなたはそれを複雑にしすぎています。認証と承認を混在させようとするのをやめる必要があります。

あなたがしたいのは、すべての人の資格情報を確立することです。この時点で、彼らが「プライマリ」ユーザーであるか「セカンダリ」ユーザーであるかを心配する必要はありません。次に、ユーザーとプライマリ/セカンダリの関係を管理するメインサイトで、どのユーザーがプライマリまたはセカンダリであるかのロジックを実行し、それらすべてをテーブルに格納できます。プライマリユーザーがセカンダリユーザーとの関係を更新するたびに、各セカンダリユーザーに必要な権利とサブ権利を付与または拒否します。それらが完了したら、最終的に、適切なユーザー資格情報をメインサイトからセカンダリサイトに複製する必要があります。

次に、セカンダリユーザーがファーム内の任意のサイトにアクセスしたい場合、自分自身を自分自身としてのみ認証します。プライマリユーザーになりすますことはありません。また、プライマリユーザーが「セカンダリ」ステータスを付与したときに付与された権限のみが付与されます。

-

OK、コメントでその解決策を打ち落としたので、これを考慮してください：

まず、本当に安全なものはないと思います。ユーザーのアクティビティを監視すれば、いつでもシークレットを回復できます。

さて、これは完全にカフから外れており、私はそれを暗号分析していませんが、いわゆる秘密共有スキームをチェックしてください。「有効な」または「実際の」メインサイトのプライマリユーザーパスワードを共有シークレットとして保存します。プライマリユーザーによって指定されたパスワードのソルトハッシュを1つのシークレットとして使用します。最初のセカンダリユーザーによって指定されたパスワードのソルトハッシュを別のシークレットとして使用し、以下同様に追加のセカンダリユーザーごとに使用します。塩漬けのハッシュを保管しないでください！ソルトと保護された共有シークレットを保存するだけです。

ユーザーがパスワードを入力すると、保護された共有シークレットを取得し、パスワードのソルトとハッシュを使用してソルトハッシュを生成し、保護された共有シークレットを復号化すると、元のプライマリユーザーパスワードが取得されます。

于 2009-09-17T04:02:24.023 に答える