Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I have my master password stored in a text document on the desktop. This document does not have to be secure, because all lines of text are scrambled. It would be next to impossible for anyone to guess my password. When I launch or unlock Keepass, I open the document, select (highlight) the password, and drag it into the "Master Password" field. There's no need for typing nor copying/pasting and having you password end up on the clipboard. As far as I know, the password is never copied to the clipboard. It seems that entering your password this way protects you against key loggers. (OS: Windows XP Home)
Relying on "hiding" your master password is not good security. The calculation is quite simple - it is a dictionary search.
Assume you have hidden your password in 1,000 characters of text. Your password will be consecutive characters to make the copy work.
To try all the 1 character paswords is 1,000 attempts.
To try all the 2 character passwords is 999 attempts > call it 1,000
To try all the 3 character passswords is 998 attempts > call it 1,000
To try all the 20 character passwords is 980 attempts > call it 1,000
So, to try all the “1 to n” character passwords in “m” characters is less than "n x m" attempts. For up to a 10 character password hidden in 1,000 characters only requires less than 10,000 attempts, which is not secure enough for me.
I select from 26 lower case, 26 upper case, 10 digits and 30 other characters, or 92 characters – call it 90. Even a 2 character password has 90 possibilities for the first character, and 90 possibilities for the second character, or 8,100 possibilities, which is almost as secure as a 10 character password hidden in 1,000 characters of text.
A 10 character password has 90 x 90 x 90 x 90 … x 90 combinations, which is about 35,000,000,000,000,000,000 combinations. At one guess per second, it would take about 1,000 billion years to guess it. As the universe is only about 15 billion years old, I am hoping I don't have too much to worry about …
… and that I don't forget it, because there is no way I, or anyone else, is going to get in to KeePass if I do.
Thanks john-ha for your reply. I think I understand your explanation.
I want to show you the text file containing my master password: (around 750 characters)
Using Notepad++, I made this file so that it could be printed, and folded to fit in my wallet.
However, because of its small size, I felt it necessary to split my password into two segments. I'm thinking the probability of someone guessing my password is extremely low.
If you like to comment on this, please do.
OK - let me give it a shot.
Let me assume that you have a 10 character password. There are 9 ways you can do that
1 - 9
2 - 8
9 - 1
Case 1 is 750 for the "1" and 741 for the "9"
Case 2 is 749 for the "2" and 742 for the "8"
So all cases is 9 cases x 750 x 750 per case = 5,000,000 which at 1 per second is about 58 days. It's a lot better than before! 4 characters my way is 10x better at about 65,000,000.
Of course, you only would be better to have one set of 750 characters and choose both halves from it, rather than 350 characters for the first half of the password; and 350 characters for the second half of the password as that is much less secure.
If you must write it down, which you shouldn't, I would use 10 characters from the file, and then remember 3 or 4 characters which I would add to make a 13 or 14 digit password making sure the added 4 are not in that sequence in the file. But you might then just as well remember the 4 characters - on their own they are 10x stronger.
This is all a bit idealised. The key bit of the security is getting KeePass to store passwords like 7Qy%$sH}8!a8hl@# which you use for web sites which people might attack. Your PC is fairly safe at home and if you lose it, you can change all your passwords fairly quickly (as I had to when I lost my previously less secure password manager file).
And don't forget, you could have a file on a USB stick which must be plugged in for KeePass to open.
Adding multiple hashes is well worth while - a PC could otherwise try a million a second. How the hashes work (crudely) is that KeePass takes the password you type in and then does a process on it - hashes it - and then does it again and again and again many millions of times. KeePass then uses the result to decrypt the database. There is no easy way to bypass that.
Your method of using most of the characters from the file, then adding 3 or 4 more memorized characters to complete the password is definitely a more secure way.
I'm going to try your method of adding a few more memorized characters to form a new stronger password.
My reply to your comment about two halves of 350 characters… I treat all text as 10 lines of contiguous characters. The middle gap is only for folding a print out. My password is not necessarily stored as: first part in "left half"; second part in "right half", but split up on either the same line, or separate lines. Also, each part may or may not have the same number of characters or closest number of characters if the password has an odd length. Like you said, it's not recommended to write it down. But since my password is purposely long and complex, it's consequently hard to remember. This is why I store it on my computer and have a hard copy someplace safe. I prefer not to use a key file on a USB flash drive. Finally, I have Keepass remind me to change my password every so often.
Thanks john-ha for all your great input and practical advice.
I suggest you take a look at http://www.grc.com/haystack.htm for some guidance on how to pick a reasonably strong password. A 60bit password (e.g. AmUgd8olBH) would take about 3.5 months to crack with a computer able to test 1 x 10^11 guesses/second. An 80bit password (e.g. AmUgd8olBHke1d) would take 40,000 centuries at the same guess rate.
The following passwords all have about the same bit strength (60bits). 2 is is a longer password than 1, but is based on a reduced character set. No additional entropy is assigned to 3 & 4 because it is assumed that the attacker knows the hyphenation pattern. The longest example, number 4, is probably the easiest to remember and use.
Thanks wellread1 for the advice on choosing passwords. Yes, I visited http://www.grc.com/haystack.htm several times to test my passwords. This is a great website. Also, I found this website: http://rumkin.com/tools/password/passchk.php which tests the strength of any password. It calculates entropy based on a list of common dictionary words.
For your password examples, it shows:
1. AmUgd8olBH Length=10 Entropy: 49 bits
2. amugd8olbhdi Length=12 Entropy: 51.6 bits
3. amugd8-olbhdi Length=13 Entropy: 61.3 bits
4. amug-d8ol-bhdi Length=14 Entropy: 66.7 bits
The program written in Java is also available for downloading if you want to run it in your browser offline.
It's interesting that these two 12 character passwords have almost 10 points of entropy spread. (Based on Strength Test)
1. UO79iY8a3Sfn Entropy: 55.6 bits
2. 6qMtCnKxQwkZ Entropy: 64.8 bits
Notice that password #1 has four numerals, while password #2 has only one. In all your examples, you have only one numeral also. This tells me that having fewer numbers means a stronger password.
Password strength estimators make various assumptions that yield different password strengths for specific passwords that belong to the same password set. The entropy (H) of the set of random passwords of length L based on a character set of size N is H=L*log(N)/Log(2). See http://en.wikipedia.org/wiki/Password_strength. Since entropy estimators can only guess what N is when given a particular password, the values they provide will vary but should always be less than the value calculated with the formula above.
Example 1 is a member of the set of passwords of L=9 with a character set of size 62 (case sensitive alphanumerics). Applying the formula above yields an entropy of 53.6 for the set. As a practical matter the entropy is somewhat lower than this because one must reduce the set size by all the trivial 9 character passwords that are also members of this set. But to a first approximation we can ignmore this.
Applying the same formula to Example 2 (L=12 N=36) yields an Entropy (H) for the set of 62. Which within is the same as Example 1 withing the limits of the approximations. Example 2 also illustrates how length improves password strength faster than increasing character set size.
Examples 3 & 4 are good examples of how the assumptions of an estimator affect the result. These examples are based on exactly the same character set and length (of the variable portion) so they have the same entropy as 2. I assign 0 entropy contribution to the punctuation because I assume that the punctuation is always a "-" and always in the same spot, and that this syntax is public knowledge because the password generation profile is stored in clear text in the keepass.config.xml file. The estimator does not know that the syntax is publicly known so it assigned a high value to the introduction of special characters.
The point is that estimators estimate. An estimate of 55 is for all intents a purposes the same a 65.
As a rule of thumb chose passwords whose convenience and strength are appropriate to what you are trying to protect. Also use a password generation system where you can evaluate password strength at least semi-quantitatively. Generally passwords in the 40-80 bit range are adequate for most situations except to protect national security secrets. You can achieve this strength with random passwords (not human picked) of 8-16 characters based on lower-case letters and digits. If you are intent on making a password of a given length stronger then expand the character set size (at the expense of typing ease). Punctuational can be added to facilitate memorization but a conservative estimate of strength would not count it as part of the password.
Correction: Example 1 is L=10 N=62. Entropy of the set is 59.5.
That's interesting how a password strength estimator miscalculates entropy like you explained.
I was also unaware that the additional hyphenation in your password examples didn't increase entropy. Up to now, I believed adding any character or more to a given password would always make it stronger.
On a different subject, does anyone know how the “Quality” number is calculated in Keepass?
(Quality = a certain number of bits based on the password entered in the “Edit Entry” window.)