PasswordMaker 0.6.1 beta4 available

[Eric H. Jung]

Hi,

PasswordMaker 0.6.1 beta4 is available for download here.

Just a couple new features this time. I'm trying to put out new releases much more quickly.

-Eric

[Tyrantmizar]

The new hotkey feature is a wonderful alternative to the blacklist/whitelist feature that I requested.  I hereby retract my request, though you may leave it up if you wish.  

Though I'm not sure why you released another beta with just one additional feature.

[Eric H. Jung]

Glad you like the new hotkey! I'm still going to add the whitelist; I've thought it through, and I think adding to Account Settings a checkbox "Auto-populate password fields on this URL" would be best. In that case, it would be a whitelist and independent of the Global Settings. What do you think?

I'm not sure why you released another beta with just one additional feature

Well, I'm pretty sure the fix for this bug made it into the build, too, but I'm not sure. In any case, it is fixed and will be in the next beta (or final) release.

-Eric

[E.Z]

Eric,

Here are my comments after briefly using beta 3/4.


1. GREAT!

The new features all seem to work fine, and make PasswordMaker more powerful and even more fun to use. Don't let this long post give you the wrong idea - there are always things to improve but already PM is wonderful.


2. UI of account settings

The UI is functional and easy to use, however I think it can be tweaked to make it a bit more straightforward to use and visually pleasing:

* Align input boxes:

Code: [Select]

Name....... __________________________________________________
Description __________________________________________________
...
When URL contains _______________ Use this URL _______________
Username......... _______________ Password.... _______________


* Try to optimize "URL components" frame - currently it's mostly empty. Maybe squeeze it into a single line:

Code: [Select]

-- URL Components --------------------------------------------
[] Protocol [] Domain [] Subdomain(s) [] Port, path, params
--------------------------------------------------------------


* Re-order fields into functional groups:

Code: [Select]

---------- Section 1 - Account identification ----------

Name
Description
When URL contains / Use This URL
URL Components
Username
(Future: ID field Name / Value )

---------- Section 2 - Password generation ----------

Hash Algorithm / Password Length
Use l33t / l33t Level
Characters

---------- Section 3 - Password modifiers ----------

Counter / Password Prefix / Password Suffix

---------- Section 4 - Generated password ----------

Generated Password / Strength Meter

Notes:
- The notation "field1 / field2" means fields are on the same line.
- Consider using section headers or frames to visually seperate the groups.


3. Minor password meter issues

The whole meter thing is not very important, but if you have spare time and looking to improve it... I think that the meter algorithm needs some tweaking.

The first thing I checked is how the length of the password affects the score. Currently it shows about 30% strength for passwords that are 3 characters long. On the other hand increasing the length rarely gets to 50%. Adding more characters to the charset improves the score, but the maximum I could manage was around 60-70%.

I think that the length of the password should have a bit more influence, lets say about 25% of the score - that is with a very long password but of poor quality the score will be 25%. For example, assuming 20 chars and above is sufficiently long:

Code: [Select]

If Length > 20 Then
  Length = 20;
Score = (Length DIV 4) * 5;
Another thing I noticed is that sometimes the meter gives lower score to longer password. For example this password: "7103F" gets about 40%, while both "7103F5" and "7103F53" get about 30%, although they are certainly not less secure.

My guess is that the meter algorithm computes a "randmoness index" that is relative to the length of the password, but isn't relative to the size of the character set.

Maybe the character set also needs to be part of the score, let's say another 25%. For example, assuming 6 chars and less isn't secure and 25 chars and above is good:

Code: [Select]

Count = (count unique chars in set);
If Count < 7 Then
  Count = 0
Else
  If Count > 25 Then
    Count = 25;
Score = Score + Count;
That leaves 50% of the score to the randmoness of the chosen characters. I don't know what is the accepted method to measure randomness - maybe standard deviation? Something else? Whatever it is, there's one more thing to take into consideration, and that is trivial patterns.

The most obvious case is popular words, names, etc. But this requires a huge dictionary (in multiple languages) that is outside the scope of PM, and is anyway not very relevant for hash results.

However hashes do sometimes produce a sequence of characters that have some pattern, especially when the password is short and especially when the user adds a prefix/suffix that isn't really random. For example the password "ABCd3" scores about 60%, but it isn't a strong password.

I thought of a simple logic that probably doesn't cover eveything but detects trivial sequences:

Code: [Select]

1. Upper-case password - if possible invoke locale upper-casing.
2. Calculate absolute differences between adjacent chars (eg. ABCBA should produce 1,1,1,1).
3. Calculate standard deviation on differences.
4. Scale result to range 0..1
5. Multiply result by randomness index.
6. Multiply result by 0.5 (50%) and add to score.
4. And...

