confidentialString function uses hard-coded key

[asgrim]

https://github.com/OWASP/phpsec/blob/master/libs/crypto/confidentialstring.php#L37

This looks like a hard coded key that is publicly available on the internet, plain for anyone to see and easily decrypt anything encrypted by this function.

Please tell me it's not the case? :cry:

[abhshkdz]

Wow. @rash805115 might be able to explain.

https://github.com/OWASP/phpsec/commit/8c63ac171460fc63dcd964a670a47600fddd54cc#diff-1fe90abdbf26c65bb2a047c0d7aab14eR31

[rash805115]

Hi @asgrim . The $key variable holds the key used to encrypt and decrypt, but the key given in the code is just a sample. Each developer while deployment will have their own key which will be secret to them. You might additionally ask why this variable is defined here and not in a config file, its because phpsec was intended to be individual plug and play libraries. Hence that single file should be self contained and ideally should not have any associations with other parts of code. If you are also wondering why have a key at all, look into other frameworks such as laravel, codeingniter, etc., everyone usually has one config file which contains a single key in plain text to encrypt and decrypt. The idea is that since the servers are not exposed to public, confidential information such as keys can be kept in code.

Also, its been a long time since I contributed to this project, and to the best of my knowledge no one is currently actively participating in it. So I urge you to contribute if you feel you can make improvements.

Please close the issue if you have no more doubts.

[asgrim]

@rash805115 the problem is, the "modern" way to use PHP libraries is to pull the library in using Composer etc. and configure things. People don't copy and paste classes from libraries into their code any more, and because that key is private, with no way of overriding the value, it is essentially unmodifiable.

I already noticed it has not been updated for a while after I sent my PR, and therein lies another issue: this repo does not contain best practice code, but still exists, and exists under a namespace (OWASP) that should be a trusted authority on best security practice. However this is not the case.

I strongly believe that this repo should be taken down, so that developers do not explore this repository and start doing things the wrong way.

On the upside: I am happy to start contributing to a new PHP security project, a library that CAN be used securely, and demonstrates (with documentation) best security practices, and recommendations, that can be kept up to date. If you'd like to discuss further to re-start this project, please get in touch with me.

[AndrewCarterUK]

I too would offer my services to help on a new security project that did follow best security practices.

[maccath]

Hi @rash805115 , I have some questions based on what you have just said, then.

How, apart from editing the phpsec Encryption class manually, do you expect users of the class to set their own key? It is a private variable, and there is no method available to set it to anything other than what is defined in the file itself. I don't see why you can't have a configuration mechanism in a plug-and-play library, by the way, especially when you /expect/ people to set their own key.

You use Laravel as an example of having a plaintext key in configuration files; this is true - a plaintext key exists in the environment configuration. This key is stored on the server outside of the public realm, and is not defined by default. It essentially forces you to create this key yourself on a per-environment basis. This is much more secure than hard-coding a private key variable within an encryption class, which people may or may not realise they need to edit!

Although nobody has been contributing to this project, it is nevertheless sad to see that a project with a focus on securty is insecure itself, and with the project still publicly available, no doubt people are still using it. I feel that there is a duty to inform your users of the steps they should take in order to secure this code themselves, even if that is just by editing the class directly, as currently - and correct me if I am wrong - there is no documentation that explains that this must be done.

I also agree that this project should be taken down, if it is not to be updated.

[owaspjocur]

Hi Katy, Andre and Rahul

I think is important to mentioned this issue in the github, as you can see indeed , the project is in incubator stage which means in an experimental phase in 'owasp' terms

The project has not been updated for more than 10 months which is quite dormant, if you take a look to owasp inventory of projects in the category of 'incubators' it happens quite often that projects become dormant and are not updated in a long time. The idea is to keep the inventory clean, as you have discovered, this issues should be fixed however these are open source projects driven by volunteer efforts, so no guarantees what so ever.

It is a rule however that if a project is not been active for more than a year it will receive a 'low activity' label and after, it will be set as inactive.

I encourage you to please log this issue in the github and I have copied owasp project coordinator to set the project under the low activity label

Regards

Johanna

On Fri, Nov 20, 2015 at 5:54 AM, Katy Ereira notifications@github.com wrote:

Hi @rash805115 https://github.com/rash805115 , I have some questions based on what you have just said, then.

How, apart from editing the phpsec Encryption class manually, do you expect users of the class to set their own key? It is a private variable, and there is no method available to set it to anything other than what is defined in the file itself. I don't see why you can't have a configuration mechanism in a plug-and-play library, by the way, especially when you /expect/ people to set their own key.

