CPasswordHelper uses CRYPT_BLOWFISH which is not compatible in php 5.1 #2788

Closed
jjnavsofs0 opened this Issue Aug 19, 2013 · 5 comments

3 participants

@jjnavsofs0

CPasswordHelper gives some amazing ease at creating and validating password hashes but when the framework stands compatible to php 5.1 then why CRPYPT_BLOWFISH is used in CPasswordHelper. It really makes it down.

I did a bit search on google and found that phpass (www.openwall.com/phpass/) can be used as fallback to CRYPT_BLOWFISH.

I can understand that security is major concern here but when we make application in Yii using CPasswordHelper and run it on client environment where default php 5.1 is installed, it won't work. So if we use phpass or such solution as fallback then it might greatly help in improving compatibility of framework.

@samdark
Yii Software LLC member

We've discussed it with @tom-- who helped us with CPasswordHelper. There's his answer that in short means that we'll not fix it for 5.1 because of security issues:

CRYPT_BLOWFISH is compatible with 5.1 and indeed many older PHP versions. The problem is that, until 5.3.0, it was not available in all PHP runtime environments. This limited availability of the CPasswordHelper API was a considered decision in its introduction to Yii.

PHP's crypt() built-in function with the CRYPT_BLOWFISH option is the only PHP API for proper password hashing that has both reasonable availability in PHP (i.e. it does not require uncommon library implementations, e.g. Colin Percival's scrypt) and broad consensus that it is a good implementation. (See this thread. CPasswordHelper can be seen as a simplified Yii alternative to ircmaxell/password_compat.)

The decision to fail when this API is not available draws the programmer's attention to the fact that proper password hashing in PHP requires certain things from the runtime environment.

phpass expresses a different philosophy: it tries to be potable across different PHP runtime environemnts. As such it falls back to less than ideal methods in certain circumstances. While it allows the user to configure the module to not use these fallbacks, the default is insecure. Considering that most PHP developers do not fully understand password security, the default risks encouraging poor password security, which untimately affects webapp users.

So CPasswordHelper's stance is that if you want to do password storage right, this API may be able to help you but you will need crypt()'s CRYPT_BLOWFISH option. If you want do password storage without crypt()'s CRYPT_BLOWFISH then Yii doesn't know how to help you.

@samdark samdark closed this Aug 19, 2013
@jjnavsofs0

@samdark thank you for explanation. But I already seen the thread that you mentioned. Though, I fully understand what you mentioned above but as I earlier pointed out that when we say YII 1.XX is 5.1 compatible then it should not have any other dependency.

Once again, I fully understand the security risk and common developer practices. So, if it has some other dependency then it may be given as an extension. But if given in core as the case is now then one should be able to use the CPasswordHelper if he has php 5.1 default installed.

I know you and coreteam have better knowledge about it and I respect that but as a common developer when you have some feature in core of framework and it nags for the shake of some dependency then it must be looked after or it may be served as an extension.

@tom--

You can use 5.1. On Windows (or other systems without the crypt function in the system C library, or without the blowfish option) you can use the Suhosin patch.

My personal opinion is that Yii does a good thing for the world of PHP web apps by telling (nagging) developers when they need to upgrade a server for the sake of users' password security.

An issue requesting a test for CRYPT_BLOWFISH in requirements/index.php (as CSecurityManager crypto depends on mcrypt) would be swell.

@jjnavsofs0

@tom-- @samdark thank you both for taking care of the issue.

@tom--

No worries. It's an important question that will come up again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment