これは、銀行向けのオンライン バンキング Web サイトを開発しているすべてのコーダーに対する質問です。
すべての銀行がオンライン バンキングの Web サイトに Java アプレットを使用するのはなぜですか? 基本的に、JRE がインストールされていない場合、それらの Web サイトを使用することはできません。
セキュリティ上の理由であれば、SSL で十分ではないでしょうか。
これは、銀行向けのオンライン バンキング Web サイトを開発しているすべてのコーダーに対する質問です。
すべての銀行がオンライン バンキングの Web サイトに Java アプレットを使用するのはなぜですか? 基本的に、JRE がインストールされていない場合、それらの Web サイトを使用することはできません。
セキュリティ上の理由であれば、SSL で十分ではないでしょうか。
スペインの大手銀行である BBVA.es は Java を使用していません。
ロシアの大手銀行である Alfabank.ru も Java を使用していません。
銀行業務にJavaアプレットを使用している銀行は本当に多いのでしょうか?
私のサンプルプール(つまり、私が使用している銀行)はJavaアプレットをまったく使用していないため、あなたのサンプルは統計的に重要ではないとあえて言います:-)
私の銀行である USAA では、Java アプレットを通常の日常的な銀行業務に使用していませんが、自宅から小切手を預け入れるためにDeposit@Homeサービスに使用しています。スキャナーにアクセスし、スキャンした小切手の画像を操作するのが簡単なため、おそらくこの例では Java を使用します。
何かを再暗号化すると安全性が低下するという印象を受けました。
私はいつもネットワーク セキュリティの教授からそのように教えられていましたが、彼の言葉よりも科学的なものを見たことがありませんでした。
しかし、その暗号化がハッシュ関数によって行われている場合、パスワードは銀行の従業員の目 (ログ、デバッグ情報など) から「安全」になりますが、それが唯一の利点です。
SSLに関しては、通信を暗号化するだけで、サーバー側では暗号化されていないデータを取得します. しかし、それは悪いニュースではありません.サーバーはあなたの注文を理解するためにそれを行う必要があります.
オーストリアで、通常の銀行業務で Java アプレットを使用している銀行、Sparkasse を見つけました。Java を使用する理由について、彼らがサイトで提供している理由を次に示します。
パスワードは特にデリケートな問題であると考えているため、特別な保護を提供したいと考えています。したがって、SSLに加えてパスワードを暗号化する必要があると私たちは考えています。そのために、パスワードを暗号化して判読不能にする追跡不可能な暗号化機能を使用しています。暗号化を実行できる Java アプレットがアップロードされます。したがって、暗号化されたパスワードのみがサーバーに転送されます。このようにして、パスワードは暗号化されたバージョンとしてのみ保存されるため、銀行員が暗号化されていないパスワードを見たり、パスワードを渡したりすることはありません.