Where to put Password Requirements?

[DoubleDee]

Attached is a screen-shot of my “Create a Member Account” form. (Error messages have been triggered.)

I need to put a message somewhere on the Form that tells people registering what the requirements are for their Password.

These include…

• At least 1 Upper-Case Letter
• At least 1 Lower-Case Letter
• At least 1 Number
• At least 1 Special Character
• Between 8-15 Characters

I was thinking of floating a box to the right of the Password field and where the error message would be, and shading it with a buff background.

Thoughts?

Debbie

[ralphm]

It’s a tricky area, this one, for which there doesn’t seem to be a definitive answer yet. If you look at this from an accessibility point of view, an error message that comes after the input box (in the HTML) won’t be seen by non-sighted users, so they may not know what’s going on.

One suggestion I’ve seen is to have a message early on the page that there was an error, then perhaps have a list of errors, each of which links to the appropriate input field. But that’s not a perfect solution.

It’s not just an issue for non-sighted users. I’m often totally confused when a page refreshes and I can’t tell if the form was submitted or not. Eventually I’ll find somewhere on the page a message that there was a problem, but it’s kind of random where it appears. Really, we need some better method to alert users to a problem. I guess ideally, the page would be returned without all the usual cruft (headers, ads, menus etc.) and just a big H1 heading stating that there has been an error! But in reality, that’s hard to work into a design, and clients hate it.

The field is still open for a really good solution to this!

[dresden_phoenix]

It sounds like a good idea. I would actually concatenate that with the “Enter your Password”. Since you have the space to the right you can fit all the info there.

you could section your markup like this:
<span class=“passw”>
<label for="password’>Password: </label>
<input type=‘text’ name=‘password’ id=‘password’>
<span>Please CREATE your password. Your password must be at least… other requirements…</span>
</span>

You could forgo using RED UNTIL an error has been committed then just color the corresponding instruction red, wrapping an EM or STRONG around it after validation ( fr the sake of the visually impaired).

[DoubleDee]

@ralph_m

It’s a tricky area, this one, for which there doesn’t seem to be a definitive answer yet. If you look at this from an accessibility point of view, an error message that comes after the input box (in the HTML) won’t be seen by non-sighted users, so they may not know what’s going on.

One suggestion I’ve seen is to have a message early on the page that there was an error, then perhaps have a list of errors, each of which links to the appropriate input field. But that’s not a perfect solution.

It’s not just an issue for non-sighted users. I’m often totally confused when a page refreshes and I can’t tell if the form was submitted or not. Eventually I’ll find somewhere on the page a message that there was a problem, but it’s kind of random where it appears. Really, we need some better method to alert users to a problem. I guess ideally, the page would be returned without all the usual cruft (headers, ads, menus etc.) and just a big H1 heading stating that there has been an error! But in reality, that’s hard to work into a design, and clients hate it.

The field is still open for a really good solution to this!

Ralph, a few things…

1.) If you tell me my Form is 100% clear what is going on - at least for sighted users - I would be besides myself?! (I don’t know how much clearer of a connection can be made between my Fields and the corresponding Error Messages next to each Field?!)

2.) Your comments above would make for a nice separate thread, but you never really answered my Original Post…

Debbie

[DoubleDee]

@dresden_phoenix

It sounds like a good idea. I would actually concatenate that with the “Enter your Password”. Since you have the space to the right you can fit all the info there.

you could section your markup like this:
<span class=“passw”>
<label for="password’>Password: </label>
<input type=‘text’ name=‘password’ id=‘password’>
<span>Please CREATE your password. Your password must be at least… other requirements…</span>
</span>

Except that would get in the way of my Error Messages…

You could forgo using RED UNTIL an error has been committed then just color the corresponding instruction red, wrapping an EM or STRONG around it after validation ( fr the sake of the visually impaired).

Why is no one following me today?!

Um, hello…

The screen-shot I posted above shows what the Form would look like IF THERE WERE ERRORS!! (The Form in its “empty” or “properly filled out” states would not have right text hanging off to the right?!)

