• ### Popular Now

• 13
• 27
• 9
• 9
• 20

This topic is 3666 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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
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
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
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
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
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
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
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
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?