Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I am having no success on brute-forcing HTTPS form (username and password), that has XSRF token and per-request session cookie, using Hydra.
I want to know if the presence of XSRF token and per-request session cookie mitigates the security risk of brute-forcing login credentials?
Disallowing login attempts that don't have a valid cookie/token (indicating that the client loaded the page before submitting the request) and having that cookie/token be single-use (so you can't just load the page once and then submit a bunch of requests with those credentials) is, in theory, a valid way to slow down login brute-force attempts. A tool can still automate the process, but it needs to make a request and receive the response for each attempt, rather than firing off requests as fast as possible, usually leading to having multiple requests in flight at once.
There are problems with this approach, though. For one thing, it's hard to scale. You can't easily load-balance your login attempts - which is important to do if you have a lot of traffic and an appropriately-expensive password hashing function - because the single-use-ness of the token breaks down if multiple "valid" requests get balanced across multiple servers and the servers' list of valid tokens isn't kept perfectly in sync. For another, it's not actually going to prevent automated brute-force - at worst, the tool simply needs to scrape the responses for the values it includes in its next request - the way a CAPTCHA will. It also becomes harder to create a tool that authenticates (with valid credentials) automatically, which is sometimes valuable to enable.