You use Laravel as an example of having a plaintext key in configuration files; this is true - a plaintext key exists in the environment configuration. This key is stored on the server outside of the public realm, and is not defined by default. It essentially forces you to create this key yourself on a per-environment basis. This is much more secure than hard-coding a private key variable within an encryption class, which people may or may not realise they need to edit!

Although nobody has been contributing to this project, it is nevertheless sad to see that a project with a focus on securty is insecure itself, and with the project still publicly available, no doubt people are still using it. I feel that there is a duty to inform your users of the steps they should take in order to secure this code themselves, even if that is just by editing the class directly, as currently - and correct me if I am wrong

• there is no documentation that explains that this must be done.

I also agree that this project should be taken down, if it is not to be updated.

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158342788.

[abiusx]

Where is the insecurity in that? I just explained that the purpose of that encryption class is to hide sensitive information, not encrypt critical data.

On Nov 20, 2015, at 4:54 AM, Katy Ereira notifications@github.com wrote:

Hi @rash805115 https://github.com/rash805115 , I have some questions based on what you have just said, then.

How, apart from editing the phpsec Encryption class manually, do you expect users of the class to set their own key? It is a private variable, and there is no method available to set it to anything other than what is defined in the file itself. I don't see why you can't have a configuration mechanism in a plug-and-play library, by the way, especially when you /expect/ people to set their own key.

You use Laravel as an example of having a plaintext key in configuration files; this is true - a plaintext key exists in the environment configuration. This key is stored on the server outside of the public realm, and is not defined by default. It essentially forces you to create this key yourself on a per-environment basis. This is much more secure than hard-coding a private key variable within an encryption class, which people may or may not realise they need to edit!

Although nobody has been contributing to this project, it is nevertheless sad to see that a project with a focus on securty is insecure itself, and with the project still publicly available, no doubt people are still using it. I feel that there is a duty to inform your users of the steps they should take in order to secure this code themselves, even if that is just by editing the class directly, as currently - and correct me if I am wrong - there is no documentation that explains that this must be done.

I also agree that this project should be taken down, if it is not to be updated.

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158342788.

[abiusx]

We’d love to welcome you aboard. The current PHP security project is outdated, by its main goals are to avoid bloat, and provide decoupled libraries, so that we don’t force developers to either integrate our entire platform or lose it all.

On Nov 20, 2015, at 4:09 AM, Andrew Carter notifications@github.com wrote:

I too would offer my services to help on a new security project that did follow best security practices.

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158331781.

[abiusx]

James, One point you are missing is that the intent of this function is to hide, not encrypt, sensitive information, so that when someone passes by your screen, or leaks one file of your code, they do not immediately recognize your password. Passwords still need to be part of the code, but hiding them is slighly better than having them in plain sight. It just involves a programmatic step of dehiding them, which is easy for the system administrator but hard for the bare eye.

Do you still think that this does not server that purpose, even with a fixed, static key?

On Nov 20, 2015, at 3:50 AM, James Titcumb notifications@github.com wrote:

Closed #108 https://github.com/OWASP/phpsec/issues/108.

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#event-470140744.

[asgrim]

That intent is not obvious, nor clearly documented. What looks like, to an untrained eye, an encryption technique (with classes called Encryption for example), is actually nothing more a vague obfuscation, nothing more secure than base64 encoding in reality.

The issue here is that this library is publicly accessible, it is under the trusted OWASP namespace on GitHub, and thus is likely considered an authoritative source on how to do encryption properly. Someone may use that code directly in their application, and be unaware of the fact that the encryption key must be changed. The public API for that class is such that it cannot even be changed in a clean way, so already presents a burden for implementation.

The fact that the fixed, static key exists and is also publicly accessible means that someone could be using this code to actually encrypt strings, but is actually using a very overpowered obfuscation technique. I hope you see my point :)

[abiusx]

I see the point, but please read your comment again. If we held everything to such standards, there would be no problems anywhere anytime.

On Nov 20, 2015, at 9:19 AM, James Titcumb notifications@github.com wrote:

That intent is not obvious, nor clearly documented. What looks like, to an untrained eye, an encryption technique (with classes called Encryption for example), is actually nothing more a vague obfuscation, nothing more secure than base64 encoding in reality.

The issue here is that this library is publicly accessible, it is under the trusted OWASP namespace on GitHub, and thus is likely considered an authoritative source on how to do encryption properly. Someone may use that code directly in their application, and be unaware of the fact that the encryption key must be changed. The public API for that class is such that it cannot even be changed in a clean way, so already presents a burden for implementation.

The fact that the fixed, static key exists and is also publicly accessible means that someone could be using this code to actually encrypt strings, but is actually using a very overpowered obfuscation technique. I hope you see my point :)

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158413322.

[asgrim]

