推測不可能なプライベートURLはパスワードベースの認証と同等ですか？

Webでリソースを公開したい。このリソースを保護したい：特定の個人のみがアクセスできるようにするため。

何らかの種類のパスワードベースの認証を設定できました。たとえば、ファイルを提供する前に、（おそらくユーザーのバッキングデータベースに対して）正しい資格情報の着信要求をチェックするWebサーバーを介してのみ、リソースへのアクセスを許可できます。

または、プライベートURLを使用することもできます。つまり、単純に推測できないパスでリソースをホストできhttps://example.com/23idcojj20ijf...ます。たとえば、正確な文字列を知っている人にアクセスを制限します。

このリソースにアクセスしたい悪人の観点から見ると、これらのアプローチは同等ですか？そうでない場合、それらの違いは何ですか？そして、保守性に関しては、どちらか一方を実装する前に私が知っておくべきどちらかのアプローチに賛否両論はありますか？

プライベートURLは、URLのビットサイズが資格情報のビットサイズと同じであっても、資格情報を使用した認証よりも若干弱くなります。その理由は、URLがより簡単に「リーク」する可能性があるためです。ブラウザにキャッシュされ、サーバーにログオンします。アウトバウンドリンクがある場合、他のサイトのリファラーヘッダーにプライベートURLが表示される場合があります。（肩越しに見ている人にも見ることができます。）

漏えいした場合（偶然またはユーザーの不注意による）、それは公開され、Googleによってインデックスに登録されることもあります。

このため、プライベートURLは通常、パスワードリセットなどのワンショット操作にのみ使用され、通常は限られた時間だけアクティブになります。

情報セキュリティには関連するスレッドがあります：ランダムURLはプロフィール写真を保護する安全な方法ですか？-1つの答えはこの話を共有しています：納税申告書がGoogleで終わると、Dropboxは古い共有リンクを無効にします。したがって、それは単なる理論上のリスクではありません。

注意：

多くの人が「プライベート」URLと認証を混同しているようです。また、信頼できるエンティティを介してリンクを送信することは、二要素認証の試みであるという混乱があるようです。明確にするために、推測しにくいものではあるが、一般にアクセス可能なリソースについて話している。

プライベートURLを使用する場合、常に侵害される可能性があると想定する必要があります。侵害された場合でも、リソースが攻撃者に情報を漏らさないように、そのようなURLを設計する必要があります。

プライベート/推測困難なURLは、パスワードベースの認証と同等ではありません。本来、プライベートURLはまったくプライベートではなく、一般公開されているリソースです。「プライベート」URLという用語は誤った名前であり、むしろ「あいまいな」URLだと思います。

「プライベート」URLの使用が許容される特定のケースがありますが、パスワード認証やキーベース認証などの従来の認証方法よりも本質的に安全性が低くなります。

「プライベート」なURLがよく使用されるのは、次のような場所です。

1. パスワードリセットメール
2. 証明書生成メール
3. アカウント/メールの確認メール
4. 購入したコンテンツ（電子書籍など）の配信
5. フライトチェックイン、搭乗券の印刷、従来の認証に加えてプライベートURLの使用など、その他のさまざまなこと

ここでの共通点は、通常、ランダムURLはワンショット操作にのみ適しているということです。また、従来の認証とランダムURL は相互に排他的ではありません。実際、これらを相互に組み合わせて使用​​して、リソースを配信するときにセキュリティを強化できます。

ロバートハーベイが指摘したように、ランダム/プライベートURLを安全に使用する唯一の方法は、ページを動的に生成し、ユーザーを半認証済みとみなす方法でURLを送信することです。これは、電子メール、SMSなどです。

ランダムに生成された/プライベートURLには通常、いくつかのプロパティがあります。

1. 妥当な時間の経過後に期限切れになるはずです
2. これは使い捨てURLである必要があります。IEは、最初にアクセスされた後に有効期限が切れます。
3. ユーザーを安全に認証するために信頼する他のエンティティへのユーザーの認証を延期する必要があります。（リンクをメールまたはSMSなどで送信することにより）
4. リソースを公開するAPIのレートを制限するか、推測できないほど十分なエントロピーを持つURLエンドポイントを作成することにより、最新のコンピューターが期限切れ前の時間枠でURLをブルートフォースすることは不可能です。
5. ユーザーに関する情報が漏洩することはありません。IE：ページがパスワードをリセットする場合：ページはリクエスターのアカウント情報を表示するべきではありません。Aliceがパスワードリセットリンクを要求し、Bobが何らかの方法でURLを推測した場合、Bobがリセットしているパスワードを知る方法がありません。
6. ユーザーに関する情報が漏れる場合は、従来の認証に加えて使用する必要があります。たとえば、Cookieが設定されている場合、またはsession_idがまだ有効である場合、ページはユーザーを認証済みと見なします。

異なるリソースには異なるレベルのセキュリティが必要です。たとえば、秘密のレシピを友人と共有したい場合、ランダム/プライベートURLを使用して友人と共有することは許容されます。ただし、リソースを使用して誰かのIDを盗んだり、他のサービスプロバイダーのアカウントを侵害したりできる場合は、そのリソースへのアクセスを制限する方がはるかに重要です。

