LOGIN INFO secure at wwww.americanexpress.CA?

On Mar 15, 9:59 pm, Gary Smith <bitbuc...@xxxxxxxxxxx> wrote:
Mister.Fred...@xxxxxxxxx wrote:
On Mar 14, 7:41 pm, Gary Smith <bitbuc...@xxxxxxxxxxx> wrote:
...When I typewww.americanexpress.com inthe
address bar and press enter, I'm immediately redirected tohttps://home.americanexpress.com/home/mt_personal.shtml, which is secure
by virtue of the "https" protocol. That's where the login boxes are, on a
secure page which causes the lock symbol to be displayed in the status
bar. Does that not happen for you?

Yes, it does. I missed the part where you use .com as the suffix
rather than .ca. That is the difference which caused the login page
to be secure. Weird, eh?

I suspect that the difference is in the waywww.americanexpress.ca is set
up. Evidently the target of its redirect is not a secure page. I'll call
that a page construction error

I'm not an web-type person, but perhaps that login region is somehow
made secure, even though the page itself is not https. It has been
speculated among office people that this is hinted at by the picture
of a lock in the login region. To me, this way of setting up the web
page has 2 drawbacks.

First, it isn't clear whether the speculation is even true. For
example, the intended message might be that the session is secure
*after* login (which is true, since it becomes https after login).
It's hard to tell from a simple icon.

Second, even if it was true, the use of a non-https page removes all
the standard security indicators that a (duly diligent) user is taught
to look for -- namely, the https on the URL, and the lock at the
corner if IE (or whatever the equivalent is for firefox, since that's
what I normally use). Due diligence, therefore, requires a user to
not use that page.

Amex front line support is reluctant to even recognize the problem and
escalate it, though I did insist. Their position is that they "try
hard" to make "things" secure (though they couldn't say how) and if I
didn't like it, I shouldn't use it. Since this boils down to
inaccessibility to online services, I appreciate your pointing out
the .com alternative, which doesn't have this problem.

2nd line support left me a voicemail assuring me that he went through
a session, and all was secure. No mention was made of the fact that
the particular point of concern was securing the login info itself, as
well as the clear indication of having done so using standard security
indicators. So it isn't clear that the problem was properly
communicated; I would tend to think not, based on the misunderstanding
at front line support. An erroneous return phone number was
provided. The frustrating thing is that there is no email address to
raise this issue in documented manner, including documentation of the
tenuous communication. Hopefully, their anti-phishing email address
(the only one I can find) will forward this message to the right
department.

The surprising thing is that most users I spoke to didn't even notice
the problem because they don't pay attention to the security aspect,
particularly at login (or they had faith in the picture of the lock in
the login region, and decided to forgo the standard indicators). This
means there will be very little demand for a change to bring it in
line with standard security indicators.

In any case, I believe that I've done what I can to respond to the
issue, and I now leave it in their capable hands. Thanks once again
for pointing out the properly coded .COM webpage so that I can avoid
the problem on the .CA webpage.

Fred

Fred

.

Relevant Pages

  • Re: Secure Login Form
    ... HTTPS should definitely be used, this web form isn't secure otherwise ... I'd recommend php, as it's server side so you are processing ... login form. ...
    (Security-Basics)
  • Re: https-Question
    ... If the form is submitted to a HTTPS address then the form data will arrive securely, but there is another issue with using insecure login pages like this. ... It's good practice to have both the login page and the page you submit to fully secure ...
    (comp.infosystems.www.authoring.html)
  • Re: Passing data from a http page to https page. Is it secure?
    ... Theoretically, yes, it's secure. ... https to begin with. ... Yahoo Login page has 2 modes Standard and Secure. ... > standard mode the login page was an http one, but the data is being posted ...
    (microsoft.public.vsnet.general)
  • Re: Is .NET Passport credential traffic secure?
    ... my point is that you must FIRST establish a secure connection to ... user instead of making the login page itself secured with SSL so the ... The "Sign In" page at eBay submits the form data ... HTTPS site: Allowing the site to generate the HTML content in the page ...
    (microsoft.public.security)
  • 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)