WebApp Sec mailing list archives

Re: Should login pages be protected by SSL?


From: "Bob Radvanovsky" <rsradvan () unixworks net>
Date: Wed, 22 Jun 2005 14:10:12 -0500

From a programming standpoint, I have made it an adamant point that for ANY site that provides ANY information of ANY 
kind (taking the uber-paranoidic approach to life), regardless of the circumstances, the users are ALWAYS forwarded to 
a "https://..."; URL.  Even the nonsecured URL goes to a secured URL.

Case in point...

Suppose that I have a domain name "www.domain.com", representing the generalized domain web site for Domain Web Site, 
Ink. (name is obvious fictional, but hopefully everyone will get the point).  Now, let's suppose that Domain Web Site, 
Ink. wants to sell some merchandise of their own, such as research papers or software that they've created.  They've 
purchased and modified an XYZ e-commerce product, which (using the term loosely, "out of the box") does NOT provide 
SECURED web access.  The owners of Domain Web Site, Ink. now create a separate web server for their e-commerce, define, 
create and implement a SECURE web server with (at least 1024-bit TLS/SSL) key encryption and is subdomained as 
"merch.domain.com".

The URL redirection/forwarder from "www.domain.com" points to:

http://merch.domain.com

which IMMEDIATELY has in its root web server's directory an "index.html" file containing:

<META HTTP-EQUIV="REFRESH" CONTENT="0; URL=https://merch.domain.com";>

Just for safety, "index.html" is symbolically linked to:

index.htm
index.shtml
index.php
index.asp
...and whatever else you can think of (to be safe).

Does this make any sense?  To me, it's simple, esp. nowadays with being able to have virtual web servers such that you 
can literally have 2 different web sites served by the same server, servicing 1 secured web server.

BTW, in my book (going back to being an uber-paranoidic person), it's never a good idea to have a SECURED web site on 
the same server that is representative as the company's "front door".  Basically, "www.domain.com" is Domain Web Site, 
Ink.'s "front door" (so to speak), such that if it is compromised, "merch.domain.com" doesn't loose it's data in the 
mean time.  However, because "merch.domain.com" is on a separate server, this now DOUBLES the threat of data loss, data 
theft, data contamination, integrity modification, etc.

All in all, I'll take what's behind Door #2, please.

Having a padlock, or a graphic representation of a padlock ON the web site is a nice idea, but I've found that *most* 
Internet-surfing humans have the mental and attention capacity (present company NOT included...) of knats.  The idea or 
notion of further dumbing down web surfing, you might as well as go back to days of pre-Internet and simply watch TV.  
Most people's comments about the Internet today
are that it's "too complicated, esp. with all of those pop-ups".  I deal with management and executives who *really* 
shouldn't even be NEAR a computer (if you can picture a Non Sequitur rendition with Obvious Man answering an executive, 
and the executive's head going *FOOM* when he asks if his computer 'thingy' is powered on).  I've had to replace entire 
computers of working with and dealing with those kinds of idiots -- but *might* be geniuses at legally stealing money 
from other businesses and people (which they throw words out there like "business", or "making money", or "building a 
business" -- which BTW, the last phrase means outsourcing their entire IT department only because Bill from ABC 
Corporation did it 2 months ago...).

The whole point is "eddgoomakashun" (spelled "education") and teaching these people how to use a computer and the 
Internet in the first place.  In most cases, give them a Palm and a sucker and send 'em on their way...

BTW -- JUST BECAUSE THE PADLOCK IS SHOWN DOES NOT MEAN THAT THE WEB SITE IS SECURED!!! 'nuf said...

-rad

At Wed, 22 Jun 2005 07:05:09 -0400, you wrote:

From a purely non-technical viewpoint: it may be a good idea for the 
login page to be protected by SSL if for no other reason that having the 
browser show the "padlock" symbol. It's something that non-technical, 
non-web developer people can see and (somewhat) understand. Since they 
are typing their password on a page, that's what many associate with - 
"I'm not entering my password here, I don't see the padlock".

Amir Herzberg wrote:

There may be some argument even in this case (privacy, tendency of 
users to use same passwords, ...). But this was _not_ my intent. I may 
not have been clear, but I am interested in sensitive sites - 
financial, shopping, security (CA, DNS, SSO, Portals, etc.). As you 
can see in my `Hall of Shame` http://AmirHerzberg.com/shame.html, many 
of these don't use SSL to authenticate the login page, only to encrypt 
the password (when using a correct login page).

So, the real question I'm asking: should login pages to sensitive 
(e.g. financial) sites be protected by SSL?



-- 
Dave Ockwell-Jenner
Solar Nexus Solutions
http://www.solar-nexus.com/


Bob Radvanovsky, CISM, CIFI, REM, CIPS
[/unixworks] "knowledge squared is information shared"
rsradvan () unixworks com | http://www.unixworks.com
(630) 673-7740 [CELL] | (847) 519-5184 [PAGER] | (412) 774-0373 [FAX]


Current thread: