Let's assume for a moment that an intruder has rooted your server. A hacker now has access to your DB which has salted user credentials in it. Assuming you store a unique salt string in each record, you are semi-protected as the hacker would then have to use a library of hashes for each record using the records salt to see if it gets a hit, which I guess is quite a pain but obtainable.

Certain frameworks such as CakePHP use a static salt string. As the intruder I could then very easily convert my library to that salt and have a go with your users. If something such as ionCube were used on top of CakePHP, would that just about lock it up for an attacker or would they have ability to still obtain some source code?

Indeed. Though I'm looking at keeping users data safe before my own server.

That is backwards, you cannot keep user data safe if your own servers are not. You must start with a strong foundation, security must be implemented at the lowest levels (sever, network) before your work on the higher levels (application).

As logic_earth says, in the event your server has been rooted (which is actually the worst nightmare we can have in this business), you are seriously screwed.

In these scenarios it is best to actually think about this as the person breaking in, compared to as the developer writing the script. Let's setup a few cases and what could happen.

1. You have used ioncube or zend on the files. This does protect your files from being initially reviewed, and of course the salt string to be shown.

However, it will not take too long with some investigation and using debugging + use of reflection to get the information you need. Of course by having root access, you would have put these files into a tarball and downloaded them. Please note that no matter the restrictions you have on the encrypted files/license, it wont be a problem to manipulate yourself around those and run the files on a local server.

In addition you would of course dump the information you needed from the database, so you have it for the future.

2. You have left the files open.In this case the person has access to review the files and get the salt string right away without too much work. And of course he would then get the database information.

As you can see out of the two, the first one will give you a little more protection, especially if the rooting was done by a script kiddie. But only then.

In addition, in both cases as the intruder I would be updating your system so that it would leave me a backdoor in case I lose root, but also update it so it would also store your users passwords in clear text the next time they logged in. That way I don't need to brute force some of them.

Please note that this is just as SIMPLE to do no matter if the files are encrypted or not. In the event they are encrypted all you need to do is rename the real file to a new filename, and create a new file where you store the content of the POST first, and then include the real file.

So in short, if the server get rooted/breached you are really screwed since that equal to give the intruder access to everything, and your code can be as secure as possible but unless the server is also updated and secured, it is not really worth that much. If you do not trust a hosting service, I would stay far away from it if your planning to host anything else than personal websites.

As I understand it, ionCube converts PHP source into byte code. With a little time, and the help of an automated tool, that byte code can be converted back into human readable source. And if the attacker doesn't need the entire source, just one string, then it's even easier.

Short answer, ionCube will delay, but not stop, an attacker.

Even better answer... If anyone is using a static salt, slap 'em upside the head.

This is where I believe having separate Database and Application servers makes sense. If a hacker gets a hold of one, they still have to work to get a hold of the other. Likewise, limit the access of your database user. For example, deny all direct access to tables, instead grant access to stored procedures and views (if and only if the view does not contain sensitive information).

If you have a variable salt, yes the hacker may have the source code, but does not have direct access to the database. If the attacker has access to the database, and you salted your passwords (and did not store it in a table), then he is limited in trying to guess the salts to crack the passwords.

In the end, if an attack has access to a server, you are likely only buying yourself time as he works to figure out how to get the information he wants/needs. Chances are in time he'll figure it out, but hopefully by then you could have adjusted your code and servers accordingly to keep your users better protected.

Even better answer... If anyone is using a static salt, slap 'em upside the head.

Since a intruder don't need to read your code, in the event a file is encoded using ioncube/zend, all you need is to write some reflection code together with using some debugging tools.

In the end all use of "salts" when hashing passwords are "static", and no matter how you implement it there is no way around the fact that with a server breach it wont help you squat. It only helps when other parts of the system has been breached.

cpradio:

This is where I believe having separate Database and Application servers makes sense. If a hacker gets a hold of one, they still have to work to get a hold of the other. Likewise, limit the access of your database user. For example, deny all direct access to tables, instead grant access to stored procedures and views (if and only if the view does not contain sensitive information).

Yes, this is something that is recommended on all larger sites or if you store vital information.

Normally a database cluster will be located on a private network or behind closed down hardware firewalls, so getting access to those servers are usually more difficult than the actual web servers.

However, in the event your web server is breached you are not really any more protected, other that they wont be able to dump the database. Since your web server will need to be able to get the data from the database, the intruder will be able as well.

In addition by installing a sniffer software, they can in worst case also get further access to the internal network and servers.

