5 ms·

I recently switched to 1password instead of bitwarden precisely because 1password combines a long secret key along with your password to decrypt the vault. If i

I recently switched to 1password instead of bitwarden precisely because 1password combines a long secret key along with your password to decrypt the vault. If im understanding the article correctly, it seems like that approach avoids the main pitfalls of using PBKDF2.

sebk 4y ago
Other than more convenient UX, with Bitwarden or any other password manager you can just generate an equivalently entropic "secret key" that you store in a file and that you manually concatenate with the password when unlocking your vault. The threat model that 1Password describes for its secret key is essentially the same as what you'd get handrolling it: https://1passwordstatic.com/files/security/1password-white-paper.pdf https://1passwordstatic.com/files/security/1password-white-p... (it should be assumed that an attacker who gains read access to the user’s disk will acquire the Secret Key) KeepassXC and derivatives also support Yubikey's proprietary hmac-challenge, wich generates the functional equivalent of the secret key off-OS, and FIDO2 devices with the hmac-secret extension provide that same functionally but with SHA256 instead of SHA1 for the HMAC. I don't know any mainstream password managers that support it yet.
jonathanstrange 4y ago
Attackers who can obtain the password database to crack it offline can also obtain the long secret, can't they?
- nogridbag 4y ago
  Assuming there's an association that links my encrypted vault to my identity, they would have to break into my home and either find a printout of the secret key or much more likely simply steal phone and computer.
the_mitsuhiko 4y ago
I'm pretty sure 1password uses PBKDF2 to get to the decryption key of the vault.
- leokennis 4y ago
  Aa I understand it, 1Password uses your master password alongside a "secret key": https://support.1password.com/secret-key-security/ https://support.1password.com/secret-key-security/ > Your 1Password account password protects your data on your devices. Someone who has access to your devices or backups won’t be able to unlock 1Password without your account password, which only you know. > Your Secret Key protects your data off your devices. Someone who attempts a brute-force attack on our servers won’t be able to decrypt your data without your Secret Key, which we never have. If I understand this article correctly (and there is a reasonable chance I don't) the PBKDF2 iterations they do on top are little more than security theater.
adrian_b 4y ago
The main pitfall of PBKDF2 has nothing to do with that. The main pitfall of PBKDF2 or similar key derivation functions is that the only way to increase the work for the attacker is to increase the number of iterations, but that is limited by how many seconds the user is willing to wait for the decryption. The user may be willing to wait less than 10 seconds until PBKDF2 is executed on a slow laptop, while the attacker may be willing to wait 10 days, while using a multi-FPGA or multi-GPU system that might run PBKDF2 ten thousand times or even one million times faster. The attacker might try 10^9 ... 10^12 passwords (30 ... 40 bits), so a weak password will probably be found. Any decent password-based encryption method uses the password only to encrypt a secret full-strength key or to make a one-way derivation of the secret key from a random value. These two ways are equivalent. If the encrypted secret key or the random value from which the secret key is generated is not stored or sent together with the encrypted text and the attacker does not have it, then the attacker must break AES or whatever cipher is used and the key derivation function does not matter. When the attacker also has the encrypted secret key or the random value from which the secret key is generated, then they will try the easier way of breaking the key derivation function, instead of breaking the main cipher. If a password manager mixes an additional internal secret value in the key derivation, there are two cases, either that secret value can be saved externally for backup or it cannot be saved. If you have an external copy, then there is a way for the attacker to get it, so it provides no additional security. Any measure usable to protect the additional secret value could be also used to protect the password-encrypted secret key without an additional secret value, with the same effect. If there is no external copy, a bricked password manager leads to the catastrophic loss of all encrypted data. The risk of suffering such a data loss is far more serious than the risk of being attacked by a strong adversary.
- dale_glass 4y ago
  It's not really a pitfall as much as it not being magic. It does the job it was designed to do. It can't magically make "password" a good password. I think the greatest strength here is large password databases -- if somebody nabs a million logins to Paypal or similar, then such measures slow down the speed at which accounts can be broken into, give time for the service provider to notice and react, makes it very unlikely for people with good passwords to be compromised, and probably completely protects nuts like myself that use fully random 16 character passwords. Yeah, some accounts will still be broken into, but it'll take more work and reduce the damage.
