興味から、そしてそれが私を激怒させるので、ここにいる誰かの中に銀行で働いている人か、あるいはこの質問の答えを知っている人がいるかどうか疑問に思いました。
私はいくつかのオンライン バンキング サイト (英国と北米) を使用したことがありますが、それらのサイトでは、パスワード パターンが一様に強制されています。アンダー/[\w\d]{6,8}/スコアを使用できる場合もありますが、/.{6,20}/ほぼすべてのオンライン バンキング サイトで (多かれ少なかれ) 使用できるものは決して使用できません。
これはストレージスペースに関係していると言われましたが、数学的にはそうではないようです。銀行がパスワード記録用のシャドウテーブルを保管していると仮定すると、口座ごとに平均10個と寛大に考えれば、パスワードの許容長さを2倍にし、既存の8文字8ビット形式に基づく文字セットのビット幅を2倍にすると、余分な11*2*8 = 176 バイト/アカウントなので、100 万アカウントあたり約 168 MB になります。1 億アカウントをサポートする巨大な銀行だとすると、それでも 16 GB しかありません。
そんなに単純なことではないですよね？私の数字は明らかに的外れです。
それとも、銀行は銀行である以上、のろのろと歩く恐竜と同じぐらいの理由がないというのが答えなのでしょうか。
www.random.com/forum のパスワードが銀行のパスワードよりも強力である技術的な理由を知っている人はいますか?
ベストアンサー1
ある銀行について聞いた話が本当なら...
パスワードを入力するたびに次のようになります。
- ウェブ サーバーは、半キロメートルのシリアル ケーブルを介して、廃墟となったオフィスにある古い 386 にデータを送信し、1989 年に銀行のマネージャーが使用していた UI (Borland C 1.0 のカスタム ハッキング バージョンを使用してコンパイル) を実行します。この UI にはシリアル インターフェイスがないため、AT キーボードのキー入力をシミュレートする別のデバイスを経由する必要があります。
- このプログラムは、パスワード (使用するには弱すぎるがソフトウェアで無効にできないカスタム アルゴリズムを使用して暗号化されている) を含むリクエストを、建物の反対側にある別の廃墟となったオフィス (移動しようとすると粉々になってしまうため) にある NetWare ファイル サーバー上の FoxPro データベースに挿入します。
- 廃墟となった最初のオフィスでは、別の古い 386 が FoxPro データベースを継続的にポーリングして新しいレコードを探し、この要求を検出し、さらに遅いシリアル ケーブル (今回は EBCDIC) を介して、アカウントを管理する実際の COBOL プログラムを実行する PDP11 をエミュレートしている 3 番目のオフィスの別のボックスに転送します。
- 残念ながら、彼らはまだ本物PDP11 は、別の安全な暗号化アルゴリズム用のカスタム マイクロコードを持っていたためです (抽出できず、改ざん防止デバイスによって消去されます)。PDP11 は、1981 年 (廃止を試みた最初の失敗した年) 以降に開設されたすべてのアカウントの増加した作業負荷を処理できないため、現在は (別のスクリーン スクレーパーとエミュレートされたハード ディスクのレイヤーを介して)、メイン サーバーの代わりに機能のサブセット (パスワード検証を含む) を実行するように仕向けられています。
したがって、パスワードには、これらすべてのシステムでサポートされている文字セットの共通サブセットのみを使用でき、パスワードの長さは、関連するデータベース フィールドの最短の長さまでしか使用できません。