Does ASP.net EventValidation and ViewState mitigate brute force attacks?

Question

One of my responsibilities at my new job pertains to network security and after I ran a directory traversal tool against our old web server I found that the admin login page to the Content Management System is unrestricted and is accessible through the internet.

I brought this to the attention of my boss who said that since the "EventValidation" and "ViewState" parameters are set, it's protected against a brute forcing applications like Hydra or Medusa. This doesn't really sit well with me because there is no reCAPTCHA or account lock-out policy in place on the web form.

I've tried to do some research on these parameters and how they affect brute force attacks but I'm not finding anything concrete, if anyone could point me in the right direction or shed some light on this issue I'd really appreciate it!

Answer 1

ViewState is not a security measure against brute force. All it is, is an encoded set of key / value pairs which is used to mimic state between page loads (post backs) that gets stuffed in a hidden input. ViewState kinda-can-not-really help with protecting against CSRF if you use a user key with the ViewState. The user key acts as an anti-forgery token.

Event validation is a security measure, but it doesn't mitigate a bruce force attack. Event validation's purpose is to make sure that the POST event's trigger is actually possible. For example, if the ASP.NET page determines that the source of a post back is a submit button called "Foo", but the "Foo" button was not rendered, then an exception is thrown because it appears that an invisible button was clicked.

Neither of these will prevent a bruce force attack on a log in form. Indeed, if you can do it over-and-over again from a browser, then all an attacker has to do is automate that.

There are a lot of things to you can do to limit bruce force attacks.

• Rate limit the attempts. Many systems will prevent login attempts for a period of time after N consecutive log in failure, like "5 tries, then you have to wait 20 minutes".
• Escalate the authentication requirements. After N failures, add a CAPTCHA. After another N failures, ask for some secondary information, or add an additional factor.