Re: Is it possible at all to secure an unencrypted website?

Joe,

Thank you for the information and for getting back to me so quickly - I'll
have to do some more thinking about our site, apparently.

More or less thinking out loud ...

Noticed when I went in to check the newsgroup, that for example the MSDN
login and subscriber download pages are secure, but the MSDN home page and
many other pages without sensitive content are not, which makes sense (secure
pages are slower).

The top right of the page says "Welcome Lena" and "Sign Out" so MSDN must
see me as logged in ... but I assume it's not actually passing any
authentication information on these pages, where someone could intercept it
and use to access the secure download page. I'm sure Microsoft wouldn't let
anyone break in so easily and steal expensive software :)

Comparing to something I noticed on another website I worked on a long time
ago ... most of the site was unsecure but there were some secure pages, and
the secure and unsecure parts used different ASP Session IDs. That would take
care of keeping the unsecure pages from giving away authentication data for
the secure pages, wouldn't it?

I'm sure there is more to it than that, of course ... I'll work away on it
and see what I can find.

Thank you again for the information, it was helpful!



"Joe Kaplan" wrote:

Your analysis is correct. If you want it to be secure, you really need to
consider SSL. Session cookies or cookies that supply authentication
information are just as easily intercepted as query string parameters if the
plaintext HTTP data can be sniffed.


--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"LenaMsdn08" <LenaMsdn08@xxxxxxxxxxxxxxxx> wrote in message
news:F7B2F251-62B1-410D-8C55-C6995AA65B21@xxxxxxxxxxxxxxxx
We recently had this discussion at work - someone had suggested
implementing
single sign-on by passing a random 32-byte key in the query string and
match
it against a database that is used by both applications. Both sites are
written in ASP.NET 1.1

It was pointed out that passing this key in the query string was a huge
security hole; anyone who intercepted the request on the Internet could
then
use the key to log in.

On the other hand, wouldn't any unencrypted (using http, not https)
website
be vulnerable pretty much no matter what you do? For example, even if the
session object is server-side, isn't the cookie that stores the session ID
passed in the HTTP request, so just as well as intercepting the query
string,
couldn't someone intercept the cookie and hijack the session?

(My apologies for the lack of correct terminology in this post.)


.

Relevant Pages

  • Re: Reality Check: Session Hijacking
    ... I'm not putting hidden fields in http ... The user is always challenged when he starts to use a secure app, ... STARTS to use the secure app. ... And NOT from the session. ...
    (comp.lang.php)
  • Re: server question
    ... >> values when a user logs in. ... And after that uses http to show the pages. ... Since I am using session var's to keep track of things, ... store the session id in a secure cookie, then it wouldn't be sent when the ...
    (comp.lang.php)
  • Re: server question
    ... The part where the user logs in, ... And after that uses http to show the pages. ... Since I am using session var's to keep track of things, ... I thought the secure mode during login was only used to ...
    (comp.lang.php)
  • Re: Client-Side Session Data
    ... cookie, but from then, it's OK to use HTTP? ... You could make this slightly more secure by associating an IP address with ... the session, and ending the session if the user's IP address changes, ... AOL that sit their customers behind a large pool of proxy servers. ...
    (comp.lang.php)
  • Re: Is it possible at all to secure an unencrypted website?
    ... Amazon also is a good example of maintaining some notion of who you are but switching to secure mode for actual ordering operations and other similar stuff. ... Once way to do this is to ensure that your actual authentication cookies are set with the Secure flag so the browser will only return them on a secure channel. ... where someone could intercept it ... the secure and unsecure parts used different ASP Session IDs. ...
    (microsoft.public.dotnet.framework.aspnet.security)
Quantcast