In the end all use of "salts" when hashing passwords are "static", and no matter how you implement it there is no way around the fact that with a server breach it wont help you squat. It only helps when other parts of the system has been breached.

Also it shouldn't make a difference to your security if someone can read the salt unless they already have a rainbow table that includes that salt. The fact that there is something added to the password before it is hashed is what "protects" the password - not whether the attacker knows what that extra value is or not.

Also it shouldn't make a difference to your security if someone can read the salt unless they already have a rainbow table that includes that salt. The fact that there is something added to the password before it is hashed is what "protects" the password - not whether the attacker knows what that extra value is or not.

That is true, but knowing the salt and the way it is applied does help if your trying to brute force. Since by knowing that you can limit your brute forcing to for example 16 characters in max length, since few people have longer passwords, while if you try to brute force without knowing the salt or how its applied, you would need to set the brute forcing to at least 100-200 characters max length.

So resource wise, knowing the salt and not least how it is applied does help a lot even if it wont give you the passwords directly.

If were are going to talk about salting now...I'll add my two bits. I'm in the camp that does both, a single site-wide salt that is applied to everyone, a user-specific salt where every user has their own salt, I refer to it as salting and peppering.

That is true, but knowing the salt and the way it is applied does help if your trying to brute force. Since by knowing that you can limit your brute forcing to for example 16 characters in max length, since few people have longer passwords, while if you try to brute force without knowing the salt or how its applied, you would need to set the brute forcing to at least 100-200 characters max length.

Knowing the salt doesn't change the length of password you need to test for. The attacker is looking for a value that will produce the desired hash to get them in - whether that is the password that the owner uses or a different value that maps to the same hash is irrelevant. For a brute force approach the number of possible values needing testing is determined by the type of hash used and is not affected by any salt and/or pepper that is applied.

Applying a salt prevents the use of rainbow tables to find a value that will work as the password - since all that is required to find a value that will produce a given hash is to simply record values and their hashes until you have a value for every possible hash and then you can do a reverse lookup of that data to get a value that will work as a password for any unsalted password using that hashing algorithm. When you add a salt then you'd need to repeat the entire process using that salt in order to build a rainbow table for that salt.

Using a brute force attack instead would take the same number of tries on average regardless of any salt or not.

Using a pepper instead of or as well as the salt means that finding a rainbow table to get you into one account doesn't also get you into all the others.

Using a pepper instead of or as well as the salt means that finding a rainbow table to get you into one account doesn't also get you into all the others.

Using a unique salt for each password is what prevents a rainbow table from being reused for other passwords. A pepper is more like encryption, where the pepper is a private key, and it prevents attackers from brute-forcing passwords, because they won't know the pepper to mix it with before hashing.

Also it shouldn't make a difference to your security if someone can read the salt unless they already have a rainbow table that includes that salt. The fact that there is something added to the password before it is hashed is what "protects" the password - not whether the attacker knows what that extra value is or not.

Creating a new column with your sites static salted md5s is no task at all. If I have salted all my user passwords with the same salt, an attacker can take their rainbow table and apply that salt to his dictionary probably in a matter of hours. However, if the salt is unique to each record, he would then have to do the same for each record in your db. That is a bit more of a task with today's computing power.

So we've learned that something like Zends Encryption or ionCube is just a slight delay to the inevitable. It's best to not use a static salt thats stored in your source code anyway and create a unique salt for each record in your table...

How strong is a unique salt? Do we need more? I wonder if creating some sort of compiled executible for password handling would help. Inside of this executible would be a second salt on top of the one stored in the record. Without seeing the source of this executable, there should be no possibility of using a rainbow table. Can compiled C++ executibles be encoded to be unreadable better than PHP?

In the crypto world, a solution is considered secure if the only option available to an attacker is to guess keys or passwords one by one until they happen to stumble across the right one. After implementing a unique salt, you'll have a secure solution. At that point, all an attacker can do is guess passwords one by one per user until he finds the correct one.

It certainly doesn't hurt to add on top compiling or obfuscating or peppering, but all those are just gravy once you have the cryptographically secure solution.

In the crypto world, a solution is considered secure if the only option available to an attacker is to guess keys or passwords one by one until they happen to stumble across the right one. After implementing a unique salt, you'll have a secure solution. At that point, all an attacker can do is guess passwords one by one per user until he finds the correct one.

It certainly doesn't hurt to add on top compiling or obfuscating or peppering, but all those are just gravy once you have the cryptographically secure solution.

Are we sure that with today's computing power, one couldn't create a rainbow table for each record in the table using the records salt on the fly?