サービスへのアクセスを取得する手段として公開アプリケーションのパスワードとして GUID を使用する場合、このセキュリティは隠蔽によるものですか?
明白な答えは「はい」だと思いますが、GUID を推測する可能性は非常に低いため、セキュリティのレベルは非常に高いように思えます。
アップデート
GUID はデバイスに保存され、プラグインされると、SSL 接続を介して GUID を介して送信されます。
たぶん、GUID を生成し、GUID で AES 128 ビット暗号化を実行し、その値をデバイスに保存できますか?
私の意見では、答えはノーです。
パスワードを新しく作成した GUID に設定した場合、それはかなり安全なパスワードです: 8 文字以上で、数字、文字、特殊文字などが含まれます。
もちろん、GUID では、 、 、 の位置は既知'{'で'}'あり'-'、すべての文字が大文字であるという事実も知られています。そのため、GUID を使用していることを誰も知らない限り、パスワードを解読するのは難しくなります。攻撃者は、自分が GUID を探していることを知ると、ブルート フォース攻撃に必要な労力が軽減されます。その観点からすると、目立たないことによるセキュリティです。
それでも、次の GUID を考慮して{91626979-FB5C-439A-BBA3-7715ED647504}ください。攻撃者が特殊文字の位置を知っていると仮定すると、攻撃者の問題は文字列を見つけることになります91626979FB5C439ABBA37715ED647504。32 文字のパスワードをブルート フォースしますか? 誰かが実用的な量子コンピューターを発明した場合、それはあなたの生涯でのみ起こります.
これは、あいまいさではなく、非常に長いパスワードを使用することによるセキュリティです。
編集: Denis Hennessy の回答を読んだ後、回答を修正する必要があります。GUID に実際にこの情報 (具体的には MAC アドレス) が復号可能な形式で含まれている場合、攻撃者はキースペースを大幅に縮小できます。その場合、それは間違いなくあいまいさによるセキュリティになります。読んでください：かなり安全ではありません。
そしてもちろん、MusiGenesis の言うとおりです。(疑似) ランダム パスワードを生成するツールはたくさんあります。私の推奨事項は、それらのいずれかに固執することです。
実際、GUID をパスワードとして使用することはお勧めできません (同等の長さの完全にランダムなパスワードを考え出す場合と比較して)。長いように見えますが、実際にはわずか 16 バイトであり、これには通常、ユーザーの MAC アドレス、日付/時刻、および小さめのランダム要素が含まれます。ハッカーがユーザーの MAC アドレスを特定できる場合、ハッカーが生成する可能性のある GUID を推測するのは比較的簡単です。
GUID が (HTTP Auth などを介して) 送信されていることを確認できる場合、それがどれほど推測可能かは問題ではありません。
Flickr などの一部のサイトでは、API キーと秘密キーを採用しています。秘密鍵は、MD5 ハッシュを介して署名を作成するために使用されます。サーバーは秘密鍵を使用して同じ署名を計算し、その方法で認証を行います。シークレットがネットワークを通過する必要はありません。
GUID は、意図的な衝突ではなく、偶発的な衝突を防ぐためのものです。つまり、GUID を推測することはほとんどありませんが、本当に推測したいかどうかを調べるのは必ずしも難しいわけではありません。
最初は無条件で「はい」と答える準備ができていましたが、それはすべてのパスワードベースの認証が曖昧さによるセキュリティであることを意味するのかどうかを考えさせられました. 厳密な意味では、ある意味でそうだと思います。
ただし、パスワードでログインしているユーザーがいて、その GUID をどこにも投稿していないと仮定すると、ユーザーが持っている安全性の低いパスワード、または sysadmin パスワードでさえ、リスクを上回ると思います。
他の方法では保護されていない管理ページへの URL にハードコードされた GUID が含まれていると言った場合、答えは間違いなくイエスです。
一般に、デバイスにキーを埋め込むか、認証中にキーを送信すると、セキュリティの脆弱性が発生します。キーが GUID であるかパスワードであるかは問題ではありません。暗号化の唯一の違いはキーの長さとランダム性にあります。いずれの場合も、攻撃者は製品のメモリをスキャンするか、認証プロセスを傍受できます。
これはいくつかの方法で軽減できますが、それぞれの方法は最終的に鍵の不明瞭性 (または保護レベル) を高めることにつながります。
保管する前にキーを暗号化します。もちろん、暗号化キーを保存する必要がありますが、間接的なレベルが導入されています。
キーを保存するのではなく、計算します。攻撃者は、単にキーを検索するのではなく、アルゴリズムをリバース エンジニアリングする必要があります。
他の人が提案したように、キー自体ではなく、認証中にキーのハッシュを送信するか、チャレンジレスポンス認証を使用します。これらの方法はどちらも、キーが平文で送信されるのを防ぎます。SSLもこれを実現しますが、適切な実装を維持するためにユーザーに依存しています。セキュリティを制御できなくなりました。
いつものように、セキュリティに取り組むときはいつでも、さまざまなトレードオフを考慮する必要があります。攻撃の可能性は？攻撃が成功した場合のリスクは? 開発、サポート、および使いやすさの観点から、セキュリティのコストはいくらですか?
通常、適切なソリューションとは、これらの各要因に十分に対処する妥協案です。幸運を！
脆弱なパスワードよりも優れているという他のほとんどの人に同意しますが、この種の認証を目的とした証明書交換のような強力なものを使用することをお勧めします (デバイスがサポートしている場合)。
また、何らかの相互認証を行うようにします (つまり、デバイスにサーバーの SSL 証明書を検証させて、それが期待どおりのものであることを確認します)。デバイスを取得してシステムに接続し、そこから GUID を読み取り、それをターゲット システムに再生するのは簡単です。
GUID をパスワードとして使用しないことをお勧めします (後で変更する最初のパスワードを除く)。覚えておくために書き留める必要があるパスワードは、本質的に安全ではありません。それは書き留められます。
編集：「本質的に」は不正確です。コメントで会話を見る
確かにそれはあいまいさによるセキュリティです。しかし、これは悪いことですか？「強力な」パスワードは、あいまいさによるセキュリティです。認証システムが安全であることは期待できますが、結局のところ、パスワードが簡単に推測できれば、認証システムがどれほど優れていても意味がありません。したがって、「強力」で「あいまいな」パスワードを作成して、推測しにくくします。
それがパスワードであるという点で、あいまいさによるセキュリティにすぎません。おそらく、GUID をパスワードとして使用する際の主な問題は、文字と数字のみが使用されていることです。ただし、GUID はほとんどのパスワードに比べてかなり長いです。徹底的な検索に対して安全なパスワードはありません。それは明らかです。単純に、GUID がある種のタイムスタンプに基づいている場合とない場合があるため、または MAC アドレスが多少無関係である可能性があるためです。
それを推測する確率と他の何かを推測する確率の違いはごくわずかです。一部の GUID は、他の GUID よりも「簡単に」(読み取り: より速く) 壊れる場合があります。長いほど良いです。ただし、アルファベットの多様性もより優れています。しかし、繰り返しになりますが、徹底的な検索によりすべてが明らかになります。
少なくとも、パスワードとして「password」を使用するよりはましです。
GUID が強力なパスワードと見なされるとは思いません。Guid.NewGuid() と同じくらい簡単に使用できる強力なパスワード ジェネレーターがたくさんあります。
それは本当にあなたが何をしたいかによって異なります。GUID をパスワードとして使用すること自体は、あいまいさによるセキュリティではありません (ただし、GUID には合計 128 個の推測可能なビットが多数含まれているという事実に注意してください: タイムスタンプがあり、それを生成したマシンの MAC アドレスを含むものもあります)。しかし、本当の問題は、そのパスワードをどのように保管し、サーバーに伝達するかです。
エンド ユーザーに表示されることのないサーバー側のスクリプトにパスワードが格納されている場合、大きなリスクはありません。ユーザーが自分のマシンにダウンロードするアプリケーションにパスワードが埋め込まれている場合、アプリケーションでパスワードを難読化する必要があり、それを安全に行う方法はありません。デバッガーを実行すると、ユーザーは常にパスワードにアクセスできます。