is it necessary to NOT put submitted password in value attr

JavaScript and client side scripting.

Moderator: General Moderators

Post Reply
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

is it necessary to NOT put submitted password in value attr

Post by Luke »

I have always just taken it as law that you aren't supposed to echo out the POSTed password back into the password element's value attribute like you do other elements when validating data. I read that it's a bad idea way back in the day because it puts it in plain text in the html. But when I really think about it... why is that bad? It's already being sent via plain text... what's the difference? If you're not sure what I'm talking about... I'm talking about this...

Code: Select all

<input type="password" name="password" value="<?php echo htmlentities($password); ?>" />
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

Probably because it can get cached and live a long time someplace.
User avatar
Oren
DevNet Resident
Posts: 1640
Joined: Fri Apr 07, 2006 5:13 am
Location: Israel

Post by Oren »

Yeah, NOT putting it is a good idea in my opinion.
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

but why? that is what I'm getting at... it's always been said that it's "not a good idea"... but that isn't good enough for me. I want a reason.
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post by pickle »

Caching is a good reason. Sure the password may be sent in plaintext, but that's just for a moment. Cached stuff, as we all know, can stick around for a lot longer.

Even if the page is submitted in plaintext, why double the chance it'll be intercepted on the wire & send it back to the client?

Also, what if the user is accessing a secure page? Then the password won't have been submitted in plaintext & by putting it in the source, you're opening up a hole.

Finally, more often than not, the password is mistyped anyway. If the password field isn't filled, the user can easily put their cursor in the field & start typing again. If the password was entered in that field, there's no way they can see where they mistyped, so they'll have to delete it anyway. Only in cases where a user mistypes their username (which is extremely rare in my experience), is it beneficial to the user to have the password field filled in.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

Only in cases where a user mistypes their username (which is extremely rare in my experience), is it beneficial to the user to have the password field filled in.
I wouldn't ever want / need to echo back the password into the password field if it was just a login... this is for a "register for an account" form.

You do make several good points though. Thanks pickle.
User avatar
superdezign
DevNet Master
Posts: 4135
Joined: Sat Jan 20, 2007 11:06 pm

Post by superdezign »

Hehe, this thread made me modify my form handler class. :-p I didn't even consider that it was actually going to be written in the HTML.
User avatar
The Phoenix
Forum Contributor
Posts: 294
Joined: Fri Oct 06, 2006 8:12 pm

Post by The Phoenix »

The Ninja Space Goat wrote:but why? that is what I'm getting at... it's always been said that it's "not a good idea"... but that isn't good enough for me. I want a reason.
Because you are sending a password in cleartext, allowing anyone with a sniffer on the network to read that password.

In fact, you shouldn't even have the password in cleartext to *offer* back to the user. If you do, that means either they sent it to you in cleartext (bad), or you stored it in cleartext (very bad).
Post Reply