web-dev-qa-db-ja.com

データベース内のどのアカウントが管理者アカウントであるかを隠して、攻撃者はどのハッシュを最初にクラックするかわからないのですか？

次のようなデータベースがあるとします。

Name   Password hash (bcrypt)                                          Status
--------------------------------------------------------------------------------
Dave   $2y$10SyyWTpNB.TyWd3nM hQ41frOtObcircAb3nJw1Cf9dC6CT7tVIEb6XS   Standard
Sarah  $2y$10$fUJrNA200sXgWUJAP7XEiuq4itHa43Y8QVIpc/YWscgVJ PYWbLLV.   Admin
Mike   $2y$10$01jx7u7hnfKOzBYyjNWskOPQ23w1Cf1gNiv42wsKqXKOf8filzS02    Standard

攻撃者がこのデータベースへのアクセス権を取得すると、サラは管理者であることがすぐにわかり、おそらくそのパスワードを解読することに集中するため、より強力な権限を持つことができます。誰かがデータベースの管理者であるかどうかを何らかの方法で非表示にして、攻撃者が管理者を知らないようにする方法はありますか？値（標準または管理者）をハッシュ化することもできますが、それによって1ビットのエントロピーしか得られず、それよりも少しだけセキュリティを高めたいと考えています。

passwordshashdatabases
36
Melkor

あなたがそれから何を得るかを考えると、これは少し面倒すぎると思います。攻撃者がデータベースにアクセスできるようになると、さらに大きな問題が発生すると思います。ユーザーの管理ステータスを難読化すると、攻撃者に少し時間がかかるだけですが、APT（高度な永続的脅威））はおそらくこの事実によって阻止されません。

127
Black Magic

難読化によるセキュリティの効果はせいぜい限られています。それが適切かどうかを判断するには、対抗する脅威を理解する必要があります。攻撃者がデータベースを直接読み取ることができる場合、特定の保存された詳細を隠すことにはどのような利点がありますか？

is難読化のメリットがある場合（これを実際に証明できることを確認してください）、その脅威に対処する難読化のタイプ（暗号化された値、オフラインデータソース、ハッシュなど）を使用します。

26
schroeder

私はブラックマジックに同意しますが、おそらくそれを行う価値はありませんが、必要に応じて key derivation function を使用してパスワードに基づいて暗号化キーを作成し、それを使用してステータスのコンテンツを暗号化できます。カラム。

潜在的には、開いているすべてのユーザーセッションのステータスをメモリに保持する必要があるため、攻撃者に対して脆弱である可能性があります。

これは、ユーザーのパスワードがわからない場合、攻撃者と同じ制限があることを意味します。 DBからステータスを読み取ることができず、ユーザーのステータスを変更したい場合は、同時にパスワードを変更する必要があります。

5
bdsl

最近のシステムの多くは、実際にはユーザーのログイン（認証方法）を、2つ以上の個別のシステムとして実装されている「プロファイル」（ユーザーが持つ権限）から分離しています。ログインサーバーは、GUID、ハッシュ化されたユーザー名、およびハッシュ化されたパスワードのみを持つことができます。ログインに成功したら、セッションをアプリケーションサーバーに転送します。アプリケーションサーバーが危険にさらされない限り、ログインデータベースはダンプされても役に立たない。

追加の手順として、ログインサーバーからのキーを使用してユーザーのデータを暗号化し（セッションの一部として保存）、アプリケーションサーバーのセキュリティを強化することもできます。通常、2つのシステムは1つのシステムよりも困難です。ただし、2つのサーバー（またはクラスター）を設定するつもりがなく、すべてが作業量が多すぎるように聞こえる場合は、おそらく現在の設計を使用するほうがよいでしょう。ターゲットにするアカウントを知っているだけでは、仕事は簡単にはなりません。攻撃者が1つをクラックできる場合、並列コンピューティングですべてをクラックできます。

3
phyrfox

PlasmaHHからの提案は、「ハッシュされたパスワード（実際には複数の文字、それは「グループID」でした）にパスワードの前に文字を追加し、認証メカニズムにすべての組み合わせを試させることでした。

