Re: Is .NET Passport credential traffic secure?

From: *Vanguard* (no-email_at_post-reply-in-newsgroup.invalid)
Date: 03/08/04 

Date: Mon, 8 Mar 2004 13:07:23 -0600

"S. Pidgorny <MVP>" said in news:uU9%239ROBEHA.212@TK2MSFTNGP12.phx.gbl:
> Coming back to the original question: the Web sites mentioned there
> are
>
> Hotmail
> Ebay
>
> On the logon page of Hotmail, all form action posts are protected
> with SSL, HTML code below:
>
> <form ... action="https://login.passport.com/..." ...>
>
> That means the authentication credentials are encrypted from me to
> Passport.

Yeah, my point is that you must FIRST establish a secure connection to
the server before *sending* your username and password. www.hotmail.com
will redirect you to a Passport page. If the Passport page doesn't
itself require an SSL connection then no padlock would appear in the
browser's status bar and so the user get no indication that a send of
their username and password will be secure (yeah, like we all trust what
a web page claims). The action of the submit in the form has it FIRST
connect to an HTTPS site to use SSL over which the username and password
are then sent.

Since HTTPS is going to get used anyway, why hide that fact from the
user instead of making the login page itself secured with SSL so the
user can see the padlock and know for sure the submit is secure?

> In case of eBay Passport login, the authentication form is also
> submitted to login.passport.com over secure channel.

Yes ... eventually. The "Sign In" page at eBay submits the form data
similarly to the above where:

<form ... action="https://scgi.ebay.com/saw-cgi/eBayISAPI.dll?... >

Again, the fact that it might be secure is hidden from the user for no
good reason. You think the majority of users view the source of a web
page to check the HTML code to verify that the submit goes to an HTTPS
site? Or might most go look for the padlock in the status bar? Why
delay the use of HTTPS?

There's only one reason I can think of where there is a benefit in NOT
using an HTTPS login page and instead submitting the form data to an
HTTPS site: Allowing the site to generate the HTML content in the page
to alter where the submitted data gets sent. The server-side CGI
program can generate the HTML code presented to the end user and as such
the target site for the submitted data can be dynamically defined at the
time the user visits the non-secured login page. Great, as that means
you cannot guarantee that sometime later the data may get submitted to a
non-secure site. For now, the form's action is to submit the data to an
HTTPS site. But are you going to interrogate the HTML code received for
that page every time you visit it? No, which means whether accidentally
or intentionally the page author can alter to where that data gets
submitted and it may not be an HTTPS site. So, again, users won't have
a clue that their username and password are secure when transmitted
unless they get to an HTTPS login page in the first place so they can
see the padlock.

What's rather stupid about sites that employ Passport is that they will
fail to let you login to your accounts there if Passport is down. While
eBay submits the form data on their non-secure login page to an HTTPS
site, they also have a link to use an SSL-secured login page
(https://scgi.ebay.com/saw-cgi/eBayISAPI.dll?...). When I wrote this
reply, trying to log into eBay using their SSL-secured login page
resulted in "Sorry, we are unable to process your request at this time
because Passport is currently unavailable", so it looks like their
server-side program is trying to use Passport. To verify this,
www.passport.net was also unusable at the time for logging in. This
prevented me from logging into Hotmail and also prevented me from
getting the https:// secure login page at eBay (I could still use the
non-secure http:// login page). A half-day later and I still cannot
reach www.passport.net. A traceroute from me dies before managing to
get to whatever is the next host in the route off my att.net network
(Comcast). I've tried using various traceroutes from other web sites
across the USA that offer a traceroute tool and none of them could get
to the passport.net domain, either. So not being able to reach Passport
results in crippling a site that relies on it.

> That's easy to
> find out by setting Internet Explorer to warn about changing between
> secure and non-secure sites, under Tools/Internet
> Options/Advanced/Security.

And if you use the non-secure login page (e.g., eBay) to get to the
non-secure pages for the site, you don't see a warning. You aren't
switching from an insecure web page to a secure web page. The form data
merely gets submitted to an HTTPS site but the next web page presented
to the browser is still an insecure web page (i.e., there was never any
switch between insecure and secure modes for the web pages presented to
the browser). With the standard non-secure eBay login, you don't see
that warning. Only if you opt to use the SSL-secured login page do you
then see the warning about subsequent navigation away form a secured
page to a non-secure pages.

> Which means they are actually establishing secure communication for
> transmitting logon credentials at all times. Yahoo! is different:
> they use Javascript on the client to send MD5 hash only.

That's maybe if you use their "standard" login. I don't bother with
their standard non-secure login page. Instead I use the following URL
in a shortcut to login to my Yahoo account:

    https://login.yahoo.com/config/login?.src=ym

Notice it uses https:// for a SSL-secured connection rather than rely on
a downloaded client-side interpreted javascript.

While the form's action has the data submitted to an HTTPS site, the
user won't know that. You won't know that, either, unless you
interrogate the HTML code for the login page you just received to ensure
they didn't change to where the data gets submitted. It seems stupid
and rude not to let the user know when they will have and not have a
secure login.

Relevant Pages

  • Re: Ace Password Sniffer : How does it work ?
    ... >> Another protocol that offers same is IPSec. ... >> authentication and secure transfer of data between server and client ... >> would be pretty hard to use SSL to secure data exchanged between ... Once you are done with the secured login, ...
    (microsoft.public.security)
  • LOGIN INFO secure at wwww.americanexpress.CA?
    ... secure page which causes the lock symbol to be displayed in the status ... That is the difference which caused the login page ... even though the page itself is not https. ... of a lock in the login region. ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: How do I protect my login page from prying eyes (forms authentication)?
    ... Sure, do this if you want to, but I'd rather devote time and energy to making my site secure even if someone discovers the "protected" site. ... Once it's out in the open (and if it's believed the contents are high valued, and people suspect that you've hidden the login page as a security measure), you may be *more* likely to be attacked. ... This means that when the site owner prints an invoice, the URL of this page will be shown in the footer. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Public Authentication Problem on Batch Job using SCP2 when SSH Client Reboot
    ... to a SSH server, HOST2. ... for secure ftp login. ... The login ID is a local user account ... we found that scp2 run failed every time the SSH client ...
    (comp.security.ssh)
  • Re: How to get rid of "You are about to leave a secure internet" msg
    ... "Warn if changing between secure and not secure mode." ... We use a feature of Citrix called anonymous logins whereby the user does ... The reason being since we use anonymous accounts to login to our citrix ... any settings are lost as well... ...
    (microsoft.public.windows.inetexplorer.ie6.browser)