krisives Posted July 16, 2014 Share Posted July 16, 2014 Howdy, A while ago we filed a few bugs related to Prestashop and passwords: http://forge.prestashop.com/browse/PSCFV-11357 This needs to be fixed. Without fixing this bug we are currently hashing passwords for no reason. The hashed passwords can easily be cracked. This needs a technical fix to make the hashes have a unique salt. Another really big issue I cannot find on the forge is sending out new passwords in plain text by default: http://i.imgur.com/pbHswTS.png This is unacceptable. A service should NEVER relay the original password given by the user. In a perfect world you would never even have the passphrase, but currently most software doesn't do password hashing on the client side. Even if you are offering a website with no products on it or no monetary value you are putting your users at risk. Many users use the same password more than once (you are probably guilty of this as well) and having that e-mail saved in their inbox is a wet dream to someone who just gained access to their email. Please take note this is worse than the typical threat model of hacking your email. If you hack my email you may be able to reset my password with other services, but you cannot gain the original in any way. With the current setup in Prestashop you can easily find the original password in e-mail history and it may lead to compromises of other accounts that share that password. We need to: Agree there is a problem Stop sending e-mails that contain passwords by default Agree on a format to store password hashes in so that we can upgrade cleanly Create an update script for Prestashop to update the passwords Cheers, Kris 2 Link to comment Share on other sites More sharing options...
Krystian Podemski Posted July 16, 2014 Share Posted July 16, 2014 Any idea how to change hash method and keep retrocompatibility? Link to comment Share on other sites More sharing options...
Dh42 Posted July 16, 2014 Share Posted July 16, 2014 I actually remember this thread you did a while back. I agree that things should be changed, but at the same time this is status que for the industry. Magento relies on this, see this screenshot http://screencast.com/t/RTMUOa5mK WHMCS relies on this, see this third party module, http://www.whmcs.com/appstore/622/WHMCS-Security---Password-Reset.html Shopify does this, see this http://ecommerce.shopify.com/c/shopify-discussion/t/plain-text-passwords-on-login-169710 Plesk does this, http://serverfault.com/questions/425116/possible-to-get-cleartext-password Who is your host, and what platform are you on? Pretty much most of the internet and any layer of hosting you are going to use does this. Link to comment Share on other sites More sharing options...
krisives Posted July 16, 2014 Author Share Posted July 16, 2014 Magento relies on this, see this screenshot http://screencast.com/t/RTMUOa5mK It's not something enjoyed by the community: http://magento.stackexchange.com/questions/5914/passwords-in-sign-up-email-bad-practice-pci-compliant No amount of failings in other peoples software will make this okay in Prestashop. Who is your host, and what platform are you on? A hacker doesn't care about what your host is or how bad other software is. This does not change the threat model. (Also Plesk changed this in 11.5 if that matters to anyone) Pretty much most of the internet and any layer of hosting you are going to use does this. Actually other than a few eCommerce sites I never get my password emailed to me directly, except for often poorly made newletter services. I may have a brand new password e-mailed to me that was autogenerated (possibly as the case with the Magento example you gave) but the idea that I put a password in and get the plain-text back from a signup is absurd and horrible and rarely happens, and when it does it's met with resistence and responses. Imagine my secret password was as the example "NotCoolMan" but I mis-typed my e-mail and someone else got that e-mail. There are so many blatant examples of why this practice is bad that it's very disheartening to have to still be making this point. *When* something bad happens these forum posts and bug posts will look very very poorly for Prestashop. 1 Link to comment Share on other sites More sharing options...
krisives Posted July 16, 2014 Author Share Posted July 16, 2014 Any idea how to change hash method and keep retrocompatibility? Yeah we extend the database column and start doing something like Unix or other systems do where they store not just a hash, but a sring that contains all the parameters: * What hashing algorithm is used (usually a number is given to each, 1 for md5, 2 for sha1, etc.) * Salt hash * Final password hash * Number of iterations It ends up looking like this: $1$abcdef1234509123abcd$badb33feeeaacc:10000 This would be: * Hash function 1 (md5 maybe?) * Salt of abcdef1234509123abcd * Final hash of badb33feeeaacc * 10000 hashing iterations Once upgraded the hashes without this format would be upgraded. We already know md5(x) so we can make a salted hash of that. Users wouldn't have to change their passwords. 1 Link to comment Share on other sites More sharing options...
Dh42 Posted July 16, 2014 Share Posted July 16, 2014 You could always make a 3rd party module that does this and see what kind of adoption rate you are getting. Link to comment Share on other sites More sharing options...
krisives Posted July 16, 2014 Author Share Posted July 16, 2014 @Dh42 Our goal is to avoid a larger scale problem that could be avoided which will negatively impact the Prestashop industry as a whole. Link to comment Share on other sites More sharing options...
krisives Posted July 18, 2014 Author Share Posted July 18, 2014 (edited) After reading more of your links I realize that NONE of them actually do what I say. Generating a random password and sending it to your email is NOT what I am complaining about. Which is what is linked in the examples you gave above about Magento, WHMCS, Shopify, etc. The examples in those links are not examples of sending the same password back to you, but instead sending randomized or first-used passwords. A fork we have contains the removal of the password from the mail_identifiers.txt as well as no longer sending it to the template within the AuthController. EDIT: The diff https://github.com/stnkris/stn2/commit/0e5009d19d8adee60b50013d5bbb6a7fb05e4c3d Sending the verbatim password back is wrong and needs to be removed from Prestashop. Edited July 18, 2014 by krisives (see edit history) 1 Link to comment Share on other sites More sharing options...
krisives Posted August 8, 2014 Author Share Posted August 8, 2014 There is a pull request related to this being worked on by some other folks: https://github.com/PrestaShop/PrestaShop/pull/1957 Link to comment Share on other sites More sharing options...
Paul7 Posted June 14, 2016 Share Posted June 14, 2016 2 years on from this discussion and Prestashop still sends the verbatim password back in an email? I'm no security expert but am I wrong in saying that any customers with a compromised email account now have a compromised Prestashop account? Link to comment Share on other sites More sharing options...
Krystian Podemski Posted June 14, 2016 Share Posted June 14, 2016 You can disable welcome e-mail after registration from back-office, you know, if someone has compromised e-mail, account in PrestaShop store is one of the minor problems for such a person i guess... Link to comment Share on other sites More sharing options...
sapphal Posted June 16, 2016 Share Posted June 16, 2016 You can edit the email in translations to remove the password field sent in the create account message to the customer. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now