Actually, I hold the opinion that if anyone should have the highest of standards, it should be OWASP, as they are making recommendations on security. If this is the perspective of the whole OWASP organisation, then I'm afraid I'm going to have to stop recommending people look up OWASP.

I may have missed the point (please, someone point out something I missed?), but leaving a private encryption key publicly accessible on the web, no matter what the intended use case, is not advocating secure coding.

This sort of attitude "if we used the highest standards, we'd have no problems" is surely what OWASP should be advocating (i.e. be as secure as possible), but the responses on here have led me to believe that is not what OWASP wants...

As I said, maybe I've got the wrong end of the stick, but to me, this looks really bad.

[abiusx]

I personally am in more favor of solutiosn that work, instead of solutions that require you to do 1000 things so that a rarely possible problem is avoided.

We’ve had many of those projects at OWASP, and they have all failed because nobody uses them.

I’m not in favor of 100% security at any price.

On Nov 20, 2015, at 9:39 AM, James Titcumb notifications@github.com wrote:

Actually, I hold the opinion that if anyone should have the highest of standards, it should be OWASP, as they are making recommendations on security. If this is the perspective of the whole OWASP organisation, then I'm afraid I'm going to have to stop recommending people look up OWASP.

I may have missed the point (please, someone point out something I missed?), but leaving a private encryption key publicly accessible on the web, no matter what the intended use case, is not advocating secure coding.

This sort of attitude "if we used the highest standards, we'd have no problems" is surely what OWASP should be advocating (i.e. be as secure as possible), but the responses on here have led me to believe that is not what OWASP wants...

As I said, maybe I've got the wrong end of the stick, but to me, this looks really bad. — Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158418384.

[AndrewCarterUK]

@abiusx

The class is called Encryption inside the crypto directory using AES and with variables named $encryptedString.

Please do not say that the point of this class is to "hide, not encrypt, sensitive information" - that is false. This class is an attempt at encryption and it is clearly advertised as that. Besides, if the purpose is hiding sensitive encryption then encryption is what it should be doing.

The encryption key and the IV should be passed as method parameters rather than hard coded into class properties - then the user can decide if they're setting them at run time or hard coding them. More importantly, the user knows that they need them.

All of this is actually distracting from the much larger issue - this whole repository is plagued with serious security flaws that have the potential to cause significant damage to anyone who trusts the OWASP name and uses the code. In my opinion the only option is to delete the whole thing as soon as possible and replace it with a warning to anyone who has ever used the code asking them to immediately review their applications security and replace any code that depended upon this library.

I honestly don't believe that this repository is fixable, but the exposure to risk of people trusting the OWASP namespace can be reduced if this is done.

[owaspjocur]

Hi James and Abbas

If this is the perspective of the whole OWASP organisation, then I'm afraid I'm going to have to stop recommending people look up OWASP.

Please consider again that projects that are in incubator phase, are in an experimental process. At this phase , the project is still in development and is not ready for major stream use (please read the description what means the incubator label)

https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects

As mentioned, owasp tries todo its best to promote security but users and consumers of projects must also realise the stage of a project. Like mentioned before , the project is an incubator and at this stage is still in experimentation phase. Getting a Flasghip status is not simple at OWASP and it is given to projects that have shown a track record.

if you can help provide the project a practical solution and contribute and want to help us make improvements please, let us know

@Abbas, if you don't mind, I can update the wiki page and the Github with the observation James mentioned Again . to me you both show different points of views but I think is important to mentioned how this key is implemented in the library

regards

Johanna

On Fri, Nov 20, 2015 at 10:41 AM, AbiusX notifications@github.com wrote:

I personally am in more favor of solutiosn that work, instead of solutions that require you to do 1000 things so that a rarely possible problem is avoided.

We’ve had many of those projects at OWASP, and they have all failed because nobody uses them.

I’m not in favor of 100% security at any price.

On Nov 20, 2015, at 9:39 AM, James Titcumb notifications@github.com wrote:

Actually, I hold the opinion that if anyone should have the highest of standards, it should be OWASP, as they are making recommendations on security. If this is the perspective of the whole OWASP organisation, then I'm afraid I'm going to have to stop recommending people look up OWASP.

I may have missed the point (please, someone point out something I missed?), but leaving a private encryption key publicly accessible on the web, no matter what the intended use case, is not advocating secure coding.

This sort of attitude "if we used the highest standards, we'd have no problems" is surely what OWASP should be advocating (i.e. be as secure as possible), but the responses on here have led me to believe that is not what OWASP wants...

As I said, maybe I've got the wrong end of the stick, but to me, this looks really bad. — Reply to this email directly or view it on GitHub < https://github.com/OWASP/phpsec/issues/108#issuecomment-158418384>.

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158418869.

