-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bob Radvanovsky wrote:
| 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).
Just use a mod_rewrite rule in your webserver if you can.
|
| 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]
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
iD8DBQFCuakBVtbq2E0xxN0RAlwOAJ9C36NIYQ0AAiIckm4lzzIRmCmFGwCeICZb
7ZJeo3ypf5MxjqSWze9G/nE=
=nONC
-----END PGP SIGNATURE-----
