Is it a bad idea to use base-64 encoded strings for passwords?

Question

First off, forgive me if this seems like an extremely naive and un-educated question. Any ways, so as above, is it a bad idea? I mean, thinking about it, it doesn't seem like a bad idea. My logic is this:

Sites should store passwords securely anyway, with salts and hashes (and sometimes peppers). Using a standard password such as Password (for examples sake only) this would be salted and hashed into a much more "unreadable" format for storage when used for an account on a website. If done as it should be, should take a while for anyone to decrypt the password.

Now if I base-64 Password into UGFzc3dvcmQ= and then use that as my password - I already have an additional 3 characters and then included that being salted and hashed - Should create a more secure hashed password? Right?

Does base 64 ultimately cause a password to be any more secure? Do websites either base-64 encode / decode before salting and hashing?

I get that if someone does manage to get the password DB and has a list of all the hashes, and assuming they manage to decrypt my password back to UGFzc3dvcmQ= I get that its an easy guess to base 64 decode it, as its an obvious looking string.

Ultimately, will it serve me better using base 64 encoded password as opposed to full on cleartext? Also, what if I perform multiple encodings adding additional characters between encodes? For example:

password > UGFzc3dvcmQ= > U**E**GFz**n**c3**C**dv**o**cm**d**Q**E**= > VUVHRnpuYzNDZHZvY21kUUU9

Answer 1

All questions of the type "Will this clever trick make my password any safer?" depends on the same thing: What passwords does the attacker try first when brute forcing the hash? The person attacking you is not stupid, and she will try the things that are most likely to succeed first, and the less likely ones later.

Unless the attacker is specifically targeting you, and knows about your encoding scheme, she is more likely to try the unencoded password before the encoded password. So in that sense, this is a win for you (at least until everybody starts doing it and it gets so common attackers starts trying this kind of thing early).

But is it very practical? Are you going to memorize the encoded string? Then why not just memorize something random (and thereby safer) instead? Are you going to use some online service to encode the password every time you use it? Then you might have it sent over HTTP and recorded in logs all over the internet, and thats not very good. So are you going to install some software thad does the encoding locally? Then why not just install a real password manager instead?

So yes, in a narrow sense UGFzc3dvcmQ= is a better password than password. But no, this does not alleviate the need for completely random passwords and password managers.

Answer 2

As long as your password is complex enough, not dictionary based etc it makes no difference how you remember it. It's how it's stored and secured that counts. Adding an extra step by B64 encoding it won't make it any more secure if the result is then just stored as an MD5 hash.

What you are doing though is moving away from usability towards security with a dose of impracticality for the end user. :)

Answer 3

Think about it like this. When you choose a password for an account on a website you have to rely on the website that it does a proper job of hashing the password. Choosing a weak password like 'password' and encoding (encoding offers really no benefit to plain text passwords, here is a site were you can decode base64 encoded strings: https://www.base64decode.org/) is always a bad idea because your password can be badly secured in their database. So first choose a password that is unique, long enough and random. These kind of weird constructs of encoding adding characters and encoding again are totally unnecessary, my advice is to just use a password manager that can generate (and remind) good random password for you.