Is there really a reason for "current password" when resetting?

Before I go and change things, I'd like to bounce this off some people.

Most sites work just like Zen does. You want to change your password, so you log into your account (obviously requiring your password) and you click on Change Password and now you're required to enter your current password... again.

First off, I hate unnecessary repetition. But more to the point, I want to help customers who have their accounts auto-created during a PayPal Express checkout. If they click "My Account" and go to change their password... what is their "current password"? They have no idea since they were never given one.

So I'm proposing that I'll simply remove the current password check. But am I opening up a security risk? I don't think so, but perhaps I'm missing something.

I want to preface by saying: ignore the whole "perhaps they walked away from their computer and someone could hijack their account" scenario. Other than that scenario, what is the harm of allowing a more direct password change?

s_mack:

I want to preface by saying: ignore the whole "perhaps they walked away from their computer and someone could hijack their account" scenario. Other than that scenario, what is the harm of allowing a more direct password change?

That is actually the only scenario that I can think of.

Cheers
RodG

This is in fact the reason.

Yes, I figured so. I believe it is an outmoded concern that hasn't really applied since the late '90s. Of course, I understand that it could be a concern for some depending on the site. It isn't a concern for my shop.

I believe it isn't my job to treat my customers like children. If they are still using Internet cafe's, surely they are familiar with logging out. I don't see the reason to annoy 99% of customers for the pseudo-protection of the 1%.

And protect against what? I don't retain anyone's payment info, so at worst they can see what's in their cart and pull up their address. Or - heaven forbid - some random stranger could use their own payment info to purchase an item in someone else's name. Seeing as though I'm not selling yellow cake Uranium, I don't see why that would be a problem either. Weird and creepy, perhaps.

So I have removed the double-need for a password and I've also removed the automatic timeout of customer sessions. I personally HATE it when I come back to a site I was shopping at to find my cart cleared. And yes, if they're logged in it doesn't happen but if I can't remember to log in to my own site when testing it I can't expect my customers to either.

Unless there's another reason then... I'm satisfied with this.

s_mack:

Yes, I figured so. I believe it is an outmoded concern that hasn't really applied since the late '90s.

Have you thought through all possible abuse cases? CSRF, XSS, remote attack? It's not just an unattended laptop in a coffee shop that you have to consider.

Assuming that the change discussed is only to be made for such a case of:

make purchase, stay logged in because purchase auto-created the account, goto account details to change the password without awaiting the autogenerated email that typically arrives before the purchase has even been complete.

Well, would say that if one were able to use appropriate credentials to make an automated purchase, the communication related to that purchase (and account login information) would be sent to the "appropriate" email address. Sure the email address of the account holder could be changed without having the new password; however, all purchases would need to be made at that point while still logged in/keeping the session active rather than being able to wander away from the device and login at a later date without having either access to the email account (more than likely available if a mobile device of the owner was used and "lost") or the device used to make the purchase.

All-in-all it appears to be a security step to ensure that the individual making the modifications has the information available that would be expected of someone with the authority to make the change(s) and if not, then perhaps the store would need to be contacted to resolve. While it can be helpful to minimize such interaction, I would say that it should not be the primary goal to eliminate all interaction.

And considering it as treatment as children?

What kind of client is making an automated purchase and immediately trying to change their password? Is this occurring in your 99% of your client population?

Why not provide an opportunity up front (or just after returning from the payment processor but before the purchase is finalized) for them to generate their own password as part of the automated process and go from there instead of removing a protection after the fact?

From the above, it appears that you are trying to address (and from what it seems above have addressed) more than the original question of the need for the current password in order to change the password when completing an automated account generation purchase. Now it is as if the current password is only needed to login to the account and at any time after login the password can be changed by whomever is at the change password screen.

s_mack:

... I believe it is an outmoded concern that hasn't really applied since the late '90s. Of course, I understand that it could be a concern for some depending on the site. It isn't a concern for my shop. ...

Understood (and I can understand it may not be much of a concern if zero payment data is stored, most orders are small in $$, and when large orders are flagged by the store owner for followup before shipping). This is your choice and I am not going to tell you it is wrong for your store. I will however type a little about my thoughts.

Personally I'd rather see the "password verification" step extended to additional actions (such as viewing / editing account details). Of course, I am also a fan these being an "option" (some people only learn fire burns by sticking their hand in the flame) and the option being enabled by default (as they are good for the majority).

swguy:

Have you thought through all possible abuse cases? CSRF, XSS, remote attack? It's not just an unattended laptop in a coffee shop that you have to consider.

