web-dev-qa-db-ja.com

バックエンドに送信するときに携帯電話番号とOTPを暗号化する必要がありますか

私はログインページを持っています。ユーザーは自分の携帯電話番号でログインし、バックエンドサーバー経由でOTPを送信します。ワンタイムパスコード（OTP）を入力すると、次のようなAPIがヒットします。

https://backend.com/api/login?mobile=9123123123&otp=1234

私の質問は、セキュリティの観点からはこれで十分です。または、何らかのアルゴリズムで携帯電話番号とOTPの両方を暗号化して、次のようなものを送信する必要があります。

https://backend.com/api/login?authToken=jshfkasfasfbmsabvj&authKey=amsfgjkashfkashjfjasgfkjahsfkj

ここで、authTokenは暗号化された携帯電話番号、authKeyは暗号化されたOTPです。

これに関する良い習慣は何ですか、ここで使用できる良い暗号化アルゴは何ですか？

Httpsを使用するようになった提案はほとんどありませんでした。実際、私はこれを使用していますが、どういうわけか質問で見逃していました。私の懸念は、誰かがAPIを理解し、携帯電話番号のOTPのさまざまな組み合わせで攻撃を開始し、アカウントのアクセス権を取得できることです。

restapisecurityauthenticationencryption
3
Saurabh

私の懸念は、誰かがAPIを理解し、携帯電話番号のOTPのさまざまな組み合わせで攻撃を開始し、アカウントへのアクセスを取得できることです。

これは、Webアプリケーションのセキュリティに関連するよくある質問です。 APIが公開されると、あらゆる種類の悪意にさらされます。

必須である https に加えて、ここでも考慮すべきいくつかの対策があります。

しきい値

1秒あたりのリクエストの最大数とソース（リモートアドレス）を設定します。 [〜＃〜] x [〜＃〜]IPアドレスごとの要求/秒としましょう。

しきい値は通常、API Gatewayまたは認証サーバーに実装されます。多くのAPIマネージャーは、すぐにしきい値を制御できます。

ポイントは、phone/otpの可能な組み合わせの数とそれらのそれぞれの順列は、通常、しきい値よりも大きく、有効なタプルをヒットする可能性を少なくする、または少なくとも、それは困難になります。

異なるしきい値でエンドポイントを設定できます。通常、セキュリティに関連するエンドポイントは、ビジネスに関連するエンドポイントよりも低い値になります。

しきい値に達すると禁止されます。禁止はあなたが望む限り続きます（1、5、10分、...）。ブラックリストが好きなら、これを追加するのに最適な場所です。

研究事例：

Opacity

エラーが発生した場合は、できるだけ多くの情報をユーザーに提供する必要があると考えられます。ビジネスルールについて話すときは問題ありませんが、セキュリティについて話すときはそうではありません。

ログインプロセスが失敗した場合は、単純な無効な資格情報で十分です。ワイヤーの反対側にいる誰にもエラーの原因を知らせないでください。

セキュリティを外部に対して不透明にすることで、攻撃対象を減らします。

認証トークン

全体的にセキュリティを考慮して、ホイールを再発明しないことをお勧めします。 [〜＃〜] jwt [〜＃〜] 。

バックエンドから自由に期限切れを強制できれば、それはプラスです。

研究事例：

トレーサビリティ

Https 接続は暗号化されます。ただし、メッセージが復号化されると、クエリ文字列をログファイルで追跡できます。したがって、クエリ文字列値が2回暗号化されているかどうかは関係ありません。認証プロセスのPOST要求を送信することをお勧めします。機密データを転送する可能性のある他のすべての要求に対して実行してください。

証明書の検証

[〜＃〜] mitm [〜＃〜] の防止策として、サーバー証明書がサーバーのドメインと一致するかどうかのチェックはプラスです。

気づき

セキュリティは深刻なビジネスです。自分自身を最新の状態にし、十分に文書化してください。ここで働き始めるのに良い場所です。 OWASP-カテゴリ 。

ここにいくつかの興味深いプロジェクトがあります：

10
Laiv

アモンの言うことを超えて：決してhttpを使用しないでください。常にhttpsを使用してください。これにより、すべてが暗号化されますおよび正しい宛先に送信されることがわかります。

PS。ブルクハートが言うことは間違ったです。彼は、httpsリクエストのパラメータは暗号化されずに送信され、証拠としてFirefoxの履歴を表示すると主張しています。ただし、Firefoxには送信済み httpsリクエストがあるため、マシンのFirefoxはパラメータを認識して記録できますが、その後は暗号化されてから暗号化されます。送り出さ。

1
gnasher729

システムに対する主な攻撃ポイントは2つあります。

1）トランスポートチャネル。アクセスの詳細（番号+パスワード）が漏洩する可能性があります。

2）特定の電話番号について、不明なノードが繰り返し資格情報を推測できるようにするAPI

保護する方法？

  • コメントで述べたように、1から保護するには数値とOTPの暗号化では十分ではありません。APIが暗号化された入力を受け取る場合、攻撃者は暗号化されたバージョンを傍受する必要があるためです。

  • httpsは1を完全に回避します。ただし、誰かがサーバーアドレスを偽装し、中間者（MITM）を演じた場合は例外です。したがって、クライアントアプリケーションがhttpsを使用するだけでなく、サーバー証明書がサーバーのドメインと一致するかどうかを確認することも安全です。

  • 電話またはその両方のOTPの暗号化は、原則として2から保護しません。OTP1234がxEHgに暗号化されている場合、暗号化されたバージョンが推測されるのは時間の問題です。以下は防御力を高めます：

    • より長いOTPを使用します（8が最小のようです）
    • oTPを短い時間枠で有効にします（OTPが毎分変化する場合、数百万の組み合わせを推測するには短すぎます）。
    • iPアドレスがNを超える推測をする場合、そのIPを一定時間ブロックします
    • 特定の電話のKを超えるOTP推測がKを超える場合は、元のIPアドレスを一定時間ブロックするか、リスクまたはその両方についてユーザーに通知します

これらの対策はOTPの推測を無効にします。

1
Christophe

まず、私は警備員ではありません。だから私がここで言うことは愚かかもしれないし、そうでないかもしれません。

私が最初に思ったのは、携帯電話番号を暗号化しないと、サードパーティがデータストリームを吸い上げて、既知の識別子をシステムのユーザーに直接リンクする情報を収集できるということでした。

これは、APIの永続性に影響を与える場合とそうでない場合がありますが、ユーザーに影響を与える可能性があります。

[〜＃〜]編集[〜＃〜]

参照してください。警告が役に立つはずだと知っていました。 httpとhttpsの問題に気づかなかった！

0
Peter M