Debbie

[ralphm]

It’s not up to you to dictate how people respond to a question.

If you are going to be so restrictive in what kind of password is allowed, it’s best to tell people up front, so I’d say place that information under the Password label, preferably as a span within the label itself, set to display: block; to make it sit on its own line. If it’s part of the label itself, there’s more chance that everyone will “see” it.

[DoubleDee]

@ralph_m

It’s not up to you to dictate how people respond to a question.

If you are going to be so restrictive in what kind of password is allowed, it’s best to tell people up front, so I’d say place that information under the Password label, preferably as a span within the label itself, set to display: block; to make it sit on its own line. If it’s part of the label itself, there’s more chance that everyone will “see” it.

It’s not about being “restrictive”, it is about SECURITY…

I think it would look awkward to have all of the requirements that I listed above under the Password label.

I think this thread is one for DeathShadow, since he is all into standards and accessibility…

Debbie

[Stevie_D]

@DoubleDee

It’s not about being “restrictive”, it is about SECURITY…

No, it’s about being restrictive.

How does enforcing those arbitrary rules help security? What it does is (a) mean that people are less likely to be able to use their password of choice, which means that they are more likely to write it down somewhere or choose something really obvious, and (b) gives any hackerbots a good headstart on what format passwords can take.

I regularly get thoroughly P!5sed off (demonstrating how to meet 3 of the 4 requirements nicely!) by websites that have these arcane and self-defeating password requirements, which usually only serves to demonstrate that the creator knows a lot less about security than he thinks. At work we have to have at least three of a capital letter, a lower case letter, a number and a non-alphanumeric character – minimum 7 characters – change it every month (or is it two?) and you can’t reuse any of your last twelve passwords. So inevitably someone with a rabbit called Bubbles goes for Bubbles1 then Bubbles2 then Bubbles3 … which is so much less secure than if they were allowed to pick one password of whatever format they wanted and stick with it.

Off Topic:

A blond/e (we’re not sexist here, just hairist) called Sam is setting up his/her new computer account at work. The techie explains the requirements to Sam and goes back to his desk. A few minutes later, he gets a phonecall from Sam, who can’t get his/her password to work. The techie is surprised, because he explained the fairly simple requirements very carefully. He clears Sam’s details and asks him/her to type it in again while he is on the phone. He notices that there’s a lot of typing before Sam comes back on and says “No, it’s still not working”. “Let me see if I can get it to work,” says the techie, “What password were you trying to use?” Sam replies, “doc grumpy happy sleepy bashful sneezy dopey london. You told me it had to be seven characters and a capital, and those were the only ones I could think of that I would remember.”

[system]

@DD – you rang?

I would axe the ‘please enter’ text as redundant to your labels. If they can’t figure it out from the label, they probably aren’t smart enough to be using the page in the first place.

My gut reaction is “You’re drawing a pretty picture before you have semantic markup of your content” – the road to failure. Markup FIRST before you get your heart set on styling that might not even be possible/practical.

which code-wise would end up something like this:

<fieldset>

	<legend>Create A Member Account</legend>
	
	<div class="key">
		<b>*</b> = Required Field
	</div>
	
	<label for="createAccount_firstName">
		<b>*</b> First Name:
	</label>
	<input
		type="text"
		id="createAccount_firstName"
		name="firstName"
	/><br />
	
	<label for="createAccount_eMail">
		<b>*</b> E-Mail:
	</label>
	<input
		type="text"
		id="createAccount_eMail"
		name="eMail"
	/><br />
	
	<label for="createAccount_password">
		<b>*</b> Password:
	</label>
	<div class="restrictions">
		Must Contain:
		<ul>
			<li>At least 1 Upper-Case Letter</li>
			<li>At least 1 Lower-Case Letter</li>
			<li>At least 1 Number</li>
			<li>At least 1 Special Character</li>
			<li>Between 8-15 Characters</li>
		</ul>
	</div>
	<input
		type="password"
		id="createAccount_password"
		name="password"
	/><br />
	
	<label for="createAccount_confirmPassword">
		<b>*</b> Confirm Password:
	</label>
	<input
		type="password"
		id="createAccount_confirmPassword"
		name="confirmPassword"
	/><br />
	
	<input
		type="submit"
		class="submit"
		value="Create Account"
	/>
		
