web-dev-qa-db-ja.com

MFAソフトウェアトークンの重複を防止/禁止する/ユーザーIDを保証する

この特定の質問に関するスレッドを見つけることができなかったので、コミュニティに助けを求めようとしています。

現在、RSA RADIUS based 2FAを使用して企業の外部VPNユーザーを認証し、企業ネットワーク内のシステムを管理できるようにしています。このソリューションのサポート契約は管理から拡張されないため、代替案を探す必要があります。

LinOTPは、非常に多様なトークンタイプを提供し、ユーザーごとのサブスクリプションベースのライセンスモデルを備え、複数のUserIdResolversを管理できるため、これまでのところ目立ったお気に入りの1つです。レルム。

私たちが直面していることの1つは、外部ユーザーが個人化されたRSAトークンを同僚に渡して、同僚などに使用させているようです。休日には、それを禁止するユーザー同意書にサインさせてもらえます。

安価で簡単にTOTP/HOTPベースの2FAトークンを生成しているように見えるので、私にとって最大の欠点は、外部ユーザーが同僚からメールで受け取ったQRコード/シードを簡単に「共有」できることです。 RSAトークンは複製できないため、これは現在使用しているものよりも「危険」です。

LinOTPでもサポートされている他のソフトウェアトークンタイプは「mOTP」です。次にTOTPを使用する場合、ユーザーはランダムなシードを指定する必要があります+ PIN彼は私たちに何かを提供するのではなく提供します。一見すると、これは私たちが探していたものとまったく同じに見えました。残念ながら、同じシードとPINを指定するだけで、ユーザーBがユーザーAとして簡単に偽装できることにすぐに気づきました。そのため、一意性も与えられていませんが、少なくとも私の見解ではTO​​TP/HOTPより少し優れています。

MOTP Sourceforgeページでの検索中に、「オプションのUDIDセキュリティ拡張機能を使用したiPhone用のMobile-OTP」を実行できるiOSクライアントアプリケーションが見つかりました。ここでは、ランダムシードが一意のデバイス識別子に対してハッシュ化され、他の人になりすまし、このユーザーが本人であることを確認することが少なくとも「難しく」なると想定しています。

だから私は私の主な質問は次のとおりだと思います:

  • ソフトウェアトークンの重複を防止し、ソフトウェアトークンの「一意性」を保証する既知のメカニズムはありますか? (例:QRコードはX秒間のみ有効)
  • ログインしようとしているユーザーのIDを保証するための既知のメカニズムはありますか? (通常のユーザー名、パスワード、トークン以外)

この時点で言及するかもしれないこと:

  • 要塞ホストが検討され、現在も検討されていますが、このディスカッションの範囲であってはなりません
  • Cisco DUOも考慮に入れられましたが、少なくともLinOTPと比較するとかなり高価であることがわかりました(3 $/u/mと1 $/u/mの比較)。
2
alphachris

これをテクノロジーで解決することはできません。それは技術的な問題ではなく、ポリシーの問題です。

ハードウェアトークンを使用しても、同僚を呼び出してトークンを取得することはできます。バイオメトリクスで支援されたジェネレーターなどがあれば、共有する方法を見つけます。人事部門が介入し、この問題に強い姿勢をとることで解決します。

OTPトークンの共有は発砲可能な攻撃であることを誰もが覚えておいてください。誰かがこのルールに違反した場合は、彼を解雇し、その後、会社全体の会議を召喚して、OTP-Sharer氏がトークンの共有を捕まえて発砲したことを全員に伝えます。

3
ThoriumBR

@ThoriumBRが指摘したように、結局のところ、ユーザーはいつでもハードウェアを交換できます。だから問題は、彼らが交換するハードウェアはおそらく交換しない-おそらく彼らのスマートフォンだ。しかし、スマートフォンでは、すでに述べたように、第2要素を構成する暗号化キーがコピーされる可能性があるという問題があります。数年前に 詳細なまとめ を書きました。

最善の方法は、実際にスマートフォンに独自の秘密鍵を生成させることです。前述のUUIDは良いアプローチです。

免責事項:私はソリューションの開発に深く関与しています。私の会社は実際にこのオープンソースソリューションのサービスを提供しています。だからこれに気分を害したなら、読むのをやめてください!

約6年前にLinOTPのフォークとして始まった privacyIDEA をご覧になるとよいでしょう。したがって、リゾルバーのようなおなじみの側面に気付くかもしれませんが、それは Github でまったく異なる方法で開発されました。

privacyIDEAは2つのトークンタイプを提供します。

2ステップ登録

HOTPおよびTOTPスマートフォントークンにより、privacyIDEAは「2step-enrollment」を追加します。スマートフォンは共有シークレットのクライアント部分を生成し、privacyIDEAサーバーに転送されます。結果のシークレットは、サーバー部分とクライアント部分から計算されます。スマートフォンごとに独自のクライアントパーツが生成されるため、トークンをコピーする簡単な方法はありません。 (ただし、ユーザーはサーバーとクライアントの部分を書き留めて、結果のシークレットを手動で計算することができますが、これもポリシーの問題です) オンラインドキュメント で詳細を確認できます。 AndroidiOS の2つのステップをサポートするアプリがあります。

プッシュトークン

他の可能性はOTPをしないことです。 OTPは手動で入力する必要があるため、第2要素として使用できるのは対称鍵のみです。手動の第2要素入力を回避する場合は、非対称キーを使用することもできます。プッシュトークンを使用すると、これが可能になります。これは、登録時にプッシュトークンがスマートフォン上で一意のキーペアを生成し、秘密キーがスマートフォンを離れないためです。ただし、ユーザーは引き続きスマートフォンを交換できます(ほとんどありません)。また、プッシュ機能にはいくつかのインフラストラクチャ上の課題があります。ですから、最初に2ステップを確認することをお勧めします。

プッシュの詳細については、 ここ を参照してください。

これが概念的な観点からも役立つことを願っています。

0
cornelinux