I've just inherited a project where all the passwords on the server side are simply converted to base64 and put in the database. No salt, no hash, nothing. Just a simple db.Add(password.ToBase64) kind of process.

Surely anyone who gets their hands on that data can extremely easily decode it? Hence the usual salt/hash approach.

I questioned the decision to use base64 strings and was told:

Regarding password - If someone is already on your server, you are already under threat irrespective or the encryption you choose. Its same even with someone penetrates your SSL layer itself.

This seems to ignore the fact that hacking into a server is not the only way to access a database. It could be as easy as going through someone's unguarded computer, stumbling across a database backup and seeing the blindingly obvious base64 strings, then joyously converting them all to raw passwords.

I know this question is probably a little bit too open-ended for the ususal StackExchange format, but the issue doesn't seem to be very well covered on here with the question wording I've used. It's a pretty important topic so I thought I'd throw it up.

To me it's utterly obvious that passwords shouldn't be stored using only base64 conversion, but I'm still relatively new to all this so maybe I've missed something.


  • 1
    Man, base64 is not encryption, it is just an encoding. Base64 is useful for sending data thru HTTP or similar but NEVER use it to store securely your data, NEVER. Also the passwords neither should be stored encrypted, they should be hashed in a one way hash algoritm, then after hashing the password you could encode it in base64. Anyone who could gain access to the data would get immediately the text plain passwords if they are only encoded in base64. Don't make the hackers life easier – Osakr Sep 28 '18 at 7:55
  • It sounds like they understand that Base-64-encoding isn't encryption. I mean, it sounds like they're saying that they don't believe that encryption is necessary because security has already been breached, rather than arguing for the merits of Base-64 as some sort of secure encoding scheme. So, your question's probably moreso about if it's okay to store passwords in plain text, where the the plain text being in Base-64-encoding is just a detail. – Nat Sep 28 '18 at 8:03
  • It is like not locking your house. Even a house in the Artic need to be locked to prevent bear intrusion. So if the db is not going to the connect to the internet, this shouldn't be taken for granted. The extra line of code and testing shouldn't take more than 2 weeks of work. – mootmoot Sep 28 '18 at 8:51
  • For me is the same storing the passwords in b64 and text plain. Providing a simple blowfish hashing to the passwords is one day of work at maxium – Osakr Sep 28 '18 at 8:52
  • This question has been covered quite extensively under 2 areas: 1) Why do we need to hash passwords? and 2) Why storing passwords in plain text is a problem. The fact that base64 has been used is meaningless as it is not a control or a protection of any kind; it's an encoding. So, you can equate your system's process with storing passwords in plain text. – schroeder Sep 28 '18 at 9:00

TLDR: Never store passwords as base64, so you are correct in that it is a very bad practice.

Surely anyone who gets their hands on that data can extremely easily decrypt it?

Well, there is nothing to decrypt. Base64 is not an encryption, it is an encoding. It's role is to make sure the password can be stored in the database nicely and special characters aren't a problem. It does nothing to protect the password. From security standpoint, it is exactly the same as storing it without any encoding.

This seems to ignore the fact that hacking into a server is not the only way to access a database.

That quote seems to ignore a lot of things. There are several reasons to hash passwords and they have nothing to do with preventing initial compromise of your server. As mentioned, hashing does nothing to prevent that. Here are some reasons to hash passwords:

  1. If your system is temporarily compromised, it allows you to recover. Thing about this scenario. Your server is compromised and your database stolen. Yes, all the personal data about your customers is leaked, nothing to do about that. But if the passwords are hashed, you can just send an email to all your customers urging them to change their passwords once the compromise is resolved. You have some level of certainty, that the user who knows the password and has access to the email is the proper user, as the attacker does not have the passwords.
  2. If your system is compromised, it protects your customer in case they use the same password on multiple services. The first thing an attacker may likely try to do with a leaked DB of plain-text passwords is try the email password combination on popular sites like Facebook.
  3. Someone with legitimate access to the server may use someone else's password to mask his tracks. Imagine a scenario where an admin has full access to the server, but everything he does is logged. If he tries to do something nefarious, it would be easy to figure out it was him. But if he just pulls a password of a different users, that may not be easy or even possible to figure out.
  4. Limit a compromise. An attacker that gained access to the DB may not have full access to the server. However, if he can pull admins password from the database and log as said admin or even just other users, he may get access he would not be able to get otherwise.
  • Thanks, and I've changed my question wording to remove the mention of 'decryption' since it's actually basic decoding. So basically my thoughts were correct - base64 encoding is a very silly way to store passwords! – Stuart Aitken Sep 28 '18 at 8:10
  • Also, I may be wrong here, but doesn't hashing also help prevent the likes of a side-channel timing attack (if no other security measures such as max login attempts are in place)? – JᴀʏMᴇᴇ Sep 28 '18 at 8:11
  • @JᴀʏMᴇᴇ Well that is a complex question that I am not sure I can answer fully. Hashing may be able to stop some types of attacks but it may allow other types. Also, timing attacks have nothing to do with max login attempts, you are probably thinking of brute-force/dictionary attacks. Hashing does make those a tiny bit harder by exhausting your server's resources, but you should never rely on that. It would be very bad if that ever came into play, as it would mean at the very least the attacker is successfully DoS-ing your server. – Peter Harmann Sep 28 '18 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.