2017-07-27 9 views
2

私はWebアプリケーションを構築しており、Webサーバーは安全です。つまり、フロントエンドでssl certを使用して接続を暗号化しています。投稿要求の本文にあるJsonオブジェクトでユーザー名とパスワードを送信するのは安全ですか?

ユーザーがログインすると、このように見えるJSONオブジェクトが作成され、サーバーに送信されます。

{ 
    username:"the user's username", 
    password:"the user's password" 
} 

サーバーでは、これはsaltを使用するハッシュアルゴリズムで検証されます。いったん確認されると、ある時間有効なapiトークンが作成され、リクエストが行われたときにユーザーを確認するためにヘッダーで前後に渡されます。このベストプラクティスのようにユーザー名とパスワードを送信する/安全であるか、ヘッダーに送信する方が良いですか?

+0

これは実際には依存しますが、ユーザー以外の誰かが彼の要求にアクセスできるような状況であれば、最初に実行する必要がある他のものがあります。 – Kadaj

+0

SSLを使用する意味ですか? POSTはHTTPS経由で送信されますか? *証明書*は暗号化を行いません。 – EJP

+0

なぜ、コンテナ管理認証を使用していないのですか? – EJP

答えて

3

多くのポイントにそれを分けることができます:

1)あなたは

2(それが有効である必要があります)ユーザとサーバ間の通信を保護するために有効なSSL証明書を使用)送信POST要求の本文にあるユーザー名とパスワードがベストプラクティスです(GETを使用して資格情報などの機密情報を送信しないでください)

3) Hにapiトークンを送信するTTPリクエストとレスポンスヘッダーがベストプラクティスです(セッショントークンなどの機密情報を送信するためにGETを使わないでください)

このように、この実装ではリスクはないようですが、

1)アイドル状態のユーザーの場合、APIトークンのタイムアウトは短くする必要があります。

2(5〜15分は、アプリケーションの重要度に基づいて平均値である)) APIトークンの長さは約長い文字列でなければなりません。 30〜40文字。

3)は、APIトークンの生成は、(セッション予測攻撃から保護するために予測することは、ランダム化とハードなければなりません。)

・ホープこのヘルプあなたは。

+0

ありがとう!あなたのポイントに基づいてそれについてかなり良い感じ、クール大丈夫。 – Dan

+0

「リスクはありません」?常にリスクがあります。 – quinz

+0

「リスクはありません」というようなことはありませんが、提案されたソリューションがベストプラクティスに従っていることを意味します。それに加えて、私はこの解決策を実装している間に彼が彼の配慮の中で取るべきであるという答えにいくつかのセキュリティ問題を挙げました。 – kingasmk

1

基本的には、HTTP基本認証です。

このベストプラクティス/セキュリティのようにユーザー名とパスワードを送信していますか、それともヘッダーで送信する方が良いですか?

セキュリティの観点から見ると、身体またはヘッダーに資格情報を送信するかどうかに大きな違いはないとは思いません。基本的に誰でもクリアテキストメッセージを読むことができれば、両方のコンポーネントの資格情報を見ることができます。基本認証を使用する一般的な方法とはいえ、HTTPヘッダーを使用することです:VGVzdFVzZXI6UGFzc3dvcmQxMjM0はあなたのbase64でエンコードされた資格情報である

Authorization: Basic VGVzdFVzZXI6UGFzc3dvcmQxMjM0 

。この場合のデコードされた文字列は次のとおりです。TestUser:Password1234

TLSは通信中の資格情報の唯一の保護であるため、通信チャネル内のすべてのノードを識別して、クリアを公開する可能性があることを認識することが重要ですメッセージ。たとえば、TLSを終了するプロキシを使用している場合、それらのプロキシはMITM攻撃の可能性のあるベクトルです。

中継中の資格情報のセキュリティを強化する場合は、非対称のエンドツーエンド暗号化を実装して、クライアント側の認証済み公開鍵で証明書を暗号化することもできます信頼できるCAによって署名されている)、そのサーバーでのみ使用できる秘密鍵で宛先の暗号化を解除します。この場合、通過中のメッセージに何が起こるか心配する必要はありません。

関連する問題