#dominoforever | Product Ideas Portal

 

Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events around #dominoforever, please visit our Destination Domino Page

Allow HTTP Basic Authentication with Umlauts using UTF-8

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

  • Guest
  • Feb 5 2019
  • Likely to implement
  • Attach files
  • Guest commented
    26 Feb 05:48am

    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.

  • Guest commented
    11 Feb 05:33pm

    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.