Bluehostを使用したメールだけでなく、ドメイン/ウェブサイトもいくつかあります。サポートが必要になるたびに、アカウントのメインパスワードの最後の4文字が必要になります。彼らはどのようにパスワードを保存するのか教えてくれないので、彼らがどのように私のパスワードを安全に保存し、それでも最後の4文字を見ることができるかに興味をそそられます。完全なパスワードがプレーンテキストで表示されますか?
いくつかの可能性があります。
完全なパスワードをプレーンテキストで保存し、サポート担当者に最後の4文字のみを表示する可能性があります。
彼らはパスワードを2回ハッシュしている可能性があります。完全なパスワードをハッシュしてから、最後の4つだけを使用してハッシュします。次に、サポート担当者は最後の4つを入力して、ハッシュされた値と一致するかどうかを確認します。これの問題は、最後の4文字が別のハッシュにあるため、フルパスワードをブルートフォースでブロードフォースしやすくなり、エントロピーが減少することです。
彼らは完全なパスワードをハッシュし、最後の4つを平文で保存している可能性があります。明らかに、これにより、パスワードデータベースにアクセスする攻撃者が最後の4桁を知っている場合、パスワードの総当たりがはるかに容易になります。
最後の4文字が検出可能な方法で保存されている他の場所(マイクスコットが以下で説明している暗号化など)。 4文字のロックを解除するための秘密が見つかれば、これは平文と同じくらい悪いです。
すべてのシナリオは非常に悪いものであり、システムのセキュリティを大幅に低下させます。どのシナリオを使用しているのかを知ることはできませんが、それぞれのシナリオでセキュリティ違反に対する考慮が不足しています。これがあなたのアカウントが侵害されることを心配しているサイトである場合は注意が必要です。
私たちはBluehostの秘密にしていないので、そのような質問に答えることは常に難しいので、推測して推測することしかできません。
ただし、説明する動作は、クリアフォームのパスワードを保存しなくても可能です。
BlueHostは 強力なパスワードの妥当なルール を推奨しているため、おそらく彼は何をしているのかを知っている人を少なくとも1人雇用しています。
そのような場合、BlueHostは Shamir's Secret Sharing または そのテーマのバリエーション の実装を使用している可能性があります。シャミールは理論的に安全であるため、これを行うスキームは本質的に安全性が低いという結論にすぐにジャンプすることはありません(他の回答と同様)。
一方、Shamirを実装するのは簡単なことではないので、他の答えも同様に当てはまる可能性があります。セキュリティは最終的にはtrustであるため、このスキームでが安全でないと感じた場合 、別のプロバイダーを見つけることをお勧めします!
彼らがパスワードをどのように保存しているかは正確には言えません。しかし、彼らのプロセスの説明から、パスワードを安全でない方法で保存する必要があることを示すことができます。
私は、彼らが最後の4文字を要求しているとき、彼らが実際にあなたが彼らに言ったことの正しさを検証することができる(つまり、彼らは単にブラフではない)と想定しています。
これは、彼らがあなたが言ったキャラクターを短時間で確認できるデータを持っていることを意味します。同じデータをブルートフォース攻撃で使用して、パスワードの最後の4文字を解読することができます。 4人のキャラクターは確かに短すぎて、断固とした攻撃者を止めることはできません。
攻撃者が最後の4つのキャラクターを持つと、別の攻撃を以前のキャラクターにかけることができます。このブルートフォース攻撃では、パスワードの最後の4文字ではセキュリティが追加されないため、せいぜい、実際のパスワードよりも4文字短いパスワードと同等のセキュリティになります。
安全なパスワードを選択し、最初に選択したパスワードとは完全に独立した4文字を追加することにより、この脆弱性を回避できる可能性があります。これは、最後の長さ4文字のみを検証でき、任意の長さのサフィックスがない場合は安全です。
実際に4文字のサフィックスだけでなく、任意の長さのサフィックスを検証できる場合、パスワードの保存はさらに弱くなります。それはプレーンテキストとして保存するのと同じくらい安全ではなく、その場合はより強力なパスワードを選択して回避することはできません。
パスワードは保存する前にハッシュ化する必要があることを知っているので、天気予報の最後の4文字を保存しているかどうかを口頭での承認の目的で保存してから保存する前にハッシュ化するか、単に保存するだけか、平文。
後者だと思います。
これは可能性が高いとは思いませんが、単に可能です。
OPがサポートを必要とするたびに、彼らはパスワードの下4桁を尋ねます。彼らはそれをソルトしてハッシュし、ソルトとハッシュとサポートを特別なサポートテーブルに再構築するのに十分な情報を格納します。
次に、OPが(完全なパスワードで)ログインすると、サポートテーブルを確認してハッシュを計算できます。次に、検証済みの「サポート」をコミットし、改ざんされた「サポート」を否認します。
もちろんこれは
サポートは、後でコミットまたは否認できるものです
最後の4つを要求するプロセスは情報を漏らしません(最後の4つを要求する人は、彼らの記憶を確実に消去できないため、資格がありません)。
これがビジネス上理にかなっている状況は想像できません。しかし、もしそうなら、代わりにユーザーに特別な4桁の「サポート」パスワードを発行すると思います。
彼らは完全なパスワードを見ることができますか?はい、間違いなく可能です推測パスワード(最後の4桁が日付またはWordの一部である場合。パスワードが完全にハッシュされている場合、4桁を知っていればブルートフォース攻撃を行うのに十分ですまたは、ハッシュ関数にヒューリスティックを適用して、考えられるパスワードの範囲を大幅に減らして4桁がどのように伝播して戻るかを確認します。
このパスワードを推測してください:
*********ange
またはこれ:
****1994
ハッカーであり、カスタマーサポートAPI(存在する場合)を悪用してユーザー情報にアクセスすることも可能です。その作業は、4桁を知ることでさらに簡単になります。
彼らはそれをすべきではありません。たとえそれが顧客の一部である場合でも、見知らぬ人にパスワードの一部を良いオプションとして与えることは決してありませんサポート。
カスタマーサポートは、元のパスワードにアクセスする方法がなく、アドホックAPIを介して不正な行為を防止する必要があります(まだサポートが完全なデータにアクセスできないはずです)。
また、カスタマーサポートが4桁のパスワードを要求する必要がある場合、「パスワードは絶対に教えないでください」などの警告をユーザーに電子メールで送信することはできません。フィッシングメールに巻き込まれます。
ユーザーの信頼性を本当に確認したい場合は、SMSコード、秘密の質問、または単にメールで送信されたキーなどを使用する必要があります。
それでも、電子メールまたはSMSを送信する方が、同じことをしている人に1〜2分を支払うよりもはるかに安価です(実際に支払われていない人を除く)。
サービスが本当に重要な何かについてユーザーの身元を確認する必要がある場合、オペレーターがユーザーの顔を見て、特定のアクション(紙にWordを書いて彼に戻るような)を実行するように要求するWebカメラストリームをおそらく使用します。誰かが録画されたビデオを使用するのを防ぐため)。
もちろんこれはプライバシーのためユーザーには好かれません^^
他の人が言ったように、このプロバイダーがパスワードの「最後の4桁」を保護する方法はたくさんあります。ただし、パスワードの一部でもブロードキャストするときはいつでも、アカウントが危険にさらされる可能性があります。誰も言及していないように見えることの1つは、チャットログに入力するパスワードの最後の4桁はおそらく暗号化されないことです。もちろん、チャットログには簡単にアクセスできる必要があります。基本的なパスワードの複雑さのルールに従っても、パスワードの有効な長さを4文字減らしただけです。それが、より安全性の低い他の場所で使用しているパスワードであると想像してみてください(残念ながら、多くの人が使用しています)。
TL:DRこれはばかげた習慣であり、私はあらゆる犠牲を払ってそれらから遠ざけるでしょう