Have to agree with swguy. There are a number of potential methods an attacker could use to gain unauthorized access. Having to enter the password again (before being able to change the password) is just another layer of protection. I'd rather know a shop is paranoid about protecting my information versus the store skipping an easy to complete verification step / action.

Just last month I made a purchase via Amazon. I logged in. I took a look at my payment history (wanted to see how much I paid for something). I noticed they had a CC on file (which I obviously wanted to remove). Before I could access the "account details" page (including the CC information), Amazon required me to "verify my password". I did so and removed the CC. I then continued browsing Amazon and found something I wanted to purchase. During checkout (the shipping step), Amazon required me to once again "verify my password" in order to continue.

So I guess I would not consider using an extra protection layer via "verify your password" to be obsolete.

But isn't that entirely different? Amazon, as you found out, stores your payment details.

Ok, help me understand. OTHER than payment details (which aren't stored on my site)... what real harm is there if someone were to gain unauthorized access to someone's account? So Evil Bob manages to see that Silly Sally was shopping at Little Store and forgot to log out. Evil Ed sits down and changes Silly Sally's password. In fact, he totally hijacks her account and changes her email too. He can see she ordered some Doodad from Little Store. He can see where Silly Sally lives (of course, Silly Sally has lots of ways for someone to figure that out, not the least of which is following her home you know, since Ed is Evil). He can even order something in Silly Sally's name and have it sent to his house, or her house or some random stranger's house. Of course, Ed is an Evil Genius, so he knows he has to use his own credit card, but hey... I guess he's evil and generous.

My point (and genuine question)... what's the worst that can happen? Isn't is a really rare edge case with virtually no consequence?

I still see it as a "layer of protection" that doesn't really protect anything and is annoying.

Now MC12345678 above seemed to indicate there's some automated email that goes out when an account is generated. There is, but it doesn't have anything useful in it, at least not with my test. It certainly doesn't give the customer a password. If it did, I wouldn't be here... that would suffice for the reason I started this. I came here for a reason though, so why aren't we experiencing the same thing?

s_mack:

... Ok, help me understand. OTHER than payment details (which aren't stored on my site)... what real harm is there if someone were to gain unauthorized access to someone's account? ...
Personally I consider my address, phone number, email address, etc all to be "private data" which should be protected from prying eyes or potential attacks. Thus my stance I would prefer to see an option where this setting is expanded. Any information gained could be used as the basis for future "phishing campaigns" by a malicious person.

As to your question, with a stock version of Zen Cart (and no additional data being passed through or saved by the store / website)... With stock code the attacker cannot change the customer's password (and lock them out of the account) unless one of two things happens. Either the attacker needs to know the current password, or the attacker would have to first change the customer's email address to one of their own (which would then be recorded and could be used to potentially track the attacker) and after changing the password use the "password forgotten" page to send a new password to the registered email.

So worst case: potentially one less step an attacker would need to perform to gain future access to the person's account; and one less step required for an attacker to block the customer from making future purchases on their account (without resetting the password / calling the store). Pretty minimal in your case.

What a malicious person could do with the account in the future is more interesting (and scary) such as: using the store as a way to validate stolen payment records gained from somewhere else, shipping fraudulent orders to an address and intercepting for pickup, etc.

Of course in most countries the liability to the store for such actions would be limited, but could require some time be spent by the store: to help a customer reset their account or to review logs and report information requested by law enforcement / banking entities.

But again, just some quick thoughts (not exhaustive).

s_mack:

... "But more to the point, I want to help customers who have their accounts auto-created during a PayPal Express checkout. If they click "My Account" and go to change their password... what is their "current password"? They have no idea since they were never given one. ...
Yes, I agree this is not the most friendly scenario. The same goes for when a store takes an order over the phone (and enters the customer into the Zen Cart database).

s_mack:

... Now MC12345678 above seemed to indicate there's some automated email that goes out when an account is generated. There is, but it doesn't have anything useful in it, at least not with my test. It certainly doesn't give the customer a password. If it did, I wouldn't be here... that would suffice for the reason I started this. I came here for a reason though, so why aren't we experiencing the same thing?
I believe McNumbers was suggesting the posted change above as a way the original issue could be addressed without removing any security layers.

For example when a customer purchases via "Paypal Express" checkout, offering the customer a link to set their password. Or in the confirmation email add a link to the "password forgotten" page (labelled as click here to change your password) - which allows changing the password via email. I would probably make some changes to the "password forgotten" page text as well (maybe something like "reset your password").

s_mack:

I still see it as a "layer of protection" that doesn't really protect anything and is annoying.

As a general rule, that is what I think of SSL. :-)

Cheers
RodG

I don't think it is appropriate to ask someone to "change" their password when, from their perspective, they never had one to begin with.

I think what I'll do is use a bit more logic. IF the customer is in the session immediately following auto-account-creation AND they go to change the password... that the check-for-current-password function will be bypassed.

Admittedly, that's the only scenario I can think of where it is really necessary and it probably isn't a very common question afterall. I only uncovered the possibility as I was testing the flow of my new site and I chose to change my password right after auto-creation and it occured to me I have no idea what the password is.

Thanks for your help/input all.

RodG:

As a general rule, that is what I think of SSL. :-)
Aye, the issues with trying to protect data in transit when you have no control or trust of the devices and lines between the client and the server. SSL encryption is just another layer of the onion (which can be defeated via a man-in-the-middle, compromised SSL issuer, compromised computer, etc). And of course worthless when the data is leaked via other communications.

