Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Password Confirmation necessary?


AngusD

Recommended Posts

Hello,

 

burt's "Two Email Inputs" got me thinking.

 

Is the "Password Confirmation"-Input really necessary, or is it a relict of the past?

 

I believe, there are at least 5 types of people:

 

People, who

  1. use the same password on every page. Yes, they are still among us. They know their password like the back of their hand, they don't need to remember it consciously.
  2. use a different password for every page. Is repeating it once enough to remember it? In the past I had several customers who created an account. When they returned a day later, they had to reset their password, because they probably couldn't remember it anymore.
  3. store their passwords online/in the cloud. (Why? Why? Why?)
  4. store their passwords in their browser. Every(?) modern browser has a password locker.
  5. use a local password-safe program.

None of them would benefit from a password confirmation input. The password is either stored somewhere, remembered, or instantly forgotten.

 

I didn't check many pages, but some ask for a password confirmation, some don't.

 

AD

 

PS: I don't plan to remove the password confirmation input (yet).

Link to comment
Share on other sites

@@AngusD - really interesting post...

 

Personally, I am a "mix" of #1 and #2 in your list.

#1 for the non-important crap, #2 for the important sites.

 

 

 

 

Here's another suggestion;

instead of removing the confirmation field, remove both password fields.

and then;

- create a random password at successful creation of account

or

- have the customer create a password at the end of the buying process

Link to comment
Share on other sites

@@AngusD

 

Interesting Rene....I never considered the password confirmation as having anything to do with remembering it but rather ensuring that you entered it correctly, since it is often hidden from view behind dots or asterisks etc. 

 

Dan

Link to comment
Share on other sites

Hi,

 

@@burt

 

The random password at account creation is not a bad idea. This way, you can easily implement (more or less) secure passwords. You'd just have to display the password at the success page or the page they return to.

 

We've created a password for you: {RANDOM_PASSWORD}

 

Please store it somewhere safe. You can change it under "My Account" --> "Change my Password"

 

On the other hand: Some would probably think something is not right, if they can't create their own password.

 

You could keep the password input and write as placeholder: Password - keep empty for random password.

This way, people can decide for themselves, if they want to use their own password or if they want the store to create it for them.

 

I wouldn't let them create it at the end of the buying process. Some just don't return to the store after they purchased the products and received the order- and payment-emails. Or they return later and wonder why they can't login.

 

 

@@Dan Cole 

 

The way I see it: People, who use the same password on every page, type the password subconciously. In the past, I had a password I used very often (I'm using different passwords for different sites now). After a while, I could type it without thinking about it. If I tried to remember it, I drew a blank. Confirming the password was unnecessary, because as long as I didn't thought about it, I wrote it correctly. (The brain is a funny thing.)

 

People, who use different passwords for every page, use some kind of storage. They don't need the confirmation, because they copy it from their storage and paste it in the fields. Everytime correct.

 

I guess the confirmation is a mix between remembering the password and writing it correctly. If I wrote it correctly, I remembered it, but with the help of password-safes and -lockers, I don't need to write it anymore. The program does it for me (that's kind of dangerous, too). 

 

So why confirming it?

 

AD

Link to comment
Share on other sites

I assume that you're talking about having to enter a NEW password a second time, and that the password field is obscured (dots, stars, etc.). We're not talking about the routine signing on to an account. I've never seen a password asked for twice in such usage.

 

What's the problem with that? It's only once per new (or changed) password, and provides a check that you haven't mistyped the password (as could happen if you only had to enter it once). It has happened to me more than once that I am told the two passwords don't match, as I have evidently had a typo in one or the other. Of course, it's possible I could make the same typo in both entries, which a third entry might have caught, but entering it twice seems to be adequate.

Link to comment
Share on other sites

Sure thing.  I don't recall if you tried my ideas for a revamped checkout?  

On that system I added a module which asks (at the end of the checkout) for passwords.

 

 


