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.