Thought about you the other day while reading an article on GPU Virtualization (and the first major use to defeat one-way encrypted text via a combination of brute force and lists). Exponential computing power growth is an understatement.

s_mack:

... I think what I'll do is use a bit more logic. IF the customer is in the session immediately following auto-account-creation AND they go to change the password... that the check-for-current-password function will be bypassed ...
Hmmm, now that I think about the situation more... I seem to remember some code in "PayPal Express Checkout" specifically "paypalwpp.php"... Something about the "customers_paypal_ec" column on the "customers" table in the database being used to indicate the created account is temporary during checkout and some code deleting the account after checkout completes... Maybe in a newer version of Zen Cart?

Perhaps someone a little more knowledgeable regarding "PayPal Express Checkout" and the above could comment?

s_mack:

Now MC12345678 above seemed to indicate there's some automated email that goes out when an account is generated. There is, but it doesn't have anything useful in it, at least not with my test. It certainly doesn't give the customer a password. If it did, I wouldn't be here... that would suffice for the reason I started this. I came here for a reason though, so why aren't we experiencing the same thing?

The real question(s) here is what is different about your store from a default store?

Dear "Customer's Name"

We wish to welcome you to "Store's Name".

You are now registered with our store and have account privileges: With your account, you can now take part in the various services we have to offer you. Some of these many services include:

Order History - View the details of orders you have completed with us.

Permanent Cart - Any products added to your online cart remain there until you remove them, or check them out.

Address Book - We can deliver your products to an address other than yours! This is perfect to send birthday gifts direct to the birthday-person themselves.

Products Reviews - Share your opinions on our products with other customers.

Your account login details, which you can use to review your purchase, are as follows:
Username: "LoginUsername"
Password: "RandomPasswordGeneratedByZC"

For help with any of our online services, please email the store-owner: "Store Owner's Email Address"

This email address was given to us by you or by one of our customers. If you did not signup for an account, or feel that you have received this email in error, please send an email to "Store Owner's Email Address"

This email is sent in accordance with the US CAN-SPAM Law in effect 01/01/2004. Removal requests can be sent to this address and will be honored and respected.

So the above is a "default" email with data from a new account replaced with a quoted version of what is normally provided.

My further question about this "test" is, is it that the email was not received, or is it that it wasn't generated and further if it was generated was it missing information?

As to some of the other points by lhungil, it had been a while since I had logged into and review the My Account area, but I too had expected to find a request for credentials to support accessing/changing the information related to say the email address or other "personal information" before I posted above. But yes, I was referring to the possibility of self generating a password during the process of checkout offering the customer a link (or other method) to set their password. Or in the confirmation email add a link to the "password forgotten" page (labelled as click here to change (set/create/recreate) your password etc...)

With regards to the terminology, like all things it can be changed to something else... It's a lot like one of the FAQs on this website addressing changing/resetting the password for admin login... Could leave the code alone and add text for the case of the just auto-created an account via purchase to add text about finding the password in the confirmation email sent to the account used for registration/purchase... These things provide the additional information that is so missing without reduction in security... (And in a way are far "easier" to correct/adjust...)

Heck, if there is a thought that the page's information seems like treating customer's like a child, then spoof it and make some sort of fun/funny text/photo/information on it calling it what it is... Just some other thoughts.. :)

on my store, after a customer purchases with PPE, it by default told them a "temporary' account was created and would be removed upon logging out. I tried that, but certainly the account remained. So at first I just changed the text to be at least truthful. But then I got to suggesting they change their password and provided a link to that page which, of course, they couldn't effectively use since they didn't know their password.

An order email is generated and sent to the customer but there's no mention at all of a password. That's with my relatively stock 1.5.4 installation and turning on PayPal Express Checkout as the only payment method. I say "relatively" stock because I do have extensive modifications to the templates but very few changes to modules or other files. I haven't gotten that far yet :) I'm still using 1.3.9 for my live store for the very fact I so extensively modded it that its taken me this long to finally upgrade. I found an upgrade too difficult (and my site looking too stale) that I decided to start from scratch.

