Security implications of using an algorithm to lengthen and salt passwords before using them?

Question

I have created a JavaScript bookmarklet which, among other things, base64 encodes my plain-text passwords combined with information from the site's domain name. The idea is that base64 output is significantly longer than its source, and the domain info keeps the same password from generating the same output if reused on a different site. You could also salt this with your own personal key, should multiple people be using the same algorithm. As long as it has predictable output the idea is that you could use it to make human readable passwords the length of a strong computer generated one. I don't see any downsides to doing this, but I'm not a security expert and I have a feeling that I'm not seeing something here that could actually weaken a good password's inherent security. Am I? If so, what is it and can it be fixed?

For your consideration here's a simplified version of the script I'm using that shows the basic idea:

(function() {
    var pwelements = document.querySelectorAll("input[type='password']");
    for (var i in pwelements) {
        var pw = btoa(pwelements[i].value + window.location.hostname.replace('www.', '').substring(0, 10));
        pwelements[i].value = pw;
    }
    return false;
})();

Using this script with the word "test" on https://password.kaspersky.com/ takes the estimated crack time from 1 second to "10000+ Centuries" (or 98 centuries if using a super computer). Obviously these sorts of password checkers are inherently flawed, but it serves to illustrate the difference I'm hoping to achieve with this. The encoded results of "test" passed through this algorithm is "dGVzdHBhc3N3b3JkLms=". Real passwords typically produce much longer output.

If this sort of thing is a good idea, is it possible to create a version of this which could be fully open-source but not compromise the security of passwords using it? Right now this is all reversible if you know the algorithm and know the output, the only saving grace is that if user specific salt was used then, once hashed server side it shouldn't be possible to just run an attack through this algorithm to brute force using the plain-text version (without knowing the salt)... I think? I think that the salt would serve as a form of two-factor authentication, but I am unsure of how effective this would be. As far as I can tell this is at least no worse than using the original password normally.

I'm convinced there is a reason this is a bad idea, but I don't know what it is.

Answer 1

I'd say that it doesn't add much. Base64 is just an encoding, it doesn't add any entropy to your password.

It's also quick to compute so it won't slow down a brute-force attack.

The only thing it can prevent is an attack against an universal rainbow table that didn't take into account the base64, but maybe some rainbow table out there did take this into account. It wouldn't be more complicated to compute that a standard rainbow table. The only good way to prevent a rainbow table attack is to use a salt.

Also, always assume that the salt is known. The purpose is to prevent rainbow tables not brute-force attack. The best way to prevent brute-force attack is to use a slow hashing process like bcrypt.