Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-26052

calculation of salted password where normalization is done wrong

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Minor - P4 Minor - P4
    • None
    • Affects Version/s: None
    • Component/s: Security
    • Labels:
      None
    • ALL
    • Security 2020-02-10

      The following example shown at page has in my opinion a bug

      computeClientKey
      function computeClientKey(username, plain_text_password) {
              mongo_hashed_password = HEX( MD5( UTF8( username + ':mongo:' + plain_text_password )));
              saltedPassword  = Hi(Normalize(mongo_hashed_password), salt, i);
              clientKey = HMAC(saltedPassword, "Client Key");
      }
      

      Normalize() is used on the place where it is used in the rfc5802 but should be used on username, password and authzid individually. Besides, in the above example, Normalize is used on a hexadecimal string which will change nothing and only eats cpu time.

      In discussions with David Golden the example is not just an example but is the way how the server does things and I understood that changing that would break code.There has been some answers returned before such as
      "we don't expect anyone to use non-ASCII usernames and passwords" or "we didn't do that before for usernames/passwords so we don't want to change and break compatibility". These two answers contradict each other because if only ASCII names are used, then changing it wouldn't do any harm because the normalization wouldn't change the strings.

      Furthermore I can't imagine that there wouldn't be any use outside the 'West' (Europe and US), so a Japanese name like 黒澤 明 (Akira Kurosawa) for example should be possible to use. This would still work without normalisation, but imagine a type setting system using this name with some other kind of spacing between the characters, it would not be mapped to an ASCII space and there will be problems while it is not visible for the reader. There are also characters which should fail normally. So this normalization proces takes care of mapping, unicode normalization, fail on wrong characters and bidirectional use which is not taken care of this way.

      To prevent any breaking of code, the server could add a boolean to the account info which says if it is using normalized names or not. New added names will be converted(bool set to true) and the old ones stay the same(bool set to false). Old servers cannot change drivers can use the old method and drivers should try login twice after some newer server version where the change is incorporated.

      That said, if you think that mostly ASCII characters are used then there should only be an occasional breakage.

            Assignee:
            spencer.jackson@mongodb.com Spencer Jackson
            Reporter:
            mt1957 Marcel Timmerman
            Votes:
            0 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: