MySQL Bugs: #62301: It is best to use only ASCII characters for user names and passwords

Bug #62301	It is best to use only ASCII characters for user names and passwords - nonsense
Submitted:	30 Aug 2011 11:34	Modified:	20 Oct 2011 15:43
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Documentation	Severity:	S3 (Non-critical)
Version:	4.1+	OS:	Any
Assigned to:	Paul DuBois	CPU Architecture:	Any
Tags:	qc

Description:
http://dev.mysql.com/doc/refman/5.5/en/user-names.html .. search for "It is best"

How to repeat:
* Why is it *best*. ?

* When is it *best* (I know people who use rare Asian characters in user names and passwords for security reasons. A little polemical I could say that pure ascii authentication is less secure.)?

* For whom is it *best* - also for people who do not have a single ascii character in their native language and may have difficulty memorizing a non-trivial ascii password?

Is English better than Chinese? Is cheesecake better than potato pie? :-)

Suggested fix:
Change to/Add something like (what I think is correct): 

"If you want to connect to a server with non-ascii authentication details the client should execute mysql_options() with a MYSQL_SET_CHARSET_NAME -parameter defining a character set matching the encoding of the authentication details. Doing so will ensure that the authentication set will take place with the specified character set. When not doing so authentication will fail unless the server default character set is the same as the enoding in the authentication details."

(And that actually made me think how to authenticate to a server running UCS2, BIG5 etc. as default charset with an ascii password unless using mysql_options() the same way. The client sends a single byte charset, the server expects 2 bytes even for assci characters.  But I may be wrong here!)

Yes, some explanations and details about *the best* would be useful...

See also Bug#52404. Much of the discussion is private, though. The gist is that due to character set conversion issues, non-ASCII characters may become garbled.

OK .. but if server is running a unciode character set as default and/or if a unicode character set is specified in mysql_options() I can authenticate with anything. Of course the user will know what (s)he is doing and the client will have to send an expectedly encoded byte-stream.

Let us take an example: A Russian user has been using a non-unicode cyrillic charset. He had no problems authenticating with cyrillic name and pw. Server default is changed to utf8. His client still sends the cyrillic characters in a ANSI-codepage encoding. Authentication now fails (I did not try but I understand it like this).

I also think the term *special character* is an outdated "Anglicanism" (from the time that ASCII grew to Extended ASCII/ANSI - what is now around 20 years ago). For a Russian person Russian is non-special. For me who is Danish "æøå" are not. "non-ASCII" is a better and more exact term than "special". "special" is subjective.

I think that the recommenation should be to use mysql_options() to define a charset in every case where authentication with non-ASCII user and or pw may happen to reflect the encoding capabilities of the client (what would mean SET utf8 in most cases). I know that specific client environments do not have this option (most notably PHP that does not implemet mysql_options() and also would have difficulty doing it due to inpersistent nature of connections made wiht PHP).

(And besides I am still a little mystified about how clients on big endian systems can authenticate with the server on other systems ... But as I neither use Mac, Solaris or whatever of the kind I will not fill my head with blue smoke wondering about it!).

Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.

Revised the section to say:

It is possible to connect to the server regardless of character set
settings if the user name and password contain only ASCII characters.
To connect when the user name or password contain non-ASCII
characters, the client should call the mysql_options() C API function
with the MYSQL_SET_CHARSET_NAME option and appropriate character set
name as arguments. This causes authentication to take place using the
specified character set. Otherwise, authentication will fail unless
the server default character set is the same as the encoding in the
authentication defaults.

Standard MySQL client programs support a --default-character-set
option that causes mysql_options() to be called as just described. In
addition, character set autodetection is supported as described in 
http://dev.mysql.com/doc/refman/5.5/en/charset-connection.html.
For programs that use a connector that is not based on the C API, the
connector may provide an equivalent to mysql_options() that can be
used instead. Check the connector documentation.

The preceding notes do not apply for ucs2, utf16, and utf32, which
are not permitted as client character sets.