28

I have developed a web site during an internship, using a database with accounts. I used the crypt() method from PHP, with a secured algorithm plus salt (found on the web with a lot of feedback). Obviously, I'd like to talk about it in my report but, would it be a security issue since that report will be made public?

I think that it wouldn't matter because the method itself is pretty secure, but maybe, if the attacker knows about the algorithm, it would make it a little bit easier to brute force.

|improve this question
  • 28
    The hash method used should not need to be secret to remain secure. If it does, it's not secure... I'm hoping that you're using something like bcrypt, which adds salt internally, in which case, given current knowledge, the best method of breaking it is to brute force common passwords, taking a very long time. – Matthew Jun 14 '16 at 15:30
  • Yes, I used bcrypt from the php function called crypt(). I'm pretty sure my algorithm is pretty strong, I was just wondering if it was "ok" to explain it in a report. Plus, the algorithm can be found on the web so... – lopoto Jun 14 '16 at 15:34
  • 1
    It is okay to publish since it is secure and not relying on security through obscurity. Take note, the algorithm may be strong, but implementation is a separate matter. The PHP developer might have made a mistake in the hash function, e.g. generate "random" numbers that are predictable. – limbenjamin Jun 14 '16 at 15:38
  • 3
    You can think of the case of open source software, where not only the algorithm used but the complete and documented code is available to everybody, and this does not make them more vulnerable than their closed-source counterparts. – WhiteWinterWolf Jun 14 '16 at 16:24
  • 7
    If your hash is so weak that describing the algorithm significantly reduces its security, you had no business using it to hash sensitive information in the first place. – Shadur Jun 14 '16 at 21:41
47

Should you make the algorithm public?

Trying to hide implementation details (such as which hashing algorithm you use) to preserve security is the very definition of security through obscurity. There is broad consensus that obscurity should not be your only line of defense.

If you need to keep your hash algorithm a secret, you are doing it wrong and need to pick a better hashing algorithm. When you use a good algorithm, there is no reason not to tell the world about it since they won't be able to crack your hashes anyway.

Also note that in your case the salt will give you away. If someone gets hold of your database, they will be able to read what algorithm was used from that. So obscurity does not make brute forcing harder here. Advertising a weak scheme, however, might encourage attackers. A strong one could have the opposite effect. The point Mike Goodwin makes in his answer should also be taken into account.

Is crypt() secure?

The relevant question to ask is therefore if crypt() is secure enough. Let's have a look at the PHP manual:

password_hash() uses a strong hash, generates a strong salt, and applies proper rounds automatically. password_hash() is a simple crypt() wrapper and compatible with existing password hashes. Use of password_hash() is encouraged.

Some operating systems support more than one type of hash. In fact, sometimes the standard DES-based algorithm is replaced by an MD5-based algorithm.

The standard DES-based crypt() returns the salt as the first two characters of the output. It also only uses the first eight characters of str, so longer strings that start with the same eight characters will generate the same result (when the same salt is used).

The function uses different algorithms depending on how you format the salt. Some of the algorithms are very weak, and the strong ones might not be available on all systems. So depending on the algorithm used, there are a number of problems here:

  • For some algorithms crypt() only applies one round of hashing. That is too fast, and will enable a brute force attack.
  • Under some circumstances crypt() will use MD5, which is known to be weak.
  • Only using the first eight characters completely nullifies the benefits of long passwords.

I therefore suggest that you switch to password_hash(). It lets you use bcrypt - a tried and tested algorithm. Then you can proudly tell the world about your hashing scheme.

