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 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 www.acsac.org/2002/papers/classic-multics.pdf 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
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 www.acsac.org/2002/papers/classic-multics.pdf 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
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
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
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: snip 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 -- 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
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 currently (still)
