Showing results for 
Search instead for 
Did you mean: 

Use native PHP Password API

Use native PHP Password API

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

PHP 5.5 introduced a new password API natively to 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 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.

New Member

Comment from davidalger, posted on GitHub Feb 02, 2015

Option 2 (as I intended to write it) would not make higher security optional. It would make supporting less secure hashes optional. I.e. the system would support and use the more secure hashing algorithm by default. If you enabled it, it would also digest and auto-upgrade the older (less secure) hashes upon successful login. If left disabled, the system would not even attempt to validate agains the older hashes.

New Member

Comment from ericthehacker, posted on GitHub Mar 29, 2015

@alankent Was a decision on legacy password hashes ever made?

I've updated the feature branch to be compatible with develop at this point (specifically, by moving the unit tests to their new location after RC2).

New Member

Comment from antonkril, posted on GitHub Mar 30, 2015

@ericthehacker we decided to go with solution similar to described in

This will allow instant security for all hashes.

New Member

Comment from piotrekkaminski, posted on GitHub Apr 09, 2015

@antonkril can you point to internal Jira ID with this change? There is a conflicting change planned

New Member

Comment from ericthehacker, posted on GitHub May 05, 2015

@piotrekkaminski Was this conflict ever resolved?

New Member

Comment from vpelipenko, posted on GitHub Jul 07, 2015

Internal ticket: MAGETWO-35013

New Member

Comment from tkn98, posted on GitHub Dec 15, 2015

Any traktion on this one? +1 to have support for password_hash(). Also +1 for an option to auto-upgrade on first login to have backwards compat build in for a user-migration phase.

Senior Member

Any update on this?


I'd be happy to offer help with this issue but am not sure where to start.


M2 Certified

There's a plugin that can do it for you - but there's no official PR right now afaik

Senior Member