プライベートで推測できないURLは、パスワードベースの認証と同等ですか？
Web上でリソースを公開したい。このリソースを保護したい：特定の個人のみがアクセスできるようにするため。
なんらかのパスワードベースの認証を設定できます。たとえば、ファイルにサービスを提供する前に、（おそらくユーザーのバッキングデータベースに対して）正しい認証情報の着信リクエストをチェックするWebサーバーを介したリソースへのアクセスのみを許可できます。
または、プライベートURLを使用することもできます。つまり、https://example.com/23idcojj20ijf...のように、推測できないパスでリソースをホストするだけで、正確な文字列を知っている人へのアクセスを制限できます。
このリソースにアクセスしたい悪者の観点から、これらのアプローチは同等ですか？そうでない場合、それらの違いは何ですか？保守性に関しては、どちらか一方を実装する前に知っておくべきどちらのアプローチにも長所と短所はありますか？
プライベートURLは、URLのビットサイズが資格情報のビットサイズと同じであっても、資格情報による認証よりもいくらか弱いです。その理由は、URLがより簡単に「漏洩」する可能性があるためです。ブラウザにキャッシュされたり、サーバーにログオンしたりします。アウトバウンドリンクがある場合、プライベートURLが他のサイトのリファラーヘッダーに表示されることがあります。 （肩越しに見ている人にも見えます。）
漏洩した場合（偶然またはユーザーの不注意により）、公開され、Googleによってインデックスに登録される可能性があります。これにより、攻撃者はサイトへの漏洩したすべてのURLを簡単に検索できます。
このため、プライベートURLは通常、パスワードのリセットなどのワンショット操作にのみ使用され、通常、限られた時間だけアクティブになります。
情報セキュリティに関連するスレッドがあります： ランダムなURLはプロフィール写真を保護する安全な方法ですか ？ -1つの回答がこの話を共有しています： Dropboxは、Googleでの納税申告が終了した後、古い共有リンクを無効にします 。したがって、それは単なる理論上のリスクではありません。
注意：
多くの人が認証と「プライベート」URLを混同しているようです。また、信頼できるエンティティを介してリンクを送信することが2要素認証の試みであるという混乱もあるようです。明確にするために、一般にアクセス可能なリソースについて話していますが、推測するのは十分難しいものです
プライベートURLを使用する場合は、常に侵害される可能性があると想定する必要があります-このようなURLは、たとえ侵害されても、リソースが攻撃者に情報を漏らさないように設計する必要があります。
非公開/推測しにくいURLは、パスワードベースの認証と同等ではありません。本来、プライベートURLはまったくプライベートではありません。パブリックにアクセス可能なリソースです。 「プライベート」URLという用語は誤った名称であると思います。むしろ「あいまい」なURLです。
「プライベート」URLを使用できる場合もありますが、パスワード認証やキーベースの認証などの従来の認証方法よりも本質的に安全性が低くなります。
私がよく使用する「プライベート」URLの使用例は次のとおりです。
- パスワードリセットメール
- 証明書生成メール
- アカウント/メール確認メール
- 購入したコンテンツ（電子ブックなど）の配信
- フライトのチェックイン、搭乗券の印刷、従来の認証に加えてプライベートURLの使用など、その他のその他のこと
ここでの共通点は、ランダムURLは通常、1回限りの操作にのみ有効であることです。また、従来の認証とランダムURL 相互に排他的ではありません-実際、これらを互いに組み合わせて使用して、リソースを配信するときに追加のセキュリティを提供できます。
Robert Harveyが指摘したように、ランダム/プライベートURLを安全に使用する唯一の方法は、ページを動的に生成し、ユーザーが半認証済みと見なされるような方法でURLをユーザーに送信することです。これは、メール、SMSなどです。
ランダムに生成された/プライベートURLには通常、いくつかのプロパティがあります。
- 妥当な時間が経過すると有効期限が切れます
- これは使い捨てのURLである必要があります：IE最初にアクセスした後に期限切れになるはずです。
- 安全にユーザーを認証するために信頼する他のエンティティにユーザーの認証を延期する必要があります。 （リンクを電子メールまたはSMSなどで送信する）
- 最新のコンピューターでは、リソースを公開するAPIをレート制限するか、推測できないほど十分なエントロピーを持つURLエンドポイントを作成することにより、有効期限が切れる前の時間枠でURLをブルートフォースにすることは不可能であるべきです。
- ユーザーに関する情報を漏らしてはなりません。 IE：ページがパスワードをリセットする場合：ページは要求者のアカウント情報を表示するべきではありません。アリスがパスワードリセットリンクを要求し、ボブが何らかの方法でURLを推測した場合、ボブは自分のリセットしているパスワードを知る方法がありません。
- ユーザーに関する情報が漏洩する場合は、従来の認証に加えて使用する必要があります。たとえば、Cookieが設定されている場合、またはsession_idがまだ有効である場合、ページはユーザーが認証されたと見なします。
リソースが異なれば、必要なセキュリティレベルも異なります。たとえば、秘密のレシピを友達と共有したい場合は、ランダム/プライベートURLを使用して共有することもできます。ただし、そのリソースを使用して誰かのIDを盗んだり、他のサービスプロバイダーとのアカウントを侵害したりできる場合は、そのリソースへのアクセスを制限することについて、さらに注意を払う必要があります。
ほとんどすべての認証スキームは、秘密を知っていることを証明するために要約されます。秘密のパスワード、または秘密のURLを知っていることを証明することにより、いくつかのサービスに対して自分自身を認証します。
より高度なプロトコル（OAUTH、Kerberosなど）を使用すると、実際に送信秘密なしで秘密を知っていることを証明できます。 「推測できない」シークレットを推測する以外にも方法があるため、これは重要です。
私は自分と同じインターネットカフェに座って、「推測できない」URLを入力すると、WiFi接続を盗聴している可能性があります。その時点で、SSLを使用していない場合、またはSSL実装の最新の新しいバグを利用できる場合は、私もあなたの秘密を知っています。
このスレッドにはすでに良い答えがたくさんありますが、質問に直接対処するには：
このリソースにアクセスしたい悪者の観点から、これらのアプローチは同等ですか？そうでない場合、それらの違いは何ですか？
定義を確立させてください。 「認証」とは、身元の主張を証明するための資格情報の提供です。アクセス制御は通常、ユーザーの識別に基づいています。
シークレットURLは特定のユーザーにバインドされていません。他の人が指摘したように、プロキシのログファイル、またはgoogleによってインデックス化された検索リクエスト、または他の多くの方法でリークする可能性があります。
一方、パスワードは一意のユーザーアカウントに関連付けられています。これをリセットするか、ユーザーの自宅の場所、既知のIPアドレス、または他の任意の数のコントロールからの使用のみを許可することができます。
ユーザー名/パスワードを使用すると、アクセスをより詳細に制御できます。
アクセス制御により、アイデンティティー（サブジェクト）がリソース（オブジェクト）にアクセスできるようになります。 URLの例では、IDは「あらゆる手段でURLを取得した人」です。
可能であれば、ユーザー名/パスワードを入力してください。時間の経過とともに、URLはあらゆる種類の予期しない方法でリークします。
どこにも言及されていないもう1つの項目は、「推測」の調整です。ほとんどのパスワード認証システムでは、それ以上の認証試行がロックアウトされるか制限される前に、ユーザーのパスワードを推測する試行回数が制限されます。
URLスキームに対して「推測」を使用して同様のことを行うことはできますが、実装するのは少し難しいでしょう。 URL生成に認識できるパターンがある場合、誰かが「ランダム」URLスペースを通り抜けるように設定するのを止めるのは難しいかもしれません。
シークレットURLは、シークレットパスワードと同じくらい安全です。ただし、パスワードはURLに比べて簡単に秘密にしておくことができます。パスワードは秘密にしておく必要があることを誰もがそのプログラムと知っているためです。
たとえば、ブラウザは画面にパスワードを表示せず、許可を得たパスワードのみを保存し、そのパスワードストレージ（マスターパスワードによってロック解除された暗号化ストレージなど）を保護する手段を提供します。対照的に、常に画面にURLが表示され、リファラーヘッダーからURLがリークされる可能性があります。さらに保護することなく、それらを閲覧履歴に自動的に保存します。
同様に、HTTPプロキシは通常、パスワードをログに記録しませんが、URLは一般的にログに記録されます。
認証にURLを使用すると、URLを共有すると認証も共有されるため、アクセスを個別に取り消す（または記録する）ことが難しくなります。
そしてもちろん、秘密のURLは秘密のパスワードのすべての弱点を継承しています。特に、認証にパスワードを使用すると、そのパスワードがサーバーおよび通信を読み取ることができるすべてのユーザーに明らかになります。
まだ言及していなかったもう1つの側面-URL短縮機能があります。
最近の出版物（2016年4月）で、URL短縮サービスは、ランダムに生成された「使用できない」URLによって提供されるセキュリティの強化を完全に無効にすることが主張されました。短い方のサービスのURLスペースは、ランダムに生成されたURLよりもかなり小さくなります。つまり、短い方のサービスと共有されるそのような「安全な」URLは、予想よりも簡単に推測できます。
説明のために-ランダムなURLが128ビット長（つまり、GUID）であると仮定しましょう。また、乱数ジェネレーターが本当に強力で、これらのビットを均一な方法で生成するとします。 128ビットの数値を推測することは非常に難しく、かなりの時間がかかる可能性があります。URLは事実上128ビットのキーで保護されています。
次に、誰かがGoogleのURL短縮サービスでこのURLを共有したとします。今日、そのサービスは、文字と数字で構成される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-six-characters-short-urls-considered -harmful-for-cloud-services /