Changing Password Length

[Guest]

If you set your minimum password length at 4 and someone sets up an account with a password that is 4 characters long, and if you then set a new minimum at, say, 6, the person with a 4-character password cannot change his password to one that is 6 characters long because osC will give him an error when he puts his current password in while trying to change passwords. What code would you modify and how to get the minimum to not apply to old current passwords on the change password page?

[masat]

I have been watching this for a while now and even started to answer once but it is going to be a considerable amount of work and considerable thought.

 

The only way I can see to do this is to inject a forced pwd change immediately after logging in. I believe there is a method in release 2.2rc2a in the admin loggin system which would be a basis for a quick approach to resolution of this issue.

 

I can foresee an addition to the customers table to track which clients have updated their password. This may be a date field so you could calculate a date which the new settings will take effect, say six months in the future.

 

Since the var ENTRY_PASSWORD_MIN_LENGTH is a db configuration value you would have to update the value of this field to your new value on the specified date accomplishing this task either manually or via a scripted cron task.

 

For customer convenience you will want a notice informing the customer you will be updating your security measures.

 

Undoubtedly you will have customers that will not change their pwd during the set period so you will want a mechanism in place to id their email and old password and send them a new random pwd.

 

A email to all customers may be in order if not a must do. You could also make it possible in this email to provide an opportunity to get a new password. You could turn this into a promotion that could potentially earn you big $$.

 

I guess the course of action I would take would be determined by my traffic, number of customers, time available, costs involved (including a projected loss of customers), and whatever else that may find its way into concerns.

 

But most of all I would kick myself and ask, "Tim, you idiot, why didn't you make the min pwd length 6 to begin with???"

 

I am sure many folks are in the same position. This would be a good contribution.

[Guest]

I have been watching this for a while now and even started to answer once but it is going to be a considerable amount of work and considerable thought.

 

The only way I can see to do this is to inject a forced pwd change immediately after logging in. I believe there is a method in release 2.2rc2a in the admin loggin system which would be a basis for a quick approach to resolution of this issue.

 

I can foresee an addition to the customers table to track which clients have updated their password. This may be a date field so you could calculate a date which the new settings will take effect, say six months in the future.

 

Since the var ENTRY_PASSWORD_MIN_LENGTH is a db configuration value you would have to update the value of this field to your new value on the specified date accomplishing this task either manually or via a scripted cron task.

 

For customer convenience you will want a notice informing the customer you will be updating your security measures.

 

Undoubtedly you will have customers that will not change their pwd during the set period so you will want a mechanism in place to id their email and old password and send them a new random pwd.

 

A email to all customers may be in order if not a must do. You could also make it possible in this email to provide an opportunity to get a new password. You could turn this into a promotion that could potentially earn you big $$.

 

I guess the course of action I would take would be determined by my traffic, number of customers, time available, costs involved (including a projected loss of customers), and whatever else that may find its way into concerns.

 

But most of all I would kick myself and ask, "Tim, you idiot, why didn't you make the min pwd length 6 to begin with???"

 

I am sure many folks are in the same position. This would be a good contribution.

Actually, that's not the problem I'm trying to deal with. If I change the minimum password length, customers with shorter passwords will not be able to change their passwords at all. It's not that I want to necessarily force them to change them, it's that even if they wanted to they couldn't. I think it's probably a relatively easy change to keep the "current password" field from being checked for the minimum length when an existing customer tries to change his password, I'm just not sure what the change would be.

[masat]

So a client has a pwd of length 4 and you reset min pwd length to 6 the client will not be able to login because of client side error checking and server side error checking that are both based on ENTRY_PASSWORD_MIN_LENGTH. Therefore if a client cannot login they hence cannot change their password.

 

Take a look at catalog/account_password.php.

 

