0

私はおそらく必要以上に多くのことをしている奇妙な暗号の問題に遭遇しました。私は現在の低熱を非難します. 少なくともいくつかのレビューなしに、暗号関連のものに独自のソリューションを展開するのは本当に嫌いです.

私は、サード パーティ サービスを統合するための SSO ソリューションを実装している最中です。このソリューションでは、独自の認証プラットフォームに対してユーザーを認証します。ユーザーが適切に認証されると、限られた数の一貫して利用可能な変数が返されます。

特定のユーザーを常に表すことが保証されているこれらの 1 つはlogin ID、ネットワーク上のユーザーです。このコンテキストで許可される他のものは、特定のユーザーに対して同じままであることが保証されていません。

login IDサードパーティのサービスに共有トークンとしてプレーンテキストで保存できません。(理由を質問する前に、非常に単純な理由があります: 法務上好ましくない... この ID は FERPA に敏感にならないように特別に作成されましたが、本質的に一度だけ削除されます)

私はそれをハッシュすることができます。おそらく他の場所に平文で保存しないのには十分な理由があるので、少なくとも合理的にハッシュしたいと思います。通常、特定のユーザーに機密性の低い識別子が他にある場合は、機密情報 (パスワードの場合など) を暗号化し、そのソルト + ハッシュと機密性の低い PK 識別子をテーブルに格納してから、比較を行うときに、機密性の低い識別子に基づいてバックアップします。

検索を実行するための機密性の低い識別子がなければ、一意のソルトなしで基本的なハッシュ操作を行うだけで行き詰まるように思われます (まだそれらをペッパーすることができます)。自分の DB に保存するものはすべて、トークンとして渡されるものと同じくらい脆弱になるため、生login IDの s からソルト化およびハッシュ化された s へのマップ テーブルを作成しても意味がありませんlogin ID。私が保存したすべてのソルト+ハッシュに対して特定のハッシュを盲目的にテストするのはばかげています。

先に進んで SHA2 をペッパー ザlogin IDs で使用して、1 日で終了することもできます (これらは結局のところ、パスワードではなく「単なる」ログイン ID であり、その解決策は少なくとも適切であると見なされています)。この場合のより良い解決策がない場合は?

4

2 に答える 2

1

これを知っておく必要があると思います:米国教育省からウィスコンシン大学リバー フォールズ校への手紙:

FERPA では、学生のユーザーまたはアカウントのログオン ID (またはログオン ID として使用される電子メール アドレス) などの一意の個人識別子を、その識別子を使用できない限り、機関が「ディレクトリ情報」として指定および開示することが許可されていると考えています。 、教育記録からディレクトリ以外の情報にアクセスするために、許可されていない個人が単独で、. 言い換えれば、学生が学生情報システム内の自分の記録にアクセスするために、個人識別子とともに、PIN やパスワード、または学生に固有のその他の認証要素などの共有シークレットを使用する必要がある場合、その識別子は、規則の§ 99.37 の要件に従って、FERPA の下でディレクトリ情報として指定および開示される場合があります。

逆に、教育機関が学生に個人識別子を使用して自分の教育記録にアクセスすることを許可しているが、学生の身元を認証するためのパスワードまたはその他の要素を使用しない場合 (または識別子自体が学生の身元を認証するためにも使用されている場合)、その識別子は、保護された情報が学生以外の誰かに開示される可能性があり、したがって「開示された場合、有害またはプライバシーの侵害」になる可能性があるため、FERPA の下でディレクトリ情報として開示することはできません。(一部の教育機関は、この方法で学生の「公式 ID 番号」を引き続き使用する場合があります。) この理由に基づいて、教育機関は、学生 (またはその他の関係者) が教育記録にアクセスできるようにするために、公開されているものだけを提供します。情報、

ただし、これが受け入れられない場合は、一時的な追加の ID (共有シークレット) を検討してください。

ユーザーに一時的に割り当てられ (ほとんどの場合、ある種のルックアップ テーブルを介して)、妥当な時間間隔でクリアされるランダム トークン (衝突をチェックする必要がないように、時間とユーザー ID を前に付けたもの) を使用できます。

ハッシュは元に戻すことができないため、一時的であっても、ユーザーに関連付けられたものが不要な場合は、ハッシュを使用できません。各レコードに対してハッシュをテストすることは、技術的に実現不可能です。

最後に、SSO と同様に、ハッシュ + ランダム トークンとユーザー ID を使用できますが、コードまたは構成でサーバーに保存されている秘密鍵を使用してユーザー ID を暗号化します。このように、攻撃者はデータを利用するために、データベースとコードまたは構成の両方にアクセスする必要があります。理想的には、秘密鍵を毎日変更します。

于 2013-10-27T01:30:55.177 に答える