</fieldset>

Since you have a LIST of requirements, well… give it a list. Float the labels left, clear:left on inputs, display:block on inputs, float:right on .restrictions – should do the job. IF those ‘please’ texts are error messages, I’d move them up next to the labels instead of putting them next to the fields… and drop the ‘friendly’ speak as unprofessional and instead say “ERROR, REQUIRED FIELD!”

I’m with the folks saying ‘bad’ on the requirements – in fact one of your requirements makes it EASIER to crack, the short length… see the xkcd comic on the subject.. Passwords like that are a social engineering disaster as users will end up writing it down on a sticky pad on the monitor or under the keyboard because they can’t remember it. (or worse shove it into a password ‘manager’ tool)

But I’m the nut who allows 127 character passwords if the user wants to have it. Security is still PEBKAC, but for the people who aren’t a problem, give them the tools to not be a problem… forcing case sensitive nonsense, numbers, special characters and then putting a absurdly short length on it? Doesn’t actually make it more secure.

Besides, 15 characters annoys me since my standard passwords are 18 to 32 characters in length.

[DoubleDee]

@Stevie_D

No, it’s about being restrictive.

How does enforcing those arbitrary rules help security?

You’re kidding, right???

Would you prefer I let everyone use passwords that are just 6 characters long and only letters?

Would that be less restrictive?!

What it does is (a) mean that people are less likely to be able to use their password of choice, which means that they are more likely to write it down somewhere or choose something really obvious, and (b) gives any hackerbots a good headstart on what format passwords can take.

I regularly get thoroughly P!5sed off (demonstrating how to meet 3 of the 4 requirements nicely!) by websites that have these arcane and self-defeating password requirements, which usually only serves to demonstrate that the creator knows a lot less about security than he thinks.

And what is it that you think you know about Security that I am missing here?

At work we have to have at least three of a capital letter, a lower case letter, a number and a non-alphanumeric character – minimum 7 characters – change it every month (or is it two?) and you can’t reuse any of your last twelve passwords. So inevitably someone with a rabbit called Bubbles goes for Bubbles1 then Bubbles2 then Bubbles3 … which is so much less secure than if they were allowed to pick one password of whatever format they wanted and stick with it.

Off Topic:

A blond/e (we’re not sexist here, just hairist) called Sam is setting up his/her new computer account at work. The techie explains the requirements to Sam and goes back to his desk. A few minutes later, he gets a phonecall from Sam, who can’t get his/her password to work. The techie is surprised, because he explained the fairly simple requirements very carefully. He clears Sam’s details and asks him/her to type it in again while he is on the phone. He notices that there’s a lot of typing before Sam comes back on and says “No, it’s still not working”. “Let me see if I can get it to work,” says the techie, “What password were you trying to use?” Sam replies, “doc grumpy happy sleepy bashful sneezy dopey london. You told me it had to be seven characters and a capital, and those were the only ones I could think of that I would remember.”

Debbie

[DoubleDee]

@deathshadow60

@DD – you rang?

Yep. It’s me again!

I would axe the ‘please enter’ text as redundant to your labels. If they can’t figure it out from the label, they probably aren’t smart enough to be using the page in the first place.

As stated above, they are error messages.

My gut reaction is “You’re drawing a pretty picture before you have semantic markup of your content” – the road to failure. Markup FIRST before you get your heart set on styling that might not even be possible/practical.

A good reminder from Dr. Semantics!! (See why I rang?!)

Here is a snippet of my code. (Please spare comments on my use of a List for the Fields if you are a UL hater!)

