PHP Web サイトの API を作成しており、ログインとユーザー パスワードを暗号化された形式で送信する必要があります。復号化するために次の方法を選択しました。
$decrypted = openssl_decrypt($user_login, 'bf-ecb', $client_id);
$user_loginのような文字列はどこにありますか'login:password'。$client_id私のサイトとクライアントアプリケーションを知っています。クライアントは iPhone 上のアプリケーションである可能性があります。私が選択した通常の暗号化アルゴリズムは、クライアント側でユーザー名とパスワードのエンコーディングに問題はありませんか?
私が選択した通常の暗号化アルゴリズムは、クライアント側でユーザー名とパスワードのエンコーディングに問題はありませんか?
おそらくWebCryptoのようなものを使用して、受け入れられ実装された暗号化アルゴリズムがクライアントで利用可能であることを確認する必要があります。ポリフィルが必要になる場合があります。
全体像を見ると、取り組むべき 2 つの問題があります。1 つ目は、Web セキュリティ モデルです。Web セキュリティ モデルでは、傍受は有効なユース ケースです。2 つ目は、サーバー セキュリティとパスワード リストの違反です。
傍受
最初の問題は W3C の哲学によるもので、壊れたビジョンについてはどうすることもできません。Web セキュリティ モデルの根本的な欠陥は、オーバーライドを使用した公開キーのピン留めで明確になりました。オーバーライドは傍受に対応し、Web 関係者はこの動作を軽視して隠蔽しようと懸命に努力しました。
あなたの当面の防御策は、あなたが行っているように追加のセキュリティ制御を配置することです。つまり、暗号化を使用して、侵入者がユーザー名とプレーン テキストのパスワードを使用できないようにします。WebCryptoが役立つはずなので、ポリフィルする必要はありません。
ただし、潜在的な問題があります。インターセプターは、暗号化されたユーザー名とパスワードの通過を許可し、クライアントに返されたときに Cookie またはトークンをキャプチャします。そのため、Cookie も保護する必要があります。
また、ユーザー名、パスワード、および Cookie は、リプレイ攻撃から保護する必要があります。攻撃者が暗号化されたユーザー名とパスワードを取得し、後でそれを再生して認証済みのセッションを取得することは望ましくありません。そのため、salt または nonce も必要になるようです。
データ侵害
2 番目の問題は、パスワードのサーバー側ストレージのベスト プラクティスに従うことで解決できます。そのためには、OWASP のパスワード ストレージ チート シートと安全なパスワード ストレージの脅威モデルを参照してください。