Use native PHP Password API

[apiuser]

Feature request from airbone42, posted on GitHub Jan 21, 2015

PHP 5.5 introduced a new password API natively to PHP. http://php.net/manual/en/book.password.php

As using BCRYPT for the default hashing algorithm it's not only more secure than the current implementaiton of md5 and sha256. But will even be automatically maintained with newer PHP versions and does not depend on any maintenance or upgrades by Magento.

So my suggestion is to replace the current hashing implementation in the Encryptor with using native password_hash and password_verify. Especially for an e-commerce system security should have a very high priority.

So rumors tell that Magento 2 will soon raise min. requirements to PHP 5.5, so that would be the best point to integrate this. Anyway if that min. version update might not come there's also a backward compatibility library available at https://github.com/ircmaxell/password_compat which could be used for PHP <5.5.

If Magento needs MD5 and SHA256 for b/c to Magento 1 hashes, I would suggest to move that into a separate module, so new Magento 2 shops without old data don't need to bother about this old hasing algorithms and the code coming with it. Even shops with older Magento 1 data could remove that b/c module after all customers have updated their password over time or by enforcing them after the first login. This reduces amount of code and complexity, buy having these Mage1 b/c modules and migrations optional.

Anyway, would Magento be interested in porting the Encryptor into that way? If it will get accepted I would definitely dig into this and try to create a PR to speed up development.

[apiuser]

Comment from airbone42, posted on GitHub Jan 24, 2015

Anyway it's technically not possible to migrate the old hashes without bruteforcing them automatically. The only way would be to ask customers to specify a new password after the first login.

[apiuser]

Comment from ericthehacker, posted on GitHub Jan 26, 2015

The only reasonable way to upgrade the hash security for old passwords would be to catch them during login, and if the passwords validates (using the old hash algorithm), rehash using the native API.

[apiuser]

Comment from alankent, posted on GitHub Jan 26, 2015

Normal approaches (some mentioned earlier in this thread) are

1. Keep track of version of hash function with password, so checking code knows which hash function to use (e.g. prefix password hash with version number)
2. Try multiple hash functions and accept password if any hash function works

The first is more secure. Forcing customers to re-enter a new password is not acceptable.

[apiuser]

Comment from airbone42, posted on GitHub Jan 27, 2015

The problem with tracking the version and not migrating the passwords is that the list will get longer and longer over time. Right now we have MD5 and SHA256 just for backwards compatibility in Magento 2. And if that approach continues they'll still be there in Magento 3 if there's no cut or a migration at some point. So newer passwords will be more secure, but there might still be a lot of old MD5 passwords especially in the bigger shop systems which have their customer base for a long time.

This issue has to be about getting rid of unsecure hashing methods, not only about adding a new one (which is also important, but just the first step).

[apiuser]

Comment from alankent, posted on GitHub Jan 27, 2015

I will make sure the product team are aware of this thread. But be aware that an influence is whether all merchants are happy to be FORCED to reset all customer passwords rather than give them an option to CHOOSE whether to take advantage of new password hashing (as part of a M2 upgrade.)

[apiuser]

Comment from davidalger, posted on GitHub Jan 27, 2015

I see three possible solutions, which I'll list in order of a (security minded) preference:

1. System only contains support for the PHP 5.5 hashing API. Users which have been imported and/or migrated in from Magento 1 may use (new functionality) to "reset" their password and regain access to their account. This option is best from a long-term security standpoint, but hardest on users, particularly if the UI/UX is not really thought through. This also requires the greatest development effort.

2. System contains support for the PHP 5.5 hashing API and uses this hashing API exclusively by default. There is a system preference added to allow those migrating from old systems (may or may not be Magento 1) to enable support for older and less secure hashing algorithms with note (on the setting) indicating that upon login the hash will be upgraded to the modern and more secure PCI compliant hashing algorithm. This requires extra development work (to add the config setting) but allows the more security minded to prohibit the use of old hash data. If the setting is added, I would expect to see it off by default, requiring those desiring hash upgrades to enable the setting for the hash upgrades to occur.

3. System contains support for the PHP 5.5 hashing API as well as the sha/md5 hashes previous versions of Magento CE/EE have used, automatically re-hashing the password to use the current standard upon customer login. This requires minimal extra development and is currently the behavior of EE when taking in data from an existing CE installation.

My personal preference would be option no 2.

[apiuser]

Comment from pronto2000, posted on GitHub Jan 27, 2015

You know, David, I like the third option a lot. In fact I have a project underway that involves importing customers from custom built system and I'm probably going to implement something like that. It's completely invisible from customer perspective and yet relatively simple to do. All that is needed is either to add an attribute for the hash type or make an educated guess based on hash length (first method being more safe, but requires more work). Also, this makes really easy to change hash method should a vulnerability found from the existing one.

[apiuser]

Comment from verklov, posted on GitHub Jan 29, 2015

@DavidAlger, agree with @pronto2000. Looks like option 3 is easier to implement and eliminates the use of less secure hashing algorithm as soon as customer logs in to the system. Why do you personally prefer option 2?

[apiuser]

Comment from davidalger, posted on GitHub Feb 02, 2015

@verklov Simple. I prefer option 2 because it gives us both the easy route which some want, and the control that others would like with minimal effort. Essentially option 2 is exactly as Magento 1 currently behaves, but with a system configuration flag which allows implementors or site admins to control the behavior. I.e. determine whether or not the system supports only one hash system or will auto-upgrade older hashes on successful login. Option 3 strictly reflects current Magento Enterprise v1 behavior as it pertains to consuming md5 hashes in sites upgraded to Magento Enterprise from Magento Community

[apiuser]

Comment from pronto2000, posted on GitHub Feb 02, 2015

Hmm ... to me the main difference between option2 and option3 is that option3 automatically upgrades password security once customer logs on no matter what. Option2 basically makes higher security level optional. I see no reason whatsoever for that except perhaps because it provides an opportunity to downgrade.