web-dev-qa-db-ja.com

YubiKeyチャレンジ/レスポンスは「ローカル」でどのように機能しますか？

私は最近、YubiKey NEOを入手しました（リストにあるすべてのうち2つのアクティブ化された第2要素認証方式しか使用できないことに少しがっかりしました）。

パスワードマネージャーでは、YubiKeyをサポートしています。Password Safeはオープンソースであり、ローカルで動作します。 YubiKey HMAC-SHA1チャレンジ-レスポンスを使用して認証するように構成できます。 （1）私のローカルPCと（2）YubiKeyの2つの関係者だけで安全なチャレンジ/レスポンスメカニズムを安全に作成する方法が混乱しています。 （ 関連ドキュメント ）

実際、マスターパスワードをYubiKeyに送信し、応答を取得し、それを使用してデータベースを復号化する利点は何ですか？現在、YubiKey応答は静的なパスワードであり、これはメモリ内で使用でき、マスターパスワードが漏洩する可能性のあるすべての場所です。

彼らは楽しみのためにそれを実装しましたか？または私はいくつかのポイントを逃していますか？

authenticationpassword-managementyubikey
11
Kousha

パスワードSafeのソースコードはオープンソースであるため、私がしたことを自由に行うことができます。

[〜＃〜] hmac [〜＃〜] は、キーとデータの2つの入力を取ります。 PSがubikeyを作成するのは、入力をデータとして受け取り、UbiKeyに送信することです。キーはUbiKey自体にあり、そこにとどまります。

したがって、イベントのシーケンスは次のとおりです。

  • パスフレーズを入力します。
  • ソフトウェアはそのパスフレーズをユビキーに送信します
  • UbiKeyは、入力としてパスフレーズと（内部に保存された）秘密鍵を使用してHMACを実行します。
  • 結果の値はアプリケーションに送り返され、データベースのロックを解除するために使用されます。

したがって、さまざまな暗号化要素が安全である限り、システムは依然として安全です。データベースのREALパスフレーズはHMAC操作の結果であり、HMACは2FAデバイスにある秘密鍵と独自のマスターパスワードで構成されます。あなたはあなたのコンピュータを通して入ります。

4
Stephane

いくつかのポイントがありません。

誰かがパスワードセーフデータベースファイルのコピーを盗んだ場合、ユビキーを物理的に所持していなければ、ロックを解除できません（パスフレーズがすでにわかっている場合でも）。

もちろん、攻撃者がシステムにアクセスしてメモリを読み取ることができるレベルのアクセス権を持っている場合、所有しているユビキーの数に関係なく、パスワードセーフデータベースのロックを解除するとすぐに失敗します。

YubikeyをPassword Safeにリンクすることの利点の1つは、Password Safeデータベースファイルをクラウドにバックアップすることについて少し気分が良くなることです。

3
Michael

基本的に、あなたが追加したのは、パスワードストレージへの昔ながらの物理的な「キー」のようなものです。

鍵屋が複製できない「鍵」。

既存のモデルでは、「パスフレーズ」が弱いリンクでした。誤ってそれを開示したり、誰かがショルダーサーフィンをしたり、キーストロークを記録したりした場合、または不審なWebサイトでそれを再利用した場合、攻撃者がパスワードストアに侵入する可能性があります。

新しいセットアップでは、攻撃者はこれらすべてに加えて、物理キーにアクセスできる必要があります。

2
curious_cat

ここでは、Yubikey with Password Safeの目的に関する元の質問は特に解決していませんが、私が行った実験は状況にある程度の光を当てることができると思います。

@Koushaが正しいことを確認しました。Yubikey応答は単に静的パスワードになります。

以下の説明に従って確認してください。 （私は Source ForgeのPassword Safe の投稿者を助けるために次のコードを提供したかったが、そうするためのアカウントを持っていない。）

秘密鍵からのパスワードセーフユビキー応答

ユビキー応答は、HMAC-SHA1とユビキーの秘密鍵を使用して簡単な方法で生成できますが、ヌル文字とオペレーティングシステムの非互換性のため、パスワードセーフユビキー応答の生成は少し複雑になります。 （基本的に、チャレンジの元のバイトごとにnullバイトを挿入する必要があります。）さらに、Yubikeyチャレンジは parsed を取得します。要するに、Linuxコンピューターでは、keyが秘密鍵を16進数形式で40 hexitsで保存し、messageがチャレンジを保存する場合、次のコマンドはPassword Safe Yubikeyレスポンスを返す必要があります。