[abiusx]

I agree. The class should be renamed. Its initial purpose was not to do encryption. It was to hide sensitive information. Also it shouldn’t have hardcoded keys, but a default key would do no harm.

As for the points mentioned by James and Andrew, they are already discussed in this issue.

If they want to help, I’d really appreciate it. I also asked him specifically to provide me with a few sentences to add to the related wiki pages.

On Nov 20, 2015, at 9:51 AM, owaspjocur notifications@github.com wrote:

Hi James and Abbas

If this is the perspective of the whole OWASP organisation, then I'm afraid I'm going to have to stop recommending people look up OWASP.

Please consider again that projects that are in incubator phase, are in an experimental process. At this phase , the project is still in development and is not ready for major stream use (please read the description what means the incubator label)

https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects

As mentioned, owasp tries todo its best to promote security but users and consumers of projects must also realise the stage of a project. Like mentioned before , the project is an incubator and at this stage is still in experimentation phase. Getting a Flasghip status is not simple at OWASP and it is given to projects that have shown a track record.

if you can help provide the project a practical solution and contribute and want to help us make improvements please, let us know

@Abbas, if you don't mind, I can update the wiki page and the Github with the observation James mentioned Again . to me you both show different points of views but I think is important to mentioned how this key is implemented in the library

regards

Johanna

On Fri, Nov 20, 2015 at 10:41 AM, AbiusX notifications@github.com wrote:

I personally am in more favor of solutiosn that work, instead of solutions that require you to do 1000 things so that a rarely possible problem is avoided.

We’ve had many of those projects at OWASP, and they have all failed because nobody uses them.

I’m not in favor of 100% security at any price.

On Nov 20, 2015, at 9:39 AM, James Titcumb notifications@github.com wrote:

Actually, I hold the opinion that if anyone should have the highest of standards, it should be OWASP, as they are making recommendations on security. If this is the perspective of the whole OWASP organisation, then I'm afraid I'm going to have to stop recommending people look up OWASP.

I may have missed the point (please, someone point out something I missed?), but leaving a private encryption key publicly accessible on the web, no matter what the intended use case, is not advocating secure coding.

This sort of attitude "if we used the highest standards, we'd have no problems" is surely what OWASP should be advocating (i.e. be as secure as possible), but the responses on here have led me to believe that is not what OWASP wants...

As I said, maybe I've got the wrong end of the stick, but to me, this looks really bad. — Reply to this email directly or view it on GitHub < https://github.com/OWASP/phpsec/issues/108#issuecomment-158418384>.

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158418869.

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158422272.

[AndrewCarterUK]

@owaspjocur

"Please consider again that projects that are in incubator phase, are in an experimental process. At this phase , the project is still in development and is not ready for major stream use (please read the description what means the incubator label)"

This project hasn't had any significant development for months. The README doesn't mention how insecure this whole repository is and I discovered it because @abiusx recommended that the insecure CSPRNG was used in the PHP CSRF Guard on the OWASP website (also insecure).

"if you can help provide the project a practical solution and contribute and want to help us make improvements please, let us know"

This repository needs to be emptied and replaced with a warning to anyone who ever used the code it previously contained. I'm happy to work on a replacement guide to using secure PHP packages that already exist in the wild, there are many well tested and used ones that do everything this tries to.

[abiusx]

I don’t see the point in emptying the repository. A simple readme file will do the trick. Plus prior users can investigate the unsafeties, and new users can realize them.

Unfortunately I don’t have the time to make that change at the moment, and would appreciate your help if you’re willing.

On Nov 20, 2015, at 9:57 AM, Andrew Carter notifications@github.com wrote:

@owaspjocur https://github.com/owaspjocur "Please consider again that projects that are in incubator phase, are in an experimental process. At this phase , the project is still in development and is not ready for major stream use (please read the description what means the incubator label)"

This project hasn't had any significant development for months. The README doesn't mention how insecure this whole repository is and I discovered it because @abiusx https://github.com/abiusx recommended that the insecure CSPRNG was used in the PHP CSRF Guard on the OWASP website (also insecure).

"if you can help provide the project a practical solution and contribute and want to help us make improvements please, let us know"

This repository needs to be emptied and replaced with a warning to anyone who ever used the code it previously contained. I'm happy to work on a replacement guide to using secure PHP packages that already exist in the wild, there are many well tested and used ones that do everything this tries to.

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158423648.

[AndrewCarterUK]

@abiusx - The point in emptying the repository is that it contains a plethora of insecure the code that could cause significant damage (financial, personal, etc...) to anyone mislead into trusting the OWASP namespace.

