URL is case sensitive for password generation

[Rick DeBay]

Domain names are case insensitive according to RFC-1035

http://www.faqs.org/rfcs/rfc1035.html
http://www1.ietf.org/mail-archive/web/ietf...t/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

[Eric H. Jung]

OK, and what about protocol?

[Rick DeBay]

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

[Rick DeBay]

The protocol is actually called 'scheme'.  And it's lower case.

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 | "+" | "-" | "." )

[Eric H. Jung]

Thanks for doing the research. I'll fix this soon.

[Rick DeBay]

Good luck, it won't be trivial because some people will have generated passwords before the case was normalized.

Rick DeBay

[Eric H. Jung]

good point. maybe i'll wait on this a bit.

[Romeo]

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.

[Rick DeBay]

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

[Romeo]

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.

[Eric H. Jung]

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.

[Rick DeBay]

And the online version and everything else should always normalize the URL.

[Rick DeBay]

In which version was this included?

[Eric H. Jung]

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.

[Rick DeBay]

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 (or some other camel case version).  I later logged on with 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.