[SERVER-23874] Increase SCRAM iteration count Created: 22/Apr/16 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 3.2.5 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Andreas Nilsson | Assignee: | Backlog - Security Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Security
|
| Participants: |
| Description |
|
As CPU processing power goes up so should our default SCRAM iteration count. The new SCRAM-SHA-2 RFC recommends 15k iterations so we should increase it to at least that. Note that the authentication delay could be substantial for slow machines. |
| Comments |
| Comment by Bernie Hackett [ 22/Apr/16 ] |
|
https://tools.ietf.org/html/rfc7677 If 15-20k rounds is too expensive on the client side, we can cache the client key as described in section 5.1 of the SCRAM-SHA-1 spec. https://tools.ietf.org/html/rfc5802 "Note that a client implementation MAY cache ClientKey&ServerKey (or just SaltedPassword) for later reauthentication to the same service, as it is likely that the server is going to advertise the same salt value upon reauthentication. This might be useful for mobile clients where CPU usage is a concern." |