<!-- CREATE ACCOUNT FORM -->
<form id="createAccount" action="" method="post">
	<fieldset>
		<legend>Create a Member Account</legend>
		<ul>
			<!-- Required Note -->
			<li id="requiredNote">
				<b>*</b> = Required Field
			</li>

			<!-- Email -->
			<li>
				<label for="email"><b>*</b>E-mail:</label>
				<input id="email" name="email" type="text" maxlength="60"
					value="<?php if(isset($email)){echo htmlspecialchars($email, ENT_QUOTES);} ?>" /><!-- Sticky Field -->
				<?php
					if (!empty($errors['email'])){
						echo '<span class="error">' . $errors['email'] . '</span>';
					}
				?>
			</li>

			<!-- Password1 -->
			<li>
				<label for="pass1"><b>*</b>Password:</label>
				<div id="restrictions">
					Must Contain:
					<ul>
						<li>At least 1 Upper-Case Letter</li>
						<li>At least 1 Lower-Case Letter</li>
						<li>At least 1 Number</li>
						<li>At least 1 Special Character</li>
						<li>Between 8-15 Characters</li>
					</ul>
				</div>
				<input id="pass1" name="pass1" type="password" maxlength="40" />
				<?php
					if (!empty($errors['pass'])){
						echo '<span class="error">' . $errors['pass'] . '</span>';
					}
				?>
			</li>

			<!-- Password2 -->
			<li>
				<label for="pass2"><b>*</b>Confirm Password:</label>
				<input id="pass2" name="pass2" type="password" maxlength="40" />
			</li>

Here is a snippet of my styles…

#restrictions{
	float: right;
	padding: 0.5em 0.5em 0.5em 2em;
	font-size: 0.8em;
	line-height: 1.1em;
	background-color: #FFC;
}

#restrictions ul{
	padding: 0 0 0 1em;
}

#restrictions ul li{
	padding: 0;
}

.error{
	display: inline;
	font-size: 0.8em;
	font-weight: 500;
	color: #F00;
}

#pass2{
	clear: both;
}

And here is a screen-shot of my new Form…

No Errors

With Errors

I like how this looks, but I don’t like the huge white-space between the Password and Confirm Password fields. How can I make the Password Fields “hug” each other?

IF those ‘please’ texts are error messages, I’d move them up next to the labels instead of putting them next to the fields…

Why do you say that?

Is what I have that bad?

And if I followed your suggestion, could I place the Error Messages BENEATH the fields so that I don’t disrupt the Label/Field pairing?

(Personally I think Red Text Error-Messages off to the right side look best…)

and drop the ‘friendly’ speak as unprofessional and instead say “ERROR, REQUIRED FIELD!”

I’ll try to toughen up a little bit…

I’m with the folks saying ‘bad’ on the requirements – in fact one of your requirements makes it EASIER to crack, the short length… see the xkcd comic on the subject.. Passwords like that are a social engineering disaster as users will end up writing it down on a sticky pad on the monitor or under the keyboard because they can’t remember it. (or worse shove it into a password ‘manager’ tool)

What I am trying to do is better than letting people choose simple, 8-character passwords like “password”, “LetMeIn”, and so on.

I would be open to making the Minimum Password Length = 20 characters and force people to use “Pass-Phrases” instead…

But I’m the nut who allows 127 character passwords if the user wants to have it.

That isn’t a bad idea.

Security is still PEBKAC, but for the people who aren’t a problem, give them the tools to not be a problem… forcing case sensitive nonsense, numbers, special characters and then putting a absurdly short length on it? Doesn’t actually make it more secure.

Besides, 15 characters annoys me since my standard passwords are 18 to 32 characters in length.

As stated, I am not opposed to longer Passwords/Pass-Phrases. But I don’t think forcing people to go beyond all Lower-Case Dictionary Words is a bad idea at all…

Debbie

[system]

@DoubleDee

Here is a snippet of my code. (Please spare comments on my use of a List for the Fields if you are a UL hater!)

Not a UL hater, but what makes that a LIST? Waste of tags with semantic meanings around tags that ALREADY HAVE meanings. Waste of code.

