Password Fields

All,

We're trying to determine how to deal with password fields losing their
state on a post back.

We've got a form that implements post backs to carry out server side
processing. As a result of the post back, passwords entered by the user
lose their values and the user gets an error message upon final validation
when they submit. Here's an illustration

1. Password : [ ]
2. Confirm: [ ]
3. Select something from a list: [ ] // this could cause a
post-back, which wipes out the passwords
4. Some other field: [ ]
5. Hit submit key

After hitting the submit key (5), the user gets an error message, because
the passwords are now blank as a result of the post back in step #3. What
techniques should be used to get around this? We've tried fiddling with
the VIEWSTATE, to remember values, but it seems like their should be better
way... (?)

-- dwaTextbox of type password are cleared by design after postback. There are ways to get around it using Javascript but it's not a safe/secure thing to do

Suresh

-- dwa wrote: --

All

We're trying to determine how to deal with password fields losing thei
state on a post back

We've got a form that implements post backs to carry out server sid
processing. As a result of the post back, passwords entered by the use
lose their values and the user gets an error message upon final validatio
when they submit. Here's an illustratio

1. Password : [
2. Confirm: [
3. Select something from a list: [ ] // this could cause
post-back, which wipes out the password
4. Some other field: [
5. Hit submit ke

After hitting the submit key (5), the user gets an error message, becaus
the passwords are now blank as a result of the post back in step #3. Wha
techniques should be used to get around this? We've tried fiddling wit
the VIEWSTATE, to remember values, but it seems like their should be bette
way... (?

-- dw
Look at it from a security standpoint, if you restored the password, any joe
could look at the source and see the password in cleartext (not like it
isn't transfered that way). If it makes you feel any better, every site
I've come across doesn't save my password across postbacks. Yeah it's
annoying, but probably best way for security reasons. If you do want to
restore it, I'm sure the method you are using works great. If you want to
do it automatically you'll probably have to do some funky
inheritance/overriding of whatever method that matches posted values to
their respective form fields, which probably wouldn't even be worth it (and
I wouldn't even know where to begin)

"dwa" <da@.hotmail.com> wrote in message
news:%238rsyGy%23DHA.3496@.TK2MSFTNGP10.phx.gbl...
> All,
> We're trying to determine how to deal with password fields losing their
> state on a post back.
> We've got a form that implements post backs to carry out server side
> processing. As a result of the post back, passwords entered by the user
> lose their values and the user gets an error message upon final validation
> when they submit. Here's an illustration
> 1. Password : [ ]
> 2. Confirm: [ ]
> 3. Select something from a list: [ ] // this could cause a
> post-back, which wipes out the passwords
> 4. Some other field: [ ]
> 5. Hit submit key
> After hitting the submit key (5), the user gets an error message, because
> the passwords are now blank as a result of the post back in step #3.
What
> techniques should be used to get around this? We've tried fiddling
with
> the VIEWSTATE, to remember values, but it seems like their should be
better
> way... (?)
> -- dwa
Suresh,

I understand the security concerns. Nevertheless, can you point us to one
of those javascript examples?

Thanks,

-- dwa

"Suresh" <anonymous@.discussions.microsoft.com> wrote in message
news:961AEBCE-240A-43CF-B466-E31A6AED72E4@.microsoft.com...
> Textbox of type password are cleared by design after postback. There are
ways to get around it using Javascript but it's not a safe/secure thing to
do.
> Suresh.
> -- dwa wrote: --
> All,
> We're trying to determine how to deal with password fields losing
their
> state on a post back.
> We've got a form that implements post backs to carry out server side
> processing. As a result of the post back, passwords entered by the
user
> lose their values and the user gets an error message upon final
validation
> when they submit. Here's an illustration
> 1. Password : [ ]
> 2. Confirm: [ ]
> 3. Select something from a list: [ ] // this could cause
a
> post-back, which wipes out the passwords
> 4. Some other field: [ ]
> 5. Hit submit key
> After hitting the submit key (5), the user gets an error message,
because
> the passwords are now blank as a result of the post back in step #3.
What
> techniques should be used to get around this? We've tried
fiddling with
> the VIEWSTATE, to remember values, but it seems like their should be
better
> way... (?)
> -- dwa
I understand the security concerns.

I have seens sites that do this (asp.net sites if memory serves)

So it's being done... which means that some people want to override the
security issue in favor of improved form behavior. Plus, the security
issue is there regardless of the postback, but that's another story...

Darn!

-- dwa

"Raterus" <raterus@.localhost> wrote in message
news:OCA2PXy%23DHA.792@.TK2MSFTNGP11.phx.gbl...
> Look at it from a security standpoint, if you restored the password, any
joe
> could look at the source and see the password in cleartext (not like it
> isn't transfered that way). If it makes you feel any better, every site
> I've come across doesn't save my password across postbacks. Yeah it's
> annoying, but probably best way for security reasons. If you do want to
> restore it, I'm sure the method you are using works great. If you want to
> do it automatically you'll probably have to do some funky
> inheritance/overriding of whatever method that matches posted values to
> their respective form fields, which probably wouldn't even be worth it
(and
> I wouldn't even know where to begin)
>
> "dwa" <da@.hotmail.com> wrote in message
> news:%238rsyGy%23DHA.3496@.TK2MSFTNGP10.phx.gbl...
> > All,
> > We're trying to determine how to deal with password fields losing their
> > state on a post back.
> > We've got a form that implements post backs to carry out server side
> > processing. As a result of the post back, passwords entered by the
user
> > lose their values and the user gets an error message upon final
validation
> > when they submit. Here's an illustration
> > 1. Password : [ ]
> > 2. Confirm: [ ]
> > 3. Select something from a list: [ ] // this could cause a
> > post-back, which wipes out the passwords
> > 4. Some other field: [ ]
> > 5. Hit submit key
> > After hitting the submit key (5), the user gets an error message,
because
> > the passwords are now blank as a result of the post back in step #3.
> What
> > techniques should be used to get around this? We've tried fiddling
> with
> > the VIEWSTATE, to remember values, but it seems like their should be
> better
> > way... (?)
> > -- dwa
Here you go

Instead of a asp:textbox use html input box of type password and set it to runat server like below

<INPUT id="htxtPWD" type="password" runat="server"

Then in your handler that handles the postback of your dropdown list add the following code

string sJs = "<script language=\"javascript\">\n"
"<!--\n"
"document.myTestForm.htxtPWD.value = \"" + htxtPWD.Value + "\";"
"//-->\n"
"</script>\n"

Page.RegisterStartupScript("", sJs)

NOTE: This WILL leave the password exposed in the source of the HTML file

HTH
Suresh

-- dwa wrote: --

Suresh

I understand the security concerns. Nevertheless, can you point us to on
of those javascript examples

Thanks

-- dw

"Suresh" <anonymous@.discussions.microsoft.com> wrote in messag
news:961AEBCE-240A-43CF-B466-E31A6AED72E4@.microsoft.com..
> Textbox of type password are cleared by design after postback. There ar
ways to get around it using Javascript but it's not a safe/secure thing t
do
>> Suresh
>> -- dwa wrote: --
>> All
>> We're trying to determine how to deal with password fields losin
thei
> state on a post back
>> We've got a form that implements post backs to carry out server sid
> processing. As a result of the post back, passwords entered by th
use
> lose their values and the user gets an error message upon fina
validatio
> when they submit. Here's an illustratio
>> 1. Password : [
> 2. Confirm: [
> 3. Select something from a list: [ ] // this could caus

> post-back, which wipes out the password
> 4. Some other field: [
> 5. Hit submit ke
>> After hitting the submit key (5), the user gets an error message
becaus
> the passwords are now blank as a result of the post back in step #3
Wha
> techniques should be used to get around this? We've trie
fiddling wit
> the VIEWSTATE, to remember values, but it seems like their should b
bette
> way... (?
>> -- dw
>>>
You can use JavaScript to do this task,

private void RegisterPasswordScript()
{
string pw= LoadPW();

StringBuilder sb = new StringBuilder();
sb.Append("<script type=text/javascript language=javascript>\n");
sb.Append("\tfunction FillPassword()\n");
sb.Append("\t{\n");

sb.Append("\t\tdocument.all[\""+_passwordTexBox1.ClientID+"\"].value=\""+pw+
"\"\n");

sb.Append("\t\tdocument.all[\""+_passwordTexBox2.ClientID+"\"].value=\""+pw+
"\"\n");
sb.Append("\t}\n");
sb.Append("\t</script>");
this.RegisterStartupScript("PWSCRIPT",sb.ToString());
}

and call this for example in Page_Load(). You should encrypt the password
before integrating it into the Script.

You have to inlcude <body onload="javascript:FillPassword();"
Hope this is what you want.

Ci@.o Jens

"dwa" <da@.hotmail.com> schrieb im Newsbeitrag
news:%238rsyGy%23DHA.3496@.TK2MSFTNGP10.phx.gbl...
> All,
> We're trying to determine how to deal with password fields losing their
> state on a post back.
> We've got a form that implements post backs to carry out server side
> processing. As a result of the post back, passwords entered by the user
> lose their values and the user gets an error message upon final validation
> when they submit. Here's an illustration
> 1. Password : [ ]
> 2. Confirm: [ ]
> 3. Select something from a list: [ ] // this could cause a
> post-back, which wipes out the passwords
> 4. Some other field: [ ]
> 5. Hit submit key
> After hitting the submit key (5), the user gets an error message, because
> the passwords are now blank as a result of the post back in step #3.
What
> techniques should be used to get around this? We've tried fiddling
with
> the VIEWSTATE, to remember values, but it seems like their should be
better
> way... (?)
> -- dwa
Thanks Suresh.

So basically, we're injecting some code to reinitialize the value explicitly
after the postback.

We'll give it a go.

-- dwa

"Suresh" <anonymous@.discussions.microsoft.com> wrote in message
news:6A9E6D25-5FF9-4233-84FB-3A2371F069E4@.microsoft.com...
> Here you go:
> Instead of a asp:textbox use html input box of type password and set it to
runat server like below.
> <INPUT id="htxtPWD" type="password" runat="server">
> Then in your handler that handles the postback of your dropdown list add
the following code.
> string sJs = "<script language=\"javascript\">\n" +
> "<!--\n" +
> "document.myTestForm.htxtPWD.value = \"" + htxtPWD.Value + "\";" +
> "//-->\n" +
> "</script>\n";
> Page.RegisterStartupScript("", sJs);
> NOTE: This WILL leave the password exposed in the source of the HTML file.
> HTH,
> Suresh.
>
> -- dwa wrote: --
> Suresh,
> I understand the security concerns. Nevertheless, can you point us
to one
> of those javascript examples?
> Thanks,
> -- dwa
> "Suresh" <anonymous@.discussions.microsoft.com> wrote in message
> news:961AEBCE-240A-43CF-B466-E31A6AED72E4@.microsoft.com...
> > Textbox of type password are cleared by design after postback.
There are
> ways to get around it using Javascript but it's not a safe/secure
thing to
> do.
> >> Suresh.
> >> -- dwa wrote: --
> >> All,
> >> We're trying to determine how to deal with password fields
losing
> their
> > state on a post back.
> >> We've got a form that implements post backs to carry out
server side
> > processing. As a result of the post back, passwords entered
by the
> user
> > lose their values and the user gets an error message upon
final
> validation
> > when they submit. Here's an illustration
> >> 1. Password : [ ]
> > 2. Confirm: [ ]
> > 3. Select something from a list: [ ] // this could
cause
> a
> > post-back, which wipes out the passwords
> > 4. Some other field: [ ]
> > 5. Hit submit key
> >> After hitting the submit key (5), the user gets an error
message,
> because
> > the passwords are now blank as a result of the post back in
step #3.
> What
> > techniques should be used to get around this? We've tried
> fiddling with
> > the VIEWSTATE, to remember values, but it seems like their
should be
> better
> > way... (?)
> >> -- dwa
> >>
Jens,

Looks pretty close to the suggestion from Suresh. So by majority vote,
we'll try it out.

Thanks,

-- dwa

"Jens Hofmann" <bully01@.gmx.de> wrote in message
news:403bf91b$0$28971$9b4e6d93@.newsread2.arcor-online.net...
> You can use JavaScript to do this task,
>
> private void RegisterPasswordScript()
> {
> string pw= LoadPW();
> StringBuilder sb = new StringBuilder();
> sb.Append("<script type=text/javascript language=javascript>\n");
> sb.Append("\tfunction FillPassword()\n");
> sb.Append("\t{\n");
>
sb.Append("\t\tdocument.all[\""+_passwordTexBox1.ClientID+"\"].value=\""+pw+
> "\"\n");
>
sb.Append("\t\tdocument.all[\""+_passwordTexBox2.ClientID+"\"].value=\""+pw+
> "\"\n");
> sb.Append("\t}\n");
> sb.Append("\t</script>");
> this.RegisterStartupScript("PWSCRIPT",sb.ToString());
> }
> and call this for example in Page_Load(). You should encrypt the password
> before integrating it into the Script.
> You have to inlcude <body onload="javascript:FillPassword();">
> Hope this is what you want.
> Ci@.o Jens
>
> "dwa" <da@.hotmail.com> schrieb im Newsbeitrag
> news:%238rsyGy%23DHA.3496@.TK2MSFTNGP10.phx.gbl...
> > All,
> > We're trying to determine how to deal with password fields losing their
> > state on a post back.
> > We've got a form that implements post backs to carry out server side
> > processing. As a result of the post back, passwords entered by the
user
> > lose their values and the user gets an error message upon final
validation
> > when they submit. Here's an illustration
> > 1. Password : [ ]
> > 2. Confirm: [ ]
> > 3. Select something from a list: [ ] // this could cause a
> > post-back, which wipes out the passwords
> > 4. Some other field: [ ]
> > 5. Hit submit key
> > After hitting the submit key (5), the user gets an error message,
because
> > the passwords are now blank as a result of the post back in step #3.
> What
> > techniques should be used to get around this? We've tried fiddling
> with
> > the VIEWSTATE, to remember values, but it seems like their should be
> better
> > way... (?)
> > -- dwa