If you are seriously suggesting that we leave this up so that people can play roulette with the insecurities in the code then I withdraw my offer of working with an organisation that has this approach to security.

This repository isn't advertised as a learning tool plagued with the vulnerabilities that it is. It is advertised as a framework for creating secure web applications (which it isn't). It should be emptied.

[abiusx]

I don’t think we’re having a constructive argument here. Have a good day.

On Nov 20, 2015, at 10:02 AM, Andrew Carter notifications@github.com wrote:

@abiusx https://github.com/abiusx - The point in emptying the repository is that it contains a plethora of insecure the code that could cause significant damage (financial, personal, etc...) to anyone mislead into trusting the OWASP namespace.

If you are seriously suggesting that we leave this up so that people can play roulette with the insecurities in the code then I withdraw my offer of working with an organisation that has this approach to security.

This repository isn't advertised as a learning tool plagued with the vulnerabilities that it is. It is advertised as a framework for creating secure web applications (which it isn't). It should be emptied.

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158424831.

[owaspjocur]

Hi Andrew

Even though I understand your point of view , I can only say that many people worked hard in this project. Although the results are not up to expectations right now, does not mean that there were not significant efforts to make the library a security library. I t is valid to consider a README warning, but emptying the project is another story. I don't think this is fair to say to the volunteers, especially after all the efforts were put to create and build this project. Like I mentioned, the project is at incubator stage and I understand that this can be misleading or confusing for people not familiar with the OWASP labels. I think maybe OWASP should considering making this labelling system more clear to users so they know what they get at this stage. This project maybe a security framework, but basically incubator means , it has no guarantees at all

regards

Johanna

On Fri, Nov 20, 2015 at 11:02 AM, Andrew Carter notifications@github.com wrote:

@abiusx https://github.com/abiusx - The point in emptying the repository is that it contains a plethora of insecure the code that could cause significant damage (financial, personal, etc...) to anyone mislead into trusting the OWASP namespace.

If you are seriously suggesting that we leave this up so that people can play roulette with the insecurities in the code then I withdraw my offer of working with an organisation that has this approach to security.

This repository isn't advertised as a learning tool plagued with the vulnerabilities that it is. It is advertised as a framework for creating secure web applications (which it isn't). It should be emptied.

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158424831.

[AndrewCarterUK]

@owaspjocur

None of the code in this repository is useful for anything other than an example of how not to do things. Saying that it is "in development" or "in incubator phase" is hiding the fact that the whole thing needs to be completely rewritten.

Could you confirm to me that you consider the feelings of your volunteers and contributors more important than the security of the applications developed by people trusting the OWASP namespace?

[owaspjocur]

Could you confirm to me that you consider the feelings of your volunteers and contributors more important than the security of the applications developed by people trusting the OWASP namespace?

Andrew, you are right to think so, I wanted to point out that the intentions and efforts to make this a security library were there, but if you consider that this has quite many security issues, could you please let us know, apart from the Key encryption issue, what other issues did you find that this library should be taken down?

On Fri, Nov 20, 2015 at 11:17 AM, Andrew Carter notifications@github.com wrote:

@owaspjocur https://github.com/owaspjocur

None of the code in this repository is useful for anything other than an example of how not to do things. Saying that it is "in development" or "in incubator phase" is hiding the fact that the whole thing needs to be completely rewritten.

Could you confirm to me that you consider the feelings of your volunteers and contributors more important than the security of the applications developed by people trusting the OWASP namespace?

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158428769.

[AndrewCarterUK]

https://github.com/OWASP/phpsec/blob/master/libs/core/random.php

        //If openssl is present, use that to generate random.
        if (function_exists("openssl_random_pseudo_bytes") && FALSE)
        {
            $random32bit=(int)(hexdec(bin2hex(openssl_random_pseudo_bytes(64))));
        }

The '&& FALSE' means that the CSPRNG openssl API is never used. Even if it was to be used the return value isn't checked (it can be false) and neither is the optional '$secure' output variable which flags whether the CSPRNG managed to securely generate a random value.

The intended fallback uses 'mt_rand' which should never be used for the purposes of cryptography. It also merges the seed values in a way that gives a ridiculously high number of collisions. Similar mistakes are made throughout the file.

https://github.com/OWASP/phpsec/blob/master/libs/auth/user.php#L71

This method converts the password to lower case before hashing it. This massively increases the opportunity for a brute force attack because 'PASSWORD' is the same as 'password'.

https://github.com/OWASP/phpsec/blob/master/libs/auth/user.php#L88

This method is vulnerable to timing attacks (should use hash_equals).

And all that is on top of the "encryption" library that this issue was originally about. I've literally discovered the last two of those in the 15 minutes since you posted your comment by looking in a single file.