I like how this looks, but I don’t like the huge white-space between the Password and Confirm Password fields. How can I make the Password Fields “hug” each other?
Since password should have a perfectly good ID on it, change the margin below it – or maybe even toss a negative margin on it. That’s part of why I’d make them display block, NOT waste a list around it for nothing, etc, etc…

@DoubleDee

Why do you say that?

RE: move the please text
I just think it would fit better there visually, especially if you’re going to have that massive requirements list in there somewhere.

@DoubleDee

Is what I have that bad?

Not so much bad, as ugly – IMHO. YMMV.

@DoubleDee

And if I followed your suggestion, could I place the Error Messages BENEATH the fields so that I don’t disrupt the Label/Field pairing?

Wouldn’t be disrupting the pairing, that’s what FOR is in there to maintain… that way you can put comments, extra instructions or anything else, before, after or around the input… so long as it visually all lines up, it’s fine.

Though that’s often why I prefer having my labels NEXT to my inputs. display:inline-block for the win. (then have my rejections appear below the input).

@DoubleDee

(Personally I think Red Text Error-Messages off to the right side look best…)

I hate it, but it’s your site so…

@DoubleDee

What I am trying to do is better than letting people choose simple, 8-character passwords like “password”, “LetMeIn”, and so on.

Just be wary of alienating visitors – I know some folks who would see that and immediately go “screw this” and use some other website. Come across that on torrent sites all the time… Did I say torrent sites… I mean… uhm… . Had one guy who was wondering why his site had little traffic – a quick poll showed nobody liked the password rules that weren’t even CLOSE to what you’re trying to set up.

@DoubleDee

I would be open to making the Minimum Password Length = 20 characters and force people to use “Pass-Phrases” instead…

That isn’t a bad idea.

No matter what you set up, it’s probably not going to effect PEBKAC – sometimes you have to live with users being morons who don’t want security (see the people who STILL piss and moan about Vista/7 ‘forcing’ a login password – and not being able to even follow the simple instructions to disable that); trying to force the issue can do more to prevent anyone from bothering to use it than it does to secure it.

See all the people who disable UAC. (and you give them linux, they chew you out for the same reason! Why does it keep asking me for my password?)

[DoubleDee]

@deathshadow60

Not a UL hater, but what makes that a LIST? Waste of tags with semantic meanings around tags that ALREADY HAVE meanings. Waste of code.

Maybe/maybe not, but if I change it, it has to wait until Release #3.

[quote]I like how this looks, but I don’t like the huge white-space between the Password and Confirm Password fields. How can I make the Password Fields “hug” each other?

Since password should have a perfectly good ID on it, change the margin below it – or maybe even toss a negative margin on it. That’s part of why I’d make them display block, NOT waste a list around it for nothing, etc, etc…[/quote]

I’m not understanding why I have the gap.

I thought that using a Float is supposed to remove the floated item from the document flow. So why doesn’t my 2nd Password just ignore the Password Requirements DIV/Float and snug up against the 1st Password field?

Here are 3 screenshots of what I see in FireBug…

Debbie

[ralphm]

@DoubleDee

I thought that using a Float is supposed to remove the floated item from the document flow.

Not entirely. Other elements just tend to flow around it. To get other elements to ignore it completely, you could position it absolutely.

Another option would be to reduce the width of the confirm password LI, as it doesn’t need to be that wide.

[DoubleDee]

Okay, DeathShadow, you can’t say that I never listen to you or try to see things your way…

So I begrudgingly decided to “turn over a new leaf” and lose my UL/LI’s on my Form Fields…

I must admit that my code doesn’t look as bad as I thought it might, and styling things wasn’t too bad.

So here is a screen-shot of my new and improved Registration Form…

I think things look awesome!!

As far as changing the location of my Error Messages, well, you can’t win 'em all?!

Thanks,

Debbie

P.S. A Registration Form is a LIST of Fields that in aggregate form a grouping of data needed to Register. Therefore a List is semantically correct if you choose to go that way…

P.P.S. Check out my thread on what makes for Highly Secure yet User-Friendly Passwords?!