あいまいであることによる多少のセキュリティですが、needsを次のような優れたプラクティスと組み合わせる必要があります。

  • bcryptの強力な作業要素
  • 強力なパスワードを持っている管理者
  • 攻撃者がデータベースのコピーを最初に持つことを防ぐ方法

これは、パスワードが見つかる前にパスワードが変更されるように、攻撃者を十分に遅くするための良い方法です。

重要ではないパスワードを1つクラックすると（強力な作業係数を使用したと想定）、数日から数か月かかる可能性があるため実行できますが、ハッキングする価値のあるアカウントがわからない場合は、各アカウントをハックする必要があります。

そのため、運が良かったり、管理者アカウントに「admin」という名前を付けたりしない限り、複数のアカウントを試さなければならず、コストが少なくとも1桁大きくなり、攻撃者はさらに待機するか、より多くの電力を購入するか、アップ。

結論として、それはユーザーを気にしない安価な抑止力であるため、価値がありません。

他の誰かが編集した他の人からの投稿など、誰かが管理者であるというヒントがある場合（管理者しかそれができない場合）、dbでそのステータスをマスクしても意味がないことに注意してください。

他の人が述べたように、これはあなたがパスワードを変更したり少なくとも尋ねたりせずにユーザー管理者になることを妨げるようなものです。

可能であれば、管理者に2要素認証を要求することは、おそらく管理者アカウントを保護するためのより良い方法でしょう。

2
satibel

はい、できます。パスワードの一部として管理ステータスを追加するだけです。

例：HereIsMe！65371 = admin HereIsMe！65370 =通常

次に、ログイン時に、最初に定期的に、次に管理者として、次のように試してください。

if (sha512($password . "0") eq $hash) {
blabla user functions
} else {
if (sha512($password . "1") eq $hash) {
blabla admin functions
}
else
{
show incorrect password message
}
}

重要：誰かが自分のパスワードの最後の文字を編集できないことを確認してください。たとえば、登録フォーム、パスワードの忘れたフォーム、パスワードの変更フォームを確認し、実際のステータスに応じて、パスワードの最後に常に0または1を追加します。ステータスをサーバー側のセッションに保存します。できればクライアント側のセッションCookieを使用して暗号化します。

これにより、パスワードのクラックに成功せずに管理ステータスを推測することは事実上不可能になります。

2
sebastian nielsen

ここには興味深い技術的な提案がいくつかありますが、完全に実装したとしても、次の理由により侵入が発生した場合、このアプローチでは文字通り何も得られないことに注意する必要があります。

  • 誰かがデータベースにアクセスできる場合（SQLインジェクションなど）、ほとんどのデータベース管理システムは以下の機能を提供しているため、データベースサービスを実行しているユーザーのアクセス許可があれば、サーバー上でほぼ何でも実行できます。ホスト上のファイルと実行中のプロセスを操作します。これは、侵入者がWebページまたはサーバー側の処理を変更して、ログイン中にプレーンテキストのパスワードをキャプチャし、アクティブユーザーの暗号化されていないパスワードを非常にすばやく取得できることを意味します。管理者アカウントがアクティブユーザーであると想定しています。
  • 誰かがあなたのパスワードハッシュにアクセスした場合、彼らはおそらく彼らが最初に解読しようとするべきものにダイヤルインするつもりはありません。バルククラッカーを実行して一度にすべてを処理し、各パスで、処理中のテーブル内のすべてのハッシュをチェックします。
  • 管理者パスワードハッシュを別のテーブルまたはデータベースの外部に完全に保持したとしても、侵入者が信頼できるユーザーになりすますことができるため侵入が検出されない限り、権限の低いアカウントの侵害により、権限の昇格が発生する可能性があります。詳細情報へのアクセス権を取得します（たとえば、モデレーターアカウントを使用して管理者と話し、Cookieの盗みやその他の悪意のある活動を開始します）。
  • サイトにソーシャル機能がある場合、管理ユーザーを識別するための他の方法がすでに公開されている可能性が非常に高いです。
0
S.C.

データベースがそれをサポートしている場合、LDAPまたは同様の認証サーバーをセットアップすると、資格情報はローカルに保存されません。

0
cybernard