Author Topic: Weenie site list  (Read 15494 times)

Offline breyed

  • Jr. Member
  • **
  • Posts: 28
Weenie site list
« on: November 13, 2005, 01:06:37 PM »
Now that PasswordMaker has matured into a tool with boatloads of options, I think the next step is to try to keep the typical user from ever having to think about them.  Just as a user logs onto Windows XP without a considering the password hash algorithm, salting, etc., the same would be ideal for PasswordMaker.  Here is my suggestion to make this a reality:

1. Set the PasswordMaker defaults to a best practice security settings that work for most (90%+) sites.  IMHO, this means the following:

1a. SHA-256 hash algorithm.
1b. Password length 16 characters.
1c. Alpha/numeric/symbol character set.

1d. No modifier, suffix, or l33t.  These add no value when public.  Side comment: I don’t really understand why these are ever useful, since it seems a user can always get the equivalent by using a stronger password.

1e. A character forcing post-filter (new).  Many sites require at least one number, one symbol, one capital letter, and one lower case letter.  After SHA-256 has been applies, the forcing filter should ensure each password has these features.  A suggestion for implementation would be this: for each character type to be forced, if it is absent, find the character with highest ascii value for which there is more than one character of its type and convert it to the forced character type.  For the conversion, take the old character’s ascii value modulus the size of the new character type’s set and add that result to the ascii value of the lower character in the new type’s set.

2. Maintain a public list of all sites that don’t work for bullet 1 (“weenie sites”).  The public list would contain the domain name of each site, plus its password length and character set.  For complicity, I recommend using an enumeration that refers to predefined character sets (the ones already present in PasswordMaker).  What to do with this public depends on how big it is expected to get:

2a. If it is small, have PasswordMaker automatically download it periodically, similar to the AdBlock Filterset.G updater.

2b. If it is large, have PasswordMaker use a web service query to the weenie status of each individual site the first time it encounters a password field on its page.  PasswordMaker would maintain a local cache of the responses.

2c. In either case, there needs to be a submission mechanism as new (to the community) weenie sites are encountered.  The forums would work initially, but ultimately, this should be integrated into PasswordMaker using web services.

3. The online version would use the weenie site list just like PasswordMaker extension.


I hope my proposal is clear so far.  Now, I’m going to throw in usernames.  The current problem is that sites vary as to whether they user email usernames or alphanumeric-only usernames.  Here is a proposed solution:

1. The user enters an email address into PasswordMaker, which optionally stored (just like the password).

2. By default this email address is populated into the email address field on forms.  If the form appears to have a username field instead, the @ is removed, and the remainder becomes a username.  If the HTML tag specifies a character limit for the username, PasswordMaker abides.

3. If PasswordMaker’s heuristics don’t correct determine whether to use email or username, or it cannot deduce the character limit, the site goes on the weenie list, in which case the username type and, if applicable, size are included.

4. For the online version would suffer a bit here, since it can’t examine the page source.  It would fall back to just showing username information available from the weenie list, if any.

The end goal is to come very close to this point: wherever you are, simply enter your email and master password, and it all “just works”, securely.

Offline Tyrantmizar

  • Sr. Member
  • ****
  • Posts: 307
Weenie site list
« Reply #1 on: November 13, 2005, 06:48:55 PM »
:applause:  

Well said.

I almost disagree on Part 2 (weenie lists).  Yes we would need them.  No arguments there.  But perhaps an auto-detecter would be better?  

It would need to detect max length and what characters are allowed.  The second part isn't usually easy to detect, is it?  A quick look at password forms shows that the coding doesn't exactly tell you what is allowed.

