生成されたAPIのアクセストークンがパスワードよりもはるかに長いのはなぜですか？
ツイッターを例に説明します。
一方、 Twitterへの登録 の場合、パスワードには少なくとも6文字が含まれている必要があります。
一方、APIへのアクセストークンは約50文字です。
（ ソース ）
この長さの違いの背後にあるセキュリティ上の理由について疑問に思っています。セキュリティを向上させるためにトークンが本当に長い場合、なぜ短いパスワードが許可されるのですか？最小長が10、15、または20文字のような所定の数字ではない理由を私が尋ねているわけではないことに注意してください。それでも、トークンと比較して大きな違いが生じます。
このトークンはランダムで長いため、推測が困難ですが、比較的weakパスワードでTwitter開発者のWebサイトに接続すると、自分のトークンを表示できます。パスワードでアクセスできる場合に、安全なランダムトークンを作成するのはなぜですか？ 2要素認証を有効にすることは可能ですが、開発者のWebサイトへのアクセスにこれは必要ありません。
したがって、次の事実を考えると：
- トークンは、ログインしたユーザーのパスワードとほぼ同じ操作を許可しますが、
- aPIへのアクセスは、インターネットからのアクセスとしてブルートフォースにすることができます。
- Twitterはパスワードの最小の長さとトークンの長さを選択できます。
なぜトークンはそんなに長いのですか？ Twitterの観点から、パスワードに6文字で十分な場合、トークンに50文字を使用するのはなぜですか？
これにはいくつかの理由があります。
1つの理由は、覚えやすいパスワードが期待されるセキュリティレベルに対して短すぎるためです。この問題を軽減するためにいくつかの方法が使用されますが、それらをアクセストークンに適用することは問題があります。
- 一部のサービスには 2番目の認証要素 が必要です。アクセストークンは、ユーザーの介入なしで使用することを目的としているため、他のほとんどの認証形式は使用できません（バイオメトリクスなどの適用対象外か、2番目のアクセストークンしか生成されません）。
- オンラインサービスは、認証の試行の間に遅延を課すことにより、ブルートフォース攻撃から保護します。これは正当なユーザーをロックアウトする可能性があり、追加の実装負担であるため、問題があります。
- パスワードの保存には スローハッシュ を使用します。これは多くのCPU時間を消費します。十分に長いアクセストークンを秘密にしてハッシュ形式で保存する必要がある場合、特別な予防策は必要ありません。同様に、キーがアクセストークンから派生した場合。
別の理由は、アクセストークンの長さは通常、プロトコルまたはライブラリの作成者によって決定されるのであって、それらを使用するサービスの作成者によってではないことです。通常、アクセストークンを長くするコストはわずかです。そのため、長さは、誰もが必要とする最高のセキュリティレベルを提供するものに設定されます。アクセストークンの長さをminimumパスワード長と比較していますが、より適切な比較はパスワードの最大長を使用することです。
一部のサービスは、アカウントとは無関係にアクセストークンを使用します（つまり、識別パラメーターと組み合わせた認証パラメーターとしてではなく、sessio Cookieとして）。異なる権限を持つ単一のアカウントに多くのアクセストークンが存在する場合もあります。したがって、アクセストークンには、衝突の確率を無限に保つために、より多くのエントロピーが必要です。
簡単に言うと、トークンは記憶されるように設計されていないため、必要なだけ長く使用できます。パスワードの長さは、短い記憶期間の後、人が実際に確実に思い出せる長さに制限されます。これにより、ほとんどの場合7〜10文字に制限されます。トークンは（アプリケーション固有であるため）一度だけコピー/貼り付けできるように設計されているため、長いことによるペナルティはまったくなく、長さが非常に長いため、トークンを安全かつ一意にすることができます（トークンに十分な埋め込みが可能です）特定のアカウントに関連付ける情報）。
私はもっと指摘された質問があると思います、なぜパスワードが長くないのですか;-)
比較的保存する必要がある場合短いパスワードには、いくつかの注意事項があります。
- レインボーテーブルの攻撃を防ぐのに十分な長さのユニークな塩で塩を入れます。
- ブルートフォースを妨げるために計算に時間がかかるキーストレッチ。
反対に、トークンが長い十分な場合は、セキュリティ上の欠点なしにプレーンなSHA-256だけを保存できます。これらは利点です：
- 塩漬けの必要はありません。ソルト付きパスワードとは対照的に、トークンハッシュはデータベースで検索できます。したがって、トークンを取得した場合は、再度ハッシュして、トークンが有効かどうかをSQLクエリで確認できます。
- 計算は高速で、サーバーのCPUで軽くなります。キーストレッチのため、パスワードをハッシュするために多くのCPUパワーが必要でしたが、トークンのハッシュは非常に高速です。
最近書いたアプリケーションの場合、アクセストークンは対称的に暗号化された形式の文字列です。
nonce=123456789;userid=123;username=bob;login_expires=12345679;...
暗号化された文字列はCookieであり、非常に長いです。復号化は高速で、サーバーから秘密鍵を盗んだ人がいないと仮定すると、データは本物です。
トークンは、プログラムでAPIにアクセスするために使用されます。パスワードは、ユーザーが入力するときに使用されます。
ユーザー名とパスワードの入力を2つの異なるページに分割する、キャプチャのようなセカンダリ入力フィールドを追加する、試行に失敗した後に待機期間を強制する（またはユーザーIDを無効にする）などの戦略により、パスワードのブルートフォースを防止します。
その間、トークンはこれらのメカニズムなしで使用され、フルスピードで実行されるAPIアクセス試行に耐える必要があります。したがって、ブルートフォースを防止するためには、もっと長くする必要があります。
つまり、言い換えると、短いパスワードと防御戦略により、長いトークンと同じセキュリティが得られます。