Currently Domino HTTP Basic Authentication Passwords need to be encoded in ISO-8859-1.
Many other systems allow to use UTF.8. The standard is unclear but there is a specification where you can announce which encoding the server expects.
See https://tools.ietf.org/html/rfc7617 for details.
Since 2015 there is RFC 7617, which obsoletes RFC 2617. In contrast to the old RFC, the new RFC explicitly defines the character encoding to be used for username and password.
- The default encoding is still undefined. Is is only required to be compatible with US-ASCII (meaning it maps ASCII bytes to ASCII bytes, like UTF-8 does).
- The server can optionally send an additional authentication parameter
charset="UTF-8" in its challenge, like this:
WWW-Authenticate: Basic realm="myChosenRealm", charset="UTF-8"
This announces that the server will accept non-ASCII characters in username / password, and that it expects them to be encoded in UTF-8 (specifically Normalization Form C). Note that only UTF-8 is allowed.
Support gave me the following, existing enhancement request today.
The business case behind it is that we need authentication with passwords containing umlauts for mobile devices.
Once we have this enhancements, we need the mobile applications also to support UTF-8 in the same way.
SPR # DKENAJTT9G :Enhancement: Non-ASCII UTF-8 passwords don't work over basicAuth
Hello. IBM/HCL failure to support any password for 20 years sticks the product to the legacy line. 1. HTTP password hash should NOT be readable by anyone except server, because it exposes easy way to bruteforce the password. 2. The system must support any characters in a password without any restrictions to diacritics and symbol position. 3. keeping different requirements for Notes and HTTP password is the same legacy story. 4. clear account auto-lock procedure is a must for all access types, no matter which protocol was used - nrpc, pop3, imap, ldap, diiop or http. Leaving at least one protocol without account auto-lock introduces just an easy way to verify password using a dictionary or bruteforce.
If you are using Sametime and are synchronizing Notes- and HTTP Passwords this can lead to a bit confusion.
If an user changes his password to anything with an umlaut, he won't get any error but will not be able to log into Sametime client anymore.
Good idea, hopefully it will be implemented soon.