printf $message |
  xxd -p | sed 's/../&00/g' |
  sed 's/00$//' | cut -c -63 | xxd -r -p |
  openssl dgst -sha1 -mac HMAC -macopt "hexkey:$key" -binary |
  xxd -p

可能であれば、一時的な秘密鍵をYubikeyに書き込み、検証に実際のパスワード以外のチャレンジを使用することをお勧めします。コンピューターが変数やその他の関連するセキュリティ問題をどのように保存するかについては、よく知りません。 （これについて誰かが知っていれば、私は喜んで学びます。）少なくとも、sttyを使用して、入力された文字を非表示にすることができます。次のスクリプトは、秘密鍵とチャレンジを表示せずに要求し、パスワードハッシュユビキー応答を出力します。

#!/usr/bin/env bash
stty -echo
printf "shared secret key (40 hexits): "
read HMACSHA1_key
if [ -z "$HMACSHA1_key" ]; then
    stty echo
    printf '\n    Empty input. Exiting.\n'
    exit 1
fi
if [ ${#HMACSHA1_key} -ne 40 ]; then
    stty echo
    printf '\n    Need exactly 40 characters. Exiting.\n'
    exit 1
fi
HMACSHA1_no_space="${HMACSHA1_key/ /}"
if [ ${#HMACSHA1_no_space} -ne 40 ]; then
    stty echo
    printf '\n    No spaces. Exiting.\n'
    exit 1
fi
HMACSHA1_key_mod_hex=$(printf "$HMACSHA1_key" | sed 's/\([0-9]\|[a-f]\|[A-F]\)//g')
if [ -n "${HMACSHA1_key_mod_hex}" ]; then
    stty echo
    printf '\n    Invalid characters: %s\n' "${HMACSHA1_key_mod_hex}"
    printf '\n    Only 0-9, a-f, A-F allowed. Exiting.\n'
    exit 1
fi
printf "\n"
printf "message/challenge: "
read HMACSHA1_value
if [ -z "$HMACSHA1_value" ]; then
    stty echo
    printf '\n    Empty input. Exiting.\n'
    exit 1
fi

printf $HMACSHA1_value |
  xxd -p | sed 's/../&00/g' |
  sed 's/00$//' | cut -c -63 | xxd -r -p |
  openssl dgst -sha1 -mac HMAC -macopt "hexkey:$HMACSHA1_key" -binary |
  xxd -p

上記のコマンドとスクリプトの移植性を証明できません。それらは、少なくとも私にとってはうまくいったものの縮小版です。

2
user121934

Koushaは、なぜ静的パスワードまたはチャレンジ/レスポンスのどちらを使用するのかを尋ねていると思います。 KeePassXCのこのページが役立つ場合があります。

https://ewen.mcneill.gen.nz/blog/entry/2017-07-23-keepassxc-with-yubikey-challenge-response/

KeePassXC YubiKeyのサポートは、YubiKey HMAC-SHA1チャレンジ/レスポンス認証を介して行われ、YubiKeyは共有シークレットとチャレンジトークンを混合してレスポンストークンを作成します。このメソッドは、KeePassXC YubiKeyサポートのために選択されました。たとえば、U2F-Universal 2nd Factorで必要になるような、カウンターを確実に追跡したり、単調に増加する値のギャップを処理したりする必要なく、確定的な応答を提供するためです。これは、セキュリティの低下（共有シークレットに依存しているため）とロバスト性（たとえば、YubiKeysカウンターがパスワードデータベースよりも新しい値に移動したためにパスワードデータベースから永久にロックアウトされないこと）と引き換えに、使用（たとえば、データベースのオープン時とクローズ時の両方でYubiKeyをアクティブ化する必要はありません。KeePassXCチケットチケット＃127には、カウンターを必要とする認証モードとのトレードオフに関するいくつかの役立つ議論が含まれています。理由）。

したがって、基本的にこれらのPWマネージャーがOTPを使用しない技術的な理由があり、これら2つのオプションは確かに安全性が低い代替手段です。 TOTPはHOTPからであるので、TOTPを使用しない理由は同様です。特に、終了時にキーを再入力する必要がある場合、TOTPの方が堅牢であるとされています。

静的パスワードとチャレンジ/レスポンスの違いを探してここに来ました。 Koushaが指摘したように、CRは基本的にSPこれはコンピューターへの内部アクセスで盗まれる可能性があります。Yubikeyのチャレンジパスワードを入力する必要があるという追加のレイヤーを追加すると思います、とにかく私はとにかくそれのためにそれのために別のパスワードを入力しなければならないでしょうKeePassXCを使用しています。

0
alchemy