PasswordMaker Forums
Firefox/SeaMonkey/Mozilla/Netscape/Flock Browser Extension => Bugs => Topic started by: Rick DeBay on September 30, 2005, 04:58:51 PM
-
Domain names are case insensitive according to RFC-1035
http://www.faqs.org/rfcs/rfc1035.html (http://www.faqs.org/rfcs/rfc1035.html)
http://www1.ietf.org/mail-archive/web/ietf...t/msg01555.html (http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01555.html)
yet the case of the domain affects the password. The URL Yahoo.com and yahoo.com will generate different passwords.
The subdomain, domain, and top level domain should be converted to upper or lower case before hashing. The remainder of the URL's case sensitivity is up to the destination, so that should be preserved.
Rick DeBay
-
OK, and what about protocol?
-
Good question. I can't find the RFCs that define URLs and URIs. The only thing that I can find that is case-sensitive is the query parameter values. Everything else is insensitive, but we all know the path beyond the domain is case sensitive depending on what is handling the request.
Does anyone know the applicable RFC?
Rick DeBay
-
The protocol is actually called 'scheme'. And it's lower case.
http://www.ietf.org/rfc/rfc2396.txt (http://www.ietf.org/rfc/rfc2396.txt)
3.1. Scheme Component
Just as there are many different methods of access to resources,
there are a variety of schemes for identifying such resources. The
URI syntax consists of a sequence of components separated by reserved
characters, with the first component defining the semantics for the
remainder of the URI string.
Scheme names consist of a sequence of characters beginning with a
lower case letter and followed by any combination of lower case
letters, digits, plus ("+"), period ("."), or hyphen ("-"). For
resiliency, programs interpreting URI should treat upper case letters
as equivalent to lower case in scheme names (e.g., allow "HTTP" as
well as "http").
scheme = alpha *( alpha | digit | "+" | "-" | "." )
-
Thanks for doing the research. I'll fix this soon.
-
Good luck, it won't be trivial because some people will have generated passwords before the case was normalized.
Rick DeBay
-
good point. maybe i'll wait on this a bit.
-
That is indeed a very good point. May be Eric, you could put a temporary warning in to the next release warning the user that a future release will use the RFC logic. This warning would only appear for URL's, which are mixed case.
-
Waiting will only make it worse, as more incorrect hashes are generated.
I suggest that the entire URL is always lowercased, except for existing accounts. For those, a warning should be issued on the account page that passwords should be changed in order to conform to the correct URL normalization, and the current behavior has been deprecated.
Rick
-
Waiting will only make it worse, as more incorrect hashes are generated.
I suggest that the entire URL is always lowercased, except for existing accounts. For those, a warning should be issued on the account page that passwords should be changed in order to conform to the correct URL normalization, and the current behavior has been deprecated.
Rick
Eric, that sounds like a good idea to me. In other words, when a new account is set up, just convert the URL to lower case. But you would have to leave the user able to convert it back to mixed case, in case an existing account with mixed account got deleted and needs to be re-set up.
-
Sounds good. I'll do it for new accounts only. Makes the code easier, too, because I don't have to worry about "converting" existing accounts in the RDF.
-
And the online version and everything else should always normalize the URL.
-
In which version was this included?
-
It wasn't. It should have been submitted as a feature request so it could have been tracked (you can argue it's a bug).
Can you tell me again why this is important? I re-read the thread and am failing to see why the current logic is bad.
-
For one, it's a bug because it violates the RFC.
Practically, I got nailed by this because I had a password at a site that I normally entered as http://secure.AmerisourceBergen.com (http://secure.AmerisourceBergen.com) (or some other camel case version). I later logged on with http://secure.amerisourcebergen.com (http://secure.amerisourcebergen.com) and was unable to generate the correct password, and I was unable to determine the capitalization that I had used.
I would like to deploy this company-wide in order to assist us with HIPAA compliance. The training and installation issues in order to cope with case-sensitive URLs make this impossible. Conforming to the RFC (URIs are NOT case sensitive) would solve this issue.
-
OK. I will release it this week. However, existing accounts won't be affected. Are you OK with this? Moreover, since the URL fields in Account Settings are editable, if someone really wants to camel case something, he certainly can. It's just that the account, when first created, will use lower-cased scheme and domain.
Sound good?
edit: BTW, comparisons of schemes, subdomains, and domains when populating passwords/usernames will be case-insensitive. Rick, I'd appreciate it if you could register so I can send you emails of the forum if necessary when developing this change.