Password Quality on Preview tab
A lightweight and easy-to-use password manager
Brought to you by:
dreichl
Menu
▾
▴
#2100 Password Quality on Preview tab
Hi,
A very simple request, in the password generator window on the last preview tab please add the Quality strength of the randomly created passwords in bits as it is shown for the selected password on the Add entry window. Anyone looking for a minimum strength of bits for a password will find it very useful.
I sincerely thank everyone on this project for all their efforts.
Best Regards,
Niranjan D. Pandit
Related
The password quality of all the generated passwords in a particular preview list is the same because the passwords were generated using the same password generation profile. The KeePass estimated quality of individual passwords selected from a preview list will vary because the estimator is estimating the quality based the single password sample without any knowledge of the generation method. The sample to sample variation is just uncertainty in the estimation method and should not form a basis for selecting or rejecting a given generated password.
Last edit: wellread1 2016-02-18
Hi,
Thanks for the quick response.
Ok, if that is the case, may be we can do away with the estimated quality
altogether. Or may be we can standardize the quality bits shown based on
the generation settings.
When the quality of the password differs from password to password, it is
very natural for an end user to want a higher quality password.
To be frank, I myself keep on generating many passwords till I am not happy
with the highest possible quality bits. :-D I hope you understand.
Anyways, No rush, no issues even if it remains as it is. I will simply
ignore the quality bits.
Thanks & Regards,
Niranjan D. Pandit
On Thu, Feb 18, 2016 at 10:20 AM, wellread1 wellread1@users.sf.net wrote:
Related
Feature Requests:
#2100Estimates of password quality are useful as long as one realizes the limitations. Password quality is an effort to provide a numerical value that indicates the amount of work (password guesses) required to have a high probability of guessing the correct one, assuming the attacker knows everything about the password except the actual password.
The KeePass estimator has to make this estimate without knowing anything about how the password was created. However, since you know how you generated your password, you can calculate a conservative password quality by applying the equations in Password Strength article to the genuinely random variable portions of your password and treating the constant or low variable portions as making no contribution to password quality.
To be frank, that is a bad idea. All you are doing is unnecessarily restricting the pool of possible passwords by applying a filter that any attacker might apply because they know that that is something people do, filter generated passwords based on a rating rather than simply accepting the random value from the generator. It is like throwing out all the even numbers between 1 and 10, as well as 1 and 5, because you think that will make it harder for someone to guess which number your accepted from a random number generator that generates random numbers between 1 and 10.
Last edit: wellread1 2016-02-18
OTOH, it is possible (tho very unlikely) that a highly random password generator may in fact generate a very poor password such as "nnNnnnmnnn". The password quality evaluation is an attempt to quantify the likelihood that password could be guessed using heuristics. Heuristic methods assume that a password is generated using the techniques that most humans would use on their own. The fact that a password was actually generated using more sophisticated techniques is irrelevant to the success of an attack on it, so while eliminating passwords with poor heuristics does restrict the password pool, it injects a measure of "anti-humanity" into the process, restricting the password pool to those less crackable, and therefore, seems like a good idea to me.
Last edit: wellread1 2016-02-19
So I feel the more important question to answer is, what is the effective /
more right method of password quality estimation?
In my humble layman opinion, if brute forcing a password is gonna take a
couple of more million years due to variations and the positioning of
characters and the length then its a better password than others.
Any thoughts?
On Feb 19, 2016 9:12 AM, "wellread1" wellread1@users.sf.net wrote:
Related
Feature Requests:
#2100This assumes that brute force is the main method that the Bad Guys are going to use to try to get your password - but usually brute force is the last resort for the Bad Guys, especially the majority of Bad Guys that only care about getting a password as opposed to your password specifically. Therefore, the best password selection strategy would be one that ensures that methods other than brute force won't be effective.
Nonsense. If every possible password in the set is equiprobable then there is no search strategy better than any other (except to not repeat guesses). Once you are selecting passwords from a equiprobable set the only consideration relevant to resistance to attack is: Is the set of possible passwords large enough that it is impractical to search a significant fraction of it?
Note: By the time the password set size is large enough to be impractical to search a significant fraction of it, the percentage of "trivial" passwords contained in the set will be miniscule and it is safe to discard those...if you ever, ever, ever encounter one.
Last edit: wellread1 2016-02-19
This is simply not going to happen in the real world. Yes, it's extremely unlikely that a good randomizer will come up with "abcdefghijkl", but when it happens (and if it's truly a mathematically good randomizer, it will eventually happen), the human running the randomizer will reject it.
Its called a random password generator. Lotteries do it all the time, why do you think that KeePass can't?
Lotteries also close down betting on certain number combinations when the number of bets on them threaten to exceed the state's ability to pay out on them if the ping pong balls were to come out that way.
You keep looking at these things as closed systems, but they're a bit like Schrödinger's cat - the only outcome that's unwaveringly accepted by all observers is the one that's never observed by anyone.
I'm not sure exactly what you mean by this, but IMO the only thing that KeePass can't do is anticipate the behavior of the persons running it and/or trying to break into it.
Whatever.
The probability of generatiing a specific password (e.g. a chosen "trival" password) and a specific different password (e.g. a chosen "non-trivial" password) are the same, they are equiprobable. The probablity of each event is exceeding small. For an 80bit password set the probability for either event is 10-24.
The number of "trivial" passwords in a set of generated passwords whose profile does not place large restrictions on the nature of the password is exceeding small compared to the number of "non-trivial" passwords. It is hard to quantitate the proportion becasue "trivial" is a subjective measure, but I invite you to examine for yourself a few hundred, or thousand, or million generated passwords using a simple profile such as a{12} to see how many exhibit characteristics that would render them likely candidates for inclusion in a password dictionary used by attackers.
I don't claim that throwing out a tiny fraction of passwords that are "trivial" has a significant impact on password strength. This thread is about large scale filtering e.g. "I myself keep on generating many passwords till I am not[sic] happy with the highest possible quality bits".
Last edit: wellread1 2016-02-19
I'm sorry, somehow I didn't see this particular reply until now. (I think there must be some bugs in the way SF links to deep chains of replies.) What you say here makes sense; rejecting entire groups of passwords based only on a single calculation attempting to quantify their quality is indeed a poor password selection strategy - and makes one's passwords less rather than more secure, because it means that one's pool of potential passwords is being sliced and diced into smaller (and therefore more discoverable) chunks.
See https://sourceforge.net/p/keepass/discussion/329221/thread/b4a3623e/#f8e6 for an example of how I approach password generation. The first step is to decide on the target Password Quality.
One could add but not substitue fixed characters to a generated password without adversely impacting strength e.g.:
The password estimator will likely underestimate the strength of a password generated using the recommendations in the post I referenced. If a few fixed charaters are added, the password estimator will overestimate the strength of the password.
The password profile generation process needs to be done only a few times. Establish a few profiles that work for most cases, and you will only rarely need to consider alternates.
I've added an item in the FAQ:
https://keepass.info/help/kb/faq.html#pwgenhq
Furthermore, on the 'Preview'/'Generate' tab page of the password generator dialog, the average estimated quality of the generated passwords is now displayed.
Here's the latest development snapshot for testing:
https://keepass.info/filepool/KeePass_250113.zip
Thanks and best regards,
Dominik
The average estimated password quality on the password tab is a nice addition. However, it looks like the average quality estimate is based on a fairly small sample of generated passwords (perhaps the 30 generated passwords?). There is a a fair bit of run to run variability apparent in this estimate that might be reduced significantly by increasing the sample size to between ~100 to 1000 passwords. In a test using the Generate Password List..., a set of 1000 twenty character lowercase alphanumeric passwords didn't consume much time. The sample size could be reported next to quality average if anyone cares. I didn't check how the generation time scales with password length or complexity.
Also there might be some benefit to increasing the number of preview passwords modestly. For example one could quickly scan a list of 100-200 passwords to get an idea of how many "trivial" passwords are generated (usually minuscule). I think some users would appreciate being able to quickly confirm that the rate of generated "trivial" passwords by a given generated password profile is <1%.
Good ideas, thanks!
I've now implemented the following: within the first 1.5 seconds after switching to the 'Preview'/'Generate' tab, as many passwords as possible are generated and their quality is estimated. For typical passwords, this makes the average more stable.
Furthermore, the number of passwords that are displayed has been increased to 50 (from 30), which is sufficient here in my opinion. Users who need a larger number of passwords can switch to another tab and back again (which generates 50 new passwords), use the 'Generate Password List' command (in the main menu 'Tools') or KPScript ('GenPw' command).
Here's the latest development snapshot for testing:
https://keepass.info/filepool/KeePass_250121.zip
Thanks and best regards,
Dominik
Looks good. The run-to-run stability of the final average password quality estimate is much improved.
I did notice a minor dithering of the average estimate within a given run. It suggests that the UI of the 'Preview' tab is updating the calculated averages during each 1.5 second password generation run. From a fit and finish perspective, reporting a stable final average is preferable if is easy to implement. The flickering average estimate attracts the eye and is unnecessary.
Subjectively, on my older computer with a 20 character single case alphanumeric profile, I noticed estimated average updates during a single run of between 1 (fairly common) to 4 (rare, e.g. 92-93-92-93) updates having a magnitude of 1 (fairly common) to 2 bits (uncommon, e.g. 92 to 94). The final estimate, e.g. 93, was quite stable. The 'Exclude look-alike characters' option seemed to increase the behavior.
The increase of the display to 50 generated passwords is fine. It is an easy list to scan and it should be large enough to convince most users that creation of trivial passwords is not an issue for reasonable password generation profiles.
I agree that the flickering of the average isn't nice, but unfortunately I don't see how this could be improved. In my opinion, showing it only at the end of the 1.5 seconds would be worse (it would attract the eye even more, and during the 1.5 seconds, users could wonder why there's no average). With the current solution, users immediately see an approximate value of the average (without having to wait 1.5 seconds).
Best regards,
Dominik
Display the initial value in pale grey and only update it and the colour at the end?
cheers, Paul
Overall this is a very nice new feature.
I am definitely nit-picking over the display of intermediate results.
Displaying the average in grey during the 1.5 seconds has similar disadvantages as hiding it.
I've now changed it as follows: during the 1.5 seconds, "Please wait..." is appended to the line. This way it's clear that KeePass is working on it, and until it's finished, the user already sees an approximate value of the average. The line is displayed in grey only when it's not possible to estimate the quality (Spr-variant passwords).
Here's the latest development snapshot for testing:
https://keepass.info/filepool/KeePass_250125.zip
Thanks and best regards,
Dominik
"Please wait…" works well