[SERVER-70549] Speculative authentication with SCRAM-SHA-256 disabled on mongod creates audit message Created: 13/Oct/22 Updated: 29/Oct/23 Resolved: 12/Jan/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.4.16 |
| Fix Version/s: | 6.3.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Spencer Brown | Assignee: | Militsa Sotirova |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Server Security
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Steps To Reproduce: |
|
||||
| Sprint: | Security 2022-12-12, Security 2022-12-26, Security 2023-01-09, Security 2023-01-23 | ||||
| Participants: | |||||
| Case: | (copied to CRM) | ||||
| Linked BF Score: | 141 | ||||
| Description |
|
When running with SCRAM-SHA-256 not enabled on a mongod server, speculative authentication attempts with SCRAM-SHA-256 cause audit messages to be logged indicating authentication failures (result code 18). This is undesirable, as the appearance of an authentication failure message in the audit log can be taken as an indication that someone is actually trying to login with a bad password. The ask here is to stop triggering audit events for speculative authentication failures. |
| Comments |
| Comment by Githook User [ 12/Jan/23 ] |
|
Author: {'name': 'Militsa Sotirova', 'email': 'militsa.sotirova@mongodb.com', 'username': 'militsasotirova'}Message: |
| Comment by Githook User [ 12/Jan/23 ] |
|
Author: {'name': 'Militsa Sotirova', 'email': 'militsa.sotirova@mongodb.com', 'username': 'militsasotirova'}Message: |
| Comment by Sara Golemon [ 13/Dec/22 ] |
|
Oh, it should be noted that for clients experiencing this spurious log warning/audit, they can instruct their clients to use a URI which includes the authentication mechanism. e.g. `mongodb://alice:secret@server1:27017/admin?authenticationMechanism=SCRAM-SHA-1 . The client/driver should then speculate saslStart using the correct mechanism. |
| Comment by Sara Golemon [ 12/Dec/22 ] |
|
Just want to clarify that the goal here is for the speculative failure to not cause the logging IF AND ONLY IF it subsequently succeeds for the same user via saslStart/saslContinue ? I don't want to see a blanket skip on the auth failure as that opens an avenue for brute forcing. |
| Comment by Spencer Jackson [ 21/Oct/22 ] |
|
I expected this to have been resolved by Failed speculative auth should not be considered an error by the AuthenticationSession, nor produce an audit event. The session should remain active, until a subsequent hello, definitively auth exchange, or if the Client it's attached to is destroyed. |