Web Control vs. html "run as server" for setting password from coo

[Guest]

I'm trying to create a login page for customers to log into our corporate
website, our presidents naturally wants the user and password fields to
populate from a cookie so the customer doesn't have to type their credentials
every time, this seems like a pretty common thing. However, when I try to
populate the password HTML textbox from the cookie, the textbox remains
blank. However, if I try this from an equivalent web control, the textbox
shows the hidden password •••••••••.

My research in Google tells me that there is absolutely no way to populate
an html textbox with text when the type="password." Articles I've read say
that this is because a user can look at the page source markup and see the
actual password, which Microsoft sees as a security issue.

However, I am able to get this to work when I use a .NET web control, even
though the password is shown in source markup. It doesn't make sense that
they would restrict functionality in an html control yet not do so in a web
control.

I'd really prefer having my textboxes be part of an html form to avoid
repeat round trips to the server, is there absolutely no workaround for the
issue?

Thanks,

Andre Ranieri

 

[bruce barker]

you can set the password from the server side by using the control
attributes. just add the "value" attribute with the password value.

-- bruce (sqlwork.com)


| I'm trying to create a login page for customers to log into our corporate
| website, our presidents naturally wants the user and password fields to
| populate from a cookie so the customer doesn't have to type their
credentials
| every time, this seems like a pretty common thing. However, when I try to
| populate the password HTML textbox from the cookie, the textbox remains
| blank. However, if I try this from an equivalent web control, the textbox
| shows the hidden password ..........
|
| My research in Google tells me that there is absolutely no way to populate
| an html textbox with text when the type="password." Articles I've read
say
| that this is because a user can look at the page source markup and see the
| actual password, which Microsoft sees as a security issue.
|
| However, I am able to get this to work when I use a .NET web control, even
| though the password is shown in source markup. It doesn't make sense that
| they would restrict functionality in an html control yet not do so in a
web
| control.
|
| I'd really prefer having my textboxes be part of an html form to avoid
| repeat round trips to the server, is there absolutely no workaround for
the
| issue?
|
| Thanks,
|
| Andre Ranieri

 

[Kevin Spencer]

I'm afraid you've still got some holes in your understanding of how ASP.Net
works. In addition, you have a security issue that you're not aware of.
Let's start with the first part first.

An ASP.Net WebForm renders an HTML form on the client. There is absolutely
no requirement that a Server Control cause a PostBack. So, ther is
absolutely no requirement that you do this with a static HTML page, although
you certainly could.

Using an HTML document, you COULD populate the password box from a cookie.
JavaScript can read cookies. Google is useful, but you have to ask the right
questions. However, how is the JavaScript is a static HTML document going to
know what password to use? I suppose you could use behaviors, and have the
JavaScript call a Web Service to obtain the password, but again, how does
the JavaScript know what password to ask for? And this is already beginnning
to look like a shortcut that is more complicated than the alternative.

On the other hand, you could use an ASP.Net WebForm instead. Using the
WebForm, you could also populate the password box from a Cookie. However,
the problem there is, the password would appear in clear text in the HTML of
the document. This would be an unacceptable security issue.

This is the reason that password boxes are not populated in almost all forms
that take passwords. There was a time when people used their own computers
all the time. Now, one of your users could drop into a cyber cafe on his
lunch break, log in to your web site, and leave his password behind for
everyone that followed.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Steve C. Orr [MVP, MCSD]]

Sending the password in plain text to the browser is a bad idea from a
security standpoint so the default security settings discourage it.
(Anybody can do a view source for the page and see the password)


However there is a workaround. You must set the password text via
clientside script.

This server side code outputs the needed client side code:

MyPWTextBox.Attributes.Add("value", strPassword)

 

[Kevin Spencer]

However there is a workaround. You must set the password text via

clientside script.

This server side code outputs the needed client side code:

MyPWTextBox.Attributes.Add("value", strPassword)

If I'm not mistaken, Steve, that would still make the password visible in
the HTML:

<input type="password" name="T1" size="20" value="password">

Your statement that it needs to be set via client-side code would be
correct, IF there was a way that JavaScript could get the password without
putting it in the HTML, such as making a Web Method call. It could then
programmatically set the value of the password box (at run-time) without it
appearing in the HTML. But, as I mentioned earlier, there would still be a
problem of determining WHICH password it would fetch.

I really think the only workable solution is to leave the password OUT of
the cookie.

As a matter of fact, now that I think of it, anyone could get the password
out of the cookie without even opening a browser! Cookies are, after all,
just text files.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Steve C. Orr [MVP, MCSD]]

Yes, it would still be visible in the HTML. Like I said, this is not a good
thing to do from a security perspective.
I was just stating that it is possible to programatically set the password
text in a password field.
You can get the password from a cookie (user server side code) or from
wherever, there is nothing very mysterious about that aspect of it.

 

[Guest]

Gentlemen,

Thanks for the great feedback. What I'm undestanding is that, if I'm going
to use cookies to remember passwords, I bypass the login/authentication page
and go right to the secure site if the user ID and password are known,
similar to MSN Messenger. This way I avoid exposing the password in html
source.

Thanks again for your time and dedication to the .net community.

Andre Ranieri

andre*at*senske*dot*com