I think the real question should be why isn't a temporary password given at the time of account creation or why doesn't the temporary account get removed.

But both those questions should be posted in the module thread.

I would do a customer password check to see if one exists, if "passed" allow account_password form to be utilized, if "failed" return a short message, "Your account is temporary and NO password is assigned to it, please click here to create a permanent account with us and have a password emailed to you."

Pass a response code in the link to alter the password_forgotten page defines.

So instead of the page saying Forgotten Password it Says "Create a Permanent Account".

Just MO

I think that what is CLEARLY happening here is that s_mack has uncovered an incomplete workflow.. Being a business analyst/project manager by day (and super hero by night:laugh:) it seems quite obvious that the PayPal Express integration workflow needs to be re-worked so that some logical things happen.. rbarbour touched on this too..

Considerations/Options

• When a Zen Cart customer profile is created "auto-magically" via the PayPal Express what options should be provided so that the customer can access the auto-generated account??
• Does the customer get some kind of notification about this auto-generated account?? Does this notification include some message letting them know that they need to change this password and instruct them how? Does the customer get NO notification at all about this auto-generated account and this auto-generated account is simply treated like a "guest" account. (similar to the COWOA guest account and the "no-account" options guest shoppers get)
• Could customer notification be handled via a SPECIAL link included in the email that only accounts created in this manner would receive. This page would not require them to KNOW the auto-generated password and they could skip right to the step of creating a new password. Is there a time limit on accessing this link?? If so what is the process when it "expires"?
• Does the customer get an option to change their password upon being returned to the store once completing the PayPal transaction? If so do they do this AFTER the sales transaction has been completed or BEFORE completing the transaction?

IMHO any solution needs to be carefully thought out so that ALL possible scenarios are planned for.. (which is why I am a HUGE fan of use cases and use case diagrams when planning out workflows)

As an aside.. The incomplete workflow is why I typically turn off the auto-magic account generation feature of PayPal Express.. There are clear holes in the current workflow, and my client's have always asked me to turn it off for the reasons/issues cited..

Just my 2.5 cents for whatever it's worth..

I hadn't considered turning it off. I should test that. I imagined that I'd have no way of communicating with the buyer if I needed to.

lhungil:

... Hmmm, now that I think about the situation more... I seem to remember some code in "PayPal Express Checkout" specifically "paypalwpp.php"... Something about the "customers_paypal_ec" column on the "customers" table in the database being used to indicate the created account is temporary during checkout and some code deleting the account after checkout completes...

DivaVocals:

... The incomplete workflow is why I typically turn off the auto-magic account generation feature of PayPal Express.. There are clear holes in the current workflow, and my client's have always asked me to turn it off for the reasons/issues cited. ...
Thank You! This was the setting I could not seem to remember last night while browsing on my phone. Not a perfect solution, but should (hopefully) result in a temporary account being created for Paypal Express Checkout orders (and deleted after checkout). If I am remembering correctly this setting also causes the "new account" email to not be sent.

But if you do want an account automatically created for these customers... Or to provide them an option to create a new account (with the PayPal information and order history)... Looks like there will be some planning and work to be done...

DivaVocals:

... I think that what is CLEARLY happening here is that s_mack has uncovered an incomplete workflow... it seems quite obvious that the PayPal Express integration workflow needs to be re-worked so that some logical things happen... rbarbour touched on this too...
Agreed. Feels like some scenarios are not accounted for (or possibly not working).

Again, thank you rbarbour and DivaVovals for chiming in!

s_mack:

I hadn't considered turning it off. I should test that. I imagined that I'd have no way of communicating with the buyer if I needed to. All of the required information to communicate with the client is stored on the order in the order table(i.e. email address and phone number)

1. If you've set your site to have unlimited session length and don't somehow ensure that your customers actually click to log out every time they're finished ... but provide NO check/balance to ensure they're allowed to change the password, that feels rather untrustworthy to me. I wouldn't want to shop in that environment.

2. You've mixed up the way the "temporary store account used to complete a one-time PayPal checkout" works. The account is indeed created, but a flag is set in it to mark it as temporary, and thus the customer cannot use that account, and cannot log in to it, and is never told about any password for it, because it is essentially a non-account.

So, if you have it set to make the account temporary, but then change the email wording to say they DO have an account, and give a link to reset its password, then you're shooting your customers in the foot.

But, if you want to have the account available for customers to use for future purchases or to download purchased products, you should set your PayPal settings to NOT make the account temporary. In this case the customer IS emailed their password as part of their Welcome Email.