Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations MikeeOK on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Is WAMU login SSL secure or not?

Status
Not open for further replies.
thedaver

thedaver

IS-IT--Management
Jul 12, 2001
2,741
US
Hi list; please help settle a debated question at work about SSL implemention as a form target on a non-HTTPS page.

Consider main page:

Their login window (upper-right) runs using the following code for the form:
Code: 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "[URL unfurl="true"]http://www.w3.org/TR/html4/loose.dtd">[/URL]

<html>
<head>
    <title>Login Form</title>
    <link rel="stylesheet" type="text/css" href="/common/style/master.css"/>
	<link rel="stylesheet" type="text/css" href="/public/style/pub.css"/>
</head>
<body class="loginfields">
    <form name="frmLogin" method="post" action="[URL unfurl="true"]https://online.wamu.com/access/oblix/apps/webgate/bin/webgate.dll?/IdentityManagement/postlogon.hdlr"[/URL] target="_parent">
         <dl>
            <dt>View Your Accounts</dt>
            <dd>Log in to your account online:</dd>
            <dd>
                User Name:
		    </dd>
		    <dd>
		        <input type="text" id="txtUserID" name="txtUserID" maxlength="32" autocomplete="off" class="fieldmedium" tabindex="1" value="Enter user name" onfocus="if(this.value == this.defaultValue) this.value = '';"/>

(.... snip ....)

     </form>
</body>
</html>

As you can see, the form's ACTION is
Code: 
action="[URL unfurl="true"]https://online.wamu.com......[/URL]

My question is... if you submit your login credentials from an HTTP page where the form action target is HTTPS/SSL, are your credentials potentially compromised or not? This is as opposed to a scenario where the login logic appeared on a main page that is HTTPS/SSL already.

One side argues that submitting this login box with empty credentials is best because it errors out to an HTTPS main page where the credentials can be submitted under "true" HTTPS/SSL.

The other side argues that the HTTPS for the form action target is sufficient to assure the credentials are protected, regardless of the main page being SSL or not.

Thanks!
Dave.




D.E.R. Management - IT Project Management Consulting
 
Sort by date Sort by votes
From the following post: Evolt

While it's not proper form to submit from unsecure to secure, the browser and server need to setup the secure channel each time prior to sending the data. It setup and tear down each time, irregardless of the referring page.
Click to expand...

I take this to mean that it doesn't matter. You can start from http and post to https, or you can start from https and post to https... the end result is the same... the information sent is secured.

That was my take on it.

Cheers,
Jeff

[tt]Jeff's Page @ Code Couch
[/tt]

What is Javascript? FAQ216-6094
 
Upvote 0 Downvote
While it's not proper form to submit from unsecure to secure, the browser and server need to setup the secure channel each time prior to sending the data
Click to expand...

I would think someone could grab that data before the process of setting up the secure channel.

The action of beginning the submit has started before a secure channel is set up, that's when someone could attack.

[monkey][snake] <.
 
Upvote 0 Downvote
Reading on that URL you provided monksnake, it seems to say that you can submit from http to https and the data will be secure. The only thing you don't get is the little padlock:

some guy at that URL said:
The only problem with submitting from an unencrypted form to an encrypted URL is that the web browser won't show the padlock icon on the page (as most browsers do nowadays) to show that the form is secure, even though it will in fact be submitted securely.
Click to expand...

Good question (especially for a Friday afternoon) [smile]

Cheers,
Jeff

[tt]Jeff's Page @ Code Couch
[/tt]

What is Javascript? FAQ216-6094
 
Upvote 0 Downvote
On that URL, they were back and forth on this subject as well.

The most definitive answer was from the guy you quoted.

I think the transfer from the http to https sites would be secure. However, I don't think the data would be secure on the http page since it could be transferred to another place.

[monkey][snake] <.
 
Upvote 0 Downvote
monksnake said:
However, I don't think the data would be secure on the http page since it could be transferred to another place.
Click to expand...
Agreed. And I think this was the source of confusion on that URL as well [smile]

Cheers,
Jeff

[tt]Jeff's Page @ Code Couch
[/tt]

What is Javascript? FAQ216-6094
 
Upvote 0 Downvote
Hmmm... cool dialog all, many thanks!

I guess I would've expected a major bank to do it right, but certainly does give you a reason to pause... Particularly troubling is that unless you inspect the form action in the source code, you would not know until AFTER submitting whether your credentials were protected.

I would vote that, irrespective of actual security, it's bad style to NOT be on a "padlocked" page when submitting important credentials. We've all been telling our grandmothers about "padlocks" for years, and then sites like WAMU go and screw with best practices for maximized consumer confidence.

TGIF!
thanks,
Dave.

D.E.R. Management - IT Project Management Consulting
 
Upvote 0 Downvote
I would vote that, irrespective of actual security, it's bad style to NOT be on a "padlocked" page when submitting important credentials. We've all been telling our grandmothers about "padlocks" for years, and then sites like WAMU go and screw with best practices for maximized consumer confidence.
Click to expand...
I couldn't agree more. Hotmail do it "wrong" too [smile]

Cheers,
Jeff

[tt]Jeff's Page @ Code Couch
[/tt]

What is Javascript? FAQ216-6094
 
Upvote 0 Downvote
Forget about the web page as stateful.

The form sitting there on a web page, and the thing you submit to the web server, are two completely different things. They are not connected. They don't rely on each other. And they can come from different places. In fact, there doesn't even have to be a rendered page at all. All that's necessary is for a valid HTTP request in SSL mode be made. The security is all in the negotiation of the protocol before any document is sent.

Write a simple program that can submit HTTPS requests. Build a valid web request entirely in another application and copy and paste it into your program. After all, it's just a single document--All the header and GET and POST data and content of it is just bytes in a stream. (Using the different parts as if it was an object with properties is merely a convenience of a programming interface to the document. But really, it's just text.)

Now, submit the GET or POST securely to your bank using https. I guarantee you 100% that the protocol is negotiated before sending the document. It's an out-of-document-band operation. The new request has nothing to do with the form as displayed in a browser, and there is no context of a page, or http:// or ftp:// or blornk://.

It is secure.

The point about the user not KNOWING it is secure is a good one. But it has absolutely nothing to do with reality. All you know is that the current page is secure. What if it was the reverse situation, where you retrieve a form securely, but it's submitted insecurely? The user won't know that unless he receives the "you are submitting an insecure form" warnings that everyone turns off in their browser first thing after installing it.

The only thing we can do is trust the site or not. If you trust your bank to get it right (and their millions of dollars is a reasonable indication that they probably are) then forget if there's a padlock icon in your browser. And if you don't trust your bank, then stop using it, and definitely don't trust the padlock icon.

Look at the reply page for an indicator about whether the form was submitted securely. But even that is not 100% foolproof as the form could have been submitted insecurely and then the browser redirected to a secure page.
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

cae154
  • Locked
  • Question
Body of email not appearing in correct font on iPhone and iPad
Replies
1
Views
1K
spamjim
spamjim
pendle666
  • Locked
  • Question
new website renders fine in IE/Edge but not in Chrome - test site was fine
Replies
2
Views
346
pendle666
pendle666
PeDa
  • Locked
  • Question
Table not formatted correctly in all browsers 1
Replies
2
Views
430
PeDa
PeDa
stinkybee
  • Locked
  • Question
HTML5 Datalist not working
Replies
2
Views
579
stinkybee
stinkybee
PSchubert
  • Locked
  • Question
Data in db table cell not displayed in asp table cell -- a CSS issue?
Replies
2
Views
297
vacunita
vacunita

Part and Inventory Search

Sponsor

Back
Top