nmadden 4y ago
Right. I believe Apple also do something similar with their built-in password manager: the password/PIN alone is not enough to decrypt, you also need access to a per-device secret key. FWIW, I am the article author and I use 1Password myself, partly for this reason, and also because their online security blurb actually contains technical details (https://support.1password.com/1password-security/ https://support.1password.com/1password-security/). Like the fact that they are using AES-GCM-256 rather than just "AES-256".
- sebk 4y ago
  This was my understanding too, but I believe the wording in their (Apple's) whitepaper is unclear now. See this comment chain on HN: https://news.ycombinator.com/item?id=33900004 https://news.ycombinator.com/item?id=33900004 , with the relevant bit being If two-factor authentication is enabled for the user’s account, the device passcode is used to recover an escrowed keychain. (https://support.apple.com/guide/security/secure-icloud-keychain-recovery-secdeb202947/web https://support.apple.com/guide/security/secure-icloud-keych...). I think there must be some misunderstanding here because I can't believe a PIN would be stored by itself, hashed or not, off-device. Interesting that 1Password switched to GCM. They were previously using CBC with E-t-M HMAC-SHA256.

sebk 4y ago

Other than more convenient UX, with Bitwarden or any other password manager you can just generate an equivalently entropic "secret key" that you store in a file and that you manually concatenate with the password when unlocking your vault. The threat model that 1Password describes for its secret key is essentially the same as what you'd get handrolling it: https://1passwordstatic.com/files/security/1password-white-paper.pdf https://1passwordstatic.com/files/security/1password-white-p... (it should be assumed that an attacker who gains read access to the user’s disk will acquire the Secret Key) KeepassXC and derivatives also support Yubikey's proprietary hmac-challenge, wich generates the functional equivalent of the secret key off-OS, and FIDO2 devices with the hmac-secret extension provide that same functionally but with SHA256 instead of SHA1 for the HMAC. I don't know any mainstream password managers that support it yet.

jonathanstrange 4y ago

Attackers who can obtain the password database to crack it offline can also obtain the long secret, can't they?

nogridbag 4y ago
Assuming there's an association that links my encrypted vault to my identity, they would have to break into my home and either find a printout of the secret key or much more likely simply steal phone and computer.

the_mitsuhiko 4y ago

I'm pretty sure 1password uses PBKDF2 to get to the decryption key of the vault.

leokennis 4y ago
Aa I understand it, 1Password uses your master password alongside a "secret key": https://support.1password.com/secret-key-security/ https://support.1password.com/secret-key-security/ > Your 1Password account password protects your data on your devices. Someone who has access to your devices or backups won’t be able to unlock 1Password without your account password, which only you know. > Your Secret Key protects your data off your devices. Someone who attempts a brute-force attack on our servers won’t be able to decrypt your data without your Secret Key, which we never have. If I understand this article correctly (and there is a reasonable chance I don't) the PBKDF2 iterations they do on top are little more than security theater.

adrian_b 4y ago

The main pitfall of PBKDF2 has nothing to do with that. The main pitfall of PBKDF2 or similar key derivation functions is that the only way to increase the work for the attacker is to increase the number of iterations, but that is limited by how many seconds the user is willing to wait for the decryption. The user may be willing to wait less than 10 seconds until PBKDF2 is executed on a slow laptop, while the attacker may be willing to wait 10 days, while using a multi-FPGA or multi-GPU system that might run PBKDF2 ten thousand times or even one million times faster. The attacker might try 10^9 ... 10^12 passwords (30 ... 40 bits), so a weak password will probably be found. Any decent password-based encryption method uses the password only to encrypt a secret full-strength key or to make a one-way derivation of the secret key from a random value. These two ways are equivalent. If the encrypted secret key or the random value from which the secret key is generated is not stored or sent together with the encrypted text and the attacker does not have it, then the attacker must break AES or whatever cipher is used and the key derivation function does not matter. When the attacker also has the encrypted secret key or the random value from which the secret key is generated, then they will try the easier way of breaking the key derivation function, instead of breaking the main cipher. If a password manager mixes an additional internal secret value in the key derivation, there are two cases, either that secret value can be saved externally for backup or it cannot be saved. If you have an external copy, then there is a way for the attacker to get it, so it provides no additional security. Any measure usable to protect the additional secret value could be also used to protect the password-encrypted secret key without an additional secret value, with the same effect. If there is no external copy, a bricked password manager leads to the catastrophic loss of all encrypted data. The risk of suffering such a data loss is far more serious than the risk of being attacked by a strong adversary.

dale_glass 4y ago
It's not really a pitfall as much as it not being magic. It does the job it was designed to do. It can't magically make "password" a good password. I think the greatest strength here is large password databases -- if somebody nabs a million logins to Paypal or similar, then such measures slow down the speed at which accounts can be broken into, give time for the service provider to notice and react, makes it very unlikely for people with good passwords to be compromised, and probably completely protects nuts like myself that use fully random 16 character passwords. Yeah, some accounts will still be broken into, but it'll take more work and reduce the damage.

nmadden 4y ago

Right. I believe Apple also do something similar with their built-in password manager: the password/PIN alone is not enough to decrypt, you also need access to a per-device secret key. FWIW, I am the article author and I use 1Password myself, partly for this reason, and also because their online security blurb actually contains technical details (https://support.1password.com/1password-security/ https://support.1password.com/1password-security/). Like the fact that they are using AES-GCM-256 rather than just "AES-256".

sebk 4y ago
This was my understanding too, but I believe the wording in their (Apple's) whitepaper is unclear now. See this comment chain on HN: https://news.ycombinator.com/item?id=33900004 https://news.ycombinator.com/item?id=33900004 , with the relevant bit being If two-factor authentication is enabled for the user’s account, the device passcode is used to recover an escrowed keychain. (https://support.apple.com/guide/security/secure-icloud-keychain-recovery-secdeb202947/web https://support.apple.com/guide/security/secure-icloud-keych...). I think there must be some misunderstanding here because I can't believe a PIN would be stored by itself, hashed or not, off-device. Interesting that 1Password switched to GCM. They were previously using CBC with E-t-M HMAC-SHA256.