Jump to content

Major security design flaw


mackhax0r

Recommended Posts

I really hope this is a joke. It's not, though. When a new user signs up for Prestashop, they receive an email with their username and password. After poking around in the translation templates', I found that throughout all the templates that this is very common. My question is this: ARE YOU FREAKING SERIOUS? 

 

This design, is a major security flaw in Prestashop. The developers can't seriously think this was ever a good idea. You can abide by every single security standard in the world, but if you send it via email which is insecure because it is not encrypted in any way, you defeat the purpose. It might be easier to just display all the passwords via plain text. Seriously.

Let's see. 
http://security.stackexchange.com/questions/94102/is-it-good-practice-to-send-passwords-in-separate-emails-and-why
http://www.thebitmill.com/articles/password_email.html

https://nakedsecurity.sophos.com/2015/05/19/uber-in-hot-water-again-over-plaintext-passwords-in-emails/

 

Seriously, I hope this is some cruel joke. I've removed every reference to the {PASSWD} flag in the translation files, but this is absolutely frustrating and unacceptable. 

 

Things we could do:

  • As a system administrator, I can view the password in the sent logs
  • If someone leaves their computer unlocked, their password is visible
  • If the user sends to the wrong email, the person gets to see their password (note: I signed up for gmail with my first last name at gmail.com, and I get a LOT of people using my email by mistake, so this isn't uncommon)
  • Literally the worst design ever

 

I'm about to deploy this product for multiple customers, and after seeing this I'm at a standstill because this is unacceptable. I'm also not modifying code to make it secure the way it is supposed to be. Do the developers have any interest in fixing this issue? I would assume not. 

  • Like 2
Link to comment
Share on other sites

This is a very good point you've raised up. Sending password in plaintext is very bad idea.

 

The fact that passwords are also stored in plain text inside email log is just insane.  Any employees with proper permissions can see them. Also this makes the job for any hacker so much easier - they don't need to crack the hashed passwords.

 

 

Edit: according to my investigation email body is not stored in ps_mail table, at least not in my shop, so I withdraw my previous objection. Anyway sending password in plaintext via email is a big design flaw.

Edited by DataKick (see edit history)
Link to comment
Share on other sites

This is a very good point you've raised up. Sending password in plaintext is very bad idea.

 

The fact that passwords are also stored in plain text inside email log is just insane.  Any employees with proper permissions can see them. Also this makes the job for any hacker so much easier - they don't need to crack the hashed passwords.

 

 

Edit: according to my investigation email body is not stored in ps_mail table, at least not in my shop, so I withdraw my previous objection. Anyway sending password in plaintext via email is a big design flaw.

 

Right, I can impersonate any user on my mail server and see sent server logs - this is what I meant, it isn't visible in the mail log in the backend..

Link to comment
Share on other sites

what is difference in doing this than say lost password being sent in an email?  it's basically the same thing...but I do understand your point.  But is it major issue, if this is only major issue in ps security,  I'm happy with that lol.

 

happy ps'ing

 

Lost password functionality shouldn't be based on generating / sending new password as well. Instead unique link to special page where user can set new password should be used. These are basic authentication flows.

Link to comment
Share on other sites

Good point!

 

Passwords are encrypted in DB by PS and it's very difficult to access it so no problem in DB; but the problem is just the password sent by mail to customer...well i think that it's possible to edit the mail template..i mean account.html and account.txt located in the lang directory ( it possible to do it in Admin>localization>translation. You delete the html code and the translation "printing" the pw in the message , this way the customer will receive only  a message. I think this can be a solution.

 

well i found this interesting topic:

 

https://www.prestashop.com/forums/topic/470551-email-configuration-password-encryption/

 

 

Fabrizio

Edited by Fabry (see edit history)
Link to comment
Share on other sites

To really affect existing ps regitsration can only be done manually (custom).    This will change in 1.7 as developers can override template and replace existing with new.  apple sales went up when they enabled finger recognition on iphones....so we are interested in bot metrics for sure lol...and agree with original poster  that current is not 'best in class'. 

Link to comment
Share on other sites

  • 2 weeks later...

This is a very good point you've raised up. Sending password in plaintext is very bad idea.

 

The fact that passwords are also stored in plain text inside email log is just insane.  Any employees with proper permissions can see them. Also this makes the job for any hacker so much easier - they don't need to crack the hashed passwords.

 

 

Edit: according to my investigation email body is not stored in ps_mail table, at least not in my shop, so I withdraw my previous objection. Anyway sending password in plaintext via email is a big design flaw.

 

The server logs and the prestashop database have nothing related together. You can view emails on your mail server without issue. And the emails would be saved in the "Sent emails" folder..

 

 

what is difference in doing this than say lost password being sent in an email?  it's basically the same thing...but I do understand your point.  But is it major issue, if this is only major issue in ps security,  I'm happy with that lol.

 

happy ps'ing

 

The proper way to design a forgotten password method is pretty simple. Email a special link that goes to their security questions, and expires after 1 hour. You don't ever send an email nor do you send a special link directly to a change password form. 

 

 

Good point!

 

Passwords are encrypted in DB by PS and it's very difficult to access it so no problem in DB; but the problem is just the password sent by mail to customer...well i think that it's possible to edit the mail template..i mean account.html and account.txt located in the lang directory ( it possible to do it in Admin>localization>translation. You delete the html code and the translation "printing" the pw in the message , this way the customer will receive only  a message. I think this can be a solution.

 

well i found this interesting topic:

 

https://www.prestashop.com/forums/topic/470551-email-configuration-password-encryption/

 

 

Fabrizio

 

This isn't an issue of whether or not the passwords in the database are encrypted. The problem here is the fact they are sending a unsecure email to customers with their login credentials. This is unsafe, unprofessional, and to be honest lazy programming. Not only do they display a password, but they kindly make a pretty graphic with your CREDIT CARD NUMBER on it. 

 

I discussed this issue outside of this forum post and decided to go with a different product. The lack of security in Prestashop is astonishing. 

Link to comment
Share on other sites

Guys, just sending a link will not change anything. A link can be intercepted as well and used to change a password so it's not in any means more secure than sending the password straight out.Changing Passwords should not involve any emails but to be honest even the largest companies do so. An other option is a Authenticator.

 

To be honest i would calm down some and its no major security flaw at all. It's just the common behavior shops used in the past. I have changed the core behavior long time ago so no emails are sent at all.

 

Happy time.

Edited by jetway (see edit history)
Link to comment
Share on other sites

While I agree it "looks" like a major security risk 0 is it really?

 

If you are using the standard product and the password in intercepted what can the hacker actually do? All that is stored is name, address and purchase history. No financial data is stored

 

Does a hacker really want to hack a customer account simply to make a purchase - they will still have to provide their own payment

Link to comment
Share on other sites

  • 1 month later...

While I agree it "looks" like a major security risk 0 is it really?

 

If you are using the standard product and the password in intercepted what can the hacker actually do? All that is stored is name, address and purchase history. No financial data is stored

 

Does a hacker really want to hack a customer account simply to make a purchase - they will still have to provide their own payment

This is the same mentality that allowed this to  happen: https://arstechnica.com/security/2017/03/firefox-gets-complaint-for-labeling-unencrypted-login-page-insecure/

and this https://www.washingtonpost.com/news/the-intersect/wp/2017/04/09/someone-hacked-every-tornado-siren-in-dallas-it-was-loud/

 

When security isn't taken seriously, someone will find a way to exploit it. Do you realize 90% of users use the same username and password in everything - including their bank accounts? It is YOUR job to keep YOUR customers information secure. I don't want my name or address getting out there!! 

 

Yes, it's a security issue. Prestashop should be ashamed of themselves.

Edited by mackhax0r (see edit history)
  • Like 1
Link to comment
Share on other sites

Yes, it's a security issue. Prestashop should be ashamed of themselves.

 

Moreover it's completely unnecessary.

 

There isn't any valid reason for passwords to be stored in prestashop database. And it doesn't matter they are stored encrypted - this only helps with sql injection attacks. If attacker somehow manage to upload php file he can easily obtain all stored passwords together with email addresses.

 

Remember, this attack doesn't need to be much sophisticated. It could be as simple as creating a free module, putting it on this forum and let user install it to their stores. When you install such module - congratulations, you've just disclosed sensitive information about your clients. It's very likely they use the same password for everything. So attacker can log in to their email account and figure out what other services your client uses. He can try to access their bank account. He can log in to their social networks to get more information, or to impersonate the user. 

 

In short - you have just put your clients in danger, and you could even cost them some serious money. They will probably never know it was YOUR site who disclosed their password. But if the attacker is ever caught and this information is revealed to the public, it will give your some seriously bad PR. Maybe even a lawsuit.  

 

We, developers, must accept that there will always be some bug or vulnerability that could be exploited for an attack. So we have to mitigate potential impact by reducing the amount of information attacker can get his hands on. 

 

Ok, my morning rant is done :)

Link to comment
Share on other sites

You do know that modules posted on Prestashop are checked? Or is that unfamiliar to you?

 

If you're so unhappy with Prestashop there are tons of other shop software out there but soon you will notice that most of the shops use the exact same way of storing password and letting people recover their password.

 

If you're so afraid of getting hacked, then why not go the way i did. I changed the core behavior and added a sophisticated way of detecting false password attempts.

 

Like already mentioned, no credit Card or payment information is stored so rather than placing an order there is not much to do. If a dude intercepts a password, its a new password generated from prestashop and does not have anything to do with a password the user gave...so it will not match  any passwords the user has for any other accounts.

 

 

Moreover it's completely unnecessary.

 

There isn't any valid reason for passwords to be stored in prestashop database. And it doesn't matter they are stored encrypted - this only helps with sql injection attacks. If attacker somehow manage to upload php file he can easily obtain all stored passwords together with email addresses.

 

Remember, this attack doesn't need to be much sophisticated. It could be as simple as creating a free module, putting it on this forum and let user install it to their stores. When you install such module - congratulations, you've just disclosed sensitive information about your clients. It's very likely they use the same password for everything. So attacker can log in to their email account and figure out what other services your client uses. He can try to access their bank account. He can log in to their social networks to get more information, or to impersonate the user. 

 

In short - you have just put your clients in danger, and you could even cost them some serious money. They will probably never know it was YOUR site who disclosed their password. But if the attacker is ever caught and this information is revealed to the public, it will give your some seriously bad PR. Maybe even a lawsuit.  

 

We, developers, must accept that there will always be some bug or vulnerability that could be exploited for an attack. So we have to mitigate potential impact by reducing the amount of information attacker can get his hands on. 

 

Ok, my morning rant is done :)

Link to comment
Share on other sites

You do know that modules posted on Prestashop are checked? Or is that unfamiliar to you?

 

I said this forum, not prestashop addons store. There is a section here offering free modules, developed by anyone.

 

Anyway, I looked into the PS code and I have to retract my last post. I based it on Fabry's response

 

 

Passwords are encrypted in DB by PS 

 

which is actually not true - passwords are not encrypted, they are hashed and therefore can't be retrieved. 

 

So my morning rant was misdirected :)

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...