ほとんどすべての認証スキームは、あなたが秘密を知っていることを証明することに要約されます。秘密のパスワード、または秘密のURL、または...

より高度なプロトコル（OAUTH、Kerberosなど）を使用すると、実際にシークレットを送信することなく、シークレットを知っていることを証明できます。これは重要です。なぜなら、推測する以外にも「利用できない」秘密を取得する方法が他にもあるからです。

自分と同じインターネットカフェに座って、「利用できない」URLを入力すると、WiFi接続を盗聴される可能性があります。その時点で、SSLを使用していない場合、またはSSL実装の最新の新しいバグを悪用できる場合は、その秘密も知っています。

このスレッドにはすでに多くの良い答えがありますが、質問に直接対処するには：

このリソースにアクセスしたい悪人の観点から見ると、これらのアプローチは同等ですか？そうでない場合、それらの違いは何ですか？

定義を確立させてください。「認証」とは、身元の主張を証明する資格情報を提供することです。通常、アクセス制御はユーザーの識別に基づいています。

シークレットURLは特定のユーザーにバインドされていません。他の人が指摘したように、プロキシのログファイル、Googleによってインデックス付けされた検索リクエスト、または他の多くの方法で漏洩する可能性があります。

一方、パスワードは一意のユーザーアカウントに関連付けられています。これをリセットするか、ユーザーのホームロケーション、既知のIPアドレス、または他の任意のコントロールからのみ使用できるようにすることができます。

ユーザー名/パスワードを使用すると、アクセスをより詳細に制御できます。

アクセス制御により、リソース（オブジェクト）へのID（サブジェクト）アクセスが許可されます。URLの例では、IDは「何らかの方法でURLを取得した人」です。

可能であれば、ユーザー名/パスワードを入力してください。URLは、時間の経過とともに、あらゆる種類の予期しない方法でリークします。

秘密のURLは、秘密のパスワードと同じくらい安全です。ただし、パスワードはURLよりも秘密にする方が簡単です。これは、すべての人とそのプログラムがパスワードを秘密にする必要があることを知っているためです。

たとえば、ブラウザは画面にパスワードを表示せず、許可されたパスワードのみを保存し、そのパスワードストレージ（マスターパスワードでロック解除された暗号化ストレージなど）を保護する手段を提供します。対照的に、それは常に画面上にURLを表示し、リファラーヘッダーを介してURLをリークする可能性があり、さらに保護することなくブラウジング履歴に自動的に保存します。

同様に、HTTPプロキシは通常パスワードを記録しませんが、URLは一般に記録されます。

また、認証にURLを使用すると、URLを共有することで認証が共有されるため、アクセスを個別に取り消す（または記録する）のが難しくなります。

そしてもちろん、シークレットURLはシークレットパスワードのすべての弱点を継承します。特に、認証にパスワードを使用すると、そのパスワードがサーバーおよび通信を読み取ることができるすべてのユーザーに明らかになります。

どこにも記載されていないもう1つの項目は、「推測」の抑制です。ほとんどのパスワード認証システムでは、ユーザーのパスワードを推測する試行回数が制限されてから、さらに認証試行がロックアウトされるか、制限されます。

URLスキームに対して「推測」を使用して同様のことを行うことはできますが、実装は多少難しくなります。URL生成に認識可能なパターンがある場合、誰かが「ランダムな」URLスペースを処理するように設定するのを止めるのは難しいかもしれません。

まだ言及されていない別の側面があります-URL短縮。

最近の出版物（2016年4月）で、URL短縮サービスは、ランダムに生成された「使用できない」URLによって提供されるセキュリティの強化を完全に無効にしていると主張されました。短縮サービスのURLスペースは、ランダムに生成されたURLよりもかなり小さくなります。つまり、短縮サービスと共有されるこのような「セキュアな」URLは、予想よりも簡単に推測できます。

説明のために、ランダムなURLが128ビット長（つまり、guid）であると仮定しましょう。また、乱数ジェネレーターが本当に強力であり、それらのビットを均一な方法で生成すると仮定します。128ビットの数値を推測するのは非常に難しく、かなり時間がかかる可能性があります。URLは事実上128ビットのキーで保護されています。

次に、誰かがこのURLをGoogle URL Shorterで共有したと仮定しましょう。今日、このサービスは、文字と数字で構成される10文字のIDを発行します。（26 + 10）^ 10〜= 3.6 * 10 ^ 15 <2 ^ 52-キー強度を128ビットから52ビットに効果的に半減しました。

ジェネレーターが他の考慮事項のためにスペース全体を使用しないという事実に加えて、ブルートフォースとサイドチャネル（ほとんどの場合、事前に割り当てられたランダムURLバッファー）を組み合わせた効果的な攻撃を仕掛けることができます。

元の記事：http : //arxiv.org/pdf/1604.02734v1.pdf記事を
要約したブログ投稿（著者による）：https : //freedom-to-tinker.com/blog/vitaly/gone-in- 6文字の短いURLを考慮した有害なクラウドサービス/