Re: AmEx unprotected login site
Perry E. Metzger wrote: When I go to the SSL protected page, I can look at the URL and the lock icon in the corner before typing in my password. Bless you for being so careful. I, instead, look at the logo of the site and of the CA as displayed in TrustBar. This is much easier, and protects me from subtle changes in the URL e.g. homographic attacks, from spoofed address bars, and from certificates granted without proper validation, e.g. `domain validated` certificates. I would expect each security expert to use TrustBar (or other appropriate browser or browser extension - but check they don't send each URL to their server). When you type in your password BEFORE the SSL connection, by the time you realize that it went to the wrong place, it is way too late. If you realize it at all. Phisher can easily make you unaware of this. I admit that not everyone will check the URL and the lock icon, but at least it is *possible* to train people to do the right thing on that. There is no way, effectively, to train people to be safe given the way that Amex is set up. And no way you can protect your users by a proxy or a local TrustBar installation, which, as argued above, can protect reasonably well even naive or unsuspecting users. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Perry E. Metzger wrote: Ben Laurie <[EMAIL PROTECTED]> writes: Perry E. Metzger wrote: "Steven M. Bellovin" <[EMAIL PROTECTED]> writes: They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. They're doing the wrong thing, and probably feel they have no choice. Setting up an SSL session is expensive; most people who go to their home page do not log in, and hence do not (to Amex) require cryptographic protection. That's why Citibank and most well run bank sites have you click on a button on the front page to go to the login screen. There are ways to handle this correctly. Why is this better? The button you click can just as easily take you to a site other than the one intended. When I go to the SSL protected page, I can look at the URL and the lock icon in the corner before typing in my password. When you type in your password BEFORE the SSL connection, by the time you realize that it went to the wrong place, it is way too late. I admit that not everyone will check the URL and the lock icon, but at least it is *possible* to train people to do the right thing on that. There is no way, effectively, to train people to be safe given the way that Amex is set up. But even if you have seen the lock and the URL, you are still vulnerable to homograph attacks and simply names that look right but aren't. I notice that AmEx have registered a _lot_ of names to make this hard, but even they don't win, for example: $ whois americanexpresscard.co.uk Domain Name: americanexpresscard.co.uk Registrant: Lantec Corporation Registrant's Address: 8 Copthall Roseau Commonwealth of Dominica 00152 DM Oops. Cheers, Ben. -- >>>ApacheCon Europe<<< http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Ben Laurie <[EMAIL PROTECTED]> writes: > Perry E. Metzger wrote: >> "Steven M. Bellovin" <[EMAIL PROTECTED]> writes: >> They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. >>> >>> They're doing the wrong thing, and probably feel they have no >>> choice. Setting up an SSL session is expensive; most people who go >>> to their home page do not log in, and hence do not (to Amex) >>> require cryptographic protection. >> That's why Citibank and most well run bank sites have you click on a >> button on the front page to go to the login screen. There are ways to >> handle this correctly. > > Why is this better? The button you click can just as easily take you > to a site other than the one intended. When I go to the SSL protected page, I can look at the URL and the lock icon in the corner before typing in my password. When you type in your password BEFORE the SSL connection, by the time you realize that it went to the wrong place, it is way too late. I admit that not everyone will check the URL and the lock icon, but at least it is *possible* to train people to do the right thing on that. There is no way, effectively, to train people to be safe given the way that Amex is set up. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
"R. Hirschfeld" <[EMAIL PROTECTED]> writes: >> From: "Perry E. Metzger" <[EMAIL PROTECTED]> >> Date: Wed, 08 Jun 2005 19:01:37 -0400 > >> The other major offender are organizations (such as portions of >> Verizon) that subcontract payment systems to third parties. They are >> training their users to expect to be directed to a site they don't >> recognize to enter in their credit card information. "Really! This is >> your vendor's payment site! Pay no attention to the URL and >> certificate!" >> >> That one in particular takes amazing brains... > > For Verizon maybe, but there are plenty of Mom and Pop internet > merchants for which it is arguably more secure to do it this way. The > merchant never sees the customer's payment information and thus > needn't know how to properly protect it, and one-time shoppers may not > know/trust the merchant anyway. If the redirect is from a secure > merchant site to a secure payment provider site, and the merchant site > informs users where they will be redirected, is this so bad? If the merchant site is secured by SSL, and prominently says that you will be redirected to a given provider, it is perhaps not so bad in theory. However, in practice, this fails the "simple rules my mom can follow" test. I'd rather that they hand a short term cert and DNS delegation to their processing partner. What I want to be able to do is tell my mom something dead simple, like "never enter your username and password or credit card information unless the web page is the one you are expecting, and it has the "lock icon" in the corner and the lock icon doesn't look like someone was faking it." Now, we face two major problems here. 1) Every complication you add on top of that means that you're training lots and lots of very naive users to do things that are potentially unsafe. Training users to expect to do unsafe things (like what Amex or what Verizon are doing) is bad, because then they won't notice in the future when they are asked to do something unsafe by a bad guy. Fidelity, to my mind, is a model of good user training. They have a set of very good web pages (see http://personal.fidelity.com/accounts/services/findanswer/content/security/minimize_risk.shtml and others) that give users excellent advice on never entering passwords in on pages that didn't arrive encrypted, never emailing personal information, etc. They allow customers to avoid ever exposing social security numbers to customer service reps, encourage users to use those services, etc. Their login page itself comes SSL encrypted. There may be other security problems they have, but encouraging users to do unsafe things isn't one of them. Now, here they (and I and others) go, trying hard to educate users about what the right thing is, and others go around forcing users to do the wrong thing just to get their day to day business done! After a while, people's defenses drop because they're being constantly trained to do the wrong thing. 2) The other issue is that the browser accepts certs from so many CAs, many of which have effectively no security. There are ways to fix this long term, but that is a whole separate discussion. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Ivars Suba responded to me: 1. This doesn't have any effect on non-SSL-protected sites (e.g. AmEx,... see `Hall of Shame`). And of course assumes users will notice the use of non-SSL-site... Vowww.. I didn't know that AmEx is not ssl protected ;)) Before user credentials are passed to site, site certificate are sent to client browser, then certificate are accepted/denied, ssl tunnel is established/access denied: As is clearly stated in messages you referred to, we all know Amex's site invoke SSL to encrypt the password. The problem is that a fake Amex site would not; and the user has no way to distinguish. Essentially, Amex site is secure against the (unlikely) eavesdropper, but not against the (much more likely) spoofer or the stronger (but possible) MITM. Is this site ssl proteceted? Shame Hall isn't so "shamy" ;) So, my claims in Hall of Shame remain. Or do you want to protect the Amex process? This will be interesting. ... Keep CA whitelist in SSL termination Proxy, and deny all others (including sef-signed site certs). You could of course do this filtering without also terminating the tunnel at your proxy. I agree that such filtering (without breaking the tunnel) is an advisable thing to do. 80% of users don't know what is the certificate. Imho, much better is trust this task to SSL termination proxy... I agree most users don't know what's a CA doing and what's a PK cert. But my intuition - and research - show that they can learn very quickly if we use simple words instead of jargon. In TrustBar, we display the name/logo of the site, followed by the words `identified by` and the name/logo of the CA. Our (limited) testing shows users understand this very well. And of course this does not prevent you from also blocking in a proxy any CAs you don't trust. Let the user decide among these you can't rule out. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Perry E. Metzger wrote: "Steven M. Bellovin" <[EMAIL PROTECTED]> writes: They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. They're doing the wrong thing, and probably feel they have no choice. Setting up an SSL session is expensive; most people who go to their home page do not log in, and hence do not (to Amex) require cryptographic protection. That's why Citibank and most well run bank sites have you click on a button on the front page to go to the login screen. There are ways to handle this correctly. Why is this better? The button you click can just as easily take you to a site other than the one intended. -- >>>ApacheCon Europe<<< http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Few comments on what Ivars Suba wrote: How to fight against phishing in organization enviroment? Quite easy- put SSL termination Proxy between client browser and SSL server: Sure, but: 1. This doesn't have any effect on non-SSL-protected sites (e.g. AmEx,... see `Hall of Shame`). And of course assumes users will notice the use of non-SSL-site... 2. This assumes that the problem is `untrusted site certificates`. Is it? Which CAs would you NOT accept anymore? In particular, would you now reject all `domain validated certificates` (about 25% of SSL sites I've heard)?? Much better imho to give the information to the user, possibly warning against (or blocking) certs from a CA you know to be bad. 3. This solution takes advantage of the fact that users don't have any idea which CA they trust... which is true but very bad, breaking the trust model. I think it is better to make the CA visible to the user (but in a way users can understand - I believe we have that with TrustBar). -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
> From: "Perry E. Metzger" <[EMAIL PROTECTED]> > Date: Wed, 08 Jun 2005 19:01:37 -0400 > The other major offender are organizations (such as portions of > Verizon) that subcontract payment systems to third parties. They are > training their users to expect to be directed to a site they don't > recognize to enter in their credit card information. "Really! This is > your vendor's payment site! Pay no attention to the URL and > certificate!" > > That one in particular takes amazing brains... For Verizon maybe, but there are plenty of Mom and Pop internet merchants for which it is arguably more secure to do it this way. The merchant never sees the customer's payment information and thus needn't know how to properly protect it, and one-time shoppers may not know/trust the merchant anyway. If the redirect is from a secure merchant site to a secure payment provider site, and the merchant site informs users where they will be redirected, is this so bad? Ray - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site (was encrypted tapes, was Re: Papersabout"Algorithm hiding" ?)
Ken, you are correct (see below). And in fact, if the page came from the right source (as validated by SSL and a secure browser extension such as TrustBar), I don't think there is any need to validate the source (which is impractical even for the geekest geek). After all, if a site is so clueless as to send you corrupted scripts, it may as well publish your password directly... Best, Amir Herzberg Ken Ballou wrote: > Unless I misunderstand, the problem is that I can not determine where my login information will go without examining the source of the login page. Sure, the form might be posted to a server using https. But, without examining the source of the login page, I won't be able to look at the certificate for the site to which my credentials have been sent until it's too late. It's still the case that if I retrieve the original login form via https, I have to examine the page source to see to which server the form will be posted. But I can examine the certificate of the site from which I got the form originally to determine whether this is a phishing attack. If the login form itself can be shown to have come from an AmEx server, I'm probably more comfortable trusting that my credentials are going to the right server. Do I completely misunderstand? - Ken . -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
"Perry E. Metzger" <[EMAIL PROTECTED]> writes: >"Steven M. Bellovin" <[EMAIL PROTECTED]> writes: >>>They're still doing the wrong thing. Unless the page was transmitted >>>to you securely, you have no way to trust that your username and >>>password are going to them and not to someone who cleverly sent you an >>>altered version of the page. >> >> They're doing the wrong thing, and probably feel they have no choice. >> Setting up an SSL session is expensive; most people who go to their .> home page do not log in, and hence do not (to Amex) require >> cryptographic protection. > >That's why Citibank and most well run bank sites have you click on a button >on the front page to go to the login screen. There are ways to handle this >correctly. I was just going to mention this myself because I've noticed local banks doing it, you click on some "log in for online banking" link and get to an HTTPS login page that's distinct from the HTTP main page. For Mozilla/Firefox users, grab a copy of the TargetAlert extension and you'll see this on the originating page, TargetAlert will tag the login link with the "opens in new window" indicator and the "HTTPS" indicator (the usual yellow padlock). When you've got TargetAlert installed, go to e.g. http://www.asbbank.co.nz/ to see this. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
"Steven M. Bellovin" <[EMAIL PROTECTED]> writes: >>That's why Citibank and most well run bank sites have you click on a >>button on the front page to go to the login screen. There are ways to >>handle this correctly. > > There's an attack there, too -- one can divert the link to the login > screen. Certainly, but at least then, the URL and the certificate won't point at Amex (or whomever). If you train your users properly, then they can avoid trouble even then. In the current case, by the time you see that there is a problem, it is too late. Furthermore, you're training your users to engage in a bad behavior. This is no different than Microsoft training their users to mindlessly open .exe files for years and years, only to reap the whirlwind when email viruses came along. The right behavior to encourage for people is "never enter in your userid and password for an important account on a page that you don't trust". They're training people to do the opposite. >>The other major offender are organizations (such as portions of >>Verizon) that subcontract payment systems to third parties. They are >>training their users to expect to be directed to a site they don't >>recognize to enter in their credit card information. "Really! This is >>your vendor's payment site! Pay no attention to the URL and >>certificate!" >> >>That one in particular takes amazing brains... >> > It's a tough problem: they want to outsource the payment processing, > but don't have the infrastructure to do so properly. They could delegate a "payments.verizon.com" DNS entry and hand the processor a "payments.verizon.com" certificate, with an expiry date quite similar to the date when their contract is up for renewal. I'd like to make my position on one thing here really clear, by the way. Since when is it considered acceptable to slack on fiduciary responsibility on the excuse that it is annoying and requires effort? No one would accept a bank saying "accounting is boring, and hard to do right, so we aren't going to keep track of your balance very well any more." No one would accept "we've decided that paying for a proper vault is expensive, so we're keeping your safe deposit box in the mens room." How is proper network security any different? This is a BANK. Keeping your money secure is what they are paid to do! Yes, it takes thought, planning, and some skill to have online security for a financial institution, but no one is obligated to own or run a bank. If you run a mortuary, you will have to deal with corpses. If you run a bank, you have to be mindful of security in handling money. As for merchants like Verizon, there is really no excuse for a for being unable to figure out how to process online credit card payments safely, whether on their own or through a contractor. No one obligates them to be in business, but if they're going to be, they have a duty to do things like keeping accurate customer accounts, paying their taxes, keeping track of who their shareholders are, and, yes, making sure that they deal with credit card acceptance non-hazardously. I know it is all a pain in the ass, but if one wants an easier life, one should be a subsistence farmer instead of a multinational corporation. Sure, I'd love not to have to deal with the annoying things I have to deal with, and I'd love not to have to pay my mortgage on time, and I'd love a pony and a mountain of gold. I'm an adult, though, so I accept that I can't have everything I want and I need to fulfill my obligations. Are we to expect less of AMERICAN EXPRESS? Of VERIZON? That's a non-starter as far as I'm concerned. If you want to have a life of excuses, you don't get to play with the grownups. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
In message <[EMAIL PROTECTED]>, "Perry E. Metzger" writes: > >"Steven M. Bellovin" <[EMAIL PROTECTED]> writes: >>>They're still doing the wrong thing. Unless the page was transmitted >>>to you securely, you have no way to trust that your username and >>>password are going to them and not to someone who cleverly sent you an >>>altered version of the page. >> >> They're doing the wrong thing, and probably feel they have no choice. >> Setting up an SSL session is expensive; most people who go to their >> home page do not log in, and hence do not (to Amex) require >> cryptographic protection. > >That's why Citibank and most well run bank sites have you click on a >button on the front page to go to the login screen. There are ways to >handle this correctly. There's an attack there, too -- one can divert the link to the login screen. > >The other major offender are organizations (such as portions of >Verizon) that subcontract payment systems to third parties. They are >training their users to expect to be directed to a site they don't >recognize to enter in their credit card information. "Really! This is >your vendor's payment site! Pay no attention to the URL and >certificate!" > >That one in particular takes amazing brains... > It's a tough problem: they want to outsource the payment processing, but don't have the infrastructure to do so properly. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
"Steven M. Bellovin" <[EMAIL PROTECTED]> writes: >>They're still doing the wrong thing. Unless the page was transmitted >>to you securely, you have no way to trust that your username and >>password are going to them and not to someone who cleverly sent you an >>altered version of the page. > > They're doing the wrong thing, and probably feel they have no choice. > Setting up an SSL session is expensive; most people who go to their > home page do not log in, and hence do not (to Amex) require > cryptographic protection. That's why Citibank and most well run bank sites have you click on a button on the front page to go to the login screen. There are ways to handle this correctly. The other major offender are organizations (such as portions of Verizon) that subcontract payment systems to third parties. They are training their users to expect to be directed to a site they don't recognize to enter in their credit card information. "Really! This is your vendor's payment site! Pay no attention to the URL and certificate!" That one in particular takes amazing brains... Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
In message <[EMAIL PROTECTED]>, "Perry E. Metzger" writes: > >Jerrold Leichter <[EMAIL PROTECTED]> writes: >> If you look at their site now, they *claim* to have fixed it: The login box > >> has a little lock symbol on it. Click on that, and you get a pop-up window >> discussing the security of the page. It says that although the page itself >> isn't protected, "your information is transmitted via a secure environment". >> >> No clue as to what exactly they are doing, hence if it really is secure. > >They're still doing the wrong thing. Unless the page was transmitted >to you securely, you have no way to trust that your username and >password are going to them and not to someone who cleverly sent you an >altered version of the page. > They're doing the wrong thing, and probably feel they have no choice. Setting up an SSL session is expensive; most people who go to their home page do not log in, and hence do not (to Amex) require cryptographic protection. A few years ago, I talked with someone who was setting up a system that really needed security. Given how few pages people would visit on the site, though, he estimated that it would increase his costs by a factor of about 15. (I didn't verify the numbers; I know from experience that he's competent and has his hear in the right place re security). --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site (was encrypted tapes, was Re: Papersabout "Algorithm hiding" ?)
Jerrold Leichter wrote: > | Perry makes a lot of good points, but then gives a wrong example re Amex > site > | (see below). Amex is indeed one of the unprotected login sites (see my > `I-NFL > | Hall of Shame`, http://AmirHerzberg.com/shame.html). However, Amex is one of > | the few companies that actually responded seriously to my warning on this > | matter. In fact, I think they are the _only_ company that responded > seriously > | - but failed to fix their site... I had an interesting discussion with their > | security and web folks, and my conclusions are: > | > | 1. These are serious people who understand technology and security > | reasonably well. They are aware of many attacks, including much more > | advanced spoofing attacks (that can foil even an expert user of a `regular` > | browser - by regular I mean without improved security indicators like > | provided by TrustBar). Unfortunately, they use this awareness to justify to > | themselves the lack of protection (`why should I put a lock when some people > | know how to break it?`) > | > | 4. Ultimately, what we have here is simply the `usability beats security` > | rule... > If you look at their site now, they *claim* to have fixed it: The login box > has a little lock symbol on it. Click on that, and you get a pop-up window > discussing the security of the page. It says that although the page itself > isn't protected, "your information is transmitted via a secure environment". > > No clue as to what exactly they are doing, hence if it really is secure. Unless I misunderstand, the problem is that I can not determine where my login information will go without examining the source of the login page. Sure, the form might be posted to a server using https. But, without examining the source of the login page, I won't be able to look at the certificate for the site to which my credentials have been sent until it's too late. It's still the case that if I retrieve the original login form via https, I have to examine the page source to see to which server the form will be posted. But I can examine the certificate of the site from which I got the form originally to determine whether this is a phishing attack. If the login form itself can be shown to have come from an AmEx server, I'm probably more comfortable trusting that my credentials are going to the right server. Do I completely misunderstand? - Ken - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: AmEx unprotected login site
Protected or not, AmericanExpress.com has multiple web vulnerabilities - I wouldn't log into it with a ten-foot pole :) -Lance -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Perry E. Metzger Sent: Wednesday, June 08, 2005 12:16 PM To: Jerrold Leichter Cc: Amir Herzberg; cryptography@metzdowd.com Subject: Re: AmEx unprotected login site Jerrold Leichter <[EMAIL PROTECTED]> writes: > If you look at their site now, they *claim* to have fixed it: The login box > has a little lock symbol on it. Click on that, and you get a pop-up window > discussing the security of the page. It says that although the page itself > isn't protected, "your information is transmitted via a secure environment". > > No clue as to what exactly they are doing, hence if it really is secure. They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Jerrold Leichter <[EMAIL PROTECTED]> writes: > If you look at their site now, they *claim* to have fixed it: The login box > has a little lock symbol on it. Click on that, and you get a pop-up window > discussing the security of the page. It says that although the page itself > isn't protected, "your information is transmitted via a secure environment". > > No clue as to what exactly they are doing, hence if it really is secure. They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site (was encrypted tapes, was Re: Papersabout "Algorithm hiding" ?)
| Perry makes a lot of good points, but then gives a wrong example re Amex site | (see below). Amex is indeed one of the unprotected login sites (see my `I-NFL | Hall of Shame`, http://AmirHerzberg.com/shame.html). However, Amex is one of | the few companies that actually responded seriously to my warning on this | matter. In fact, I think they are the _only_ company that responded seriously | - but failed to fix their site... I had an interesting discussion with their | security and web folks, and my conclusions are: | | 1. These are serious people who understand technology and security | reasonably well. They are aware of many attacks, including much more | advanced spoofing attacks (that can foil even an expert user of a `regular` | browser - by regular I mean without improved security indicators like | provided by TrustBar). Unfortunately, they use this awareness to justify to | themselves the lack of protection (`why should I put a lock when some people | know how to break it?`) | | 4. Ultimately, what we have here is simply the `usability beats security` | rule... If you look at their site now, they *claim* to have fixed it: The login box has a little lock symbol on it. Click on that, and you get a pop-up window discussing the security of the page. It says that although the page itself isn't protected, "your information is transmitted via a secure environment". No clue as to what exactly they are doing, hence if it really is secure. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site (was encrypted tapes, was Re: Papersabout "Algorithm hiding" ?)
Amir Herzberg wrote: 3. They did not actually spell out the problem in using SSL in the homepage (like eTrade, for instance). But I think I know the reason (they didn't confirm or deny). I think the reason is that they host their site; in particlar, when I tried accessing it via https, I got an Akamai certificate... [I don't think they liked this observation; now you are led to the unprotected site] This would appear to be an artefact. If you fetch the page you are redirected to (http://home.americanexpress.com/home/mt_personal.shtml) over HTTPS you'll find it is still an akamai server. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Amir Herzberg <[EMAIL PROTECTED]> writes: > Perry makes a lot of good points, but then gives a wrong example re > Amex site (see below). Amex is indeed one of the unprotected login > sites (see my `I-NFL Hall of Shame`, > http://AmirHerzberg.com/shame.html). However, Amex is one of the few > companies that actually responded seriously to my warning on this > matter. In fact, I think they are the _only_ company that responded > seriously - but failed to fix their site... [...] I'm surprised that they responded to you. I tried to get to respond to my inquiries about it for weeks without any success. I did get a nice letter from JP Morgan Chase telling me I was crazy and that there is no security problem on their site (which suffers from the same problem). I probably should publish it to assure the dismissal of the people responsible for sending it to me. > 2. They have a serious problem in using SSL in their homepage, and for >business reasons, they don't want to put the login on a different >page. Well, those "business reasons" are pretty obviously an incorrect balance of security and convenience, as I'm sure you would agree. The inconvenience of having to click one more button to get to your account is minimal -- almost unmeasurably small. The inconvenience of the company having to explain to tens of thousands of people that they've screwed them badly, along with all of the money lost, is substantially higher. One day they'll be paying that second inconvenience. Many other financial institutions get this right, by the way. Citigroup gets this right. If their customers can click onto another page, so can customers of American Express, Chase, etc. > below are the relevant parts of Perry's message... I think you'll > agree you picked wrong example. I don't agree. I think this is still a case of human frailty causing a security problem, rather than some sort of technological issue. If you know what the problem is and you decide not to do anything about it because you believe that "for business reasons" you shouldn't put the login on a separate page, you've got nothing to blame for your future security problems other than yourself. My point is simple. We have enough protocols, software, etc. to avoid most of the security issues we have to deal with at this point. Most of the remaining problem tends to be human beings. In this case, the human beings security people who know better but give in when management decides for what amounts to aesthetic reasons that it needs a login on the front page that isn't protected by SSL. > As I said, I agree with the above (and most of the removed stuff). > But below you jumped to the wrong conclusions. I disagree. I'll stand by most of what I said. >> Every company should be telling its users never to type in their >> credentials on a web page downloaded in the clear, but American >> Express and lots of other companies train their users to get raped, And they are indeed training their users to enter in security credentials on unsecure pages. >> and why do they do it? Not because they made some high level decision >> to screw their users. Not because they can't afford to do things >> right. It happens because some idiot web designer thought it was a And if in this one case it turns out that they did indeed make a high level decision to screw their users, so much the worse. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]