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]
