Is it a good idea to hash data with my own custom logic?

Question

I will be storing personal user information in my MySQL database, such as passwords, e-mail addresses and phone numbers. I was wondering if it's a good idea to encrypt this data with my own logic, or to use existing hash functions instead? Just to give you a simple example of what I was thinking of: if a user chooses 'pass' as his password, on the client side of the database connection I would set my encrypted password to be the chosen password's characters mingled with a bunch of other random characters. For example: I would choose to have the first character of 'pass' to be the 3rd character of the encrypted, the second character would be the 9th, the third would be the 11th and the fourth would be the 16th. That way the encrypted password would be stored in the database like this:

0fpdr76ga5sy022sch09 (this is just a simplified example, the actual encryption will be a little longer and a little more complicated)

As you can see, the chosen password is 'hidden' in the encrypted password (the letters in bold) and I am the only one who knows where the password's characters are (assuming no one will ever get access to my application's source code, where the encrypting and decrypting actually happens). If I want to retrieve the password from the database I would know exactly how to decrypt it and get to the actual password, while an outsider would not know what to do with it if he ever got his hands on my data. This is my just my assumption, though, I'm still very new to the programming world, so I was wondering if a more experienced programmer could give me some advice on this. Is this a safe approach? And if not, why? What are the risks and/or downsides to doing it like this?

Answer 1

I was wondering if it's a good idea to encrypt this data with my own logic

It’s not, because…

assuming no one will ever get access to my application's source code

… this isn’t a good assumption, and because…

If I want to retrieve the password from the database I would know exactly how to decrypt it and get to the actual password

… you shouldn’t be able to do this. People have a tendency of reusing passwords, and you shouldn’t have easy access to their other accounts just because they did that (even though it’s a bad idea).

Use an existing hash designed for passwords. If you’re using PHP – it seems like a decent guess going by the MySQL – that’s password_hash. It is both easier and safer than rolling your own.

As for your example: it’s bad. You can just try every subsequence of 0fpdr76ga5sy022sch09 – there are only 2^20, and that’s assuming you ignore clues like “subsequences that look like words”. Schemes like that also let you know the length of the password and which characters it doesn’t contain. (This paragraph’s tone is also generally a pretty big understatement of how bad it is. Seriously, do not use anything like this scheme to protect anything, ever.)

Answer 2

With this logic, you are just scrambling data (hiding it from plain site), but its very easy to retrieve it using algorithms available. (trust me, it takes less than few millisecond for a computer to break this code).

Similar questions are already answered on forum. Best way to store password in database, please check that.

if you are curious on the topic of encryption, a best place to start would be The Code Book

Answer 3

NO.

This is not a good idea, for several reasons:

• If you fear that someone will be able to access your database (that's why you want to encrypt it, right?), then you should also fear that they will be able to access your source-code, wich means your whole scheme falls apart from the start.
• even if you manage to keep your algorithm for encryption safe, chances are someone able to access your DB will be able to get some information out of it anyway (either by brute force, or using something like statistical analysis to search for known or common passwords, etc). Encryption is a complicated science. It's best to leave the technical details to the experts.
• This may be a little beyond what you are considering right now, but if you DO get hacked, and some or all of your data is leaked, you will probably have a harder time explaining it to your users if it happened because you had "home-made" security. For my part at least, I would be more forgiving of a data leak if I knew you had made a real effort to apply security measures that are up to date and generally accepted as trustworthy by the industry.

In short: It's best to leave encryption to the experts. Instead of building you own, your're most likely better off looking for a good way to apply their solutions to your particular situation.

Answer 4

Nooo. Please Nooo. DO NOT DO THAT.

Just that it looks pretty secure to you doesn't mean it is. There is a common saying attributed to Bruce Schneier says that "any person can invent a security system so clever that she or he can't think of how to break it." The challenge is to design a system that others won't be able to break. That's why it's a good practice to err on the side of tried and test algorithms. If it's for fun, go ahead and design your won crypto algorithms, but don't bet people's privacy and your company's reputation on that.

The Creator of PGP, Phil Zimmermann was quoted saying:

When I was in college in the early 70s, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful government intelligence agencies. I felt so smug about my achievement.

Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme.

From this humbling experience I learned how easy it is to fall into a false sense of security when devising an encryption algorithm. Most people don’t realize how fiendishly difficult it is to devise an encryption algorithm that can withstand a prolonged and determined attack by a resourceful opponent.

Since you're using PHP and MYSQL, the password_hash function suggested above would be pretty easy to use and pretty secure. If you are looking for more features (various security policies, access control, key management, audit logs etc.) then you will need to look into commercial solutions. MyDiamo will give you all that you need with more features and assurance that your system is secure. Give it a try...they have a free version.