iOSアプリで基本認証を使用しても安全ですか？
各URLリクエストに対してユーザーのユーザー名とパスワードを送信するiOSアプリに取り組んでいます。現時点では、起動の準備ができるまで簡単にするために、ユーザー名とパスワードは、次のようなGETリクエストでHTTPSを介して渡されます。
https://www.example.com/api/login.php?username=user&password=pass
HTTPSは送信用のパラメーターを保護しますが、これに関するセキュリティ上の懸念は、URLがブラウザーの履歴とサーバーのログに保存できることです。
私の質問は...私が現在行っているようにユーザー名とパスワードを渡すのをやめて、送信する前にそれらをbase64エンコードした場合、以下のようにヘッダーに含めます、これは安全ですか？ユーザー名とパスワードは履歴やログに保存されますか？
Authorization: Basic aHR0cHdhdGNoOmY=
編集： base64は簡単に元に戻すことができることはすでに知っています...それは私が求めていることではありません。ヘッダーではなく、HTTPS GETパラメータにユーザー名とパスワードを配置することのセキュリティについて質問しているだけです。
PDATE：現在、ログインエンドポイントに基本認証を使用しており、その後のすべてのリクエストに使用するJSON Webトークンを返します。
ユーザー名とパスワードは履歴やログに保存されますか？
通常、認証ヘッダーはログに記録されませんが、もちろん、これらのデータをログに記録するようにアプリケーションまたはサーバーを構成できます。したがって、設定を確認してください。
履歴への保存について：ブラウザの場合、このような資格情報は履歴に保存されませんが、Cookieと同様に保存され、サイトにアクセスしたときに自動的に送信されます。ただし、ブラウザではなく独自のアプリを使用しているため、この情報をどのように管理するかはあなた次第です。
最初の交換後に一時的なトークンを使用して、すべてのリクエストで実際の認証情報を送信しないようにする必要があります。したがって、アプリは一時的なトークンを記憶するだけでよく、完全な資格情報を記憶する必要はありません。
そしてはい、それはURLよりもヘッダーに置く方が良いです：
- uRLはクライアントによって記録される場合があります
- uRLはおそらくサーバーによって記録されます
- uRLがリークする可能性があります（ https://www.contextis.com/resources/blog/leaking-https-urls-20-year-old-vulnerability/ ）
ヘッダーが使用されると、OPがスキームが完全に安全であるかどうかを完全に尋ねているかどうかは完全にはわかりません。
私の質問は...私が現在行っているようにユーザー名とパスワードを渡すのをやめて、送信する前にそれらをbase64エンコードする場合、以下のようにヘッダーに含めますこれは安全ですか？
...または、質問onlyがクライアント側のロギングに関連し、ではない場合全体安全：
ユーザー名とパスワードは履歴やログに保存されますか？
ただし、質問が全体的な安全性に関するものであると想定して、OPがHTTPSを使用しているにもかかわらず、MITMリプレイ攻撃がまだ可能であるため、すべてのリクエストを介して資格情報を転送することは今日では悪いと考えられていることを理解したいと思います（たとえHTTPSが採用されています）。したがって、HTTPSを使用している場合でも、JWTなどのトークンスキームは、要求時に基本認証を使用するよりも優先する必要があります。
あなたの全体的なアプローチには根本的に欠陥があると思います。私はあなたがどこへ向かっているのかを完全に理解できますが、あなたの全体的なアプローチは間違っています。
多くのアプリケーションのセキュリティレベルの低下の大きな原因の1つは、セキュリティを最初から組み込むのではなく、後の段階に任せることです。多くの場合、アプローチは「アプリを動作させるだけで、基本的な機能が動作したらセキュリティに対処します。
このアプローチの問題は、基本的な機能を機能させると、セキュリティに関するオプションが制限されるような方法で制限が設定され、設計がガイドされることが多いことです。
これは完全に理解できます。新しいキラーアプリの右側に座ったときは、クールなパーツに注目したいと思います。これは、見たい主要な機能であり、実際の進捗状況を見たいと思っています。多くの場合、管理者や意思決定者は、見るものを生み出すというプレッシャーを高めます。このすべての安全なものは足場であり、邪魔になる-一種の必要な悪。
残念ながら、非常に多くの場合、これはセキュリティに重点を置いていないことになります。設計により、十分なセキュリティを追加することが難しくなりすぎたり、納期などの他のプレッシャーが加わったりして、コーナーがカットされます。
セキュリティモデルから始めます。それを機能させて、アプリの機能から始めます。これにより、デザインが改善され、保守が容易になります。この特定のケースでは
- ええ、GETパラメータのアプローチを間違いなく取り除きます。
- Base64エンコーディングについては忘れてください。それは本当にあなたを買うものではなく、誤った安心感を生み出す可能性があります。
- パスワードやユーザー名を送信する必要性を最小限に抑える方法を検討してください。なんらかの認証トークンの使用を検討してください。
- トークンが暗号化されていることを確認してください。
ユーザー名とパスワードだけでなく、認証トークンを使用することには多くの利点があります。有効期限などの追加情報をトークンに暗号化できます。ブラウザのバージョンやOS情報など、クライアントの詳細を含むトークンも見たことがあります。これは、一種の指紋として使用できます。
トークンを使用する主な利点は、ユーザー名とパスワードを絶対最小回数だけ渡すことです。この情報を送信する必要が少ないほど、効果的です。ただし、トークンを効果的かつ安全な方法で使用するには、トークンをアプリケーションに組み込む必要があり、後で追加する必要はありません。
これを最初からアプリに組み込むもう1つの利点は、さまざまなアプローチやライブラリをより簡単にテストできることです。トークンベースのさまざまな認証および承認ソリューションが世の中にあり、どのアーキテクチャが言語、プラットフォームに最適であるかを特定する必要があります。最初からこれを正しく行うと、残りのコードを既存のコードベースにレトロフィットするよりもはるかに簡単に配置できます。
これは安全ですか？
特にありません。 Base64エンコーディングは簡単に元に戻すことができます。
ユーザー名とパスワードは履歴やログに保存されますか？
たぶん、入手できる情報からは本当にわかりません。もちろん、データがMitM攻撃で記録される可能性があります。
これは本当にリスクの問題に帰着します。絶対にしないでください。財務/健康記録に適しているでしょうか。新製品のテスト中、特にライブデータを記録しておらず、稼働前にデータベースをリセットする場合は、それで十分でしょうか。