3 ms·
I strongly agree with the conclusion that the libraries should reject input they can't correctly handle instead of silently truncating it. I co-maintain a rate
by nfriedly 2y ago
I strongly agree with the conclusion that the libraries should reject input they can't correctly handle instead of silently truncating it.
I co-maintain a rate-limiting library that had some similar rough edges, where it wouldn't always be obvious that you were doing it wrong. (For example: limiting the IP of your reverse proxy rather than the end user, or the inverse: blindly accepting any X-Forwarded-For header, including those potentially set by a malicious user.) A couple years back, I spent some time adding in runtime checks that detect those kinds of issues and log a warning. Since then, we've had a significant reduction in the amount of not-a-bug reports and, I assume, significantly fewer users with incorrect configurations.
- deepsun 2y agoIf the input is 71 character, all the libraries happily accept it, but an attacker needs to guess only 1 character.
- arccy 2y agohave separate salt / pepper / user id args
- tedunangst 2y agoHow is the library supposed to know you're doing that wrong?
- cmgriffing 2y agoIf these tools had a runtime check, then the cache key creation would have failed out. 72 is the max length of id, username, and password combined. If that combination is over 72, then failure and the cache key would not have been created. So, no, the attacker would not need to guess only one character of a password.