Its horrible security to send out passwords in cleartext.

  • Security is sadly a topic that the EDD people to not care about. Sending clear text passwords out to people should not be done. I have fixed this with this code. This hides the field be then tells the users after the did the purchase that they should create a password. Not very user friendly, I currently had disabled it but I am thinking of activating it again because I think my sales gone down because if this.

    
<?php
namespace nextgenthemes\website;

add_filter( 'edd_auto_register_email_body', __NAMESPACE__ . '\\edd_auto_register_email_body', 10, 4 );

function edd_auto_register_email_body( $default_email_body, $first_name, $username, $password ) {

	// Email body
	$out = __( "Dear", "edd-auto-register" ) . ' ' . $first_name . ",\n\n";
	$out .= sprintf(
		__( "Thanks for your purchase! A account with a random password has been created for you. Please <a href='%s'>follow the lost password procedure</a> to create a secure password for your account in case you want to ask a support question or access your downloads. (For security reasons passwords are not send out in cleartext)", "nextgenthemes-website" ),
		wp_lostpassword_url()
	) . "\n\n";
	$out .= __( "Your Username:", "edd-auto-register" ) . ' ' . $username . "\n\n";

	return $out;
}

    Also using emails and usernames isn’t exactly great either as you can guess them form the author slugs WP generates from them.

    My Idea would be so simply use javascript on checkout to fill in a random generate password on checkout automatically. WP already has a function for this. And do not display the 2nd password confirm field at all, and maybe even autofill the username field with something based on the first/last name they enter.

    To elaborate on my point that this is not the first time I notice this pattern from EDD:

    They had ssl_verify => false all over their code, I think its now changed it now changed some areas, or at least the is a option to verify your shops ssl. But with the software licensing extension those API calls and downloads are (or at lease were) totally unresponsively ignoring SSL altogether. Because some WP bug that was fixed like 10 years ago. Their entire attitude to simply ignore it because it may fail in some very rare cases is very bad.

    It could lead to a chain reaction from a MITM attack on easydigitaldownloads.com that all extensions they ship to customers would ship from hackers sites instead with malicious code and given that many of their customers use EDD SL as well they could spread it from there. Because all the API calls simple ignor(ed) SSL! Not a security expert but at least I pay a little bit attention.

    Also, and my guess is that this is very common in this industry. They do support via email and they expect you to send them passwords to your sites in cleartext!

    Great Idea, bad execution.

    • This topic was modified 6 years, 9 months ago by Nico.
    • This topic was modified 6 years, 9 months ago by Nico.
Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Contributor Pippin Williamson

    (@mordauk)

    Nico,

    First of all, thank you very much for your genuine feedback. While we’re never thrilled to hear negative experiences, it does help us be more proactive in improving areas of the platform.

    Let me be perfectly clear: security is of the utmost concern and priority to us.

    There are a few items here that should be addressed.

    1. The password that is sent in plain text is an auto generated password. It is sent only as a temporarily password and it is never intended that the user use that password permanently. What we should be doing here, which we do not currently, is clearly informing the users that they have an auto generated password that needs to be changed after the purchase is complete. Doing this would resolve the security concern while still providing an easy, clean experience for the customer.

    2. You mentioned the ssl_verify flag that we used to set to false. You’re absolutely right about this. We hated that we had it that way but it was genuinely the only way for a long time while the bug in WordPress itself was present. When the bug was resolved, we were able to cease that practice. If you have ever noticed it anywhere that we missed, please do let us know as we do want to ensure that all instances have been updated.

    3. When it comes to security concerns, please consider contacting us privately via [email protected] with the information so we can work with you to get any and all concerns addressed without broadcasting problems to the wider internet that potentially allows someone of malicious intent to exploit them. Our team includes three of the top security experts in WordPress and security is something we care greatly about.

    Best regards

    Thread Starter Nico

    (@nico23)

    security is of the utmost concern and priority to us.

    Sorry but NO! Just no.

    1. The password that is sent in plain text is an auto generated password. It is sent only as a temporarily password and it is never intended that the user use that password permanently. What we should be doing here, which we do not currently, is clearly informing the users that they have an auto generated password that needs to be changed after the purchase is complete. Doing this would resolve the security concern while still providing an easy, clean experience for the customer.

    Lets see how the WP standard registration process looks like.

    1. You put in your email.
    2. WP sends a email with a code as url arg to you.
    3. You do back to the site your email is verified.
    4. Then you will be asked to type in or use a generate pass. This will be the first real pass you get for your account.

    And or a similar process is pretty much how every single site on the web works. So no I do not think this is all good by simply telling people to change the pw after its send to them. If they don’t it will be a valid pass forever and I think its a reason sites do not do it this way.

    The authorization code to generate a pass has the same effect as your proposed temp pass but its better because its not a password and I do not know the details, yes its send on cleartext as well but my guess is WP will do some things to improve security like deactivating the account when no pass is generated in a certain amount of time …

    Can’t you hook into the the default user registration process of WP? The user should just be send the default mail WP sends out when vanilla registering.

    You also did not address the part about using email addresses as usernames, users are able to login with their emails anyway no matter what their username is. And again emails can be easily guessed by the author slug WP generates. I think this entire approach is bad for security. I feel bad about it because thanks to this plugin I have a lot of customers in my DB with their email as their username and also a password that they never changed that was send in cleartext.

    2. You mentioned the ssl_verify flag that we used to set to false. You’re absolutely right about this. We hated that we had it that way but it was genuinely the only way for a long time while the bug in WordPress itself was present. When the bug was resolved, we were able to cease that practice. If you have ever noticed it anywhere that we missed, please do let us know as we do want to ensure that all instances have been updated.

    Also let me be clear about this it was actually me who informed you about this, otherwise you would have kept in in place for the next 10 years until finally someone else whould point it out to you. And I got nothing that a little “thank you” text for this.

    So to not tell me

    security is of the utmost concern and priority to us.

    its just sounds ridiculously dishonest. And no it was not the only way. You could have detected the PHP WP combination that was very very outdated that had this problem where ssl failed, then you should inform users they had to upgrade or enable a option and a BIG FAT warning that this option will compromise their security. But no what you did was took the lazy sledgehammer method because you did not want to have support influx because of this or whatever. Just NO! You did not cease that practice when that bug was resolved, you ceased it after a way to long time after I told you about it!

    3. When it comes to security concerns, please consider contacting us privately … Our team includes three of the top security experts in WordPress and security is something we care greatly about.

    Since when do you have them employed? So it takes some guy who has a little bit of knowledge and above average attention I guess to be alarmed by software delivery done with sslverify => false. And lastly let me also tell everyone that I did contact you privately about this, to lazy to research the exact time-frame but I think it took you over 6 months to actually do something about it. Sorry but I can’t really take you seriously when you claim now that you care so much. Not sure what those security experts are doing but this should be the very first thing to spot and fix, from what I saw anyway.So please do not act like I am just

    broadcasting problems to the wider internet

    right away. Do people get anything out of it apart from a “thank you” text via email?

    I actually wrote some JavaScript now that simplifies/reduces the checkout process. Will be live on my site soon I guess and I will maybe release it as as a plugin. But again I think most ideal solution to this would be to combine this with the vanilla registration process WP already has. Not sure if this is possible but I would be happy if would do it this way.

    • This reply was modified 6 years, 9 months ago by Nico.
    • This reply was modified 6 years, 9 months ago by Nico. Reason: bah
    • This reply was modified 6 years, 9 months ago by Nico.
    Plugin Contributor Pippin Williamson

    (@mordauk)

    Adding an option to enable a password to be set through an email notification is a good idea. Note, instead of berating us, you could have made that as a friendly suggestion and we’d have happily considered it ??

    Keep in mind that some features do not get added, or are in the backlog, simply because there is so much to do each day. The lack of a feature doesn’t mean it’s ignored or that bad practices or lack of caring are in place.

    Also let me be clear about this it was actually me who informed you about this, otherwise you would have kept in in place for the next 10 years until finally someone else whould point it out to you

    Thank you for bringing it up! You were not the only person that noticed, however, so please be respectful and do not assume the worst of us or anyone else. We were of the issue for quite some time. We did, afterall, make the conscious decision to include it after learning about the problem in core.

    Your concern with emails as usernames is valid and could be addressed by auto generating usernames. Please also keep in mind, however, that logging in by an email address was not possible until a recent release of WordPress core and this plugin has been around much longer. Again, some times changes do not get implemented as fast as we would like simply because there are not enough hours in the day.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Its horrible security to send out passwords in cleartext.’ is closed to new replies.