Can I slow down a brute force attack by encoding password input data?

Question

I'm building a php login form with only a username & password as $_POST data. But before submitting the form, a JS function check() will base64_encode the password input, then finally submits the form like this: (the customized base64_enc function is a little bit more advance than just a base64 encode)

function check() {
   var pwd = $_get_by_id('loginPw').value;
   $_get_by_id('loginPw').value = base64_enc(pwd);
   $_get_by_id('loginFrm').submit();
}

Of course, beside that, I know we have pleinty of security things to prevent the brute force (session id, csrf token, captcha, tempo ban...).

But I wonder if, at this point, this simple javascript trick could slow down an attack ? (Even the attacker must generate another processed version of his/her dictionaries)

For example if hydra tool can process each line of wordlist before running a thread (with a shell code version of what we have in the javascript check() fn)

Answer 1

Can I slow down a brute force attack by encoding password input data?

Yes, you can artificially slow down a brute-force attack by having the client perform an expensive task for each login attempt. This concept is called a proof of work. It's a well-known approach to fight mass spam and technically you could also apply it to authentication systems on the web.

However, your concrete proposal wouldn't qualify as a proof-of-work protocol. That's because base64 isn't expensive at all and requires an equal amount of work for the client to generate as it does for the server to verify. Also, an attacker could reuse the encoded passwords as often as they like without having to recompute them, e.g. to attack other accounts.

For a real proof-of-work implementation, you could e.g. build a challenge-response scheme and require the user to perform expensive hash computations on each login attempt. The challenge could be to partially invert a hash: You provide a random sequence and challenge the user to generate a SHA-256 hash ending with that very sequence. Increasing the length of the sequence requires exponentially more hash computations by the client but verifying the results is always just a string comparison.

The project "proof-of-work-login" is one of the few real-life examples I found that pick up the idea of using a POW for logins. (I can't comment on the quality of the implementation though.) From the description:

A client side SHA256 hash must be calculated before allowing a login. This limits bruteforce login attacks in environments where you can't ban by IP like Hidden Services.

Nevertheless, you should bear in mind that for web applications there are simpler means to obstruct brute-force attacks such as CAPTCHAs, limiting login attempts per account, blacklisting IPs, etc.

Answer 2

No, this idea won't slow down an attacker, because the encoded password is the password-- it is the value that an HTTP client needs to access the system. The original password is almost incidental at that point. Instead, the hacker will turn his attention to iterating through Base64 strings instead of passwords, and the total entropy will be exactly the same. Also, if the hacker has a dictionary of passwords, it is trivial to generate a dictionary of Base64 strings comprising the same exact list.

However, it is not a terrible idea to slow down an attacker by asking him to solve a complex problem. CAPTCHA is the most common example-- hacker tools can figure out how to solve a CAPTCHA, but it does require a bit of CPU and will reduce the number of brute force attempts per second. Solving any complex problem would do the same, e.g. if in addition to submitting the password the script also had to guess the value behind a hash (based on a random and unrelated value) that is provided by the server. But you would want to keep that mechanism completely separate from the password.

Answer 3

It won't change anything to the attacker. He won't even need to update his dictionaries.

The attack generates passwords, and sends them to a function which will do the HTTP request. The attacker has to select the URL to target, name the parameters. Encoding the password in that function isn't slow. It's orders of magnitude faster than the HTTP request, and the impact on the request size will be so small that it won't have any effect at all.