HTTPSと基本認証は、銀行のWebサービス（RESTful）に対して十分に安全ですか？
私は過去数日間SSL/TLSについて読んでおり、実際に解読されたことがないようです。
SSL/TLSがクライアントアプリケーションとサーバー間のすべての通信に使用され、パスワード/ APIキーがランダムで強力でサーバー側に安全に格納されている（暗号化、ソルト化されている）場合、基本認証は十分に安全だと思いますか？銀行サービスでも？
ユーザー名/パスワードがリクエストごとに送信されるのを嫌う人がたくさんいます。これは、Basic Authの実際の弱点ですか（SSL/TLSが使用されている場合でも）、それとも不合理な恐怖によるものですか？
HTTP基本認証は、ブラウザ側で、常に醜いブラウザ制御のログインポップアップを伴うため、ブラウザ/サーバ接続ではあまり使用されません。もちろん、これは、醜さを観察する人間のユーザーがいないサーバー間接続には適用されませんが、基本認証の不信と廃用という一般的な風潮の一因になります。
また、1990年代には、SSLが登場する前は、平文のパスワードをネットワーク経由で送信することは銃乱射と見なされていました。愚かにも、人々は HTTP Digest のようなチャレンジ/レスポンスプロトコルで十分であると考えていました。セキュリティを確保します。今ではそうではありません。認証方法に関係なく、アクティブな攻撃者によるハイジャックを回避するために、完全なトラフィックを少なくとも暗号化して認証にリンクする必要があります。したがって、SSLはが必要です。ただし、SSLが有効な場合は、SSLトンネルで「そのまま」パスワードを送信しても問題ありません。つまり、まとめると、SSLの基本認証は、核発射コードや金銭関連の問題など、深刻な目的に十分対応できます。
セキュリティは 中間者攻撃 の不可能性に依存していることを指摘する必要があります。これは、SSLの場合（一般的に使用されているように）サーバーの証明書に依存します。 SSLクライアント（あなたの場合は別のサーバー）は、適切なCRLをダウンロードして失効ステータスをチェックするなど、SSLサーバーの証明書を細心の注意を払って検証する必要があります。それ以外の場合、クライアントが偽のサーバーにリダイレクトされると、偽のサーバーの所有者はパスワードを学習します...その意味で、HTTPダイジェストのようなものを使用すると、状況がすでにかなり腐っていた場合に備えて、追加の緩和レイヤーが追加されます。 MitMを実行する偽のサーバーであるHTTPダイジェストは、いつでも接続をハイジャックできます。
少し先に進むと、パスワードベースの認証を使用する場合、実際にはパスワードベースの相互認証が必要であることに注意してください。理想的には、SSLクライアントとSSLサーバーは、共有パスワードの知識に基づいて相互に認証する必要があります。証明書には、不要な複雑化があります。理論的には、SSLクライアントとサーバーはそのような状況では TLS-PSK または TLS-SRP を使用し、すべてのX.509証明書ビジネスを完全に回避する必要があります。
特に、SRPでは、サーバーが保存するのはパスワード自体ではなく、その派生物（追加の数学構造を持つハッシュ）です。重要な点に注意する必要があります。WebAPIの場合、クライアントとサーバーはどちらも人間が関与しないマシンです。したがって、「パスワード」は、ミートバッグに記憶されるほど弱いものである必要はありません。そのパスワードは、たとえば、25個のランダムな文字のシーケンスであり、エントロピーが屋根を通過しています。これにより、通常のパスワードハッシュ方式（低速ハッシュ、ソルト）は役に立たなくなります。 をサーバーのデータベースに保存しないようにしたい（したがって、潜在的なSQLインジェクションの餌食として）パスワードは「そのまま」ですが、ケース、単純なハッシュで十分です。
これは次のことを示しています。理想的には、あるサーバーが別のサーバーと通信するためにRESTful APIを使用し、共有（ファット）シークレットに基づく認証を使用する場合、通信はTLSとSRPを使用する必要があります。証明書はなく、サーバーに保存されているハッシュのみ。すべての作業はすでにSSL/TLSレベルで行われているため、HTTP基本認証やその他のHTTPベースの認証は必要ありません。
残念ながら、SRP対応のSSL/TLS実装の現在の展開状態では、通常、まだSRPを使用できません。代わりに、サーバー側でX.509証明書を備えたより一般的なSSL/TLSを使用する必要があり、クライアントはこれを厳密に検証します。検証が適切に行われている限り、パスワードを「そのまま」送信することに問題はありません。 HTTP基本認証の一部として。
HTTP認証の主な問題は、ブラウザを閉じる以外にログアウトする方法がないことです。また、パスワードはリクエストごとに送信されるため、認証はステートレスです。たとえば、20分間何も操作しないと、ユーザーをログアウトできません。
銀行のようなセキュリティの高いサイトは、通常（常に？）ユーザーが手動でログアウトする手段を提供するだけでなく、また後にユーザーをログアウトします非活動の期間。これにより、多くの日和見攻撃を防ぐことができます。
実際、これらのリクエストが私の銀行から送られるのを見てきました。ただし、ユーザー名とパスワードを毎回送信するのではなく、引き続きセッション識別子を使用します（これは実際には安静ではありません）。ユーザー名とパスワードだけではなくセッションを使用するのは、認証の第2要素が必要だからです。つまり、ページをリロードするたびにチャレンジレスポンスを再入力する必要があります。
銀行がユーザー名とパスワードを使用しているだけなら、正直言って気にしません。しかし、私の意見では、自己尊重銀行アプリケーションは、SMS、カードリーダー、トークンなどのいずれかによる2要素認証の形式を使用する必要があります。