[SERVER-26052] calculation of salted password where normalization is done wrong Created: 09/Sep/16 Updated: 28/Jan/20 Resolved: 28/Jan/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Marcel Timmerman | Assignee: | Spencer Jackson |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Sprint: | Security 2020-02-10 |
| Participants: |
| Description |
|
The following example shown at page has in my opinion a bug
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 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. |
| Comments |
| Comment by Spencer Jackson [ 28/Jan/20 ] | ||||||||||||||||||||||||||||||||||||||
|
While SCRAM-SHA-1 credentials continue to be unnormalized, MongoDB's implementation of SCRAM-SHA-256 performs SASLPrep on passwords. In order to normalize passwords, create users with or update them to have credentials supporting the new mechanism. | ||||||||||||||||||||||||||||||||||||||
| Comment by David Golden [ 15/Sep/16 ] | ||||||||||||||||||||||||||||||||||||||
|
Also relevant:
| ||||||||||||||||||||||||||||||||||||||
| Comment by David Golden [ 09/Sep/16 ] | ||||||||||||||||||||||||||||||||||||||
|
Example failure (MongoDB 3.2.9): Shell:
Perl client code:
Error when running:
Server log messages:
| ||||||||||||||||||||||||||||||||||||||
| Comment by Bernie Hackett [ 09/Sep/16 ] | ||||||||||||||||||||||||||||||||||||||
|
Hi, Can you provide an example where you have not been able to authenticate a user due to the drivers and server not using SASLprep? |