Some just don't return to the store after they purchased the products and received the order- and payment-emails.

 

These people don't need passwords.

 

 

Or they return later and wonder why they can't login.

 

Here there are (at least) two needs;

 

1.  those coming back to check on the status of an order

Customer needs a password to login to check this.  

Shopowner -could- set up a system based on a "token" (this is something I have posted about previously), this would negate the need for a login, negating the need for a password.  Why make a customer login to do something?

 

2.  those coming back to place a new order

Customer needs a password to login to start the checkout process

Shopowner -could- use some system to check if the password (from the previous login) is blank and if so, do something.  Send a password?  

 

How about this;

 

On the initial visit set up a token (stored in DB).  Store that token and customer ID in a Cookie (probably obfuscated in some manner).  Next time they come back, get token/email from cookie, match against DB.  Auto Log In.   No need for Passwords, ever.

Link to comment
Share on other sites

@@MrPhil

 

Yes, create account, password reset, account passwort. Everywhere you have to confirm the password.

 

@@burt

 

Sorry, I think I never took a look at your revamp checkout module.

 

I don't want to abolish the whole password system, just maybe the password confirmation. ;)

 

We're selling downloads, so people need a valid account to download the products.

 

I see two problems:

 

1. Everybody who has the token, has access to the account. Ok, no difference to a password, but people may be a bit more hesitant to give a password to someone than a random token, that only works on one site. ("Hey, I bought some cool stuff! Here's the URL where you can download it: URL&token=$token")

2. People can setup their browsers to delete cookies when they shut down the browser. No cookies, no access to the account. Back to square one: They need something to get into their account --> Password

 

Besides, I already installed an autologin module. It works... well, but at the moment... it's a different topic.

 

At the moment I'm not sure if there's a way to kill the password confirmation without changing some files.

 

AD

Link to comment
Share on other sites

Besides, I already installed an autologin module. It works... well, but at the moment... it's a different topic.

 

I hate it when my threads meander into unrelated areas.  

And now I'm guilty of it too.  Sorry.

 

Back on Topic...somewhat.  

There is an inbuilt system if there is no password detected...

Possibly this system might be of use.

 

To test it, log in to your test shop.

go to account.php

Log into phpmyadmin, and null the password for your customer_id

Refresh account.php

You should now see an extra link "set password"

if not, I *think* it's a content module that you can install.

Link to comment
Share on other sites

 Is repeating it once enough to remember it?

 

That's not the point of having you enter the password a second time. Passwords are almost always entered obscured (dots or stars), so you can't see what you typed. As you're often typing a given password for the first time here (i.e., it's not an automatic reflex), it's really easy to make a mistake (typo). Then your account doesn't work and you have to go through the annoyance of a password reset request. Unless you want to do something about typing in the password in plain text, so you can see it (as well as can anyone looking over your shoulder!), and then immediately erasing it, two entries is the best option. Entering a new password for a given site is not a common task (unless you suffer from amnesia), so why get worked up over entering it a second time?

 

It occurs to me that this practice probably started eons ago, when everyone used typewriter-like devices that printed on paper. They would multiply overprint the place for you to enter the password (sometimes to the point of tearing the paper!) and you would type in your new password. No one looking at the discarded paper was likely to determine what you typed in. Nowadays, it might be relatively safe to display the password on the screen (at low contrast) and then blank it out when you proceed to the next step. Just a thought.

Link to comment
Share on other sites

  • 2 weeks later...

Been thinking on this some more...

Password: [                                        ]
[ ] show password

If "show password" is ticked, the password input changes from a password field to a normal input field

If it is then unticked, it reverts back to a password field.

 

This solves two "problems";

 

1.  user can tick the box if he is in a private space (no one looking over his shoulder)

2.  user can leave the box unticked if he is in a public space

 

Thoughts ?

Link to comment
Share on other sites