if (strlen($password_current) < ENTRY_PASSWORD_MIN_LENGTH) {
     $error = true;

 

you can comment this or change ENTRY_PASSWORD_MIN_LENGTH to '4' inline whereby making the script less dynamic. I suggest to always stay away from hard coding any var

 

 

You will also need to adjust the javascript form_check accordingly and adjust the appropriate spots in the log in system.

 

Not checking these field lengths will most certainly allow security issues. I think this issue is much larger than you are considering.

 

If you change the min pwd length requirement the customers you have that do not meet the new requirement will not be able to log in.

 

Since passwords are md5 encrypted you can not determine how many characters a pwd is comprised of therefore requiring new pwd for everyone even those that meet the new requirement.

 

Now, you could intercept the password during processing, count the characters and force a password update but somewhere you are going to have to force the update in order to get all client credentials within the new requirement.

[Guest]

So a client has a pwd of length 4 and you reset min pwd length to 6 the client will not be able to login because of client side error checking and server side error checking that are both based on ENTRY_PASSWORD_MIN_LENGTH. Therefore if a client cannot login they hence cannot change their password.

 

Take a look at catalog/account_password.php.

 

if (strlen($password_current) < ENTRY_PASSWORD_MIN_LENGTH) {
     $error = true;

 

you can comment this or change ENTRY_PASSWORD_MIN_LENGTH to '4' inline whereby making the script less dynamic. I suggest to always stay away from hard coding any var

 

 

You will also need to adjust the javascript form_check accordingly and adjust the appropriate spots in the log in system.

 

Not checking these field lengths will most certainly allow security issues. I think this issue is much larger than you are considering.

 

If you change the min pwd length requirement the customers you have that do not meet the new requirement will not be able to log in.

 

Since passwords are md5 encrypted you can not determine how many characters a pwd is comprised of therefore requiring new pwd for everyone even those that meet the new requirement.

 

Now, you could intercept the password during processing, count the characters and force a password update but somewhere you are going to have to force the update in order to get all client credentials within the new requirement.

Changing the minimum password length does not seem to keep them from logging in with a shorter password that was set up before the change, but it keeps them from changing the password after logging in. I tried commenting out what appeared to be the relevant code in account_password.php (see below) but it didn't work when I tested it.

 

$password_current = tep_db_prepare_input($HTTP_POST_VARS['password_current']);

$password_new = tep_db_prepare_input($HTTP_POST_VARS['password_new']);

$password_confirmation = tep_db_prepare_input($HTTP_POST_VARS['password_confirmation']);

$error = false;

if (strlen($password_current) < ENTRY_PASSWORD_MIN_LENGTH) {

$error = true;

$messageStack->add('account_password', ENTRY_PASSWORD_CURRENT_ERROR);

} elseif (strlen($password_new) < ENTRY_PASSWORD_MIN_LENGTH) {

$error = true;

$messageStack->add('account_password', ENTRY_PASSWORD_NEW_ERROR);

} elseif ($password_new != $password_confirmation) {

$error = true;

$messageStack->add('account_password', ENTRY_PASSWORD_NEW_ERROR_NOT_MATCHING);

}

if ($error == false) {

[masat]

OK it didn't work.

What did it do?

What did the java validation say?

What errors are you getting?

How do you know it didn't work?

 

btw I stand corrected on the login. The code checks that I was looking at are of my own doing and are not standard osc code. Sorry for the misinfo.

 

Did you by chance change the size of the password field in the db? Standard code calls for 40 characters.

Do you have contribs that may be affecting this function?

Have you tried a original account_password.php page?

Have you verified the db setting? What is it set to?

[Guest]

OK it didn't work.

What did it do?

What did the java validation say?

What errors are you getting?

How do you know it didn't work?

 

btw I stand corrected on the login. The code checks that I was looking at are of my own doing and are not standard osc code. Sorry for the misinfo.

 

Did you by chance change the size of the password field in the db? Standard code calls for 40 characters.

Do you have contribs that may be affecting this function?

Have you tried a original account_password.php page?

Have you verified the db setting? What is it set to?

If you increase the minimum password length, a customer with a shorter password will get the error message saying that the password must be at least x characters (x being the new, higher minimum) when trying to change his password. I take it that is because the minimum is applied to the old password when trying to set a new password. What I can't figure out is why commenting that out doesn't work (I still get the error message when trying to change the password to a new one that meets the new minimum). The changes are being made in Admin but are confirmed in both the text I have on the site (which states the minimum by calling it from the database) and the error message that is generated, which states correctly the new minimum.

[masat]

Since you commented the server side error check the error message must be generated by the client side error check.

 

require('includes/form_check.js.php');

 

Disable the js and comment the server check and it should work.

 

If it doesn't... I don't know.

[Guest]

Since you commented the server side error check the error message must be generated by the client side error check.

 

require('includes/form_check.js.php');

 

Disable the js and comment the server check and it should work.

 

If it doesn't... I don't know.

Commented out the code that checked current password length in both account_password.php and form_check.js and it works. Thanks for the help in finding the .js check (I had missed that one).

[tigergirl]

I read this post with interest and sure enough it is a bug - I tested it myself. I would like to increase password length and feel dumb that I didn't start with a higher number! Sorry but I didn't understand the solution and wondered if baddog could post the solution he found please?

 

Thanks