|improve this answer
  • 2
    Nice analysis.I think crypt is designed to be compatible with (ancient) Unix functionality. – Neil Smithline Jun 14 '16 at 15:52
  • 1
    Thanks for you long answer, it was very clear. But I'm using bcrypt because of the version field which is $2y$, this is the algorithm identifier of bcrypt. Also, I think I tried to use password_hash() but it requires a recent PHP version, and I do not have it currently. This web project is not done from scratch and I'm only a trainee. When I started this, the hash function used was MD5, so I decided to change it on my own because I know it was not secured anymore, and my manager didn't care about it. I think I'm doing the right things but I can't change everything, thanks again :-) – lopoto Jun 14 '16 at 15:55
  • 2
    @OrangeDog According to the linked man page $2a$ is also blowfish: Blowfish hashing with a salt as follows: "$2a$", "$2x$" or "$2y$", a two digit cost parameter, "$", and 22 characters from the alphabet "./0-9A-Za-z". [...] Versions of PHP before 5.3.7 only support "$2a$" as the salt prefix: PHP 5.3.7 introduced the new prefixes to fix a security weakness in the Blowfish implementation. – Anders Jun 14 '16 at 18:02
  • 4
    @lopoto If your PHP is recent enough to have a correctly working bcrypt implementation, you can use the password_hash polyfill. – CodesInChaos Jun 14 '16 at 18:27
  • 1
    @lopoto The password_compat library I linked works in many older versions of PHP. Since your php supports $2y$ it's supported by the library. – CodesInChaos Jun 14 '16 at 19:07
8

@Anders is correct that security through obscurity is no security at all.

Having said that, publishing implementation details gives information to attackers that they could use if vulnerabilities are discovered in your implementation in the future or it the attacker has zero-day vulnerabilities.

Think of it this way - many penetration tests begin with a reconnaissance phase that discovers protocols, technologies and versions in use. This info is then used to attempt known exploits if there are any.

If this kind of information is useful to pen testers, then it is also useful for attackers. Why make their lives easier by doing part of their job for them? All other things being equal, they are likely to focus on the systems that make things easier for them ahead of the ones that make them work harder.

On balance, unless there is some clear benefit to you or your employer in publishing the technical details, I would keep them private. Work on a need-to-know basis.

Just to repeat though, to avoid downvotes - I completely agree that security through obscurity is no security at all ;-p

|improve this answer
  • 8
    There can be a slight reputation benefit to publishing details of your password hashing method, as long as it is strong. With big name mistakes like the Adobe breach (encrypted passwords), Ashley Madison (bcrypt, but then MD5 in a different field...) and so on, being able to show best practice can be good. It's not a big thing though. – Matthew Jun 14 '16 at 16:04
  • 3
    @Matthew: I agree. If you can see some clear benefit, then publish. Otherwise don't. – Mike Goodwin Jun 14 '16 at 16:07
  • 1
    Security through obscurity might be no security at all, but I'm still not telling you my ATM PIN – infixed Jun 14 '16 at 16:43
  • 15
    @infixed, the point of the phrase "security through obscurity" is that in a correctly secure cryptographic system, the key is the only part you need to keep secret. (Your ATM PIN is a key.) All the rest—algorithms, implementation details, etc.—should be possible to reveal without making it the slightest bit easier to crack the system. Although as Mike points out, that isn't by itself a reason to reveal your implementation details. – Wildcard Jun 14 '16 at 20:23
2

Not only can you, you absolutely should.

Kerckhoff's principle dictates that the only valid thing for the security of your system to rest upon is the secret key, and that any secure system should be designed with the notion that "the enemy knows the system" assumed to be true up-front.

Therefore, by Kerckhoff's principle, sharing the details of the system can't make it any less secure, because you must assume up-front that the enemy already knows the system, because the bad guys are willing to hack and commit espionage to get access to the workings of it. What sharing can do, however, is help make your system more secure by sharing it with the good guys, experts who would be able to analyze and review it. If there are vulnerabilities, good guys and bad guys will both find them, but the bad guys won't share them with you so you can fix them.

Therefore, if you want your system to be secure, you can't afford not to share how it works.

|improve this answer
  • If the enemy knows everything then wouldn't the "secret key" also be available, or do I have a misconception about the Salt storage in the DB? Thanks. – XaolingBao Jun 15 '16 at 21:48
  • @Lasagna The enemy can know the workings of the system (code) without knowing the key (data), and Kerckhoff's principle is to assume that this is the case, and therefore the only thing that the security of your system can reliably rest upon is the key. – Mason Wheeler Jun 15 '16 at 22:27
  • So we are under the assumption the system hasn't been compromised then. I will look more into the Principle, thanks. – XaolingBao Jun 15 '16 at 22:29
  • @Lasagna Yeah. Kerckhoff's principle is about establishing a secure system in the first place, not responding to a compromise. – Mason Wheeler Jun 15 '16 at 22:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.