Is it enough to save all my fields in mysql as base64?

Question

I have not santized user inputs and data comming from url etc what i did is i encoded each and every thing in database as base64 even id of tables primary keys.. is it enough to fight against vulnerabilities ?

Answer 1

What is the vulnerability you are protecting against? as stated by Mat, you'd be immune to SQL injection but that would be all.

In addition, it is worth noting that base_64 encoding has no security value beyond the removal of SQL injection and it is obvious to any viewer that your data is base_64 encoded, so it is easy to crack.

Might I suggest you read the work of OWASP before you go any further. Some of it is a little dry but most is valuable pre-reading for any web developer. If you just make sure you are covered for their top 10, that will do for a start.

To give some pointers for reading:

DO think about your data. Anything sensitive should be protected. The truly paranoid might consider AES encryption but frankly unless you are storing health, financial or military data, that is probably overkill. Keep your key secret - anyone who can download your db can probably download your key. There are ways to prevent this BTW but your question suggests you are not quite at that level yet. Where you can, don't encrypt keys as it prevents indexing, and leave trivial data unencrypted. but DO make sure that unencrypted data cannot be used to draw significant conclusions about encrypted data.

DO store passwords as salted hashes. At least if your db is compromised, the hacker will not be able to attack your users' other accounts (they WILL use the same password...)

DON'T use email addresses as usernames AND password resets. It's either/or

DON'T DIY security solutions. AES is good enough for anything short of CIA after all.

DO obfuscate your keys in HTML - there are lots of simple obfuscators on the net.

Do check for an authenticated session for EVERY page that accesses your DB ESPECIALLY AJAX scripts.

DON'T rely on client side authentication - that only stops the stupid. Malicious people can get round it very easily.

FINALLY-

DO use prepared statements for ALL user input.

Sorry to go on a bit, but these issues come up in one form or another every day in this forum and it is worth having a bit of a repeat of them.

Once you are doing/not doing everything on the above list, you will be immune to most serious problems though still far from secure. I have deliberately not fully explained any of the methods as you will learn a huge amount about application security by googling them and reading around a bit.

have fun...

EDIT to answer the comment below.

There is nothing inherently wrong with using base_64 encoding as a means to beat SQL injection. It is completely reliable as base_64 encoding does not include any characters that can upset the sql.

There are a few reasons not to though:

-It is very data intensive, taking a lot more space to store your data. -It makes searching through your data very inefficient. -It makes it hard for you to read your data but not harder for an attacker. -It provides no effective password protection (use a salted hash for these please).

echo base64_encode("Abcde")."<BR>".base64_encode("cd"); 

demonstrates the search and size issues effectively - you can't use LIKE or wildcards effectively without an extra instruction - WHERE from_base64(field) LIKE '%cd%' will work if you have mysql 5.6.1 or above.

If it suits your particular needs to do it this way, then well and good but I put it to you that you are not learning to do this properly. If you use prepared statements instead, you can store your data efficiently, indexably, scalably, searchably, securely, human-readably and easily-debuggably.
What you are doing will work well enough for a very small site but not for anything larger.

Answer 2

No, it's not.

All you'll manage to do with that (apart from wasted CPU and space in your database) is to store unsafe data. If done correctly you've protected yourself against SQL injection. But that's all. As soon as you decode the data, you're back with all the problems of unsanitized data.

So unless you're planning to never do anything with what you've stored, you're not safe.