Re: An attack on paypal --> secure UI for browsers
> The solution to this is Palladium (NGSCB). > > You'd want each ecommerce site to download a Nexus Computing Agent into > the client. This should be no more difficult than downloading an Active-X > control or some other DLL. The NCA has a manifest file associated with it No shit? This is moronic. But then it reflects the impaired cognitive abilities of corpdrones in mintel. I pay for the "computer", and then all these corporations start downloading shit to my "computer" in order to make it safe for me to use it, right ? I am lay person and need to trust these people, as I am clueless about stuff they download. But their web page says it's good. This all happens *after* I buy the computer. So, to recap, I pay several $K for the "computer" and then have to customize it so that it becomes "safe". The computer, as malladium authenticates the computer. Why do I want $3,000 authentication token ? No, mintel making money is not the right answer. Try again. = end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Re: An attack on paypal
At 11:01 AM -0700 6/11/03, Major Variola (ret) wrote: >At 03:39 PM 6/10/03 -0700, Bill Frantz wrote: >>IMHO, the problem is that the C language is just too error prone to be >used >>for most software. In "Thirty Years Later: Lessons from the Multics >>Security Evaluation", Paul A. Karger and Roger R. Schell >> credit the use of PL/I >for >>the lack of buffer overruns in Multics. However, in the >Unix/Linux/PC/Mac >>world, a successor language has not yet appeared. > >What about Java? Apart from implementation bugs, its secure by design. Java is certainly an improvement for buffer overruns. (The last estimate I heard was that 1/3 of the penetrations were due to buffer overruns.) Java is still semi-intrepreted, so it is probably too slow for some applications. However Java is being used for server-side scripting with web servers, where the safety of the language is a definite advantage. Of course, when you cover one hole, people move on to others. Server-side Java is succeptable to SQL injection attacks for example. Cheers - Bill - Bill Frantz | Due process for all| Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. [EMAIL PROTECTED] | American way. | Los Gatos, CA 95032, USA
Re: An attack on paypal
At 03:39 PM 6/10/03 -0700, Bill Frantz wrote: >At 5:12 PM -0700 6/8/03, Anne & Lynn Wheeler wrote: >>somebody (else) commented (in the thread) that anybody that currently >>(still) writes code resulting in buffer overflow exploit maybe should be >>thrown in jail. Not a very friendly bug-submission mechanism :-) >IMHO, the problem is that the C language is just too error prone to be used >for most software. In "Thirty Years Later: Lessons from the Multics >Security Evaluation", Paul A. Karger and Roger R. Schell > credit the use of PL/I for >the lack of buffer overruns in Multics. However, in the Unix/Linux/PC/Mac >world, a successor language has not yet appeared. What about Java? Apart from implementation bugs, its secure by design. --- "and then you go to jail" is a bad error-handler for a protocol.
RE: An attack on paypal
> the lack of buffer overruns in Multics. However, in the > Unix/Linux/PC/Mac > world, a successor language has not yet appeared. Work on the existing C/C++ language will have a better chance of actually being used earlier. Not that it removes the problem entirely, but it should catches a lot of easy stack smashing bugs. http://gcc.gnu.org/projects/bp/main.html -- Vincent Penquerc'h
Re: An attack on paypal --> secure UI for browsers
Adam Lydick writes: > I'd guess that no applications (besides the secure nexus) would > have access to your "list of doggie names", just the ability to display > it. The list just indicates that you are seeing a window from one of > your partitioned and verified applications. I would also assume the > window would get decorated with the name of the trusted application (not > just your secret list). Thus you only need a single secret list to > handle all of your "authorized" applications. That makes sense. However it puts the burden onto the user to closely inspect his window frames in order to make sure that he is talking to the program (or NCA in Palladium) that he thinks he is talking to. It also introduces the problem of program-name spoofing; you might be given a dialog to enter your password for Paypa1 or E-Go1d. If users were that careful, we wouldn't have these kinds of problems in the first place.
Re: An attack on paypal --> secure UI for browsers
Joseph Ashwood writes: > Ok what flavor of crack are you smoking? Because I can tell from here that's > some strong stuff. Downloading random DLLs that are given complete access to > private information is one of the worst concepts that anyone has ever come > up with, even if they are signed by a "trusted" source. Just look at the > horrifically long list of issues with ActiveX, even with WindowsXP (which > hasn't been around that long) you're already looking at more than half a > dozen, and IIRC win95 had about 50. This has less to do with "windows is > bad" than with "secure programming is hard." Arbitrarily trusting anyone to > write a secure program simply doesn't work, especially when it's something > sophisticated. You clearly know virtually nothing about Palladium. NCAs do not have "complete access to private information". Quite the opposite. Rather, NCAs have the power to protect private information such that no other software on the machine can access it. They do so by using the Palladium software and hardware to encrypt the private data. The encryption is done in such a way that it is "sealed" to the particular NCA, and no other software is allowed to use the Palladium crypto hardware to decrypt it. In the proposed usage, an NCA associated with an ecommerce site would seal the data which is used by the user to authenticate to the remote site. The authentication data doesn't actually have to be a certificate with associated key, but that would be one possibility. Only NCAs signed by that ecommerce site's key would be able to unseal and access the user's authentication credentials. This prevents rogue software from stealing them and impersonating the user. > Now for the much more fundamental issue of your statement. Palladium will > never "download site-specific" anything. Palladium is a hardware technology, > not a web browser. If you read the entire message it was clearly referring to a Palladium-enabled web browser. And Palladium is more than a hardware technology; it includes hardware and software components. > I will refrain from saying Paladium is a bad idea, simply because I see some > potentially very lucrative (for me) options for it's use. Fine, at least you admit you're a whore. But you'll probably do even better if you learn how it actually works. Seriously, have you read any of the documents linked from http://www.microsoft.com/resources/ngscb/?
Re: An attack on paypal
James A. Donald wrote: > How many attacks have there been based on automatic trust of > verisign's feckless ID checking? Not many, possibly none. I imagine if there exists a https://www.go1d.com/ site for purposes of fraud, it won't be using a self-signed cert. Of course it is possible that the attackers are using http:// instead, but more people are likely to notice that. > That is not the weak point, not the point where the attacks > occur. If the browser was set to accept self signed > certificates by default, it would make little difference to > security. I don't think any currently can be - but regardless, an attacker wishing to run a fraudulent https site must have a certificate acceptable to the majority of browsers without changing settings - That currently is the big name CAs and nobody else.
Re: An attack on paypal --> secure UI for browsers
The problem to be solved is this. Spoofed sites can acquire user credentials, especially passwords, and then use those to impersonate the user on the real sites. With paypal and e-gold, this allows stealing real money. Using client certificates to authenticate would solve this, because even if the user got fooled and authenticated to the spoofed site, the attacker wouldn't learn the client cert secret key and so would not be able to masquerade as the user. The problem (among others) is that this allows a virus to steal the client cert. If it is protected by a password, the malware must hang around long enough for the user to unlock the cert (perhaps because the malware sent a spoofed email calling for the user to visit the site, even the real site!). It can then read the user's keystrokes and acquire the password. Now it has the cert and password and can impersonate the user at will. The solution to this is Palladium (NGSCB). You'd want each ecommerce site to download a Nexus Computing Agent into the client. This should be no more difficult than downloading an Active-X control or some other DLL. The NCA has a manifest file associated with it that contains the ecommerce site's signing key. This allows the NCA to be effectively locked to that key. The user's site-specific client certificate would be sealed to this NCA. That means that no other NCA could get access to the client cert for that site, nor could any legacy software. All this is protected by the Palladium hardware and software. If a password is used for further security, to unlock the client cert (in addition to the NCA-specific encryption), it can use a secure channel to the NCA so that no keystroke loggers can steal the password. (However, as mentioned in a previous mail, this may not stop rogue NCA's from fooling the user by pretending to be the ecommerce site's NCA and picking up the password. It's not clear that adding a password really increases security. Fortunately the NCA security itself is already vastly stronger than anything available on a PC today.) In short, if Palladium comes with the ability to download site-specific DLLs that can act as NCAs, it should allow for solving the spoofed-site problem once and for all. When you login to paypal or e-gold, you would authenticate yourself using a cert that only those sites could see. This can be done in the framework of standard SSL, but would require a Palladium-aware browser.
Re: An attack on paypal --> secure UI for browsers
It's simple. It solves the problem that Microsoft Salesmen have. In order to sell shit, you have to make it look like gold. Cee Eee Ohs have heard it said that Microsoft software is insecure crap. Now the Microsoft Salesmen can do fancy demos with pretty colors and slick Operators Are standing By, Act Now, *New*, Don't Delay, Improved, Secure, Bells Whistles and Coolness demos and sign the suckers up. Just like the wonderful ads that peppered NYC when Ex-Pee came out saying "Reliable, and Secure." --Kaos-Keraunos-Kybernetos--- + ^ + :25Kliters anthrax, 38K liters botulinum toxin, 500 tons of /|\ \|/ :sarin, mustard and VX gas, mobile bio-weapons labs, nukular /\|/\ <--*-->:weapons.. Reasons for war on Iraq - GWB 2003-01-28 speech. \/|\/ /|\ :Found to date: 0. Cost of war: $800,000,000,000 USD.\|/ + v + : The look on Sadam's face - priceless! [EMAIL PROTECTED] http://www.sunder.net On Tue, 10 Jun 2003, Nomen Nescio wrote: > I don't see how this is going to work. The concept seems to assume > that there is a distinction between "trusted" and "untrusted" programs. > But in the NGSCB architecture, Nexus Computing Agents (NCAs) can be > written by anyone. If you've loaded a Trojan application onto your > machine, it can create an NCA, which would presumably be eligible to > put up a "trusted" window. > > So either you have to configure a different list of doggie names for > every NCA (one for your banking program, one for Media Player, one for > each online game you play, etc.), or else each NCA gets access to your > Secret Master List of Doggie Names. The first possibility is unmanageable > and the second means that the trustedness of the window is meaningless. > > So what good is this? What problem does it solve?
Re: An attack on paypal --> secure UI for browsers
Take this with a grain of salt. I'm no expert. However: I'd guess that no applications (besides the secure nexus) would have access to your "list of doggie names", just the ability to display it. The list just indicates that you are seeing a window from one of your partitioned and verified applications. I would also assume the window would get decorated with the name of the trusted application (not just your secret list). Thus you only need a single secret list to handle all of your "authorized" applications. -AdamL On Mon, 2003-06-09 at 22:00, Nomen Nescio wrote: > I don't see how this is going to work. The concept seems to assume > that there is a distinction between "trusted" and "untrusted" programs. > But in the NGSCB architecture, Nexus Computing Agents (NCAs) can be > written by anyone. If you've loaded a Trojan application onto your > machine, it can create an NCA, which would presumably be eligible to > put up a "trusted" window. > > So either you have to configure a different list of doggie names for > every NCA (one for your banking program, one for Media Player, one for > each online game you play, etc.), or else each NCA gets access to your > Secret Master List of Doggie Names. The first possibility is unmanageable > and the second means that the trustedness of the window is meaningless. > > So what good is this? What problem does it solve? -- Adam Lydick <[EMAIL PROTECTED]>
Re: An attack on paypal
At 11:43 PM 6/8/2003 +0100, Dave Howe wrote: >HTTPS works just fine. >The problem is - people are broken. >At the very least, verisign should say "ok so '..go1d..' is a valid server >address, but doesn't it look suspiously similar to this '..gold..' site over >here?" for https://pseudo-gold-site/ - but really, if users are going to >fill in random webforms sent by email, they aren't going to be safe under >any circumstances; the thing could send by unsecured http to any site on the >planet, then redirect to the real gold site for a generic "transaction >completed" or even "failed" screen >A world where a random paypal hack like this one doesn't work is the same as >the world where there is no point sending out a Nigerian as you will never >make a penny on it - and yet, Nigerian is still profitable for the con >artists. in a world where there are repeated human mistakes/failures at some point it is recognized that people aren't perfect and the design is changed to accommodate peoples foibles. in some respects that is what helmets, seat belts, and air bags have been about. in the past systems have designed long, complicated passwords that are hard to remember and must be changed every month. that almost worked when i person had to deal with a single shared-secret. when it became a fact of life that a person might have tens of such different interfaces it became impossible. It wasn't the fault of any specific institution, it was a failure of humans being able to deal with large numbers of extremely complex, frequently changing passwords. Because of known human foibles, it might be a good idea to start shifting from an infrastructure with large numbers of shared-secrets to a non-shared-secret paradigm. at a recent cybersecurity conference, somebody made the statement that (of the current outsider, internet exploits, approximately 1/3rd are buffer overflows, 1/3rd are network traffic containing virus that infects a machine because of automatic scripting, and 1/3 are social engineering (convince somebody to divulge information). As far as I know, evesdropping on network traffic doesn't even show as a blip on the radar screen. In the following thread on a financial authentication white paper: http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper there is point made that X9.59 standard doesn't directly address the Privacy aspect of security (i.e. no encryption or hiding of data). However, the point is made that it changes the paradigm so that the financial account number no longer represents a shared-secret and that it can be supported with two-factor authentication i.e. "something you have" token and "something you know" PIN. The "something you know" PIN is used to enable the token, but is not a shared secret. Furthermore, strong authentication can be justification for eliminating the need for name or other identification information in the transaction. However, if X9.59 strong authentication is used with two-factor authentication and no identification information is necessary then it would make people more suspicious if privacy information was requested. Also, since privacy information is no longer sufficient for performing a fraudulent transaction, it might mitigate that kind of social engineering attack. The types of social engineering attacks then become convincing people to insert their hardware token and do really questionable things or mailing somebody their existing hardware token along with the valid pin (possibly as part of an exchange for replacement). The cost/benefit ratio does start to change since there is now much more work on the crooks part for the same or less gain. One could also claim that such activities are just part of child-proofing the environment (even for adults). On the other hand, it could be taken as analogous to designing systems to handle observed failure modes (even when the failures are human and not hardware or software). Misc. identify theft and credit card fraud reference: http://www.consumer.gov/idtheft/cases.htm http://www.usdoj.gov/criminal/fraud/idtheft.html http://www.garlic.com/~lynn/aadsm14.htm#22 Identity Theft Losses Expect to hit $2 trillion http://www.garlic.com/~lynn/subpubkey.html#fraud Slightly related in recent thread that brought up buffer overflow exploits http://www.garlic.com/~lynn/2003j.html#4 A Dark Day and the report that multics hasn't ever had a buffer overflow exploit http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation somebody (else) commented (in the thread) that anybody that
Re: An attack on paypal
James A. Donald wrote: > Attached is a spam mail that constitutes an attack on paypal similar > in effect and method to man in the middle. > > The bottom line is that https just is not working. Its broken. HTTPS works just fine. The problem is - people are broken. At the very least, verisign should say "ok so '..go1d..' is a valid server address, but doesn't it look suspiously similar to this '..gold..' site over here?" for https://pseudo-gold-site/ - but really, if users are going to fill in random webforms sent by email, they aren't going to be safe under any circumstances; the thing could send by unsecured http to any site on the planet, then redirect to the real gold site for a generic "transaction completed" or even "failed" screen A world where a random paypal hack like this one doesn't work is the same as the world where there is no point sending out a Nigerian as you will never make a penny on it - and yet, Nigerian is still profitable for the con artists.
Re: An attack on paypal
At 02:55 PM 6/8/2003, James A. Donald wrote: Attached is a spam mail that constitutes an attack on paypal similar in effect and method to man in the middle. The bottom line is that https just is not working. Its broken. The fact that people keep using shared secrets is a symptom of https not working. The flaw in https is that you cannot operate the business and trust model using https that you can with shared secrets. I don't think it's https that's broken, since https wasn't intended to solve the customer authentication / authorization problem (you could try to use SSL's client certificates for that, but no one ever intended client certificate authentication to be a generalized transaction problem). When I responded to this before, I thought you were talking about the server auth problem, not the password problem. I continue to feel that the server authentication problem is a very hard problem to solve, since there's few hints to the browser as to what the user's intent is. The password problem does need to be solved, but complaining that HTTPS or SSL doesn't solve it isn't any more relevant than complaining that it's not solved by HTML, HTTP, and/or browser or server implementations, since any and all of these are needed in producing a new solution which can function with real businesses and real users. Let's face it, passwords are so deeply ingrained into people's lives that nothing which is more complex in any way than passwords is going to have broad acceptance, and any consumer-driven company is going to consider "easy" to be more important that "secure". Right now, my best idea for solving this problem is to: - Standardize an HTML input method for which does an SPEKE (or similar) mutual authentication. - Get browser makers to design better ways to communicate to users that UI elements can be trusted. For example, a proposal I saw recently which would have the OS decorate the borders of "trusted" windows with facts or images that an attacker wouldn't be able to predict: the name of your dog, or whatever. (Sorry, can't locate a link right now, but I'd appreciate one.) - Combine the two to allow sites to provide a user-trustable UI to enter a password which cannot be sucked down. - Evangelize to users that this is better and that they should be suspicious of any situation where they used such interface once, but now it's gone. I agree that the overall architecture is broken; the problem is that it's broken in more ways than can just be fixed with any change to TLS/SSL or HTTPS. - Tim
