No, you should aim to make your server secure, but NEVER assume it is totally secure. Security should be layered. This mistake is too common.
It sounds like you might be getting confused with hashing. Hashed content can often be easily unhashed using rainbow tables. Encrypting definately adds security. A strong encryption is almost impossible to decrypt without the key. So you need to make sure your keys are kept safe.
In most cases encrypted data is easier to decrypt than hashed data. To decrypt encrypted data all you need is the key and the code needs to have that available in order to be able to do the decryption for use on the site.
Where the code and the database are on the same server encryption only prevents casual inspection of the data. Only where they are on completely separate servers in different data centres would encryption provide any real security.
Hashed data on the other hand is generally as secure as it can be since with a proper hash designed for the purpose it would take millions of years to construct a rainbow table to extract the data since each field would need its own completely different rainbow table. Of course hashes can only be used for passwords and similar because the system has no way to retrieve the original value that the hash was created from.
As the pin codes need to be shown to the user after peroccessing payment, they are sold, hashing isn’t the case here. I should be able to decrypt the codes from db.
As I got, having the php source code in a separate server from db server i increase the security.
So in one server I need to store the encryption key and source code, and then connect to an external db server? Am I right?
Is it the only secure option?
How to lower the risk, if we do it in one server?
The encrypted copy in the database only protects against those with direct access to the database rather than via the application. Via the application the data all gets decrypted first thing.
Server security can be set up so that the database is only directly accessible from the server running the application (or not externally accessible at all when both are running on the same server). That means that they need to either break into your account (and other security measures will reduce the chance of that) or have physical access to the server.
Where the data is encrypted and someone has physical access to the server (the only way not prevented by other security measures) then if the code is on a server at the same location then that person could if they wanted to get the key and decrypt the data as they will have access to both. So encryption really only protects confidential data from being viewed accidentally while the person is doing their job maintaining the system, if they wanted to breach their conditions of employment and steal your data then having it encrypted is no protection unless the code runs on a server at a different data centre - which would make it more secure from those at the physical location but make it easier to break in remotely. Also encrypted data makes it more likely that a would be thief would target your data rather than data stored in plain text as the encryption shows that you have something worth trying to protect.
Far more important than encrypting the data in the database is the security measures to keep people from being able to access it at all such as the security measures built into your scripts to properly validate all inputs and to keep code and data separate as much as possible so as to reduce or eliminate the possibility of code injection.
Thats a good point, keeping the key safe is a challenge on its own. But if you can keep the key safe, then some encryption algorithms are considered impossible to crack.
Would it not be suitable to create a new voucher code at the time when it is issued, send it to the user, and store it hashed in the database? Then the only person who knows the voucher code is the user (assuming no spyware is installed, and the user hasn’t shared the voucher code with anyone else), and the only way it can be checked to be valid is against your database. The actual original voucher code is not stored anywhere, and it destroyed after it is created. To check if a users voucher code is valid, you simply hash the voucher code they give you, compare it with the hashed codes in the database, and then you can find the row with data assosiated with that voucher code and determine if it is valid.
You need to use a strong hash though, some of the common ones have rainbow tables like I said before.
Always assume everything you store in a database at some time will come in hand of somebody that shouldn´t have it. Therefor, data that´s critical, should always be encrypted in a non-reversible way. Always.
I’m just wondering what would be the benefits of having database in a separate datacenter, if someone with physical access can see the source code on the first server. He checks the sources and get all things including encryption key, the remote database connections parameters, etc. So he does what I do to connect to the database from the first server and get all data decrypted. Am I right?
in this case to difference between 1 server or 2 server.