Forum Discussion
ColinConrad
Nimbostratus
NimbostratusCase insensitivity in ASM Brute Force username and/or password elements
I have a login page I'm attempting to enable brute force protection for (JSON/AJAX auth type), and it supports username and password JSON elements that are case insensitive from our application's perspective, meaning we expect clients to send them with inconsistent casing. The help text shows that the F5 BIG-IP expects these parameters to be case sensitive, which makes me think that even if we used an ASM policy with case sensitivity disabled during creation, it would still be treated as case sensitive. Frankly even if this did work as a workaround, I'm not sure I'd want to do this because I don't want everything in the policy to be case insensitive - just these few login elements. Also I'm not able to create a "duplicate" login URL where each one uses a different case for the username and/or password elements - the ASM policy prevents this. What is the recommendation for how to implement brute force protection for username and/or password parameters that can be sent with multiple cases?
AbhishekMaratHi Colin,
We have the exact same issue/concern regarding the username/password JSON element in the Login page properties. Glad we are not the only ones with this issue. Did you get a response on how to resolve this? Perhaps, opened a F5 support case for this? Let me know when you get a chance on how things worked out for you. Appreciate your time on this.
Thank you!
gulyHi guys, I'm facing the same issue as you do. Did you get any response from support? This is really unexpected behaviour, when the whole policy is case insensitive.
Thanks.
ColinConradI never got a response on this question. What I ended up doing was working with our application teams to ensure that our client code would always send the usernames/passwords with a given case, and then I implemented a Brute Force policy for that known-good scenario, and wrote an iRule to deny any requests that do not conform to this casing, knowing that they would all be illegitimate. I'm sure there are other ways of solving this, but I'm still not sure about the "best approach". Another way I considered was having a dedicated ASM policy just for Brute Force where the whole policy defined as case insensitive, and using a Local Traffic Policy that looked for our application's login URIs and using this dedicated policy in that scenario. I hope these ideas help.