@@burt Gary I don't see any problem with that...are you thinking of taking it a step further by not requiring the password to be entered twice, if the field is made visible?

 

Dan

Link to comment
Share on other sites

@@Dan Cole pretty much yes.  

 

It takes the thought of @@AngusD (remove confirmation input) and the thoughts of @@MrPhil (potential security) and solves it all quite straightforwardly...

 

Proof of Concept:

 

 

Don't get hung up on the fact this on the login box.  

The login box has a password without confirmation so is good for simplistic testing...

Link to comment
Share on other sites

With a bit of lateral thinking, I have managed to get this working on create_account as well...seems fairly solid in initial testing.

Now comes the hard part...getting it to work without any core code changes  :see_no_evil:

Link to comment
Share on other sites

I'd personally stick with password confirmation (plus "show password"). I see customer's email addresses wrongly typed too often (things like gnail.com or yahhoo.com) that causes new customer's email bounced and people forgetting about the shop. If people can type an email address wrong sure they will type passwords even worse.

 

I am also the king of "sticky keys" and "type quickly and fail" so I know what I'm talking about  :x  I'd personally be lost without the saved password list from firefox o:)

 

BTW I recently discovered those saved lists takes first two fields on a form instead reading their labels, so I placed "password" right after the email field on registration form to help those silly guys like me :D

Link to comment
Share on other sites

I'd personally stick with password confirmation

 

That's the beauty of doig things without touching core...shopowner can decide to stay as is, or to install a module to change things, and never have to touch code... all is good.

Link to comment
Share on other sites

@@burt

 

No core changes, my attempt:

<script>
$(document).ready(function () {
	
	// To do: Add a link/button/whatever to enable the confirmation input again

	// Add the show password checkbox
	$('#inputPassword').closest('.form-group').after('<div class="col-xs-offset-3"><p><input type="checkbox" name="show_password" value="1" id="show_password" /> Show Password</p></div>');

	// Hide the inputConfirmation input field
	$('#inputConfirmation').closest('.form-group').hide();

	// The create_account-script expects a confirmation-input, we just copy the value of the password-input to the confirmation-input. The reason why we hid the confirmation input
	$('#inputPassword').on('keyup',function () {
		$('#inputConfirmation').val($('#inputPassword').val());
	});

	// If the show-password box is checked, switch from type password to type text and back, if unchecked again
	$('#show_password').change(function() {
		if($('#show_password').is( ":checked" )){
			document.getElementById('inputPassword').setAttribute('type', 'text');
		}else{
			document.getElementById('inputPassword').setAttribute('type', 'password');
		}
	});
});
</script>

It's a work in progress.

 

AD

Link to comment
Share on other sites

I've remembered a web that was one step beyond: It has a single form for login, with a checkbox to show hidden password an hide password confirmation. I liked it very much, but today visited it and they had sadly changed to a classic login/create account selection setup.

 

You only entered your email and password; if you previously created an account you would be logged in; if no account existed in the shop it then showed the regular create account page, but you had already entered email and password for the new account.

Link to comment
Share on other sites

This sounds interessting. It could persuade people to create an account. Clearly a project for the future.

 

Updated script: I've replaced the "show-password"-checkbox with a button and added a button for confirming the password.