On top of this, the whole library does not follow object oriented design principles that make it more maintainable (no interfaces for example) or modern coding standards that help it get deployed to projects (thank god).

I'm not exaggerating when I say this, I can genuinely see no other option than emptying the whole repository and replacing it with a warning to anyone who ever used this code.

[SvenRtbg]

As one of the contributors to this repository, it's current state makes me sad.

You all are correct asserting that this particular library, in its current state, is a failure. Its goals, set before a Google "summer of code" event long ago, were to write for once a secure library that everyone should use. In the effort that followed, @rash805115 wrote code for basically everything that you'd need in a decent web framework: Form validation, controllers, database, logging, security stuff, session handling.

This probably has been a very educational effort, however I always found that this approach is flawed: There are already plenty of libraries around that do database abstraction or logging. IF they have security problems, the solution should be to fix them, not write another library that cannot compete with the other's features (no matter if it is more secure or not).

I have tried to find the one unique feature that no other library has, and there probably is one: Asserting secure passwords. There are several interesting checks I haven't seen anywhere else. This should be separated into one package, made to live up to expectations, and be released.

However, with this library being started at a time where Composer was in it's infancy, some things would have to change: I do find it annoying that there are so many violations of coding standards just because "Well yeah this is better for entry level developers I think".

Let's put an end to this project as it was intended at the start. Nobody did work on it since Aug 18, 2014. My merge from @philsturgeon 's pull request only added fixes to the TravisCI build tool.

So effectively this project is on hiatus for more than a year!

[owaspjocur]

Hi Sven, Andrew

Thank you for your feedback and I think there are enough valid points to consider that the project is inactive right now and it should be set as an inactive project.

As a defender security library project , there are definitely high risks using it at this stage and that can be misinterpreted by potential users. Considering owasp guidelines, the project in indeed inactive since it has not been updated for that long.

I have asked Claudia, our project coordinator to set the project as an inactive project and also set a label on the wiki similar to this https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

With regards on the github content, since it falls under OWASP github, there should be also a clear label that the project is inactive and contains many security issues that makes the project not usable as a security library

I will also contact the wiki editors group to make sure we have a label for this kind of situation as the project wiki page must also be archived.

Best regards

Johanna OWASP Volunteer

On Fri, Nov 20, 2015 at 12:17 PM, SvenRtbg notifications@github.com wrote:

As one of the contributors to this repository, it's current state makes me sad.

You all are correct asserting that this particular library, in its current state, is a failure. Its goals, set before a Google "summer of code" event long ago, were to write for once a secure library that everyone should use. In the effort that followed, @rash805115 https://github.com/rash805115 wrote code for basically everything that you'd need in a decent web framework: Form validation, controllers, database, logging, security stuff, session handling.

This probably has been a very educational effort, however I always found that this approach is flawed: There are already plenty of libraries around that do database abstraction or logging. IF they have security problems, the solution should be to fix them, not write another library that cannot compete with the other's features (no matter if it is more secure or not).

I have tried to find the one unique feature that no other library has, and there probably is one: Asserting secure passwords. There are several interesting checks I haven't seen anywhere else. This should be separated into one package, made to live up to expectations, and be released.

However, with this library being started at a time where Composer was in it's infancy, some things would have to change: I do find it annoying that there are so many violations of coding standards just because "Well yeah this is better for entry level developers I think".

Let's put an end to this project as it was intended at the start. Nobody did work on it since Aug 18, 2014. My merge from @philsturgeon https://github.com/philsturgeon 's pull request only added fixes to the TravisCI build tool.

So effectively this project is on hiatus for more than a year!

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158447768.

[AndrewCarterUK]

Hi @owaspjocur

