証明書ベースの認証とユーザー名およびパスワード認証
ユーザー名とパスワードによる認証よりも証明書ベースの認証の利点と欠点は何ですか？一部は知っていますが、構造化された詳細な回答をいただければ幸いです。
[〜＃〜]更新[〜＃〜]
私は同様に、彼らがどんな攻撃を受けやすいかを知ることに興味があります。これまでのところブルートフォースについて言及していますが、証明書については何も言及されていません... XSRFについてはどうですか？証明書は有効期間が短く、管理ポリシーが変更を要求する前にパスワードが長く存続する間、失効できることが期待されています...
1。ユーザーは愚かです
パスワードはユーザーの記憶に収まるもので、ユーザーが選択します。認証はユーザーの物理的なアイデンティティremotelyの検証に関するものであるため（検証者の観点から）、ユーザーの動作は必然的にプロセスに関与しますが、パスワードはセキュリティの処理で最も悪名高く、ユーザーの一部、つまり彼の脳。ユーザーは単にパスワードエントロピーが何であるかを理解していません。私はそれらを非難していません。これは技術的な主題であり、専門分野であり、すぐに現実的に「常識」になることはできません。一方、物理的なトークンのセキュリティははるかに「具体的な」ものであり、平均的なユーザーは非常に上手になります。進化論者たちは、過去100万年の間、人間はそのために積極的に選択されてきたと言います。なぜなら、フリントツールを握ることができなかった人々は、子孫を持つために十分に生き残っていなかったからです。
ハリウッドの映画は、ユーザーがパスワードを考える方法のモデルとして使用できます。これは、ユーザーが映画に行くためでもあります。常に、Arch Enemyは短いパスワードを持ち、それを自慢するのが大好きで、可能な場合はいつでも手掛かりを配布します。そして、常に、イギリスの秘密のエージェントは、女王のお気に入りの花壇の下に植えられた核融合爆弾を停止するために、時間内にパスワードを推測します。映画は歪んだ誇張された現実を映し出しますが、それでも平均的なユーザーが操作する精神的なベースラインを表しています。攻撃者よりも「機知に富んでいる」ことによってセキュリティを提供するものとしてパスワードを想定しています。そして、常に、ほとんどがそれに失敗します。
「パスワードの安全度」は必須のルール（少なくとも8文字、少なくとも2桁、少なくとも1つの大文字と1つの小文字...）によって多少改善できますが、これらのルールはユーザーの負担と見なされ、場合によっては生来の自由に耐えられない制約-ユーザーは、創造的な創造性をもって、ルールに対抗するようになります。多くの場合、パスワード強化ルールはそのようにして裏目に出ます。
一方、ユーザー証明書はストレージシステムを意味し、そのシステムがユーザーの家や車のキーを持って持ち運ぶ物理デバイスである場合、セキュリティは、平均的なユーザーがセキュリティをどの程度適切に管理しているかに部分的に依存します。物理的なオブジェクト、そして彼らは通常それで良い仕事をします。少なくとも、適切なパスワードを選択する場合よりは優れています。これが証明書の大きな利点です。
2。証明書は非対称暗号を使用します
「非対称」とは、役割を分離することです。パスワードを使用すると、パスワードを確認する人はいつか、パスワードまたはパスワードと同等のデータを知っています（まあ、それは [〜＃〜] pake [〜＃〜]）の場合は完全には当てはまりません プロトコル）。ユーザー証明書の場合、証明書は、物理的なIDと暗号化された公開鍵の間のリンクを保証する証明機関によって発行されます。ベリファイアはdistinctエンティティである可能性があり、そのようなリンクを検証し、それを使用してユーザーを認証することができますなしで機能を取得するユーザーを偽装します。
簡単に言えば、これが証明書のポイントです。ユーザーのデジタルID（つまり、物理的なIDからコンピューターの世界へのマッピングを行うエンティティ）を定義するユーザーを、 ユーザーを認証するユーザー。
これは、否認防止をもたらすデジタル署名への道を開きます。これは特に、オンライン顧客から金融注文を受け取る銀行に関心があります。彼らは顧客を認証する必要があります（これは私たちが話しているお金であり、非常に深刻な問題です）が、彼らは注文の説得力のある痕跡を持っていることを望みます-の意味で：裁判官は確信しているでしょう。単なる認証では、銀行は適切な顧客と話していることをある程度保証しますが、第三者にそれを証明することはできません。銀行は偽の接続トランスクリプトを作成する可能性があるため、銀行自体に囲まれていると主張する顧客に対しては無害です。ユーザーが証明書を持っている場合でも、デジタル署名はすぐには利用できません。ただし、ユーザーが認証に証明書を使用できる場合、ほとんどのハードワークは完了しています。
また、パスワードは本質的にフィッシング攻撃に対して脆弱ですが、ユーザー証明書はそうではありません。厳密には非対称性のため：証明書の使用には、ピアに秘密データを明らかにすることは決してないため、サーバーになりすました攻撃者は、そのように価値のあるものを知ることができません。
3。証明書は複雑です
ユーザー証明書の導入は複雑であり、費用がかかります。
証明書の発行と管理は、あらゆるPKIベンダーがあなたに伝えることができる（そして実際、私はあなたに伝えます）ように、ワームの完全な缶です。特に失効管理。 PKIは、約5％の暗号と95％の手順です。それはできますが、安くはありません。
ユーザー証明書は、ユーザーが「排他的アクセス」の下で何らかの方法で秘密鍵を保存することを意味します。これは、ソフトウェア（既存のオペレーティングシステムやWebブラウザが実行できる）、または専用のハードウェアを使用して行われますが、どちらのソリューションにも独自のユーザビリティの問題があります。発生する2つの主な問題は、1）ユーザーがキーを失うこと、2）攻撃者がキーのコピーを取得することです。ソフトウェアストレージはキーの損失を（故障したハードディスクのなすがままに）考えられる問題にし、複数のシステム（デスクトップコンピューターやiPadなど）間でキーを共有すると、攻撃者に対して十分に保護されない可能性が高い手動操作が含まれます。ハードウェアトークンは、デバイスドライバーの厄介なビジネス全体を意味します。
ユーザー証明書は、クライアント側での比較的複雑な数学的操作を意味します。これは貧血のPentium IIでも問題にはなりませんが、一般的なWebサイト内でスラップされた一部のJavascriptからの証明書を使用することはできません。証明書は、クライアント側のソフトウェアからの積極的な協力を必要とします。このソフトウェアは、人間工学的に言えば、最適ではない傾向があります。平均的なユーザーは通常、WebサイトへのHTTPS接続にクライアント証明書を使用する方法を学ぶことができますが、時々発生する警告ポップアップを無視する方法を学ぶことを犠牲にして、一部の攻撃（攻撃者が試みるアクティブな攻撃など）に対してはるかに脆弱になります。独自の偽のサーバー証明書をフィードします）。
一方、パスワードベースの認証は、どこにでも簡単に統合できます。もちろん、失敗することも同様に簡単です。しかし、少なくともそれは必ずしもいくつかの非圧縮性の追加コストを伴いません。
まとめ
ユーザー証明書では、パスワードでは実行できない役割を分離できます。それらは、実装と展開の問題の大部分を追加することを犠牲にして行われます。ただし、パスワードは人間の心に収まるため安価であり、本質的にセキュリティが低くなります。パスワードに関するセキュリティの問題は、一部の策略（PAKEプロトコルを含む）によって緩和され、とりわけ、問題が発生した場合にユーザーを非難することによって緩和されます（平均的なユーザーは安全なパスワードを選択できないことを知っていますが、事故が発生すると、まだ彼のせいだ-それは銀行がそれを行う方法です）。
ユーザー名/パスワード
Pro：導入が簡単-いくつかのコードと安全なデータストアを使用するだけです。セキュリティポリシーに応じて、パスワードを自動生成するか、新しいユーザーにパスワードの作成を強制できます。
Pro：管理が簡単-パスワードのリセットは（一部のセキュリティポリシーの場合）自動化ツールで実行できます
Con：セキュリティを確保するために、パスワードは早期かつ頻繁にリセットする必要があります。ユーザーがパスワードを忘れたり変更したりしないことは、セキュリティ上のリスクか、使いやすさのどちらかです。
Con：良いパスワードは覚えにくい場合があり、ユーザーがパスワードを再利用したり書き留めたりする問題につながります。
Con：パスワードデータストアは弱点です。侵入者がパスワードストアを取得すると、マザーロードを取得します。
Con：パスワード送信のすべての部分が露出につながる可能性があります-使いやすさのためにパスワードをローカルに保存するWebサイト、平文で送信する内部サーバーコンポーネント、パスワードを平文で保存するCOTS製品のログファイル。秘密が送信の一部であるので、あなたはあなたの最も弱いリンクと同じくらい強いだけです-露出を防ぐために真剣な努力を要し、要件はユーザーとシステム開発者の両方にあります。
証明書：
Pro：シークレットの送信は必要ありません。秘密鍵の証明には秘密情報が含まれていません-あらゆる種類のストレージ/送信の弱点を軽減します。
Pro：複数のアプリケーションにわたるステータスの集中管理システムを可能にする信頼できる当事者（CA）によって発行されます。証明書が不良になると、取り消される可能性があります。共有IDが使用されていない限り、パスワードブレークインの修正は、システムごとに個別に行う必要があります。
プロ：否認防止のケースがより強力です-ほとんどのパスワードシステムでは、アカウントの作成前にユーザーが最初に認証される方法はかなり弱く、パスワードリセットメカニズムは、もっともらしい拒否の別の要因を提供する可能性があります。証明書の発行には多くの形式があるため、ユーザーが本人でないと言うのははるかに困難です。警告-あなたはまだあなたのCAの発行ポリシーと同じくらい良いです。
Pro：認証だけでなく、完全性と機密性も提供できます。
Con：依然としてパスワード/ PINが必要です-次に、ほとんどすべての秘密鍵ペアのストレージメカニズムがPINでロック解除されます。スマートカードには、総当たりを防止するための改ざん防止機能とロックアウト機能を持たせることができますが、カードがドッキングされているコンピューターの横にある付箋にユーザーがPINを書いたという事実は修正されません。時々パスワードの問題は、PKIを使用すると小規模で再現されます。
Con：インフラストラクチャの複雑さ-PKIのセットアップは簡単な作業ではなく、一般に導入と保守の両方で非常にコストがかかるため、大規模で高価なシステムでのみ使用できます。
Con：証明書ステータスのレポートと更新は簡単ではありません-破損したユーザー資格情報を取り消すことは、インフラストラクチャのサイズと複雑さのために面倒です。通常、CAは、OCSPサーバー内でプロビジョニングされる場合とされない場合があるCRLを生成します。次に、すべてのアプリケーションがすべてのログインでCRLまたはOCSPステータスを確認する必要があります。これにより、PKI資格が侵害されたと報告されてから、その資格に依存するシステムが実際にアクセスを拒否し始めるまでの間に、システムにさまざまな時間遅延が生じます。ステータス更新の速度は加速できますが、システムの複雑さのコストが高くなります。
その他の注意点：
証明書は有効期間が短く、管理ポリシーが変更を要求する前にパスワードがより長く存続する間、取り消すことができると予想されます...
私はその前提に同意しません。私が取り組んだ、パスワードとPKIの両方をサポートするシステムでは、パスワード更新の要件に関するポリシーは、証明書の発行に関するポリシーよりもはるかに短いです。失効は別のワームの缶です-それは秘密鍵の侵害の可能性が低いイベントのためです。秘密鍵データはシステムを介して送信されないため、このデータが公開されるリスクは、通常、パスワードが公開されるリスクよりもはるかに低いと想定されています。実用上、パスワードの有効期間は短いと考えられています。
私は同様に、彼らがどのような攻撃を受けやすいかを知りたいと思っています。これまでのところブルートフォースについて言及していますが、証明書については何も言及されていません... XSRFについてはどうですか？
ここでリンゴとオレンジを混ぜています。ブルートフォースは、どちらのタイプの認証クレデンシャルに対しても実行可能な攻撃となる可能性がありますが、XSRFは、認証メカニズムに関係なく実行可能な潜在的なタイプのアプリケーションに対する攻撃です。ユーザー名/パスワードが何らかのテキストインターフェイスで入力されるため、そのインターフェイスでクロスサイトスクリプティングが発生する可能性があることを意味しない限り。
一般的に（公式用語が欠けていることをお詫びします-通常、典型的な攻撃用語を調べますが、時間が足りません）：
ブルートフォース-平均的なパスワードのキースペースは非対称キーのキースペースよりも小さいので、パスワードはブルートフォースの方が簡単です。ただし、証明書の十分に小さいキーサイズはブルートフォースにも対応しており、ブロードフォース攻撃キーへの能力は、キーサイズの増加に伴ってラットレースを強制するCPU機能とともに増大します。
知識に基づく推測-RSAアルゴリズムには弱いキーがあるため、ほとんどの非対称キーアルゴリズムでは、キースペースを合理的な推測セットに狭めるのは簡単であり、ほとんどの非対称キーアルゴリズムではそれほど明白ではないため、暗号がどれほど大きいかによってある程度依存します。攻撃者はそうです。
ソーシャルエンジニアリング-どちらの方法でも実行できますが、証明書がハードウェアに保存されている場合は、ユーザーのPINだけでなく、キーを保存するハードウェアも制御する必要があります。
内部攻撃-システム内部から資格情報を取得し、それを使用して正当なユーザーをエミュレートするかどうかは、状況によって異なります。パスワードが安全に保管されていない場合、これはパスワードベースのシステムでより実行可能です。ただし、CAを制御できる場合は、正当な証明書を自分で発行することができ、アクセスの制御方法によって異なります。
途中の男-依存する-途中でパスワードを傍受する暗号化メカニズムによってパスワードが暗号化されていない場合、途中の男がパスワードを傍受する可能性があります。これはSSL/TLSで実行できます。ただし、PKIの使用方法によっては、途中の男がPKI転送の一部を傍受することもできます。 nonceやタイムスタンプのないPKI署名は、中間の男による複製攻撃にさらされています-メッセージがタイムリーであるか一意であるかを知る方法がない限り、傍受したメッセージを再送信できます。
- ユーザー名とパスワード
- それはあなたが知っていることのすべてです。あなたはサービスで認証するために秘密のコードワードを与えています。
- これは、ストリームで傍受された場合に使用できることを意味します。暗号化を使用すると、その可能性は低くなりますが、依然として可能です。誰かが途中で男になりパスワードを取得したり、認証を受けたコンピュータを乗っ取ったりする可能性があります。
- ユーザー名とパスワードは、いつでもどのコンピューターでも使用できます。これは、セキュリティが重要な場合は悪いことであり、アクセシビリティが重要な場合は良いことです。銀行にとっては...これは悪いです。 Facebookの場合、それは本当に重要ではありません。
- 証明書
- 証明書はもう少し洗練されています。サーバーはデータをクライアントに送信し、クライアントはデータに署名して送信します。これは、サーバーがいつでも秘密鍵を知らないことを意味します。そのため、サーバーの真ん中または乗っ取りが原因でアクセスできるようになりますが、キーはありません。
- 証明書は使いにくいものです。それらを思い出せず、盗まれる可能性があります。
最高のシステムは組み合わせです。鍵にパスワードを設定して、2要素認証を行います。知っているもの（パスワード）と持っているもの（キー）。ただし、セキュリティの層が増えるほど、痛みが大きくなります。これは、すべてのセキュリティにおける大きなトレードオフです。
スティーブンのポイントに同意します。問題は通常、一方の比較ではないため、調査するのは難しい質問です。両方が存在し、通常互いに評価されていない理由を理解する良い方法は、使用方法に焦点を当てることです。証明書はマシンレベルのキーストアに関連付けられているため、事前に計画された特定のマシン間のマシン間認証に最適です。私たちはモバイルであり、事前に予測するのが難しい方法で多数のシステムから認証する傾向があるため、パスワードは人々に非常に適しています。したがって、事前に設計されたハードウェアベースの認証では証明書が一般的であり、パスワードはモバイルウェットウェアベースの認証に適しています。スマートカードは、モバイルヒューマンに証明書ベースの認証を追加し、プロセスに別の要素を追加する優れた方法です。
多くの場合、パスワードはブルートフォースで攻撃されたり、ソーシャルエンジニアリングされたりする可能性があります。これは、その所有者が記憶する必要があるため、多くの場合、秘密鍵よりもはるかに簡単なためです。
（RSAの場合は2048または4096ビットの）十分な強度の秘密鍵をブルートフォースすることはできません。公開鍵ベースの認証を必要とするシステムに対して認証を行う唯一の方法は、最初に他のコンピューターへのアクセスを取得して秘密鍵を取得することです。これにより、攻撃がさらに複雑になります。個人にパスワードを明かしてもらうためのソーシャルエンジニアリングは役に立ちません。パスワードは、秘密鍵を解読するだけで、ターゲットシステムへの直接のアクセスを許可するわけではありません。秘密鍵とパスワードを一緒に公開するソーシャルエンジニアリングは、はるかに困難になる可能性があります。
さらに、パスワードはユーザーのマシンからユーザーが使用したいシステムにネットワークを介して送信されます。秘密鍵は、クリアフォーマットでも暗号化フォーマットでも、ネットワークを介して送信されません。むしろ公開鍵だけが送信されます。
Webページで証明書とパスワードの両方を使用できることを忘れているようです。証明書を持ったユーザーが来るとドアが開きます。また、証明書がない場合は、いつものように名前とパスワードでログインする必要があります。
このようにして、関心のあるユーザーは証明書を取得し、他のすべてのユーザーは古い方法で証明書を取得します。
オプションを追加したい-ワンタイムパスワードデバイス。証明書とパスワードの長所と短所について他の人が言ったことに同意します-OTPデバイスは動作するためにいくつかのバックエンドコンポーネントを必要としますが、私の意見では多くの手間をかけずに統合できます（Active Directoryは少し異なりますが、その他システムはそれほど難しくありません）。
パスワードとワンタイムパスワードの組み合わせは非常にうまく機能します。パスワード付きのYubikey（USBまたはNFC接続が必要））または表示されたコードフォブのようなより簡単なソリューションを使用できます。
どちらのオプションも、Linuxベースの操作に簡単に追加できます。 Active Directoryで実行する場合は、コードを処理してすべてのADサーバーにインストールするためのソフトウェアを購入する必要があります。次に、ユーザーはパスワードフィールドの先頭にOTPを入力し、次に通常のパスワードを入力します。それのためにあなた自身のモジュールを開発することは可能ですが、私が見たものからコストが法外です。