クライアント側でopenssl_encryptを使用してユーザ名とパスワードを暗号化していますか？

Question

私はPHPウェブサイト用のAPIを作成しており、暗号化された形式でログインとユーザーパスワードを送信する必要があります。

$user_loginが 'login:password'のような文字列である

$decrypted = openssl_decrypt($user_login, 'bf-ecb', $client_id); 

：私は、復号化するための以下の方法を選択しました。 $client_idは私のサイトとクライアントアプリケーションを知っています。クライアントはiPhone上のアプリケーションである可能性が高いです。私は通常の暗号化アルゴリズムを選択しましたが、ユーザー名とパスワードのエンコーディングでクライアント側で問題はありませんか？

Answer 1

通常の暗号化アルゴリズムを選択しましたが、ユーザー名とパスワードのエンコーディングでクライアント側で問題は発生しません。

おそらくWebCryptoのようなものを使用して、受け入れられ、実装された暗号化アルゴリズムがクライアントで利用できるようにする必要があります。 polyfillする必要があります。

大きな画像では、2つの問題があります。まず、Webセキュリティモデルです。 Webセキュリティモデルでは、インターセプトは有効なユースケースです。次に、サーバーのセキュリティとパスワードリストに違反しています。

---

傍受

最初の問題は、W3Cの哲学によるもので、あなたが壊れたビジョンについてできることは何もありません。 Webセキュリティモデルの基本的な欠陥はPublic Key Pinning with Overridesではっきりと判明しました。上書きは傍受に対応しており、ウェブの人々はその行為を軽視して隠蔽しようとしました。

あなたの直ちに防衛策は、あなたがやっているように、追加のセキュリティコントロールを配置することです。つまり、暗号化を使用して、ユーザー名とプレーンテキストのパスワードを犯罪者が利用できないようにします。 あなたを助ける必要がありますのでpolyfillする必要はありません。

しかし、潜在的な問題があります。インターセプタは、暗号化されたユーザー名とパスワードの受け渡しを許可し、クライアントに返されたときにCookieまたはトークンを取得できます。だから、あなたもクッキーを守る必要があります。

ユーザー名、パスワード、Cookieはリプレイ攻撃から保護する必要があります。攻撃者が暗号化されたユーザー名とパスワードを取得し、後でそれを再生して認証されたセッションを取得する必要はありません。だから、塩やナンセンスが必要なように聞こえます。

---

データ侵害

第二の問題は、パスワードのサーバ側のストレージのベストプラクティスに従うことによって修復することができます。そのために、OWASPのPassword Storage Cheat SheetとSecure Password Storage Threat Model