## Recommended Posts

Daedalus AI    100
In my line of business, it's common for our clients to want forms for adding new customers or whatever in their website. One thing they often complain about, is the fact the password field clears on postback (server validation fails for example). This is for security reasons, I know, and I know of a few ways to get around this. 1) I could use AJAX to fetch the password when the page loads and fill it in, although this isn't that desirable as there may be a few second interval before the password is filled in. 2) RegisterExpandoAttribute() 3) Or do it manually; tbxPassword.Attributes["value"] = "Password"; (which is basically what RegisterExpandoAttribute() does). Are there any major security issues with doing any of these? I am fairly certain there is, as then you wouldn't need a "workaround". Thanks Daed.

##### Share on other sites
ToohrVyk    1595
Are you trying to keep the password field filled even if the 'create new user' form fails to validate?

⇒ Ask for the password, login and mail on the first page of the form and keep them around on the server until all the other pages of the form have been completed. The first page is simple enough that it will almost never fail, and the other pages can fail without the password disappearing.

Are you trying to have the password, which is already bound to the user, auto-appear on several distinct uses of the same form?

⇒ There's no point to ask for the password if you're going to fill it in yourself. Use a session system.

##### Share on other sites
Daedalus AI    100
Create New User;
Email : xxx@xxx___

[Submit]

Say they fill each of the above in ('xxx'), and submit and email validation fails (and is validated on the server-side).

Create New User;
Email : xxx@xxx___ <- Sorry this is wrong!

[Submit]

The client will complain that the passwords have been cleared.

I know the most they will have to do on most occasions is re-enter these two fields, but I can sympathise with the client if they have many of these forms to fill in and it becomes quite tedious.

Clients are often fussy, they'll want masked password fields, but they also don't want the fuss of re-entering the password fields.

##### Share on other sites
ToohrVyk    1595
How many "create user" forms does a given user need to fill? I'd say at most one.

However, if a site administrator needs to create several users at once, then it's generally a bad idea to let that administrator enter the passwords himself—instead, provide a random password generator which creates a new password for every new user (the user may then change his password at will). Even better, provide an "username : email" input system using a single textbox:

Joe Davis : me@davis.joeFoo Bar : foo.bar@aol.comMickey Mouse : mickey@example.com

##### Share on other sites
Daedalus AI    100
I like the idea for the Username : Email.

However, this is not a case of a user creating themselves an account. In this particular job, we have a pretty complicated relationship between all the different types of accounts, and in certain cases, they will have to create many accounts.

A randomly generated password would be alright, but that aint what the client wants.

I suggested just using normal plain text fields, but they don't want them either.

Which just brings me back to my original Q of whether my workarounds are opening up great big doors with personal invites to every hacker in the vicinity?

Normally, I would just think the client is being stupid, but this is a topic that has been frequently discussed on many projects with many clients, which is why it's bothering me.

##### Share on other sites
Wan    1366
Perform basic validation client-side. It's not difficult to check for empty fields, invalid email formats with some simple javascript. That way you keep the password and you don't have to make a round-trip to the server. For validation that depends on information stored server-side (like duplicate user names or email addresses), you can still do the post back. Needless to say, doing some of the validation client-side doesn't mean you don't have to perform the same checks again server-side.

If you absolutely have to keep the password filled in, at least replace it by a random sequence of characters of the same length instead of the actual password, while storing the real value on the server:
tbxPassword.Attributes["value"] = "xxxxxx"  // real password is 'foobar'

##### Share on other sites
Daedalus AI    100
Quote:
 Original post by WanMasterPerform basic validation client-side. It's not difficult to check for empty fields, invalid email formats with some simple javascript. That way you keep the password and you don't have to make a round-trip to the server. For validation that depends on information stored server-side (like duplicate user names or email addresses), you can still do the post back. Needless to say, doing some of the validation client-side doesn't mean you don't have to perform the same checks again server-side.If you absolutely have to keep the password filled in, at least replace it by a random sequence of characters of the same length instead of the actual password:tbxPassword.Attributes["value"] = "xxxxxx" // real password is 'foobar'

Yeah, I do all the client-side validation as much as possible (and just starting up the use of AJAX for validation as well, in an attempt to reduce the page refreshing as much as possible).

My example is just a bad example in that respect.

##### Share on other sites
tstrimp    1798
You really should not do this. There is a reason that data isn't there by default. I'd go with the suggestion of a random password or no password and then provide a link in the email to another page where they can fill in their new password. This allows you to truly validate their email and let them fill in their password only once.

##### Share on other sites
Daedalus AI    100
Quote:
 Original post by tstrimpYou really should not do this. There is a reason that data isn't there by default.

Try telling that to a client paying £155,000+ for it!

"Are there any major security issues with doing any of these?
I am fairly certain there is, as then you wouldn't need a 'workaround'."

All I want to know, is;
What are the risks?

##### Share on other sites
Wan    1366
Quote:
 Original post by Daedalus AIAll I want to know, is;What are the risks?

Okay, in a nutshell it comes down to this: the transmission of sensitive data should be kept to an absolute minimum. Currently, by using packet sniffing or even by just simply taking a look at the page's source it's possible to obtain the password. Although one can argue that it will never be 100 percent safe, this certainly isn't helping making things more secure.

##### Share on other sites
Daedalus AI    100
Quote:
Original post by WanMaster
Quote:
 Original post by Daedalus AIAll I want to know, is;What are the risks?

Okay, in a nutshell it comes down to this: the transmission of sensitive data should be kept to an absolute minimum. Currently, by using packet sniffing or even by just simply taking a look at the page's source it's possible to obtain the password.

I see, thanks.

I'm a Software Developer 1st, Web Developer 2nd, and do not know enough about malicious attacks.

I guess my best option is to develope a control to provide the illusion the password is filled in and disable the client-side validation for those fields unless they are changed.

##### Share on other sites
ToohrVyk    1595
An alternate solution is possible.

When first receiving the form, if an error happens, then store the password provided in a database, and bind it to an unique form identifier. Then, return the form to the user with two differences: there is now a hidden field which contains the unique form identifier, and also a javascript which autofills the password with the same number of stars as there were letters in the original password. When the form is posted back, if it was bound to a form identifier, then the database-stored password replaces the form-sent password and processing resumes.

From a security standpoint, passwords are only sent once. The only public critical data is the length of the passwords, which is sent back, but your client already accepts this risk since the correct number of stars appears in the password field.