一部のサイト（オンラインバンクなど）では、プレーンテキストとして保存せずに、パスワードから特定の文字のみを要求するのですか？
私は システムが変更された文字の最小数を強制する方法は... が私の質問に答えると思いましたが、これは別のケースのようです。
オンラインバンキングアカウントにサインオンすると、4桁のPINからランダムな3桁の数字と、（長いランダムな）パスワードからランダムな3文字を入力するよう求められます。
これらすべてに対する私の限られた理解から、銀行は私の完全なパスワードを持っていないため、このログインから私のパスワードハッシュを作成できません。それで彼らは私のパスワードをクリアテキストで保存し、個々の文字を比較していますか？利便性とセキュリティの適切なバランスですか？
このブログ投稿でこの質問をするように求められます： パスワードのセキュリティを気にする人は？NatWestはしません
銀行がこの要件をどのように処理するかは明確にはわかりませんが、@ rakhiが言及しているプロセスの代替プロセスは、 [〜＃〜] hsm [〜＃〜] と可逆暗号化を使用することです。
完全なパスワードは、対称暗号（AESなど）を使用して暗号化されたデータベースに格納されます。次に、パスワード文字がアプリケーションに渡されると、暗号化されたパスワードと共にHSMに送られます。
次に、HSMはパスワードを復号化し、3文字が期待どおりであることを確認して、アプリケーションに成功/失敗の応答を返します。したがって、パスワードは平文で保持されません（安全と見なされるHSMを除きます）。
これは、PIN暗号化をATMネットワークで処理できる方法（例：対称暗号化とHSM））と連携します。
完全なパスワードのハッシュ以外のパスワードについて知っている必要がある場合はいつでも、パスワードはハッシュされていないと想定できます。 PCI-DSSについて言及しましたが、銀行がパスワード情報を暗号化またはハッシュするときに適用される規制については、私が認識しているものはありません。 PCI-DSSは、PINまたはその一部のバリエーションでのログインを含め、銀行口座情報をカバーしません。
それらが良い場合、パスワードは暗号化を使用して保存されます。それらがあまり良くない場合、確かにプレーンテキストで保存できます。
私はここでのトレードオフが好きだと認めます。パスワードデータベース全体が侵害された場合、攻撃のリスクが高まる可能性がありますが、銀行のセキュリティは上位にあるべきだと私は反論します。データベースの侵害が疑われた場合、とにかくハッシュ化されていても暗号化されていても、すべてを変更する必要があります。どちらの場合でも、この特定の方法では、攻撃者がキーロガーを使用して攻撃を行うのに十分な有用な情報を入手するのに、はるかに長い時間と複雑さが必要です。
接線的に関連するもの： http://projecteuler.net/index.php?section=problems&id=79
NatWestの計画は、疑わしい価値があると私に思わせます。 NatWestのスキームでは、フィッシング攻撃によってPINとパスワードのすべてまたはほとんどが盗まれる可能性があります。フィッシング攻撃のしくみは次のとおりです。
フィッシングサイトは偽のログイン画面を表示し、PINの3桁と3文字のパスワードを要求します。
ユーザーは自分の答えを入力します。
フィッシングサイトは、エントリが正しくないことを示す応答を表示し、ユーザーに再度プロンプトを表示します。
多くのユーザーはおそらく自分が何かを間違って入力したと思い、再試行します。
フィッシング詐欺師が賢い場合、フィッシングサイトからの2番目のプロンプトは、異なる数字と文字のセットを要求します。ユーザーがもう一度試みると、フィッシングサイトはPINの4桁すべてとユーザーのパスワードの6文字を知ることができます。（NatWestは、ユーザーに6- 8文字なので、6文字のパスワードがすべてまたはほぼすべてであることが保証されます。）この時点で、ゲームオーバーです。
したがって、NatWestの計画があなたに何かを買っているかどうかは私には明らかではありません。
同様の質問 で、@ captaincomicによるコメントがこの記事にリンクしています： Partial Passwords-How？（From Archive.org） この機能を許可する方法を説明していますなし回復可能な形式でパスワードを保存するか、各文字を個別にハッシュします-Shamir秘密共有スキームを使用します。
それは接線的に関連しているだけですが、David Aspinall（エジンバラ大学）とMike Just（グラスゴーカレドニアン大学）が2013年に部分的なパスワードに関する論文を発表しました： "Give Me Letters 2、3、6！" ：部分的なパスワードの実装と攻撃 。
彼らの論文は、バックエンドのストレージメカニズムが無関係であるオンライン攻撃を検討していますが、それはあなたの質問に密接に関連している合格の発言をします：
部分的なプロトコルをサポートするには、実装はパスワードのプレーンテキストを保存するか、クエリされる可能性のあるすべての組み合わせに対して一方向のチェックを実行するメカニズムを考案する必要があります（長いパスワードの場合は多数になる可能性があります）。ここでは、この攻撃モードについては調査しません。
彼らがしていることは、各文字をハッシュしてそれを保存したり、できれば安全なデバイスにパスワードを平文で保存したりすることではありません。 HSM。
これは悪いアプローチではありません。銀行はユーザーにいくつかの文字の入力を要求します（たとえば、HSBCはランダムな位置から3です）。これは、トロイの木馬、キーロガー、またはフィッシングサイトがこれらの3文字をキャプチャした場合、完全なパスワードがないことを意味します。
また、銀行は秘密の質問や別のパスワードに頼ることなく、電話などでユーザーを認証するために部分的なパスワードを使用できます。これも、コールセンターの担当者が完全なパスワードを知らなくても可能です。
おそらくより広く使用されていない理由であるいくつかの問題：
主なものは、パスワードを平文で保存したくないということです（実際には、PCI-DSSなどの規制により禁止されています）。したがって、アプローチは、パスワードの一方向ハッシュを作成し、それを格納することです。ユーザーがパスワードを入力すると、これがハッシュされ、格納されているハッシュと比較されます。部分的なパスワードでは、リバース暗号化でパスワードを保存する必要があります。これはベストプラクティスではありません。または、ハッシュを多数保存する必要があります。誕生日とパスワードのすべての文字を含むHSBCの場合、個別のハッシュが必要です。また、すべてのハッシュを格納するためにデータベースのフィールドを割り当てることができるように、パスワードの最大長を課す必要があります（おそらく、これを回避するよりスマートなデータベースおよびアプリケーションテクノロジーがあるでしょう）。
これは、ユーザーに弱いパスワードを選択することを奨励します。 8文字の複雑なパスワードがある場合：tpEz％e2Sその2番目、4番目、5番目の文字が難しいことを思い出そうとすると、ユーザーは簡単な辞書の単語を選択しやすくなります。
また、アカウントロックアウトタイプの機能がない場合は、8文字よりも3文字を推測またはブルートフォースするほうが指数関数的に簡単です。
完全なパスワードがわからないという自信は見当違いである可能性があります。パスワードがフラムで、F、l、hを知っている場合は、完全なパスワードを適切に推測できる可能性があります。
単に1、3、5番を要求してから、パスワードが間違っていると言って2、4、6番を要求するように変更したフィッシングサイトも、ユーザーが2回考える前に入力するため、完全なパスワードを取得する可能性があります。
ユーザーの利便性の観点からすると、ブラウザを使用してパスワードを覚えたり、Lastpassや1Passwordなどのパスワードマネージャを使用したりすることはできません。
ほとんどの銀行は、ユーザー名とパスワードに依存することから離れています。 HSBCは企業顧客にRSAトークンを提供し、バークレイズはEMVスマートカードリーダーを持っています。ほとんどすべてがRSA適応認証などの検出テクノロジーを使用して、ブラウザー、場所、使用プロファイル、速度などのベースラインを確立し、パッシブ認証と不正使用の検出を行います。