<script>
$(document).ready(function () {

	// Add the show password checkbox
	$('#inputPassword').closest('.form-group').after('<div class="form-group"><div class="col-sm-offset-3 spass" id="spass"><div class="col-sm-3 show_password" id="spass"><span class="alert-link btn btn-danger btn-sm" role="button" id="show_password"><i class="fa fa-warning fa-lg"></i> Show Password</span></div></div></div>');

	// Add a button to enable the confirmation input
	$('#show_password').closest('.spass').after('<div class="col-sm-3"><span class="alert-link btn btn-info btn-sm" role="button" id="confirm">Confirm Password (optional)</span></div>');

	// If you hide a password-field, the browser fills other input fields with an email-address and password
	// As a workaround, we change the password type to text type before we hide the inputConfirmation field
	// This somehow fixes the issue. Stupid, but it works.
	document.getElementById('inputPassword').setAttribute('type', 'text');
	document.getElementById('inputConfirmation').setAttribute('type', 'text');

	// Hide the inputConfirmation input field
	$('#inputConfirmation').closest('.form-group').hide();

	// Set the inputPassword field back to type password when we focus the field
	// --> Don't do this, if the inputPassword field has been changed by the show-password-button
	$('#inputPassword').on('focus', function () {
		if($('#show_password').hasClass('btn-danger')){
			document.getElementById('inputPassword').setAttribute('type', 'password');
		}
	});

	// The create_account-script expects a confirmation-input, we just copy the value of the password-input to the confirmation-input
	// --> But only, if the inputConfirmation is hidden
	$('#inputPassword').on('input propertychange mouseup change',function () {
		if($('#inputConfirmation').is(':hidden')){
			$('#inputConfirmation').val($('#inputPassword').val());
		}
	});

	// Click on the "Confirm Password"-button
	// --> Remove any success- or error-classes
	// --> Set the inputPassword back to password
	// --> Set the inputConfirmation back to password
	// --> Empty the inputConfirmation field and make it visible again
	// --> Hide the "Confirm Password"-button
	// --> Hide the "Show Password" Checkbox
 	$('#confirm').click(function() {
		$('#inputPassword, #inputConfirmation').closest('.form-group').removeClass('has-success has-error');
		document.getElementById('inputPassword').setAttribute('type', 'password');
		document.getElementById('inputConfirmation').setAttribute('type', 'password');
		$('#inputConfirmation').val('');
		$('#inputConfirmation').closest('.form-group').show();
 		$('#confirm').hide();
 		$('#spass').hide();
 	});

	// If the show-password-button is clicked, switch from type password to type text and back, if clicked again
	// --> Change the class of the button from danger to info and back again
	// --> Replace 'Show' with 'Hide' and back again
	$('#show_password').click(function() {
		if($('#inputPassword').attr('type') == 'password'){
			document.getElementById('inputPassword').setAttribute('type', 'text');
			$('#show_password').removeClass('btn-danger').addClass('btn-info');
			$('#show_password').html($('#show_password').html().replace("Show", "Hide"));
		}else{
			document.getElementById('inputPassword').setAttribute('type', 'password');
			$('#show_password').removeClass('btn-info').addClass('btn-danger');
			$('#show_password').html($('#show_password').html().replace("Hide", "Show"));
		}
	});

	$('#inputFirstName').focus();
});
</script>

AD

Link to comment
Share on other sites

@@AngusD

 

Hi

 

Tried this code on wee test site and found that when entering password instead of showing the "dots" it actually shows the password as typed in, and the Show Password button doesn't appear to work. Maybe something Ive done or perhaps I have the code in the wrong place. I placed it at the end og the login.php file.

 

Cheers

 

Grandpa

Link to comment
Share on other sites

@@grandpaj

 

Thanks for testing.

 

I've tested it in Opera 35 and Chromium 48 and it works fine. Then I tested it in FireFox/Iceweasle and... it fails, but not completely. (No (modern) IE on Linux)

 

In an unmodified OsC-Bootstrap, it works as it should (in FireFox/Iceweasle). In my modified store, it doesn't. If I replace the modified version of my create_account-script with the default one, it works.

 

I need to investigate further.

 

EDIT: I have a script installed ("Twitter Typeahead Autocomplete Search") that  interfers with my script, but only in FireFox/Iceweasle. 

 

AD 

Link to comment
Share on other sites

@@AngusD

 

Hi AD

 

Hope I haven't put you wrong.

The code that doesn't seem to work is the second one the one with the buttons,

For me the first one works a treat.

 

Cheers

 

Grandpa

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...