11

I have recently heard that most of the PHP code is confidential, because if attackers know your database structure or the hash function used to encrypt the passwords, there is higher chances of a breach.

I was wondering, if it's so, then what about open source projects where everything is wide out in the open?

1

3 Answers 3

22

I have recently heard that most of the PHP code is confidential, because if attackers know your database structure or the hash function used to encrypt the passwords, there is higher chances of a breach.

That's only when designers don't use the correct hash function or protect the webapp from SQL injection. But these things can be easily detected, there eve are automated tools these days that can look for SQL injection vulnerabilities via the source code (instead of pointing sqlmap at the webapp)

If you use something like scrypt, you're perfectly safe in telling everyone that you use it.

MediaWiki used to use a salted MD5 hash. The salt is installation specific and not part of the open source code (it gets generated on install). This isn't as secure as it can be (per-user salts and using a better hashing algorithm would be better), but it's still secure as long as the LocalSettings file isn't exposed. (Admittedly, that's not a great level of security). I think Drupal does this too, but with sha512.

I was wondering, if it's so, then what about open source projects where everything is wide out in the open?

Security by obscurity is not security. If putting the code out in the open impacts security, then you don't have any security in the first place.

Besides, if there are security holes in the code, these get caught by contributors too. I recently caught and patched a security-related bug in the Bugzilla software, for example.

6
  • 5
    wat? Salt should be randomized per password hashed, not once per installation. Feb 17, 2014 at 12:01
  • @SimonRichter well, that's what Mediawiki does. Feb 17, 2014 at 12:11
  • @Manishearth: How do you think so? You can opt-out of the salt, but not define an installation-specific one. Salts are randomly generated per user.
    – Bergi
    Feb 17, 2014 at 14:25
  • Plaintext passwords are also "secure as long as the database isn't exposed"
    – paj28
    Feb 17, 2014 at 14:30
  • @Bergi hm, looks like they improved it Feb 17, 2014 at 14:34
35

This is called "security through obscurity", which is generally considered to be a bad security model for most (if not all) purposes.

There are two main terms focusing upon this concept:

Kerckhoff's principle:

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

Claude Shannon reformulated this later, in more generic terms, as Shannon's maxim:

The enemy knows the system.

The point is that security should come from solid security concepts, rather than trying to hide information and algorithms. Cryptographically strong operations ensure security, whereas private code only ensures obscurity.

12

I have recently heard that most of the PHP code is confidential

This appears to be incorrect. At the very lease, most PHP is unobfuscated and readable to anyone it's distributed to.

because if attackers know your database structure or the hash function used to encrypt the passwords, there is higher chances of a breach.

Also incorrect. Neither the database structure no hash function is critical in architecting the initial breach. Those might be useful after a breach, but what's important in generating the initial attack is knowledge of some flaw or vulnerability in the site code.

Having the source code can be helpful in finding security vulnerabilities (cf.: Wordpress and Joomla plugins), It's not really necessary. In fact, most of the interesting vulnerabilities (Windows, Flash, Internet Explorer, Acrobat, etc.) are found without the aid of source code.

Making your project Open Source makes the code easier for third parties to audit (with or without your permission) which should lead to earlier discovery of bugs and vulnerabilities, hopefully making them quicker and easier to patch.

Assuming your project is popular enough to get a reasonable amount of scrutany, this should mean that your project is less likely to have important security vulnerabilties once the initial discovery and vetting period is accomplished. It's difficult to get good data on this, but some evidence suggests that popular open-source software is less likely to have those "sleeper" vulnerabilities that sit there present and active but unpublicized for decades.

You must log in to answer this question.