Account created - password is "your password"

From issue #1566218 (which dealt with Ubercart 2.x).

When an anonymous user completes a checkout, and the store is set to create a new user account for that user but not automatically log them in, then the completion page displayed to the user specifies the new password as "Your password". Refer following:

Order complete
Your order is complete! Your order number is 3.

Thank you for shopping at Mainspring Six-Test. A new account has been created for you here that you may use to view your current order status.

Login to your new account using the following information:

Username: user03
Password: Your password

Return to the front page.

This function worked fine in Ubercart release 2.7, so the changes to create 2.9 have caused the problem, which is that the data attribute "$order->password" is missing when the above messages are generated.

My investigations show that when the function "uc_cart_checkout_complete" (in file uc_cart.pages.inc") is called as the menu item "cart/checkout/complete" that it loads the order from the order_id in $_SESSION but this copy of the order no longer has the attribute "$order->password" set so when the call is made to function "uc_cart_complete_sale" it cannot set the variables required for substituion into the messages to display on the completion page.

Note that the function "uc_cart_complete_sale" was called earlier in the process by "uc_payment_enter" (in file uc_payment.module") and at that time the $order->password attribute was present.

Note also that the two emails sent to the anonymous user both have the password correctly embedded. The Drupal standard system email "register_no_approval_required" email (see "admin/user/settings") is sent in function "uc_cart_complete_sale_account" (which is called by "uc_cart_complete_sale" and is the place where the new password is generated). I don't know where that other email is sent from, but it comes from the template "uc_order-customer.tpl.php".

A work around is to replace the checkout completion message to remove the account credentials and advise that the new account details have been emailed to the user.

This change had to be made to fix the security vulnerability noted in SA-CONTRIB-2012-064: http://drupal.org/node/1547674

"Your password" shows up when the user selects their own password at checkout; it is expected that they should remember what they entered, and we should not send it in plaintext. If a password is not entered at checkout then a randomly generated password should be included in the email.

In 6.x, the message sent by Drupal core contains the password, but in 7.x it only contains the login link. This is a design decision in core and Ubercart cannot affect this.

The issue I reported did not relate to the email message being sent by Drupal or Ubercart to the user, but rather to the contents of the checkout completion page.

I thought I had explained clearly that the "uc_cart_checkout_complete" function generates the message shown to the user. In Ubercart release 2.7 the randomly generated password was in $order->password (an attribute that did not get saved to the database anyway) at the time these message strings were generated, but in release 2.9, this value had been deleted from the $order object by the time it got to the function "uc_cart_checkout_complete".

This password value should be left in the $order object until after that function has run, or else another way found to pass the value to the function where the strings are generated.

The issue that I reported in http://drupal.org/node/1566218 and which was moved here as per the request of TR has not been fixed by the changes referenced. In fact, the changes referenced (removing the system generated password from the order object) seem to have created the problem. I have therefore re-opened this issue so that it does not get forgotten. It may be more appropriate to re-open the original issue as I believe that it was distinct from the one that this thread has covered.

In Ubercart release 2.7 the randomly generated password was in $order->password

No, it wasn't; previously the password was stored inside $order->data which was saved to the database, and hence the source of the vulnerability.

In release 2.9, this value had been deleted from the $order object by the time it got to the function "uc_cart_checkout_complete".

Can you identify where this occurs? There is no explicit deletion from the order object.

However, if your payment method involves redirecting offsite, then I guess the password can be lost from memory during this redirect. I don't see your payment method specified, but if this is the case, I am not sure what we can do about it, given that we are not allowed to store the plaintext password anywhere.

Need to know what payment method you are using to try and reproduce this further.

No, it wasn't; previously the password was stored inside $order->data which was saved to the database, and hence the source of the vulnerability.

Refer to:

function uc_cart_complete_sale_account($order) {
  // Order already has a user ID, so the user was logged in during checkout.
  if ($order->uid) {
    $order->data['complete_sale'] = 'logged_in';
    return;
  }

  $result = db_query("SELECT uid FROM {users} WHERE LOWER(mail) = LOWER('%s')", $order->primary_email);

  // Email address matches an existing account.
  if ($account = db_fetch_object($result)) {
    $order->uid = $account->uid;
    $order->data['complete_sale'] = 'existing_user';
    return;
  }

  // Set up a new user.
  $fields = array(
    'name' => uc_store_email_to_username($order->primary_email),
    'mail' => $order->primary_email,
    'init' => $order->primary_email,
    'pass' => user_password(),
    'roles' => array(),
    'status' => variable_get('uc_new_customer_status_active', TRUE) ? 1 : 0,
  );

  // Override the username, if specified.
  if (isset($order->data['new_user']['name'])) {
    $fields['name'] = $order->data['new_user']['name'];
  }

  // Create the account.
  $account = user_save('', $fields);

  // Override the password, if specified.
  if (isset($order->data['new_user']['hash'])) {
    db_query("UPDATE {users} SET pass = '%s' WHERE uid = %d", $order->data['new_user']['hash'], $account->uid);
    $account->password = t('Your password');
  }
  else {
    $account->password = $fields['pass'];
    $order->password = $fields['pass'];
  }

  // Send the customer their account details if enabled.
  if (variable_get('uc_new_customer_email', TRUE)) {
    drupal_mail('user', 'register_no_approval_required', $order->primary_email, uc_store_mail_recipient_language($order->primary_email), array('account' => $account), uc_store_email_from());
  }

  $order->uid = $account->uid;
  $order->data['new_user']['name'] = $fields['name'];
  $order->data['complete_sale'] =  'new_user';
}

which appears to show clearly that the password generated for a new user is stored as $order->password.

This was available in the $order object passed to function "uc_cart_checkout_complete" when I was testing with v2.7, but not with v2.9. I demonstrated this by installing a fresh copy of Drupal/Ubercart (v2.7)/PaymentExpress which worked. I then upgraded to Ubercart v2.9, and it no longer worked.

I am using the uc_paymentexpress module to provide access to the DPS PaymentExpress payment gateway via a hosted payment page (so user is redirected away from Ubercart to make the payment and then returns on completion). It may be that the password was being held in $_SESSION or similar in the earlier version, but this is no longer the case.

A workaround is to modify the checkout completion message displayed to users so that it does not try to show the login id and password, as these have been correctly emailed to the user.

I may look at implementing a function hanging off hook_order to catch and remember the generated password at some stage if I feel that I require this to be displayed to the user on completion of checkout.

The code you quote was rewritten for 6.x-2.9.

The code from 6.x-2.7 can be found here:

http://drupalcode.org/project/ubercart.git/blob/8d47b419a801d60e0724241f...

Note this does not set $order->password, instead setting $order->data, which is saved in the database and hence the source of the vulnerability.

I have tracked down the problem, and it appears that it was not related to the 2.7 -> 2.9 upgrade but simply happened at the same time.

The message shown to the user at completion of the checkout process is generated by the function uc_cart_complete_sale as shown above. It turns out that various different payment process functions are calling this function in order to ensure that the user account is available to them, so when the "real" cart checkout completion processing is being done (the order object having since been reloaded several times), the originally created password is no longer available.

I have solved my problem by using hook_order to capture the password when it is created, and to store it in the $_SESSION variables until it is really required at the end of the checkout.

A better solution would be to re-structure the checkout process so the uc_cart itself created the user account (if required) during the submit processing and making it available for all subsequent processing.

Stopping all the continual "order_load" calls (from other contributed modules) that happen during this phase would also greatly assist .

I see this on my Ubercart 3 install. I find two simple configuration workarounds to the original problem with the checkout message - no coding required:

1. Edit the checkout message. It's at admin/store/settings/checkout. Click on "Completion messages". Scroll down to the New Users text field. Change the message to remove the nonsense about the account. Instead, put in something about "Instructions for logging in have been e-mailed to you." Click Save configuration. Or....
2. Log in new customers. It's at admin/store/settings/checkout. Click on "Anonymous checkout." Select the "Log in new customers after checkout" checkbox. Click Save configuration

If you want the new customer to know his new password immediately, there is also an option for him to specify it at checkout time.

Meanwhile, since it seems that the !new_password "token" is no longer functional, it should not be mentioned on the config page, and the default "New users" message should be changed to not include it. This is the work that should be done, and it should be a pretty easy patch.

The new_password token *is* valid for the case where the password is auto generated by the system, and a payment method is used where the account is created during checkout (as opposed to PayPal WPS, where the account may be created during the IPN). As we are not allowed to store the plaintext password for security reasons, this is the best we can do. The checkout messages are configurable for exactly this reason. Unless you have disabled it, the user will always be emailed their new account details.

longwave, what people have tried to express to you multiple times in this thread is that in the exact situation you describe — "where the password is auto generated by the system, and a payment method is used where the account is created during checkout" — Ubercart simply replaces that !new_password token with the string "Your password". It does not display the password itself.

I am using Authorize.net to process credit cards. The user never leaves the site during the checkout process. And when an anonymous user completes the checkout process, they see the first attached screenshot. I hope a picture helps increase your understanding here.

So given what you've seen now, can you elucidate under what circumstances you consider the !new_password token to be valid?

EDIT: Please disregard the second screenshot below, it was part of another point I made which turns out to have been mistaken.

Drupal 7.23 + UberCart 7.x-3.5 (from 2013-Jul-11)
Payment method: PayPal Website Payments Standard (sandbox)

[EDIT: the problem is real enough, but a solution with combination of settings is found below at: #21]

I appreciate that the other postings here are almost a year ago (and thanks to all of you for your contributions) but there still seems to be a problem when using UberCart in combination with PayPal Website Payments Standard.

If under the configuration > checkout > anonymous checkout options one does not allow new customers to specify a password, it is not apparent that a password is ever generated, although the default Customer information pane message (easily changed of course, as pointed out above) promises:

Optional. New customers may supply custom account details.
We will create these for you if no values are entered.

The Account details email that arrives on completion has (as pointed out in many examples above) not a password, but just:

username: [username]
password: Your password

It also includes a single-login link that is supposed to be used to set your password:

This link can only be used once to log in and will lead you to a page where
you can set your password.

But this can result in a trap if one has also selected the option to:

[x] Log in new customers after checkout.

The user can't change the password, as an original password (never issued) has never been emailed or communicated to the user; The user is stuck, and the only way to get out of the cul-de-sac is for the admin to reissue the password (or for a password change request to be made, I did not try that, but it is not ideal).

As far as I can tell, the only thing that works is to enable:

[x] Allow new customers to specify a password.

And then safest is to then disable:

[ ] Log in new customers after checkout.

So that the emailed Account details single-use link has its intended function.

But that is also not completely safe, because it is relying on the user to record the password. Both on the the completion page at /cart/checkout/complete and in the Account Details email, even when one has provided a password, it simply says:

Password: Your password

I think for most customers that is not the expected behaviour, "normally" full login details are emailed (even if one provides the username and password at purchase). I recorded my test passwords in a password wallet, but otherwise the current setup (in combination with PayPal at least) is error prone.

I acknowledge that the problem can in part be addressed by changing the messages to customers in the configurations, but it is not ideal.

Drupal 7.23 + UberCart 7.x-3.5 (from 2013-Jul-11)
Payment method: PayPal Website Payments Standard (sandbox)

My current workaround is to change the default 'Customer information pane' settings at /admin/store/settings/checkout to:

IMPORTANT: New customers must supply custom account details (both username and password).
Please note your password carefully and securely; Your username (only) will be emailed to you.

It may seem a bit stern, but otherwise users may rely on an emailed password.

I welcome any feedback on similar experiences with my combination of UberCart 7.x-3.5 with PayPal, or different experiences with other payment gateways.

[EDIT: no, it is better to not let anon users set password, see solution at: #21]

Drupal 7.23 + UberCart 7.x-3.5 (from 2013-Jul-11)
Payment method: PayPal Website Payments Standard (sandbox)

[EDIT: prefer solution at: #21]

An alternative strategy is to disable entry of a password by anonymous users on purchase (at checkout), and then rely on the link in the Account Details email. The logic and text of that email then make sense, and it works (one does not need an existing password to change the password) as long as one does not have the option to login automatically on returning to the store enabled (because that requires an old password to change the password, a "trap").

The information for New account details help message at /admin/store/settings/checkout then has to become something like (rather verbosely):

IMPORTANT: New customers must supply a username (please use at least 6 characters).
You will be emailed a special single-use link that you can use to login once and set your password.

(Please note your password carefully and securely, it will not be emailed to you on being set.)

It is important that you use this single-use login link within 24 hours.

But it is still not ideal:

Problem1: the password selected by the new user is never emailed to them, not even when they login using the single-use emailed link and then set/choose a password. This may be down to Drupal core. As far as I can see there is no option under /admin/config/people/accounts to have username and password details emailed when a password is set or changed (except when an account is created by admin).

Problem2 (not such a worry because the form can be customised): The logic of the default Order complete page text at /cart/checkout/complete then no longer applies:

Order complete

Your order is complete! Your order number is nn.

Thank you for subscribing to [store] . A new account has been created for you here that you may use to view your current order status.

Login to your new account using the following information:

Username: [username]
Password: Your password

But of course one does not yet have that information. There is nothing in there to say that you need to use the emailed single-use link instead.

I appreciate that this can be changed under: /admin/store/settings/checkout New users. But even if one changes the default text, how can one include a reference to the single-use login link (that is emailed) on that page ? The best one can do is tell new users that they should check their email and use that link. It would be nice if the single-use link could be embedded in that page on completion of the sale.

Q: Is there a token for the single-use login link ?

[EDIT: no, just don't sent the email with the single-use link, see solution at: #21]

Drupal 7.23 + UberCart 7.x-3.5 (from 2013-Jul-11)
Payment method: PayPal Website Payments Standard (sandbox)

I still can't get it to be consistent with anonymous users purchasing.

If I do not permit the anonymous user to choose a password at the checkout (but do ask them to set a username) they get 2 emails with different information:

1. An email with 'Subject: Your Order at [store[', containing both the username and a valid password.

2. An email with 'Subject: Account details for [username] at [store[', containing only the username and the 'your password' placeholder, and the single-use login link.

It makes no sense to have the 2nd email or to use that single-use login link when one has just been sent a valid password.

[EDIT: so just don't send the email with the single-use link, rely on the Your Order at email, it has the generated password, see solution at: #21]

Drupal 7.23 + UberCart 7.x-3.5 (from 2013-Jul-11)
Payment method: PayPal Website Payments Standard (sandbox)

The solution for my setup is to set the following at /admin/store/settings/checkout under Anonymous checkout:

Enable:

[x]  Allow new customers to specify a username.

Disable:

[ ]  Allow new customers to specify a password.

Disable:

[ ] Send new customers a separate e-mail with their account details.

That way there won't be a clash between the 'Order at [store]' email with a password and the Account details email with the single-use login link.

Disable (now optional, since no clash with single-use email link):

[ ]  Log in new customers after checkout.

Under Completion messages for New users messages can be changed to draw the new customer's attention to the 'Order at [store]' email with the password, noting that under PayPal it seems not to give the !new_password token, so that should be removed.

@webel: Thanks for the detailed testing and explanation of this issue.

There is nothing more Ubercart can do here, as we are not allowed to store plaintext passwords for any reason. There are automated tests to prove this works as far as possible for basic payment methods, but it is not guaranteed to work with all payment methods; you will have to figure out a combination of settings that works best for your store setup in this case.