Windows App protection of account key
I read the following articles and this raised a couple of questions
https://blog.elcomsoft.com/2017/08/one-password-to-rule-them-all-breaking-into-1password-keepass-lastpass-and-dashlane/
https://blog.elcomsoft.com/2017/08/attacking-the-1password-master-password-follow-up/
1.
Is the article a little misleading - have they assumed that a single password is needed to gain access to the vault?
Have they taken into account the existence of two inputs into the decryption process - the account key and master password? If they had to try and brute force both of these in unison that would be very difficult as effectively they would have to try every password with every account key combination. In reality they would probably just be trying to brute force the result of this combination.
As their process is an offline brute force attack on the local copy of the vault have they captured the account key and therefore only, I know this is not easy, need to brute force the master password? Have they captured the local obfuscated account key and un-obfuscated it?
2.
The 1password windows app stores the account key locally, I understand why and also why the account key is mainly to protect the encrypted blobs on your server, and I read somewhere that this local account key is obfuscated, rather than securely encrypted. Is this the case? and if so why don't you encrypt it locally with an AB private key in the application itself? That way only the local vault and encrypted account key could be obtained rather than the local vault and obfuscated account key - would this then mean that an offline attack would be a lot harder as they have two deal with two encryption inputs rather than just the one?
Obviously when it comes to the web browser storing the account key that could be a different story.
3.
Did this admission that less iterations accidentally crept into a release of 1password appear on the 1password blog?
https://blog.elcomsoft.com/2017/08/one-password-to-rule-them-all-breaking-into-1password-keepass-lastpass-and-dashlane/#comment-42086
Is there any user action needed to ensure that the correct, 100,000, iterations are being used on their vault - as far as I was aware this would require some form of re-encryption either of the vault or the vaults encrypted master key?
On the plus side the 3000 password attempts per second on 1password 100,000 iteration and 6200 on 1password dropbox 60,000 iterations compares well to other password managers :-) Also they do not currently support brute forcing the windows desktop app local vault 1Password10.sqlite or Mac B5.sqlite - yet.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
@fryrpc: I'm going to take my best shot at your questions since there are fewer of us around on the weekend, but please please ask follow-ups if I don't adequately address one of your queries. I'm a security enthusiast, but not a guru, so I'm sure others will be able to jump in with additional thoughts and detail where needed.
Have they taken into account the existence of two inputs into the decryption process - the account key and master password?
The benchmarks Elcomsoft ran were with standalone vault data, so the Secret/Account key was not taken into account. Of course, there's no need to in this instance as standalone vaults don't use a Secret Key. It's tough to say what effect the Secret Key may have were Elcomsoft to similarly test 1Password membership data. They mention the tool does not yet support the local data format we use on Mac and Windows for membership data. Beyond the local data format, however, the testing process to try to crack data from our server would necessarily be different than that used on Dropbox data thanks to two-secret key derivation. You can learn a bit more about that in this blog post. :chuffed:
I read somewhere that this local account key is obfuscated, rather than securely encrypted. Is this the case? and if so why don't you encrypt it locally with an AB private key in the application itself? That way only the local vault and encrypted account key could be obtained rather than the local vault and obfuscated account key - would this then mean that an offline attack would be a lot harder as they have two deal with two encryption inputs rather than just the one?
Here, I'll pull from our Security Design White Paper (PDF):
Once a client is enrolled, it will store a copy of the Secret Key on the local device. Because the Secret Key must be used to derive the user's MUK it cannot be encrypted by the same MUK. Although lightly obfuscated, the Secret Key is stored on the local device unencrypted. Where possible, the Secret Key will be put into something provided by your system for storing authentication secrets. For 1Password for Mac and 1Password for iOS that will use the iOS and OS X keychains respectively. But when 1Password has been used from a web browser, the Secret Key is stored in the browser's local data store, a fairly exposed location.
Recall that the Secret Key is designed so that an attacker will not be in a position to launch an offline password guessing attack if she captures data from the server alone. It does succeed at that goal, but in the current version, our ability to protect the Secret Key on your computer is limited by the tools available to that particular client.
In light of this, someone simulating brute force attack on local data might assume they already know your Secret Key to emulate a worst-case real world scenario. This is one of many reasons you'll often see us fussing folks about wanting to use a shorter Master Password. Despite the protection your Secret Key provides, using a strong Master Password is still extremely important. It's arguably more than 50% of what's protecting your data. Of course, all of this is assuming your system has been compromised in the first place. Anything you to do to keep your local device safe also serves to protect your 1Password data by keeping the baddies away from your device in the first place. :+1:
Is there any user action needed to ensure that the correct, 100,000, iterations are being used on their vault - as far as I was aware this would require some form of re-encryption either of the vault or the vaults encrypted master key?
This is handled by the app without any action by you, so you'll just need to make sure 1Password is up-to-date and you'll be all set. I'm not sure if this change is deployed just yet, but I've reached out to the developers to check and my advice would remain the same either way. Just update as needed and you'll be all set when the fix goes live (if it's not already). I'll poke back in here with something more definite on status once I know. :chuffed:
0 -
@fryrpc just wanted to chime in about iterations count - it's coming with next beta of 1Password for Windows. Upon every unlock app measures time and increases iterations as required. 100,000 is not the number you should rely on, instead app adjusts iterations to ensure that unlock takes roughly 1 second. On the devices I use what used to be enough few years ago with 10,000 iterations requires 300,000-500,000 today. A note to hackers: don't waste time on trying to force iteration count down, we took care to never go to low :p
While app takes care about your iterations count, please make sure you have a good master password.
0 -
So in summary:
1.
They have not yet tested the newer offline local cache vault format - OK
2.
Local security key is obfuscated only - Could 1password encrypt this locally with an AB secret key contained in the application that way one piece of the decryption puzzle is not left easily accessible?
3.
Iteration issue in 1password for Windows is still outstanding pending beta and then final release and the answer in the meantime to this "mistake" is to increase your master password length. When is this expected to be released into live production? Should an update to the windows app be released in the interim that uses 100,000 iterations, or whatever your enforceable lowest limit is going to be?0 -
@fryrpc: Based upon what I know, we aren't able to encrypt the Secret Key on Windows, but I'm probably not the best person to answer that one. Tomorrow is a holiday in the U.S. and Canada so I may not get to poke someone right away, but I'll be sure to ask so I can get you some details about it. :+1:
As for the iterations fix, Sergey's point is less that you need to increase the length of your Master Password, but moreso that an extra character in your Master Password does far more for your security than increasing the number of iterations ever could. If you're already using a strong Master Password, you're already more protected today than someone using a weaker Master Password with more iterations. Of course, you should always use the longest and most complex Master Password you're comfortable with. It will always serve to make your account and your vault more secure, no matter what. :chuffed:
0