The Auto-populate checkbox mentioned above will be a very welcome addition!


Thanks for the great work.

EZ.

[Eric H. Jung]

Wow, thanks for the excellent feedback! I need time to compose a full reply and will do so this evening.

-Eric

[Eric H. Jung]

Hi E.Z.,

Thanks again for the extension comments!

1. Thank you!
2. These are all excellent suggestions and I've started implementing them already
3. These, too, are excellent suggestions, but I might have more trouble implementing them. I don't want to get bogged down in a strength meter right now when I'm working towards getting a 1.0 release of PasswordMaker out. I will definitely change the existing algorithm though (which is detailed here) before the next release. Most password strength algorithms I've seen (including Firefox's) are incredibly simple when you compare them to what I tried to achieve. I think simpler might just be better right now.

Just FYI, here's Firefox's pw strength algorithm used in Tools->Options->Privacy->Saved Passwords->Set Master Password

Code: [Select]

function setPasswordStrength()
{
// Here is how we weigh the quality of the password
// number of characters
// numbers
// non-alpha-numeric chars
// upper and lower case characters

  var pw=document.getElementById('pw1').value;

// pw is the user-entered password

//length of the password
  var pwlength=(pw.length);
  if (pwlength>5)
    pwlength=5;


//use of numbers in the password
  var numnumeric = pw.replace (/[0-9]/g, "");
  var numeric=(pw.length - numnumeric.length);
  if (numeric>3)
    numeric=3;

//use of symbols in the password
  var symbols = pw.replace (/\W/g, "");
  var numsymbols=(pw.length - symbols.length);
  if (numsymbols>3)
    numsymbols=3;

//use of uppercase in the password
  var numupper = pw.replace (/[A-Z]/g, "");
  var upper=(pw.length - numupper.length);
  if (upper>3)
    upper=3;


  var pwstrength=((pwlength*10)-20) + (numeric*10) + (numsymbols*15) + (upper*10);

  // make sure we're give a value between 0 and 100
  if ( pwstrength < 0 ) {
    pwstrength = 0;
  }
  
  if ( pwstrength > 100 ) {
    pwstrength = 100;
  }
}

Edit:

Check it out. PasswordMaker with tabs:

[E.Z]

Hi Eric,

2. These are all excellent suggestions and I've started implementing them already

If you want me to look at experimental builds, I'll be glad to help.

...I don't want to get bogged down in a strength meter right now...

I agree that the meter is low priority. After all in 99.99% of the cases the password will be extremely secure. The meter is useful only under specific un-common conditions - when user supplied prefix/suffix comprise most of the characters in the password, and/or the user uses a very narrow character set.

I think that it's safe to assume that not only those conditions are very unlikely to happen, but also that users who modify the character set, prefix and suffix - are advanced users who can judge the quality of a passowrd.

Anyway I've written a detailed analysis of password security and how to measure it, as a reply to your post in the Password Quality thread.

Check it out. PasswordMaker with tabs

The title of the first tab is the same as for the settings button, which is confusing. I think it should be changed to "Accounts" or "Account Manager".

I can hardly wait for the next release!

EZ.

[Eric H. Jung]

If you want me to look at experimental builds, I'll be glad to help.

Yes, that would be most helpful. Tyrantmizar toyed with one yesterday for me. Please make sure your email address in your forum profile is up-to-date so I can contact you.

Anyway I've written a detailed analysis of password security and how to measure it, as a reply to your post in the Password Quality thread.

Excellent, thanks. Agreed that it's better to continue the topic there.

The title of the first tab is the same as for the settings button, which is confusing. I think it should be changed to "Accounts" or "Account Manager".

Yup. Thanks, I missed that.

I can hardly wait for the next release!

Heh. Me too. FYI: i've started looking into arbitrary form field population (like username, account #, whatever). The user will be able to drag-and-drop an icon onto any field, and the name of the field is determined for him. That way, there's no need for users to view the form's HTML.

[E.Z]

Eric,

Please make sure your email address in your forum profile is up-to-date so I can contact you.

My email address in the profile is correct. Besides we've already exchanged a few emails so you should have my address anyway (although I'm not sure it's the same one).

FYI: i've started looking into arbitrary form field population (like username, account #, whatever). The user will be able to drag-and-drop an icon onto any field, and the name of the field is determined for him. That way, there's no need for users to view the form's HTML.

I always thought of this as an advanced feature, but it may be used by people who know nothing about HTML forms. So this is really a great idea.

If you want me to test it, just send me a test build...

EZ.