I'm a bit hesitant to the idea of people submitting the weenie sites.  We would need to double-check things, to make sure someone isn't trying to, say, mess up their competitor.  And with the potential for several submitions a day...
Tyrantmizar
- <a href="http://tyrantmizar.blogsome.com/">Check out my blog</a> (shameless plug :P)
- Lord of the Feature Requests / Enhancements Forum - BWAHAHAHAHA!!!!
- Lord of the other one, the [url=http://forums.passwordmaker.o

Offline breyed

  • Jr. Member
  • **
  • Posts: 28
Weenie site list
« Reply #2 on: November 13, 2005, 10:41:56 PM »
Quote
[An autodetector] would need to detect max length and what characters are allowed. The second part isn't usually easy to detect, is it? A quick look at password forms shows that the coding doesn't exactly tell you what is allowed.

Good point.  I forgot about being able to autodetect password length from the HTML.  This would even work with the online version: the online version would always generate 16 characters, and then the paste operation would naturally be truncated to fit by the browser.  The only case where autodetection wouldn't work is for length checks that are only done server-side.  For those, the weenie list would be needed.

Quote
I'm a bit hesitant to the idea of people submitting the weenie sites. We would need to double-check things, to make sure someone isn't trying to, say, mess up their competitor. And with the potential for several submitions a day...

This is a concern of mine, too.  The scheme would only work if the weenie list were a small minority of all sites, such that there wouldn't be too many submissions.  Anyone know of a good way to get a rough statistic on this?

There are ways to balance abuse defense and review overhead. For instance, the first 5 submissions by a registered submitter would reviewed by a human, and subsequent submissions would not require review.  Even then, there would be a mechanism to report abuse (these forums would probably be enough, since abuse will likely be rare).

For weenie submissions subject to human review, the weenie site would still go into the submitter's cache immediatley so that password generation works for him without having to wait for the review.

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Weenie site list
« Reply #3 on: November 15, 2005, 04:40:35 AM »
I have to admit I'm not following a lot of this conversation. I need to re-read it more closely and write another reply. I'm not really sure what the goal or intention is...

Offline breyed

  • Jr. Member
  • **
  • Posts: 28
Weenie site list
« Reply #4 on: November 15, 2005, 12:01:36 PM »
Executive summary: :king: As-strong-as-allowed, compatible passwords for all web sites, with zero end-user configuration.

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Weenie site list
« Reply #5 on: November 21, 2005, 04:10:03 PM »
OK, I've re-read this and here are my comments.

Quote
1. Set the PasswordMaker defaults to a best practice security settings that work for most (90%+) sites. IMHO, this means the following:

1a. SHA-256 hash algorithm.
1b. Password length 16 characters.
1c. Alpha/numeric/symbol character set.

I think 1a and 1c are already the case, no? tyrantmizar, can you add 1b to the FRL?

Quote
A character forcing post-filter (new). Many sites require at least one number, one symbol, one capital letter, and one lower case letter. After SHA-256 has been applies, the forcing filter should ensure each password has these features
Good idea. Tyrantmizar, can you add this to the FRL please?

I'm not too interested in the weenie list idea. It seems like a lot of work for not much payback, don't you think?

Quote
1. The user enters an email address into PasswordMaker, which optionally stored (just like the password).

2. By default this email address is populated into the email address field on forms. If the form appears to have a username field instead, the @ is removed, and the remainder becomes a username. If the HTML tag specifies a character limit for the username, PasswordMaker abides.
The problem I see with this is many people don't use the same email address in their accounts. How would PasswordMaker know which one to use? Also, when you say "If the form appears to have a username field instead", how is PasswordMaker supposed to determine that? By the HTML input name?

Offline breyed

  • Jr. Member
  • **
  • Posts: 28
Weenie site list
« Reply #6 on: November 22, 2005, 01:23:52 AM »
Quote
It seems like a lot of work for not much payback, don't you think?
It's a good question. For someone like you and me, there isn't much payback, because we can maintain our own exception lists fairly proficiently, and when using 3rd party computer, where we don't have our exception list, usually discern that what configuration to use when using the online version.

Now a more novice user on the other hand wouldn't stand much of a chance in correctly configuring site exceptions with the extension, much less figuring out what to do on a 3rd party computer with the online version.

So the short answer for payback is that is moves PasswordMaker from the domain of the techies to the main stream, i.e. the domain of the unsophisticated web user.

Quote
The problem I see with this is many people don't use the same email address in their accounts. How would PasswordMaker know which one to use? Also, when you say "If the form appears to have a username field instead", how is PasswordMaker supposed to determine that? By the HTML input name?
Yes, this is a problem that can be only partially solved.  What I put forth is my vision for how PasswordMaker could solve the problem to the extent technically possible.  To some extent, it depends on the user being willing to establish a simple model, that is using a single username/email.  The payback may well be worth it, however.  I know that I would like automatically knowing my credentials for any site, without having to perform any kind of look-up.  I'd be willing to rename some of my existing account usernames for this.  Of course, some accounts won't let you rename, so I'd need a personal exception list.  But at least it would be small and stable.

One could ask: Once you need a personal exception list of any sort, is it worth trying to get rid of personal exception lists at all?  I'm not sure on this.  I tend to think yes, since it would be nice to at least not have to add to the list, and I could put it on my web site in a undisclosed location and always have it available, and not worry about having to update it when I sign up on a new site.

Regarding email vs. username detection, I was thinking of using the HTML input name as a heurstic.  It would be imperfect, in which casae the weenie list would be used to catch the sites that didn't fit the heuristic.

PasswordMaker Forums

Weenie site list
« Reply #6 on: November 22, 2005, 01:23:52 AM »