I think they are all wise moves. It does sound, however, like this code will remain public in the OWASP namespace (just with labels of being inactive). The project you linked has no label of inactivity on its GitHub page (https://github.com/OWASP/OWASP-WebScarab).

Unfortunately, not everybody reads README files and not everybody checks your wiki pages. Also, every code file in this repository has been indexed by Google.

How will you guarantee that nobody ever stumbles across this code and uses it in their project?

Regards,

Andrew

[owaspjocur]

Hi @owaspjocur https://github.com/owaspjocur

I think they are all wise moves. It does sound, however, like this code will remain public in the OWASP namespace (just with labels of being inactive). The project you linked has no label of inactivity on its GitHub page (https://github.com/OWASP/OWASP-WebScarab).

Unfortunately, not everybody reads TODO files and not everybody checks your wiki pages. Also, every code file in this repository has been indexed by Google.

How will you guarantee that nobody ever stumbles across this code and uses it in their project?

Regards,

Andrew

Andrew:

I have cc Claudia who can bring this discussion at higher level

If you have a former request to take down the library from OWASP Github repository, please, make a former request to Claudia who can further take this issue with the staff as they control the Github account

We have also recently discussed setting a higher level for accepting defenders libraries as this has many risks associated of using insecure libraries

Regards

Johanna

On Fri, Nov 20, 2015 at 12:51 PM, Andrew Carter notifications@github.com wrote:

Hi @owaspjocur https://github.com/owaspjocur

I think they are all wise moves. It does sound, however, like this code will remain public in the OWASP namespace (just with labels of being inactive). The project you linked has no label of inactivity on its GitHub page (https://github.com/OWASP/OWASP-WebScarab).

Unfortunately, not everybody reads TODO files and not everybody checks your wiki pages. Also, every code file in this repository has been indexed by Google.

How will you guarantee that nobody ever stumbles across this code and uses it in their project?

Regards,

Andrew

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158457583.

[owaspjocur]

Regarding Inactive projects in OWASP github, is wise to setup an inactive label too I grew https://github.com/OWASP/OWASP-WebScarab/blob/master/README

On Fri, Nov 20, 2015 at 12:56 PM, johanna curiel curiel < johanna.curiel@owasp.org> wrote:

Hi @owaspjocur https://github.com/owaspjocur

I think they are all wise moves. It does sound, however, like this code will remain public in the OWASP namespace (just with labels of being inactive). The project you linked has no label of inactivity on its GitHub page (https://github.com/OWASP/OWASP-WebScarab).

Unfortunately, not everybody reads TODO files and not everybody checks your wiki pages. Also, every code file in this repository has been indexed by Google.

How will you guarantee that nobody ever stumbles across this code and uses it in their project?

Regards,

Andrew

Andrew:

I have cc Claudia who can bring this discussion at higher level

If you have a former request to take down the library from OWASP Github repository, please, make a former request to Claudia who can further take this issue with the staff as they control the Github account

We have also recently discussed setting a higher level for accepting defenders libraries as this has many risks associated of using insecure libraries

Regards

Johanna

On Fri, Nov 20, 2015 at 12:51 PM, Andrew Carter notifications@github.com wrote:

Hi @owaspjocur https://github.com/owaspjocur

I think they are all wise moves. It does sound, however, like this code will remain public in the OWASP namespace (just with labels of being inactive). The project you linked has no label of inactivity on its GitHub page (https://github.com/OWASP/OWASP-WebScarab).

Unfortunately, not everybody reads TODO files and not everybody checks your wiki pages. Also, every code file in this repository has been indexed by Google.

How will you guarantee that nobody ever stumbles across this code and uses it in their project?

Regards,

Andrew

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158457583.

[AndrewCarterUK]

Hi @owaspjocur

Thank you for your cooperation. Will Claudia read this thread? (I didn't see the tag in your response)

If so, can this thread and the evidence presented in it constitute a formal take down request? I'd really rather not spend the time collecting it again and all the information and arguments are present here and public.

Best Regards,

Andrew Carter

[owaspjocur]

Hi @owaspjocur https://github.com/owaspjocur

Thank you for your cooperation. Will Claudia read this thread? (I didn't see the tag in your response)

If so, can this thread and the evidence presented in it constitute a formal take down request? I'd really rather not spend the time collecting it again and all the information and arguments are present here and public.

Best Regards,

Andrew Carter

Hi Andrew

No she is not in this thread but I'm cc her and letting her know that this can be consider as a formal request

regards

Johanna

On Fri, Nov 20, 2015 at 1:02 PM, Andrew Carter notifications@github.com wrote:

Hi @owaspjocur https://github.com/owaspjocur

Thank you for your cooperation. Will Claudia read this thread? (I didn't see the tag in your response)

If so, can this thread and the evidence presented in it constitute a formal take down request? I'd really rather not spend the time collecting it again and all the information and arguments are present here and public.

Best Regards,

Andrew Carter

— Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-158460686.

[AndrewCarterUK]

Thank you very much for your cooperation @owaspjocur - you have been very helpful.

[asgrim]

Whilst I sympathise that effort has been put in to making this happen (no-one likes to throw away code!) I think this is the right choice, thank you for listening. I think me and @andrewcarteruk can probably join forces and present something with some thought, so watch this space :)

[paragonie-scott]

Oh my god OWASP, why are you shipping your own broken cryptography library?

https://github.com/OWASP/phpsec/blob/3d3f1a99736d72e7fd850690585e9e5bb1063515/libs/crypto/confidentialstring.php#L133

Hey, I heard you like PHP Object Injection from chosen-ciphertext attacks, because you're not authenticating your ciphertext at all.

• https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly
• https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong

I really hope nobody uses this, and instead opts for a sane authenticated encryption library, such as defuse/php-encryption.

[paragonie-scott]

https://gist.github.com/paragonie-scott/91893fdb18ee4d1a1b95

[paragonie-scott]

@abiusx Someone pointed me to this article: http://www.devstrend.com/8-best-php-security-libraries

I saw "crypto" and looked at it. Then I looked at the issues to see if anyone had previously reported an issue with confidentialString. When reading the OP of this thread, I saw the unserialize() and responded.

[AndrewCarterUK]

@abiusx Sensitive data should be encrypted.

Again:

"The class is called Encryption inside the crypto directory using AES and with variables named $encryptedString."

It attempted to be encryption, it advertised itself as encryption and some poor soul out there is probably using it as "encryption".

[AndrewCarterUK]

Furthermore:

https://github.com/OWASP/phpsec/blob/master/libs/crypto/confidentialstring.php#L26 "Cipher to be used for encryption."

https://github.com/OWASP/phpsec/blob/master/libs/crypto/confidentialstring.php#L34 "Key to be used for encryption/decryption."

https://github.com/OWASP/phpsec/blob/master/libs/crypto/confidentialstring.php#L42 "Mode to be used for encryption/decryption such as "ebc", "cbc" etc."

I could easily continue.

@abiusx - Could you point out a place where I have done anything other than make constructive points?

[paragonie-scott]

this library is not for encryption. its for hiding literal sensitive data in the application.

And how does it do that? By using the mcrypt encryption library, of course.

Trying to bury a security vulnerability with semantics is dishonorable.

Here's a fun fact about open source programming that's often a hard pill to swallow: You can't control or predict what users will do with it.

To wit: https://github.com/search?q=qgyXyjD5YpF&type=Code&utf8=%E2%9C%93

[asgrim]

@abiusx I have to agree (with @AndrewCarterUK), this LOOKS (for all intents and purposes) like an attempt at an Encryption library, except it has horrendous insecure flaws. I'm not sure what you mean by "hiding literal sensitive data", the intent of this library very much looks like an Encryption library.

[asgrim]

@abiusx the point is I'm still unclear about the intent of this library... as I said, I don't know what you mean by "hiding literal sensitive data".... isn't that what encryption is supposed to be for?

[paragonie-scott]

What is the security vulnerability in here?

Chosen-ciphertext attacks (with a non-secret key and IV to boot) that lead to PHP object injection, not to mention the recent CVEs affecting unserialize() (and possibly with more to follow).

[AndrewCarterUK]

@abiusx passwords should not be masked. They should be hashed (preferably with an algorithm such as bcrypt) or, if they need to be retrieved, encrypted properly.

[paragonie-scott]

What is the proper way to encrypt passwords properly?

You don't encrypt passwords, you hash them.

• http://codahale.com/how-to-safely-store-a-password/
• https://paragonie.com/white-paper/2015-secure-php-data-encryption
• https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence

[abiusx]

Hashing is not encryption. Encryption needs to be decryptable.

On Nov 25, 2015, at 12:10 PM, Scott notifications@github.com wrote:

What is the proper way to encrypt passwords properly? http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ https://paragonie.com/white-paper/2015-secure-php-data-encryption https://paragonie.com/white-paper/2015-secure-php-data-encryption https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence — Reply to this email directly or view it on GitHub https://github.com/OWASP/phpsec/issues/108#issuecomment-159675597.

[AndrewCarterUK]

@abiusx

1. Web browsers do encrypt passwords (https://support.mozilla.org/en-US/kb/password-manager-remember-delete-change-and-import#w_protecting-your-passwords)
2. (edit) Look at Scott's links.

[paragonie-scott]

@abiusx If you're concern is someone with code exec getting the password, game over. If the application can decode the password, an attacker can replay your algorithm to decrypt it.

[AndrewCarterUK]

"1. Web browsers do not encrypt passwords on HTML forms. Please refrain from fallacious examples. I’m not talking about the internals of the web browser, but the way it handles HTTP requests."

HTML forms containing passwords should be transmitted over HTTPS.

[asgrim]

The fact is, this is still an issue. This "confidentialString" function looks, and acts like encryption. If the intention is to "mask passwords" I'm not sure what possible use case this would have in PHP. The only thing you should ever do in a PHP application with a password is hash it, end of.

[asgrim]

Says any responsible application developer who cares about security. I'm not sure why you'd replace passwords with * in a PHP application, and surely str_repeat is sufficient for this purpose?

$masked = str_repeat('*', strlen($password));

Why do you need mcrypt to do anything if that's the case? By using mcrypt it LOOKS like you're trying to encrypt things, and if the intention is to encrypt passwords, then that is very bad indeed.