銀行のパスワードがなぜそんなに弱いのですか？

Question

興味をそそられ、それが私を激怒させるので、ここのSOmebodyがたまたま銀行で働いているのか、そうでなければその答えを知っているのだろうかと思っていました。

いくつかのオンラインバンキングサイト（英国および北米）を使用しましたが、それらは一般に/[\w\d]{6,8}/のパスワードパターンを適用します。アンダースコアを使用することもありますが、/.{6,20}/出会うほぼすべての！bankingサイトで（多かれ少なかれ）得るもの。

これはストレージスペースに関係していると言われましたが、数学はそれをサポートしていないようです。銀行がパスワードレコードのシャドウテーブルを保持していると仮定して、アカウントごとに平均10をsayしみなく使用し、8文字の8ビットの既存のフォーマットに基づいてパスワードの許容長を2倍にし、文字セットのビット幅を2倍にすると、追加 11 * 2 * 8 =アカウントあたり176バイトなので、1Mアカウントあたり約168Mb。 1億個のアカウントをサポートする巨大な銀行だとしましょう-まだ16Gbだけです！

それほど簡単なことではありませんか？確かに私の数字はベースから外れています。

または、ここでの答えは、銀行は銀行であり、恐竜をlo倒しているよりもこの理由はないということです。

www.random.com/forumのパスワードが私の銀行のパスワードよりも強い技術的な理由を誰か知っていますか？

Answer 1

私は実際に今銀行で働いており、過去にかなりの数で働いてきました。

これが起こる主な理由は、一般に、これらの決定を最終的に担当する人々は、最終的にそれらを実装する人々ではないということです。 <！> quot;ビジネスユニット<！> quot;銀行の非技術的なビジネスの専門家は、これらの決定を行うことになります。 多くの場合、政治的またはビジネス上の理由で技術的な異議が却下されます。しかし、これは銀行だけに限ったことではありません。これは、技術的な考慮事項が主な関心事ではないことが多い業界で発生します。

Answer 2

特定の銀行について聞いた話が本当なら...

パスワードを入力するたびに：

• Webサーバーは、1989年に銀行のマネージャーが使用したUI（Borland C 1.0のカスタムハッキングバージョンを使用してコンパイルされた）を実行する、放棄されたオフィスの古い386に0.5 kmのシリアルケーブルを介して送信します、シリアルインターフェースがないため、ATキーボードのキー押下をシミュレートする別のデバイスを経由する必要があります。
• このプログラムは、パスワードを含むリクエストを（もう使用するには弱すぎるがソフトウェアでは無効にできないカスタムアルゴリズムを使用して暗号化）を、反対側の別の放棄されたオフィスのNetWareファイルサーバー上のFoxProデータベースに挿入します建物の終わり（彼らがそれを動かそうとした場合、それが少し落ちるという理由だけで）。
• 最初の放棄されたオフィスに戻って別の古い386、新しいレコードのFoxProデータベースを絶えずポーリングし、この要求を検出し、さらに遅いシリアルケーブル（今回はEBCDIC）でエミュレートしている3番目のオフィスの別のボックスに転送しますアカウントを維持する実際のCOBOLプログラムを実行するPDP11。
• 残念なことに、彼らはまだ real PDP11も必要です。これは、別の安全な暗号化アルゴリズム用のカスタムマイクロコードがあったためです（抽出できなかったり、改ざん防止デバイスによって消去されます）。 1981年（最初の不成功に終わった試みの年）以降に開かれたすべてのアカウントの増加したワークロードを処理しないため、（スクリーンスクレーパーとエミュレートされたハードディスクの別のレイヤーを介して）機能のサブセット（パスワードを含む）の実行にだまされます検証）メインサーバーに代わって。

したがって、パスワードは、これらすべてのシステムでサポートされる文字セットの共通サブセットのみを使用でき、最短のデータベースフィールドが関係している場合にのみ使用できます。

Answer 3

銀行は、主にレガシーシステムへのインターフェイスとしてオンラインサービスを使用します。パスワードはおそらく、どこかでIBMメインフレームによって処理され、Cobolで書かれており、パスワード構造は70年代に設計された可能性があります。

さらに、銀行はそのような政治構造であるため、経営陣は主に<！> quot; concrete <！> quot;結果として、セキュリティなどの問題は、ホットな問題になり、その後<！> quot; initiative <！> quotになるまで対処されません。対処します。

私が働いていた銀行の1つでは、本番パスワードはユーザーIDと同じでした（<！> quot; root <！> quot; <！> quot; root <！> quot;でログインするのと同じ考えです）。ユーザーパスワードは、姓の最初のN文字+ SSNの最後の4桁の組み合わせにオンラインでリセットできるため、ユーザーは、名前とSSNを知っていて、あなたとしてログインした場合、パスワードをリセットできます。

Answer 4

おそらく、ほとんどの銀行システムは、8文字のパスワードがセキュリティで保護されていると見なされていたずっと前に開発されました。とにかく銀行口座からブルートフォースパスワードを検討する人はいないと思います。8文字のままです。私はすべての銀行が3回かそこらでアカウントをブロックするに違いない。

Answer 5

これは<！> quot; bug <！> quot;です。最近クライアント用に構築したサイトに関してBugzillaにログインしました（ありがたいことに、銀行ではありません！）：

  

<！> quot;ユーザーは！または、パスワードに_が含まれていますが、これは少し奇妙に思えます。これは、英数字のみを使用できる6〜8桁のパスワードになるように更新できますか？<！> quot;

• 実際には、少なくとも1つの英数字以外の文字でした