Security: Key Generation
From what I read in your documentation:
The database is fully encrypted with this randomly generated key.
I'm not so much concern about the 128 bit length of the key than I am about it's randomness...
It's a known fact that computer aren't random machine; at the end of the day, it's gonna be a pseudo-random generated key.
Most PRNGs have a hard time having a full coverage with maintaining a good distribution.
This could definitively lead to weakness while attempting to hack the database.
Would it be possible to have more detail regarding the generation of this random key?
--
[edit]
Regarding this 128b key, changing the master password will just reencrypt the key, the 128b key itself doesn't change, correct?
Assuming I'm willing to wait for the whole database to be re-encrypted with a new key, is there a way to request a regeneration of this key?
[/edit]
Thanks,
Kandjar
Instead it is encrypted with a random 128-bit number that was picked when 1Password first created your Agile keychain. That 128-bit number is your true decryption key. This key, in turn, is encrypted using your master password.
The database is fully encrypted with this randomly generated key.
I'm not so much concern about the 128 bit length of the key than I am about it's randomness...
It's a known fact that computer aren't random machine; at the end of the day, it's gonna be a pseudo-random generated key.
Most PRNGs have a hard time having a full coverage with maintaining a good distribution.
This could definitively lead to weakness while attempting to hack the database.
Would it be possible to have more detail regarding the generation of this random key?
--
[edit]
Regarding this 128b key, changing the master password will just reencrypt the key, the 128b key itself doesn't change, correct?
Assuming I'm willing to wait for the whole database to be re-encrypted with a new key, is there a way to request a regeneration of this key?
[/edit]
Thanks,
Kandjar
This discussion has been closed.
Comments
Team Member
You are absolutely correct that getting good random numbers for these keys is crucial. I remember back in the 1990s when Netscape produced its own secure web server. It turned out that even when they were using 128 bit encryption, their random number generator was only pulling from a 32-bit space. This was a big embarrassment for them when it was discoverd and helped sway people toward using what later became Apache.
But enough history. On the Mac and iOS we use Apple's SecRandomCopyBytes(), which in turn gets its entropy from /dev/urandom. SecRandomCopyBytes is designed to provide cryptographically appropriate random numbers.
I'll have to consult with Stefan about how exactly this is done on Windows, but we most certainly are using cryptographically appropriate sources of randomness.
You are correct. This design choice is similar to what you find in other tools that separate the key from the password such as SSH private keys or GPG/PGP keys.
If you really want to force the creation of a new key, you should export your 1Password data to a 1Password Interchange Format file (1pif). Be careful how you handle that 1pif as it is not encrypted at all. Then create a new 1Password data file and import the 1pif. It is only when you create a new data file that a new key will be generated.
Thanks. These are great questions. Please ask more!
Cheers,
-j
I see; so potentially, assuming that you own a Mac (or an iPad for example) and a Windows version of iPassword;
it may be better to initially create the database using one OS or the other.
One may have a slightly better random key than the other.
Well, I doubt it will matter much; but if you could investigate on what's happening on the window side, that would be really nice.
I think that's fair enough; it's not a process I would want to do daily or weekly.
So that solution is a perfectly fine and I agree; the fact that the intermediate file is unencrypted requires that much more precaution.
I will have to do the intermediate file process anyway since I'm seriously considering migrating from another password manager (Spb'yuck! Oops, let's stay polite, that's not fair for them) to 1password.
Team Member
I know from Stefan that we are using well trusted cryptographic libraries on Windows as well. I'm just not sure exactly what they are and what our calls to the system are. I'm an old Unix guy, so it is easier for me to answer questions about OS X and I've looked at Apple's Security tools fairly closely. (Indeed the suite of tools in OS X 10.6 have been validated as FIPS 140-2 compliant).
I defer to Stefan about the Windows end of things, but I know that everyone one of us follow expert recommendations in exactly how to use cryptographic routines. We have always understood the importance of good choices for randomness when creating keys.
I'll ask him to respond.
Again, I'll have to defer to others about Windows. On the Mac you can use "Secure Empty Trash" or srm from the command line. I'm sure that there are plenty of utilities to properly delete files on Windows, and I suspect that you know more than I do in that respect.
I'm glad we are winning your approval. I know that you haven't been happy with every bit of our design decisions, but I am very gratified by your consideration.
On Mac OS X you can securely erase files by putting them in the Trash and then using Secure Empty Trash (or use srm from the command line). I'm not familiar with what tools are available on Windows, but I'm sure that there are plenty.
Cheers,
-j
On Windows, we use a combination of CoCreateGUID and a PRNG. To avoid PRNG predictability, we reposition the PRNG frequently using the time of day as a pseudo random seed. The PRNG isn't perfect (none of them are), but the algorithm used to generate GUIDs is extremely complex.
Team Member
Lol!!!! Love it!
How about:
int getRandomNumber() { return numberOfWindowsBlueScreenSinceNoon(); }Not as random I guess
It's a matter of time elapsed * big numbers
I do find it "interesting" that 1P/Mac uses standard OS X resources to obtain FIPS 140-2 caliber "random" keys whereas 1P/Win shuns Microsoft's cryptographic services (some of which are FIPS 140-2 certified) in favor of what strikes me as more of a roll-your-own method.
—Ben F
Team Member
Thanks!
We certainly didn't roll our on on Windows, but we do rely on a set of libraries that work on all of the Windows versions we support. So that excludes relying directly on tools built into Vista and Windows 7. If we could get people away from Windows XP, that would make life easier.
There is actually some news on the Mac side of things. CDSA and direct support for OpenSSL dynamic libraries are being deprecated and replaced with the Common Crypto framework in OS X and iOS. This is good news for us for a number of reasons. Common Crypto is much easier to deal with and it means that we can share more of our code between Mac OS X and iOS. Also, Apple really seems to be working to get FIPS certification for this moving much faster than it did with CDSA.
Cheers,
-j
Is there a way for Windows users to force creation of a new master encryption key? Last time I checked, 1P/Win could only import logins.
I'm mostly a Mac person, but I'm also something of a 1P evangelist, and I have friends and family whom I have turned on to 1Password who don't have Macs. I'll usually start them out with a "baby" master password and encourage them to beef it up later if they take to the program. But it seems to me that the benefit of changing the master password is marginal at best, because an attacker who can get hold of an older copy of the keychain (user backups, 1Password backups, recovered Dropbox versions, etc.) and break the old master password would obtain the master encryption key. Very few users would have the know-how to hunt down and purge those old backups.
If I had my druthers, users changing a master password would be confronted with a prompt asking whether they also wish to change the master encryption key(s). A help box could explain the costs (time) and benefits (security) of changing the master key(s) to a keychain whose security may have been compromised. This would address two concerns:
Whadda ya say?
—Ben F
p.s. There also needs to be a way for the 1Password app to signal the browser extensions to "flush their caches" when a master password changes. It is both confusing and frustrating when a browser extension won't accept the new password, and it's a bit frightening to see the old password work. Where is that old data? How long will it be there? How can I be sure that it's gone?
Such an approach might improve the correspondence between the protection which 1Password actually provides and the protection which users might intuitively expect based on a simpler mental model of how the program works.
In addition, it ought to be possible for 1Password to update older entries "in the background" after a master password change, so that eventually all of the user's data is encrypted with the new master key and the old master key can be retired. I imagine that there could be pros and cons to this approach, but it could be a better option than the potentially-confusing "Change encryption key too?" prompt that I suggested in my previous post.
Team Member
I don't want to go into detail about all of your suggestions. They contain ideas that we've explored. We know that we need to do something, but getting something that works extremely reliably is a challenge. We need a system that won't leave people locked out of their data if there is a power failure or disk crash or system failure during the process. This is one of the reasons why we try to avoid re-encrypting everything during a master password change.
These are all things that we are working on, but it's still a bit too early to tell what our solution will be for our new data format.
Cheers,
-j
The primary system (Dropbox users may have additional options) for not locking people out of their data if there is a system crash, or for recovering data after changing, and then forgetting, the master password, is File > Restore Data File From Backup …
Encouraging folks to burn all of their backups immediately after changing a master password carries clear risks.
But let's set aside the problem of how best to retroactively protect data that was entered into 1Password with a weak master password. My main focus is on a user who wants to increase security by "beefing up" the master password before entering stuff like credit cards and banking logins. If you generate a new master encryption key whenever the user changes the master password, and you simultaneously "expire" the old master encryption key (so that it becomes a decrypt-only key, analogous to an expired or revoked PGP subkey), wouldn't new and edited keychain data be safe even if an attacker obtains, and cracks, an older version of the keychain? And wouldn't that align fairly well with a naïve expectation of the protection afforded by changing the master password?
—Ben F