6文字のトークンを使用してドキュメントにアクセスする
ユーザーがフォームに6文字/数字（A_Z、0-9）を挿入してドキュメントにアクセスできるWebアプリを構築しています。すべてのドキュメントには、1ABH5Fのようなランダムに割り当てられたアクセスコードがあります。
ユーザーが有効なコードを挿入すると、ドキュメントが表示されます。ユーザーログイン（認証なし）はありません。一般に公開されています。
フロントエンドはステートレスAPIを介してドキュメントにアクセスします-コードはAPIに送信され、ドキュメントを返します。
情報セキュリティをどのように実装すべきですか？ここに誰もセキュリティの専門家ではありませんが、次のように考えていました。
- フロントエンドでのキャプチャの使用
- 1つのIPからのAPIの呼び出しを3時間/時間以上に制限する
ドキュメントへのアクセスを防ぐために他に何を実装する必要がありますか？
このシステムのユースケースを指定することは非常に重要だと思います：
これは、この文書を持っている人が誰でもオリジナルの（デジタル）文書を閲覧できるシステムです。これは、ユーザーがドキュメント（例：自動車ディーラー）を印刷し、それを他の会社（例：自動車登録局）に持って行くことができる環境で使用されます。
ここでの問題は、ユーザーが印刷されたドキュメントを改ざんして（そしてDO！）、それを他の会社（自動車登録局）に持ち込むことができることです。これらの他の会社は、オリジナルが印刷版と同じであるかどうかを確認する方法を持っている必要があります。
他の会社（10000以上の自動車登録局のいずれか）がわからないため、6文字のトークンを保持/表示している人は誰でもオリジナルのドキュメントにアクセスできます。
ブルートフォーシング
つまり、サイズが36文字と6文字のアルファベットがあります。これにより、約20億のトークンが提供されます。 1,000種類のドキュメントがあるとします。これにより、ドキュメントに関連付けられたトークンを200万回に1回推測することができます。 1年に1時間ごとに1000の異なるIPから試行すると、ほぼ1000万回の推測が得られます。これにより、いくつかのドキュメントが得られます。
確かに、CAPTCHAはこれを難しくします。しかし、それらは完璧ではなく、常に humans によって解読できます。
ここでの問題は、トークンのみを入力し、ドキュメントIDを入力しないため、ドキュメントではなく、IPでのみレート制限できるということです。そのため、トークンを取得するための非常に大きなスペースがない限り、ブルートフォースからの保護は非常に困難になります。
共有する
パスワードは個人的なものであり、共有しないことをお勧めします。つまり、侵害された場合は簡単に変更でき、誰が手に入れるかをある程度制御できます。
このようなドキュメントトークンは、設計によって共有されることになっています。誰がそれを取得するかについては、ほとんど制御できません。最終的にはメールサーバーとバックアップになり、世界中の人々のデスクトップに投稿されます。
誰がトークンにアクセスできるかわからないので、トークンを変更する必要がある場合は、トークンを持っているはずのすべての人にトークンを再配布する必要があります。それは安全でも実用的でもありません。
結論：より良い方法があるはずです
これはあなたに非常に良いセキュリティを与えません。保護しているリソースがそれほど重要でない場合はそれで十分かもしれませんが、私はそれを価値のあるものに使用しません。
私はあなたの正確なユースケースを知りませんが、それが何であれ、あなた自身のAPIをローリングするよりもこの問題を解決するより良い方法がなければなりません。既存のソリューションを使用すると、独自のコードを記述する必要がないという問題も回避できます。
既存のクラウドストレージサービス、社内イントラネットへのVPN接続などを使用します。 IDE=を起動せずにコーディングを開始しないでください。
更新：ユースケース
これは、アクセストークンがおそらく良いアイデアの1つです。しかし、上記の問題を回避するには、次のようにします。
- CAPTCHAとIPによるレート制限の両方を維持します。 （偶発的または故意のDOSを防ぐために、レート制限がどのように行われるかを再検討することをお勧めします。）
- 力ずくの強制に対処するために、トークンのサイズを大きくします。 Googleドライブでは49文字を使用し、大文字、小文字、数字を使用します。それで十分でしょう。
- 共有の問題を回避するには、ドキュメント自体のQRコードにトークン付きのURLを印刷します。これは、peoplpeが扱い慣れている物理的な紙の領域に穴の問題をもたらします。紙を見る人々はデジタルのオリジナルにアクセスするでしょう。それは簡単に理解できます。
- ドキュメントにアクセスできる回数、または少なくともトークンを使用できる最大時間に制限を設定することを検討してください。車を1週間以内に登録する必要がある場合、トークンが2週間後に機能する理由はありません。
- トークンをプレーンテキストでデータベースに保存しないでください。それらをハッシュします。 （ここでは、SHA256のような高速なもので十分です。大きなランダムトークンがある場合、bcryptをロールアウトする必要はありません。）
- [〜＃〜] csprng [〜＃〜] を使用してトークンを生成します。そうしないと、いくつかのトークンにアクセスできる攻撃者によって推測される可能性があります。
「6文字のトークンを見ている人は誰でも元のドキュメントにアクセスできる」と言うので、これらには何もreallyの秘密はないと仮定します（つまり、単にトークンを見つけるだけでは詐欺を実行できませんでした）私の隣人のゴミ）。それ以外の場合は、電子メール登録とパスワードを使用した通常の認証スキームを選択します。
多くのトークンベースのシステムはあなたが説明する方法で使用されますが、あなたの場合、トークンの長さは驚くほど短いです。トークンを少なくとも2倍長く使用することをお勧めします。これにより、システムを使いにくくすることなく、ブルートフォース攻撃を非現実的にすることができます。
PS。ああ、OとIをアルファベットから除外してください。
1つのIPからのAPIの呼び出しを3時間/時間以上に制限する
まず最初に、これは巨大なサービス拒否リスクです。誰かが「l」と「1」を混同したからといって、1時間ロックアウトされるのは受け入れられません。
ほとんどすべてのオフィスコンピュータがNAT44の背後にあることに注意してください。各IPの背後には複数のユーザーがいます。 CGNAT（NAT444） およびNAT464を使用すると、同じIPを使用しているさまざまな建物の多くのホームユーザーも表示されます。