web-dev-qa-db-ja.com

LastPassによるクライアント側ソルトの使用

LastPassチームは [〜＃〜] faq [〜＃〜] で次のように述べています：

ログインにソルトハッシュを使用していますか？

はい、最初にクライアント側でユーザー名を使用してLastPassパスワードの「ソルト」を実行します（コンピューターでは、LastPassはパスワードを取得しません）。次にサーバー側で、データベースから2番目の256ビットのランダムな16進ハッシュソルトを取得します。それを使用して、データベースに格納されているものと比較されるソルトハッシュを作成します。

部分「クライアント側でユーザー名を使用してLastPassパスワードの「ソルト」を最初に実行する」が文字通りの意味であるかどうかを誰かが知っていますか？

この答え によると、これはほとんどの場合そうです：

これらの詳細から、LastPass復号化キーは次のように計算されると思います。

DK = PBKDF2(HMAC-SHA256, password, email, <user set>, 256)

これは疑似コードのように見えるので、PBKDF2の3番目の引数はソルトであるとしか推測できません。

PBKDF2を介してemailを実行してソルトとしてより適切にすることは正しいことだと私は理解しています。これはもちろん、猫が自分のしっぽを追うところです。そもそもそもそもメールを塩として使用することを強いられたのでしょう。

encryptionsaltpbkdf2lastpass
8
Oliver Weichhold

私は "LastPassパスワードのソルトをクライアント側のユーザー名で最初に行います"と解釈します：クライアント側でPBKDF2関数を実行して、パスワードとユーザー名（メール）をソルトとして含めます：

client_encryption_key = PBKDF2(HMAC-SHA256, password, salt_email, 5000, 256) // 5000 rounds, 256 bits
auth_key = sha256(client_encryption_key) // this is what is sent to the server for authentication
server_key = PBKDF2(HMAC-SHA256, auth_key, salt_random, 100000, 256) // this is what is stored in the auth db

クライアントキーはデータの暗号化/復号化にも使用されることに注意してください。

電子メールに関するNHのコメントに答えるには、おそらく塩は適切ではない可能性があります。塩は通常、秘密とは見なされません。それらの目的は、2つの同一のパスワードに対して生成されるキーが異なることを確認することです。

3
HTLee