[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: more SASLprep/protocol problems

Hallvard B Furuseth wrote: 
Clients are to prepare passwords in the same fashion in which
the password storage application producing and storing them
(or their hashes).  Interoperability with all of these systems
is dependent on implementing that rule.


What preparation?  The systems I know don't modify passwords input by
the user at all.


Sure they do. Today it's so common and simple that you don't even think
about your keyboard strokes getting translated to your OS' character set
(e.g. Windows Unicode) and again getting translated by the LDAP client to
ASCII or UTF-8 (or ISO-8859-1 in case of Netscape 4.5+).

If we remove the statement, a client produces EBCDIC (or even UTF-16)
passwords would be fully conformant but fail to interoperate with your
ASCII based external password store.

Not if the client offers an option to prepare passwords. 

Uurgs! You wanna let the user decide whether to translate passwords or not?

There was a discussion here about NON-ASCII chars in passwords some time ago since many people reported interoperability problems with deployed software (e.g. Outlook using UTF-8 vs. Netscape 4.5+ using ISO-8859-1). Please check the list's archives. I'm quite happy that there is such a preparation statement recommending UTF-8.

Ciao, Michael.