Customer unable to log in

[Dirty Butter]

"there are also a few legit users denied access"

 

Do these records have a salt? A 32 or 128 character password?

 

 

Salvador - while we wait for Bsmither's return - go check the CubeCart_customer table for those few legit users who were denied access to see if they have a salt and what length their password is. You can Search for the login email address by clicking SEARCH and using LIKE&...& as the choice instead of LIKE.

[bsmither]

If 'LIKE&...&' doesn't work, try 'LIKE %...%'.

[Dirty Butter]

LOL! Well, that's what I meant - lot of good I am.

[bsmither]

Setting aside the statements that the admin reset the password in CC5's Edit Customer screen and still could not log-in as that customer, I am finding, so far, only two possibilities:

* the store got moved between CC3 and CC5 from a 32-bit server to a 64-bit server (very, very low probability)

* the customer used a password that required a utf-8 translation (interesting)

 

There is nothing in the documentation that would suggest the MD5 output would be different for the same input, between 32-bit and 64-bit machines, operating system, and PHP. Neither is there any interesting discussions about the PHP function used to create a salt value.

 

Maybe the customer used a password with non-straight-ascii characters such as: pässwörd, which would be a different input between a CubeCart installation running ISO-8859-1 (CC3) vs an installation running UTF-8 (CC5).

[salvador21]

That's what mine looks like, too. I've never been in that table before. Can you tell if a legitimate looking one tried more than three times to login, rather than using the forgot password link? If you do, they blocked themselves as CC should have, although I'm not sure if CC provides a warning about that to the customer or not.

Yes, I can see one that looks like they tried unsuccessfully 4 times

[salvador21]

 

In phpMyAdmin, you can filter for only the records where a column has a certain value. So, among all the 'spam' and robots in the access table, there will be the '[email protected]' username (email) we are looking for.

 

"there are also a few legit users denied access"

 

Do these records have a salt? A 32 or 128 character password?

 

Not quite sure what you mean by the [email protected]

 

I checked a couple of member with  unsuccessful attempts:

 

4 unsuccessful = 8 character salt and 128 character password

 

2 unsuccessful = 8 character salt and 128 character password

 

2 unsuccessful followed by successful = 8 character salt and 128 character password

 

At this stage, can anyone tell me if I should worry about this? ie are there likely to be a lot of customers unable to login for reasons other than they got the wrong password?

 

Thanks

[bsmither]

In America, John Doe and John Smith are typical and obvious replacement names for use in examples of what to do or try.

 

John Smith

123 Main St

Anytown, USA

 

We appreciate your examining of the logs. Unfortunately, I think you would not find any evidence to suggest that a failed log-in happened with a 32 character password and no salt. What you report above suggests that if any one of the above started from a CC3 style password, then that one got converted to CC5 style passwords without first making a match.

 

And that is strange.

[salvador21]

In America, John Doe and John Smith are typical and obvious replacement names for use in examples of what to do or try.

 

John Smith

 

Ah, I knew about John Doe of course. I was confused because the customer with the problem is John E. Smith

 

So are you saying this is just a strange hopefully one-off occurrence, and nothing I can do to stop it happening, or it is unlikely to happen to loads of customers.

[Dirty Butter]

Sadly, it sounds like this is a wait and see situation. As I see it, you can hope it won't happen again, or you could add some wording to the login page to indicate a contact link if they have trouble, or you could pre-emptively email all your clients with an announcement about your new store look and use that as an opportunity to offer help if they run into any issues.

[salvador21]

Sadly, it sounds like this is a wait and see situation. As I see it, you can hope it won't happen again, or you could add some wording to the login page to indicate a contact link if they have trouble, or you could pre-emptively email all your clients with an announcement about your new store look and use that as an opportunity to offer help if they run into any issues.

 

Well this is rather annoying, maybe I'm making too much of it, but currently this makes me feel like looking for another shopping cart solution that may be more reliable. 

Even with notices or mass mailouts (which i don't like), I think some customers frustrated by not being able to login may well just go elsewhere to buy something.

[Dirty Butter]

I would hope that this was a fluke, but can certainly understand your concern. It would be a shame to lose you in the community over something that may not happen again.

[bsmither]

Please create a new test account in your store. Then, in phpMyAdmin, change these values in the CubeCart_customer table for that new customer record:

* delete the 'salt' value

* set the 'new_password' value to 0

* replace the 'password value' with 084e0343a0486ff05530df6c705c8bb4

 

This is a hash that represents the word guest. This will be what CC3 would have had.

 

Now try to log in using guest as the password.

[salvador21]

Please create a new test account in your store. Then, in phpMyAdmin, change these values in the CubeCart_customer table for that new customer record:

* delete the 'salt' value

* set the 'new_password' value to 0

* replace the 'password value' with 084e0343a0486ff05530df6c705c8bb4

 

This is a hash that represents the word guest. This will be what CC3 would have had.

 

Now try to log in using guest as the password.

 

Done! And logged in successfully as guest

[bsmither]

This test is (to me) proof positive that your store's front-side code is functioning correctly.

 

Reset that record back to those values mentioned above.

 

Now, go to admin, and reset that customer's password. Now try to log in. The last time you did this, you got a failed attempt.

[salvador21]

Now, go to admin, and reset that customer's password. Now try to log in. The last time you did this, you got a failed attempt.

 

This works fine, I can log in using the password reset by admin. 

 

Does the 32 character password mean they joined when it was CC3?

[bsmither]

Yes, or if the 32-pass has a salt, CC4.

 

Based on these experiments on your store, I have to say the sole problem was that the customer was not using the correct email address as the username and got blocked.

 

Except for that nagging incident where you changed the password and still could not log in. My interpretation of the code suggests that using a different browser (dis-similar 'user-agent' string) would cause CubeCart to not find the record in the blocker table.