Re: An attack on paypal
At 08:15 PM 6/18/2003 -0400, Ian Grigg wrote: Certificate caching is a far more powerful idea than, say, CA-signed certs. If it were added to browsers, and servers initialised with self- signed certs, then the security of the net would go up immensely. Integrated with some of the ideas that people have suggested concerning WoT, publically distributed certs, and individualised displays (amounting to local secrets keyed on the cert), we could actually start to see people using secured browsing when they wanted to rather than when they were forced to. typically certificates have had two characteristics 1) asn.1 encoding for network interoperability distribution and 2) trusted third party binding of some information to the public key self-signed certificate caching is really loading public key into a locally maintained table. in principal there is no need to maintain asn.1 encoding format in a locally maintained table since it eliminates having to decode it on every use and the asn.1 encoding is only useful if you 1) are planning on redistributing somebody else's public key and 2) need the original bit format for validating the self-signed signature. The validating of the self-signed signature can be done on initially acquiring the certificate and then it can be decoded, and the decoded values loaded into the table. the table/database just becomes entries of public keys and the associated attributes (which might be a combination of the original plus any additional that you might want to add along the way). in that sense it becomes more of authentication management along the lines of kerberos, radius, and/or the AAA RFCs, aka authentication, authorization, and accounting. in previous posts about BBB, it is possible that it would be used in combination with online trusted references i.e. analogous to real-time call to BBB and obtaining referrels and any complaint information ... and then possibly remembering it by recording it in the table (aka online trust propogation as opposed to the offline trust propogation represented by TTP certificates). Part of the issue with the offline TTP stale, static certificate model was that it periodically tried to overload the contents of the certificate trying to justify the expense of the ceritifcate to the public key owner but having little or no idea what might be the future requirements of a broad range of relying parties. A locally maintained relying-party table/database would allow the relying party to dynamically adapt the trust characteristics that they were interested in. Decoding the self-signed certificate before loading into the local table helps highlight that the recorded trust characteristics don't have to be restricted to just those that happen to exist in the stale, static certificate (created at some time in the past by entities that had no anticipation regarding your specific trust requirements). past discussions of online & offline trust propogation: http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II) http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP http://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia addenda) http://www.garlic.com/~lynn/aadsm14.htm#42 An attack on paypal http://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#4 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps http://www.garlic.com/~lynn/aepay11.htm#7 FTC says incidence of ID theft jumped in 2002 http://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group http://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ? -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
Matthew Byng-Maddick wrote: > > On Fri, Jun 13, 2003 at 04:32:12PM -0700, Bill Stewart wrote: > > An e-gold-specific or paypal-specific client can tell, > > because it can remember that it's trying to see the real thing, > > but the browser can't tell, except by bugging you about > > "Hi, this is a new site that's giving us a new cert" placebo box. > > Don't knock this warning, it might be enough of an indication to the user > that something is not quite right. "But I've logged into e-gold before, > and it never said this...". It certainly should be. In most browsers, > though, there isn't even that, by default, at least, IMLE. It's certainly enough - IMHO - to take the wind out of the sails of the current rash of pirates. If the "placebo box" were to present the number of times connected, and showed this in a graphical fashion, I think it would be something ordinary users would understand. E.g., bright and bold and pulsing for 1st time, with a big frowny face and the number 1. Warm and fuzzy for 10th time, with a big 10 and a smiley face. It might even put the fun back into browser programming :-) Certificate caching is a far more powerful idea than, say, CA-signed certs. If it were added to browsers, and servers initialised with self- signed certs, then the security of the net would go up immensely. Integrated with some of the ideas that people have suggested concerning WoT, publically distributed certs, and individualised displays (amounting to local secrets keyed on the cert), we could actually start to see people using secured browsing when they wanted to rather than when they were forced to. It might even raise the stock of the profession above the current "maybe it's all snake oil" rating that some skeptics have applied :-) (Oddly enough, the market for CA-signed certs would also increase, and the factory signers would make a killing, but that's a rant for another day.) -- iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
On Fri, Jun 13, 2003 at 04:32:12PM -0700, Bill Stewart wrote: > An e-gold-specific or paypal-specific client can tell, > because it can remember that it's trying to see the real thing, > but the browser can't tell, except by bugging you about > "Hi, this is a new site that's giving us a new cert" placebo box. Don't knock this warning, it might be enough of an indication to the user that something is not quite right. "But I've logged into e-gold before, and it never said this...". It certainly should be. In most browsers, though, there isn't even that, by default, at least, IMLE. MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
At 02:24 PM 06/11/2003 -0700, David Honig wrote: At 12:42 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote: >actually, if you had a properly secured DNS then you could trust DNS >to distribute public keys bound to a domain name in the same way they >distribute ip-addresses bound to a domain name. ... Adding PKeys to Yellow Pages merely lets you get scammed *confidentially*. Unfortunately, that doesn't help you against wetware attacks - the "paypa1.com" and "e-g0ld.com" web sites can have valid certs, and your browser is unlikely to notice that they're different from the certs at the sites "paypal.com" and "e-gold.com" because they've got different domain names. So it won't notice that the certs have changed, because they haven't, they're just the new certs for the new websites. And client-side certs won't help, because the bogus sites can happily accept them or ignore them. An e-gold-specific or paypal-specific client can tell, because it can remember that it's trying to see the real thing, but the browser can't tell, except by bugging you about "Hi, this is a new site that's giving us a new cert" placebo box. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
> as in previous observations having a domain name owner register their > public key in the internet registry (domain name infrastructure or > ip-address registery) starts to lesson the requirement for having SSL > domain certificates. Yes; this is why (I think) VeriSign bought Network Solutions. Then no matter who wins the tussle over which infrastructure certifies peoples' keys, VeriSign will own it. Of course, canny spooks at SAIC extracted billions of dollars from VeriSign for this privilege...after extracting hundreds of millions from gullible public investors, and extracting more from domain users via their official government approved monopoly... John - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
The problem with these stop crackers and hackers by law is that it allows
software developers to get away with leaving huge gaping security holes
unfixed. Anecodatal evidence: The classic well known Robin Hood and Friar
Tuck "hack".
These days, the bug wouldn't get fixed and the guys reporting it would
wind up in jail because they "convinced" the OS authors to fix the
bug. IMHO, not the right way to go at all.
from http://ftp.arl.mil/ftp/unix-wizards/V16%23017
scroll down a bit more than half way down the page (also available from
most other GNU sources)
Back in the mid-1970s, several of the system support staff at
Motorola discovered a relatively simple way to crack system
security on the Xerox CP-V timesharing system. Through a simple
programming strategy, it was possible for a user program to trick
the system into running a portion of the program in `master mode'
(supervisor state), in which memory protection does not apply. The
program could then poke a large value into its `privilege level'
byte (normally write-protected) and could then proceed to bypass
all levels of security within the file-management system, patch the
system monitor, and do numerous other interesting things. In
short, the barn door was wide open.
Motorola quite properly reported this problem to Xerox via an
official `level 1 SIDR' (a bug report with an intended urgency of
`needs to be fixed yesterday'). Because the text of each SIDR was
entered into a database that could be viewed by quite a number of
people, Motorola followed the approved procedure: they simply
reported the problem as `Security SIDR', and attached all of the
necessary documentation, ways-to-reproduce, etc.
The CP-V people at Xerox sat on their thumbs; they either didn't
realize the severity of the problem, or didn't assign the necessary
operating-system-staff resources to develop and distribute an
official patch.
Months passed. The Motorola guys pestered their Xerox
field-support rep, to no avail. Finally they decided to take
direct action, to demonstrate to Xerox management just how easily
the system could be cracked and just how thoroughly the security
safeguards could be subverted.
They dug around in the operating-system listings and devised a
thoroughly devilish set of patches. These patches were then
incorporated into a pair of programs called `Robin Hood' and `Friar
Tuck'. Robin Hood and Friar Tuck were designed to run as `ghost
jobs' (daemons, in UNIX terminology); they would use the existing
loophole to subvert system security, install the necessary patches,
and then keep an eye on one another's statuses in order to keep the
system operator (in effect, the superuser) from aborting them.
One fine day, the system operator on the main CP-V software
development system in El Segundo was surprised by a number of
unusual phenomena. These included the following:
* Tape drives would rewind and dismount their tapes in the
middle of a job.
* Disk drives would seek back and forth so rapidly that they
would attempt to walk across the floor (see {walking drives}).
* The card-punch output device would occasionally start up of
itself and punch a {lace card}. These would usually jam in
the punch.
* The console would print snide and insulting messages from
Robin Hood to Friar Tuck, or vice versa.
* The Xerox card reader had two output stackers; it could be
instructed to stack into A, stack into B, or stack into A
(unless a card was unreadable, in which case the bad card was
placed into stacker B). One of the patches installed by the
ghosts added some code to the card-reader driver... after
reading a card, it would flip over to the opposite stacker.
As a result, card decks would divide themselves in half when
they were read, leaving the operator to recollate them
manually.
Naturally, the operator called in the operating-system developers.
They found the bandit ghost jobs running, and X'ed them... and were
once again surprised. When Robin Hood was X'ed, the following
sequence of events took place:
!X id1
id1: Friar Tuck... I am under attack! Pray save me!
id1: Off (aborted)
id2: Fear not, friend Robin! I shall rout the Sheriff
of Nottingham's men!
id1: Thank you, my good fellow!
Each ghost-job would detect the fact that the other had been
killed, and would start a new copy of the recently slain program
within a few milliseconds. The only way to kill both ghosts was to
kill them simultaneously (very difficult) or to deliberately crash
the system.
Finally, the system programmers
Re: An attack on paypal
> IE checks the server name against each CN's individually. I found that by experimentation too. I have VBScript sample on how to generate such a CSR request for IIS using the CryptoAPI. Furthermore, IE does not care if the CNs have different domains. e.g. /CN=www.domain.com/CN=www.domain.net/CN=www.domain.org -or even- /CN=www.domain.com/CN=www.cypherpunks.com/CN=www.microsoft.com You can self-sign such a cert with OpenSSL just fine. Whether you can get a real CA to sign such a thing is another matter. Adam - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
--- "James A. Donald" <[EMAIL PROTECTED]> wrote: > -- > On 11 Jun 2003 at 20:07, Steven M. Bellovin wrote: > > Let me point folk at http://www.securityfocus.com/news/5654 > > for a related issue. To put it very briefly, *real* > > authentication is hard. > > I don't think so. > > Verisign's authentication is notoriously worthless and full of > holes, yet very few attacks have been based on getting > certificates issued to wrong party, or on stealing poorly > defended and readily accessible certificates, even though that > is quite easy to do. On the whole PKI as used today is fairly useless. I mean just because Company A signed/issued me a key doesn't mean I'm a nice guy nor a legit business. All it means is I paid money to have another company sign my key. What *would* be more useful is a model of web-o-trust. E.g. you make up your own key. Then you import public keys from third-party auditors you trust. Overtime the auditors will visit the business and if they like it they will sign the key. So say you trust auditors A, B and C and I trust auditors B, C and D. Well chances are if company Z is good the will be audited by at least one of the auditors we have in common. Unfortunately there is easy corruption in this model so you would have to keep tabs on your auditor yourself. However, in this model it wouldn't cost money [hey everything net-related should cost money right?] and would actually be meaningful. Tom __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
-- On 11 Jun 2003 at 20:07, Steven M. Bellovin wrote: > Let me point folk at http://www.securityfocus.com/news/5654 > for a related issue. To put it very briefly, *real* > authentication is hard. I don't think so. Verisign's authentication is notoriously worthless and full of holes, yet very few attacks have been based on getting certificates issued to wrong party, or on stealing poorly defended and readily accessible certificates, even though that is quite easy to do. One of the scams described in the paper you cite was the old "www.e-go1d.com" scam, but done using paper, rather than the internet -- the scammers registered a company name similar that of a target company owning a large block of IP addresses, and printed letter head paper similar to that of the other company. The problem was not that authentication was hard. Passwords would have sufficed. Self signed public keys would have worked even better. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG NoFj3E7m34BUCZIG2feG13OK1W+zx+gF7GsDX+Fm 40IAMrSyeCwPFMzRybwYkgWLZ2JE97Ao595KgemVp - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
At 05:34 PM 6/11/2003 -0700, David Honig wrote: When I buy $20 of gas with non-bearer credentials (ie, credit card), the vendor does a real-time check on me. Seems fair/useful to be able to do same on them. I suppose eBay's feedback suffices... if their last N "feedbacks" are negative, I might go elsewhere. we sort of tried that ... however the financial justification sort of fell apart. the big thing about BBB is being able to trust some merchant that you have absolutely no knowledge about. However, the actual buying patterns are extremely skewed ... with well over 80 percent of the transactions either repeat or with some organization that there is other avenues of trust propagation and involving a very small number of very large merchants. The BBB model tends to work with higher value, infrequent transaction. The remaining online, merchant market segment not covered via other trust processes, tended to represent a small percentage of total transactions, spread over a very large population of very small merchants, and frequently low value. eBay is an attempt to provide an alternative delivery for such market segment and the issue is how does eBay operations break even financially on a BBB like offering. The first filter is to quickly catch major scamming operations ... and differentiate between the one-off transactions. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
At 03:38 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote: even before e-commerce, the real >BBB process was that people called up the BBB and got realtime information > i.e. it was an online, realtime process. > >the equiivalent for an online, internet paradigm (as opposed to something >left over from the offline email genre of at least 10--15 years earlier) >was that the browswer tab;e pf trusted entities were of online authorities >(as opposed to certificate manufacturing) and if you cared, you clicked >thru to the BBB and got realtime information about the merchant in question >(being equivalent to when people call the BBB to actually get some level of >real input as opposed to just a fuzzy comfort fealing). When I buy $20 of gas with non-bearer credentials (ie, credit card), the vendor does a real-time check on me. Seems fair/useful to be able to do same on them. I suppose eBay's feedback suffices... if their last N "feedbacks" are negative, I might go elsewhere. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
> "Matt Crawford" <[EMAIL PROTECTED]> writes: > >... Netscrape ind Internet Exploder each have a hack for > >honoring the same cert for multiple server names. Opera seems to honor at > >least one of the two hacks, and a cert can incorporate both at once. > > > > /C=US/ST=Illinois/L=Batavia/O=Fermilab/OU=Services > > /CN=(alpha|bravo|charlie).fnal.gov/CN=alpha.fnal.gov > > /CN=bravo.fnal.gov/CN=charlie.fnal.gov > > Just to clarify this, so you need a multivalued CN, with one containing the > expression "(a|b|c)" and the remaining containing each of "a", "b", and "c"? > Is it multiple AVAs in an RDN, or multiple RDNs? (Either of these could be > hard to generate with a lot of software, which can't handle multiple AVAs in > an RDN or multiple same-type RDNs). Which hack is for MSIE and which is for > Netscape? Each CN is in a single-element RDN as usual. Netscape honors only the first CN in the SubjectDN, but will treat it as a restricted regex (shell-like * wildcard, alternation and grouping). IE checks the server name against each CN's individually. This was mainly determined by experimentation. I think we did find a limit on how long that first regex could be, but I don't remember what it was. Longer than my example, but short enough that some of our bigger virtual-hosting servers were inconvenienced by it. Openssl has no qualms about multiple same-type components. You just have to use the somewhat documented 0.commonName = ... 1.commonName = ... 2.commonName = ... in the configuration file. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
> You can also use *.fnal.gov Yes, we know, but our in-house CA operator (me) won't issue such a certificate. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
Steven M. Bellovin wrote: > Let me point folk at http://www.securityfocus.com/news/5654 > for a related issue. To put it very briefly, *real* authentication is > hard. It may be that real authentication is hard, but the unbelievably sloppy practices of domain name registrars doesn't prove the case. Imagine if property ownership were recorded with the same degree of rigor. "I'm sorry, sir, but you don't own your house any more. We received a typewritten letter with your name on it saying you were transferring ownership to ShoppingMall Inc. The demolition teams are moving in, and I'm afraid you'll have to be out by Friday." Domain names are handled carelessly while real estate is not, due to many factors. Probably one of the main ones is the relative immaturity of the domain name system compared to the centuries of experience we have evolving mechanisms to deal with real property. Clearly the registrars are making little or no effort to authenticate domain name transfers at present. At one time you could specify that only messages signed with a given PGP key would authorize a transfer, but that precaution has apparently disappeared, no doubt due to lack of interest and the costs of support. Maybe this could be something that a registrar could use to differentiate itself from the many otherwise-identical competitors in the market: we won't let your domain names get stolen. What a novel concept. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
"Matt Crawford" <[EMAIL PROTECTED]> writes: >True as written, but Netscrape ind Internet Exploder each have a hack for >honoring the same cert for multiple server names. Opera seems to honor at >least one of the two hacks, and a cert can incorporate both at once. > > /C=US/ST=Illinois/L=Batavia/O=Fermilab/OU=Services > /CN=(alpha|bravo|charlie).fnal.gov/CN=alpha.fnal.gov > /CN=bravo.fnal.gov/CN=charlie.fnal.gov Just to clarify this, so you need a multivalued CN, with one containing the expression "(a|b|c)" and the remaining containing each of "a", "b", and "c"? Is it multiple AVAs in an RDN, or multiple RDNs? (Either of these could be hard to generate with a lot of software, which can't handle multiple AVAs in an RDN or multiple same-type RDNs). Which hack is for MSIE and which is for Netscape? Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
At 08:07 PM 6/11/2003 -0400, Steven M. Bellovin wrote: Let me point folk at http://www.securityfocus.com/news/5654 for a related issue. To put it very briefly, *real* authentication is hard. "real" authentication is actually that hard; it is "identification" that tends to really get sticky. one of the reasons for simplified security taxonomy like PAIN or PAIIN ... aka Privacy Authentication Identification Integrity Non-repudation 3-factor authentication is something you have (like a token) something you know (like password) something you are (like biometrics) In the past, I've posted regarding proposals for implementing authentication techniques in association with various internet operation registries in part because they are currently relying primarily on identification which is easily spoofed. the previous posts highlight the domain name take-over exploits using the same techniques used in the referenced article for ip-address take-over. the issue for SSL domain name certificates and people concerned about the integrity of the domain name infrastructure is that the certification authorities aren't the authoritative reference for the information that they are certifying it is the domain name infrastructure (and similarly the ip-address registry). The domain name take-overs have been very similar to the described techniques in the article for ip-address take-over. Somewhat the CA industry proposal is for the registries to implement public key registration at the same time the domain name (or ip-address) is registered. The public key is registered in the registry account record and all future interaction is done via authenticated signed transactions (authenticated using the public key in the registry account record). The claim regarding the operation of the internet operational registries is that they are effectively non-authenticated in much the same way that current credit card transactions are not authenticated. The x9.59 standard is for all electronic retail payments and are authenticated using a public key registered in the account record. This is effectively the some proposal (somewhat instigated by the certification authority industry) for transitioning the internet registries from non-authenticated transactions to authenticated transactions (by using digitally signed messages that are authenticated with public key registered in the corresponding registry account record). as in previous observations having a domain name owner register their public key in the internet registry (domain name infrastructure or ip-address registery) starts to lesson the requirement for having SSL domain certificates. random past posts regarding irony/catch22 for the CAs and SSL domain name certificates: http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto? http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form) http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ? http://www.garlic.com/~lynn/2001l.html#22 Web of Trust http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me http://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification http://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure? http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack http://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack http://www.garlic.com/~lynn/2003d.html#29 SSL questions http://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface http://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
Let me point folk at http://www.securityfocus.com/news/5654 for a related issue. To put it very briefly, *real* authentication is hard. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal (trivia addenda)
somewhat related to the early posting in this m.l. about distributed computing systems conference and possible interest from security and cryptography sections. when my wife and I were doing ha/cmp http://www.garlic.com/~lynn/subtopic.html#hacmp we were working with two people in the following meeting in ellison's conference room http://www.garlic.com/~lynn/95.html#13 who the following year, left and joined a small client/server startup and were responsible for something called the commerce server (the company also had this thing called https/SSL). we then worked with these two people on the implementation for payments for the thing called the commerce server and well as the infrastructure regarding trusting online merchants (as part of promoting this whole thing that came to be called electronic commerce): http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 and more recent posting in the same thread that I had also posted about buffer overflows and the multics study: http://www.garlic.com/~lynn/2003j.html#15 A Dark Day in any case, one of the jokes has been there are actually only 200 people in the industry. in any case, back to the recent related thread on distributed system operation: http://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats http://www.garlic.com/~lynn/2003i.html#72 A few Z990 Gee-Wiz stats http://www.garlic.com/~lynn/2003j.html#3 A few Z990 Gee-Wiz stats http://www.garlic.com/~lynn/2003j.html#7 A few Z990 Gee-Wiz stats and past posts discussing the BBB aspects for online electronic commerce: http://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group http://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II) http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP http://www.garlic.com/~lynn/aepay11.htm#7 FTC says incidence of ID theft jumped in 2002 http://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ? -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
You need a Better Business Bureau's cert, where the BBB is financially liable. (This implies it checks in *meatspace* and probably implies competition too.) we actually included that in suggestion as part of original stuff for setting up electronic commerce and providing comfort to consumers. however it didn't take the form of a certificate which is left over from ancient offline world (aka certificates are akin to the little BBB certificates that you get to put in your window ... a comfort issue but doesn't actually address any real cases). even before e-commerce, the real BBB process was that people called up the BBB and got realtime information i.e. it was an online, realtime process. the equiivalent for an online, internet paradigm (as opposed to something left over from the offline email genre of at least 10--15 years earlier) was that the browswer tab;e pf trusted entities were of online authorities (as opposed to certificate manufacturing) and if you cared, you clicked thru to the BBB and got realtime information about the merchant in question (being equivalent to when people call the BBB to actually get some level of real input as opposed to just a fuzzy comfort fealing). lots of past posts about merchant comfort certificates and ancient efforts to suggest requiring a BBB operation for internet merchants: http://www.garlic.com/~lynn/subpubkey.html#sslcert -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
At 12:42 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote: >At 10:56 AM 6/11/2003 -0400, Sunder wrote: >>In either case, we wouldn't need to worry about paying Verisign or anyone >>else if we had properly secured DNS. Then you could trust those pop-up >>self-signed SSL cert warnings. > >actually, if you had a properly secured DNS then you could trust DNS >to distribute public keys bound to a domain name in the same way they >distribute ip-addresses bound to a domain name. The DNS is like the Yellow Pages phonebook. A secure DNS would prevent evil postmen from editing your copy of the Yellow Pages before he drops it off at your house. But *anyone* can buy an entry in the Yellow Pages. And you can't sue the Yellow Pages because of an advert there --even a signed (unedited) one. Adding PKeys to Yellow Pages merely lets you get scammed *confidentially*. Verisign doesn't help ---they don't check anything in meatspace. They're not liable. You can't sue them. "Kosher meat certified by that vegetarian catholic up the street" You need a Better Business Bureau's cert, where the BBB is financially liable. (This implies it checks in *meatspace* and probably implies competition too.) Another metaphor: you can't sue the DMV if someone defrauds you using a fake-ID. You can't sue the DMV even if its a valid ID. You can't get your money back if the valid ID points to someone who is no longer bound to that name & location. And getting scammed by whispering doesn't help either. On the other hand, if reputation is all that matters, you can conduct business without a fixed IP, DNS record, or Verisign, by transacting on a public bulletin board (skywriting), using only signatures to maintain the rep (and provide confidentiality when exchanging credit card info). There's a bootstrap problem of building reps, and getting others to believe them, but Pkeys let you maintain all the *identity* you need. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
In message <[EMAIL PROTECTED]>, "Matt Crawford" writ es: >> The worst trouble I've had with https is that you have no way to use host >> header names to differentiate between sites that require different SSL >> certificates. > >True as written, but Netscrape ind Internet Exploder each have a hack >for honoring the same cert for multiple server names. Opera seems to >honor at least one of the two hacks, and a cert can incorporate both >at once. > > /C=US/ST=Illinois/L=Batavia/O=Fermilab/OU=Services > /CN=(alpha|bravo|charlie).fnal.gov/CN=alpha.fnal.gov > /CN=bravo.fnal.gov/CN=charlie.fnal.gov You can also use *.fnal.gov --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
> The worst trouble I've had with https is that you have no way to use host > header names to differentiate between sites that require different SSL > certificates. True as written, but Netscrape ind Internet Exploder each have a hack for honoring the same cert for multiple server names. Opera seems to honor at least one of the two hacks, and a cert can incorporate both at once. /C=US/ST=Illinois/L=Batavia/O=Fermilab/OU=Services /CN=(alpha|bravo|charlie).fnal.gov/CN=alpha.fnal.gov /CN=bravo.fnal.gov/CN=charlie.fnal.gov > So you need to waste IP's for this. Waste? Heck no, that's what they're for! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
At 10:56 AM 6/11/2003 -0400, Sunder wrote: In either case, we wouldn't need to worry about paying Verisign or anyone else if we had properly secured DNS. Then you could trust those pop-up self-signed SSL cert warnings. actually, if you had a properly secured DNS then you could trust DNS to distribute public keys bound to a domain name in the same way they distribute ip-addresses bound to a domain name. the certificates serve two purposes: 1) is the server that we think we are talking to really the server we are talking to and 2) key-exchange for establishing an encrypted channel. a properly secured DNS would allow information distributed by DNS to be trusted including a server's public key and given the public key it would be possible to do the rest of the SSL operation (w/o requiring certificates) which is establishing an agreed upon session secret key. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
Sunder <[EMAIL PROTECTED]> writes: > The worst trouble I've had with https is that you have no way to use host > header names to differentiate between sites that require different SSL > certificates. > > i.e. www.foo.com www.bar.com www.baz.com can't all live on the same IP and > have individual ssl certs for https. :( This is because the cert is > exchanged before the http 1.1 layer can say "I want www.bar.com" > > So you need to waste IP's for this. Since the browser standards are > already in place, it's unlikely to be to find a workaround. i.e. be able > to switch to a different virtual host after you've established the ssl > session. :( This is being fixed. See draft-ietf-tls-extensions-06.txt -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
The worst trouble I've had with https is that you have no way to use host header names to differentiate between sites that require different SSL certificates. i.e. www.foo.com www.bar.com www.baz.com can't all live on the same IP and have individual ssl certs for https. :( This is because the cert is exchanged before the http 1.1 layer can say "I want www.bar.com" So you need to waste IP's for this. Since the browser standards are already in place, it's unlikely to be to find a workaround. i.e. be able to switch to a different virtual host after you've established the ssl session. :( Personally I find thawte certs to be much cheaper than verisign and they work just as well. In any case, anyone is free to do the same thing AlterNIC did - become your own free CA. You'll just have to convince everyone else to add your CA's cert into their browser. You might be able to get the Mozilla guys to do this, good luck with the beast of Redmond though. Either way, having a pop-up isn't that big deal so long as you're sure of the site you're connecting to. In either case, we wouldn't need to worry about paying Verisign or anyone else if we had properly secured DNS. Then you could trust those pop-up self-signed SSL cert warnings. --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, James A. Donald wrote: > The most expensive and inconvenient part of https, getting > certificates from verisign, is fairly useless. > > The useful part of https is that it has stopped password > sniffing from networks, but the PKI part, where the server, but > not the client, is supposedly authenticated, does not do much > good. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
"James A. Donald" <[EMAIL PROTECTED]> writes:
>On 8 Jun 2003 at 14:47, tom st denis wrote:
>>I disagree. That attack is more akin to a "Hi, I'm calling
>>from {insert bank here} and we need your CC info to update
>>your file."
>>
>>That doesn't mean credit cards [nor your bank] are flawed.
>
>Actually credit cards, and your bank, are flawed, as any porn
>site operator will tell you.
There's a wonderful story at http://www.zug.com/pranks/credit/ by someone who
tried to see how b0rken he could make his signature before anyone complained.
He tried at various times a random scribble, a crosshatched scribble, a
regular grid, an 'X', a drawing of a stick-figure person, his name in Egyptian
hieroglyphics, various famous people's names, and even "I stole this card".
No-one ever complained.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
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. A nice essay, partially on the need to include technological protections against human error, included the above paragraph. 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. YMMV - 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 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
-- On 9 Jun 2003 at 2:09, Dave Howe wrote: > The problem is here, we are blaming the protective device for > not being able to protect against the deliberate use of an > attack that bypasses, not challenges it - by exploiting the > gullibility or tendency to take the path of least resistance > of the user. The real weakness in HTTPS is the tendency of > certificates signed by Big Name CAs to be automagically > trusted - even if you have never visited that site before. > yes, you can fix this almost immediately by untrusting the > root certificate - but then you have to manually verify each > and every site at least once, and possibly every time if you > don't mark the cert as "trusted" for future reference. To > blame HTTPS for an attack where the user fills in a web form > received via html-rendering email (no https involved at all) > is more than a little unfair though. How many attacks have there been based on automatic trust of verisign's feckless ID checking? Not many, possibly none. 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. A wide variety of ways of getting big name certificates that one should not have, have been discovered. Attackers never showed much interest. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG uJuAm4Xwyo4xTn0ozjBmW2ZqpI8Z3ru25WDmB7iw 43PXj2QDpBfcahqs2aOleapJYsqtA6S36+hOdVkpR - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
-- On 8 Jun 2003 at 20:00, Anne & Lynn Wheeler wrote: > that is why we coined the term merchant "comfort" > certificates some time ago. my wife and I having done early > work for payment gateway with small client/server startup in > menlo park ... that had this thing called SSL/HTTPS ... and > then having to perform due diligence on the major issuers of > certificates we recognized 1) vulnerabilities in the > certificate process and 2) information hiding of transaction > in flight only addressed a very small portion of the > vulnerabilities and exploits. https is like a strong fortress wall that only goes half way around the fortress. The most expensive and inconvenient part of https, getting certificates from verisign, is fairly useless. The useful part of https is that it has stopped password sniffing from networks, but the PKI part, where the server, but not the client, is supposedly authenticated, does not do much good. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 9ZQw+0/xh1y28CkGulSQSVxewfy71qzXGHI8KJbN 4osBv1veq07jaMVh2zVetZVKqIRfQjiwJaKu99GqM - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
--
On 8 Jun 2003 at 14:47, tom st denis wrote:
> I disagree. That attack is more akin to a "Hi, I'm calling
> from {insert bank here} and we need your CC info to update
> your file."
>
> That doesn't mean credit cards [nor your bank] are flawed.
Actually credit cards, and your bank, are flawed, as any porn
site operator will tell you.
> The attack is based on you giving out the secrets, and alas,
> no crypto can really stop that
If people routinely conduct business by sharing secrets, they
will tend to share secrets with the wrong people. The
solution, envisaged a long time ago, but not implemented
successfully, is not to use shared secrets.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
z/jW5FTj5fTxewjBZmMh+hI7TPK07m0Wi/ugRB/p
4o2DM1LcrAnzZHIYbECFoxfE1N1Ts2we2cISfJ8QL
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal --> secure UI for browsers
Yes, >NOW< if you can load yourself into kernel space, you can do anything and everything - Thou Art God to quote Heinlein. This is true of every OS. Except if you add that nice little TCPA bugger which can verify the kernel image you're running is the right and approved one. Q.E.D. Look at the XBox hacks for ideas as to why it's not a trival issue, but even so, one James Bond like buffer overflow in something everyone will have marked as trusted (say IE 8.0, or a specially crafted Word 2005 macro), and the 3v1l h4x0r party is back on and you iz ownz0red once more. It's not enough to fear Microsoft, you must learn to love it. Give us 2 minutes of hate for Linux now brother! --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, Rich Salz wrote: > But if the system is rooted, then the attacker merely has to find the > "today's secret word" entry in the registry and do the same thing. > Unless Windows is planning on getting real kernel-level kinds of protection. > > > It was none other than Microsoft's NGSCB, nee Palladium. See > > http://news.com.com/2100-1012_3-1000584.html?tag=fd_top: > > See previous sentence. :)
Re: An attack on paypal --> secure UI for browsers
> 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. But if the system is rooted, then the attacker merely has to find the "today's secret word" entry in the registry and do the same thing. Unless Windows is planning on getting real kernel-level kinds of protection. > It was none other than Microsoft's NGSCB, nee Palladium. See > http://news.com.com/2100-1012_3-1000584.html?tag=fd_top: See previous sentence. :) /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal --> secure UI for browsers
Nomen Nescio <[EMAIL PROTECTED]> writes: >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. Maybe MS will implement something like the secure attention key in the old VAX A1 VMM (Ctrl-Alt-Del already serves this purpose for logins) which gives you a guaranteed non-spoofed interface to the kernel (see for example "A Retrospective on the VAX VMM Security Kernel" by Karger et al for more information on this). They certainly have the VMS knowhow :-). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal --> secure UI for browsers
Tim Dierks wrote: > - 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.) It was none other than Microsoft's NGSCB, nee Palladium. See http://news.com.com/2100-1012_3-1000584.html?tag=fd_top: NEW ORLEANS--Microsoft is trying to make security obvious. The software giant plans to visually alter document or application windows that contain private information that's secured through Microsoft's Next-Generation Secure Computing Base (NGSCB), formerly known as Palladium. Secure windows will look different than regular, unsecured windows in order to remind users that they are looking at confidential material, Peter Biddle, product unit manager for Microsoft, said Thursday at the Windows Hardware Engineering Conference (WinHEC) here. ... The border of a secured page may contain information--such as the names of all the dogs that someone has ever owned--to make the data instantly recognizable as sound to the individual owner, as well as difficult to replicate. A hacker can create a spoof page with dogs' names running along the border but, in all likelihood, not one reading "Buffy, Skip and Jack Daniels--and in that order," Biddle said. ... Information on secured windows will vanish if another window is placed on top of it or shifted to the background. Erasing the information will prevent certain types of attacks and remind people that they're dealing with confidential material, Biddle said. When the secure window returns to the top of the stack, the information will reappear, he said. 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? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal --> secure UI for browsers
Amir Herzberg <[EMAIL PROTECTED]> writes: >Ka Ping Yee, User Interface Design for Secure System, ICICS, LNCS 2513, 2002. Ka-Ping Yee has a web page at http://zesty.ca/sid/ and a lot of interesting things to say about secure HCI (and HCI in general), e.g. a characterisation of safe systems vs. general-purpose systems: In order for Alice to use her computer usefully, she has to be able to instruct programs to do things for her. In order for those programs to carry out tasks, she has to trust those programs with some authority. So every useful operation involves making the system a little bit less safe. In order to keep the system from becoming unboundedly unsafe, Alice must also be able to make her system more safe. A system in an ultimately safe state is one that can't do anything other than what was planned ahead of time. General-purpose computing is useful to Alice only because she can make unpredictable inputs into the system, asking it to do new things. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal --> secure UI for browsers
>Yuan, Ye and Smith, Trusted Path for Browsers, 11th Usenix security symp, >2002. Minor nit: just Ye and Smith. (Yuan had helped with some of the spoofing) Advertisement: we also built this into Mozilla, for Linux and Windows. http://www.cs.dartmouth.edu/~pkilab/demos/countermeasures/ --Sean -- Sean W. Smith, Ph.D. [EMAIL PROTECTED] http://www.cs.dartmouth.edu/~sws/ (has ssl link to pgp key) Department of Computer Science, Dartmouth College, Hanover NH USA - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal --> secure UI for browsers
At 18:03 08/06/2003 -0400, Tim Dierks wrote: - 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.) Here are two... Yuan, Ye and Smith, Trusted Path for Browsers, 11th Usenix security symp, 2002. Ka Ping Yee, User Interface Design for Secure System, ICICS, LNCS 2513, 2002. This issue is also covered somewhat by my article in CACM (May 2002). Best, Amir Herzberg http://amir.herzberg.name - 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 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] Amir Herzberg http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
At 02:09 AM 6/9/2003 +0100, Dave Howe wrote: The problem is here, we are blaming the protective device for not being able to protect against the deliberate use of an attack that bypasses, not challenges it - by exploiting the gullibility or tendency to take the path of least resistance of the user. The real weakness in HTTPS is the tendency of certificates signed by Big Name CAs to be automagically trusted - even if you have never visited that site before. yes, you can fix this almost immediately by untrusting the root certificate - but then you have to manually verify each and every site at least once, and possibly every time if you don't mark the cert as "trusted" for future reference. that is why we coined the term merchant "comfort" certificates some time ago. my wife and I having done early work for payment gateway with small client/server startup in menlo park ... that had this thing called SSL/HTTPS ... and then having to perform due diligence on the major issuers of certificates we recognized 1) vulnerabilities in the certificate process and 2) information hiding of transaction in flight only addressed a very small portion of the vulnerabilities and exploits. lots of past discussions related to our use of merchant comfort certificates from the past: http://www.garlic.com/~lynn/subpubkey.html#ssl we concluded that a real issue is that way too much of the infrastructure is based on shared-secrets and there was no realistic way of providing blanket protection to all the exposures and vulnerabilities of such shared-secret infrastructures. somewhat related discussion in the security proportional to risk posting: http://www.garlic.com/~lynn/2001h.html#61 so rather than trying to create a very thick blanket of encryption covering the whole planet a synergistic approach was attempting to provide alternatives to as much of the shared-secret paradigm as possible. As in the referenced post: http://www.garlic.com/~lynn/aepay11.htm#53 authentication white paper strong encryption of identification and privacy (and shared-secret) information is good ... but not having identification, privacy and shared-secret information is even better. there are all sorts of ways of obtaining shared-secret information (and/or privacy and identification information prelude to identity theft) including various kinds of social engineering. as previously mentioned requirement for X9.59 standard was to preserve the integrity of the financial infrastructure for ALL electronic retail payments. As per previous notes, X9.59 with strong authentication eliminates the account number as a shared-secret as well as eliminating requirements for name, address, zip-code, etc as part of any credit card authentication process (strong encryption of vulnerable information is good, not having the information at all is even better). ALL in addition to referring to things like credit cards, debit cards, atm transactions, stored-value transaction, over the internet, at point-of-sale, face-to-face, automated machines, etc also refers to ACH transactions. ACH information allows for unauthenticated push or pull transactions. Social engineering requesting bank account information so somebody can push tens of millions into your account also allows for them to generate a pull transaction removing all the money from your account. Part of the above posting on the authentication white paper makes references to securing ACH transactions: http://www.asuretee.com/company/releases/030513_hagenuk.shtm -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
In message <[EMAIL PROTECTED]>, Anne & Lynn Whee ler writes: > >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. One could argue that that's because of https... More seriously, eavesdropping on passwords was a *very* big problem starting in late 1993. Part of the problem was that ISPs then didn't know better than to put NOC workstations on their backbone LANs; when those were compromised, the attackers had wonderfully-placed eavesdropping stations. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
> 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. The problem is here, we are blaming the protective device for not being able to protect against the deliberate use of an attack that bypasses, not challenges it - by exploiting the gullibility or tendency to take the path of least resistance of the user. The real weakness in HTTPS is the tendency of certificates signed by Big Name CAs to be automagically trusted - even if you have never visited that site before. yes, you can fix this almost immediately by untrusting the root certificate - but then you have to manually verify each and every site at least once, and possibly every time if you don't mark the cert as "trusted" for future reference. To blame HTTPS for an attack where the user fills in a web form received via html-rendering email (no https involved at all) is more than a little unfair though. > in the past systems have designed long, complicated passwords that are > hard to remember and must be changed every month. that almost worked when > a 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. I am not aware of one (not that that means much, given I am a novice in this field) Even PKI relies on something close to a shared secret - a *trustworthy* copy of the public key, matching a secret copy of the private key. In x509, this trustworthyness is established by an Ultimately Trusted CA; in pgp, by the Web Of Trust, in a chain leading back to your own key; in SSH, by your placing of the public key into your home dir manually (using some other form of authentication to presumably gain access) in each of these cases, the private key will almost invariably be protected by a passphrase; at best, you can have a single passphrase (or even single private key) to cover all bases.. but that just makes that secret all the more valuable. > 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. That is pretty much because defence occupies the position of the interior - attackers will almost invariably attack weak points, not strong ones. It is easy to log and calculate how many attacks happen on weak points, but impossible to calculate how many attacks *would* have happened had the system not been in place to protect against such attacks, so the attackers moved onto easier targets. It makes little sense to try and break one https connection (even at 40 bit) if by breaking into the server you get that information, hundreds of others (until discovered) and possibly thousands of others inadvisedly stored unprotected in a database. > 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: Which again matches well to the Nigerian analogy. Everyone *knows* that handing over your bank details is a Bad Thing - yet they still do it. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [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 currently (stil
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. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
"James A. Donald" <[EMAIL PROTECTED]> wrote:
>
>>Attached is a spam mail that constitutes an attack on paypal similar
>>in effect and method to man in the middle.
Yeah, I've been seeing that one for a month or
two now. I've seen several versions. Some of
them are quite well done. I imagine they get
more than a few victims.
I would have thought that the perpetrators would
have been too afraid of stings to try something
so bold. The existence of such schemes is a sad
commentary on the state of law enforcement.
>>The bottom line is that https just is not working. Its broken.
On 06/08/2003 05:47 PM, tom st denis wrote:
I disagree. That attack is more akin to a "Hi, I'm calling from
{insert bank here} and we need your CC info to update your file."
...
So your "conclusions" are a bit off.
You guys are talking past each other.
All statements of the form.
-- foo is working (or not)
-- foo solves the problem (or not)
are so imprecise as to be useless.
It is better to talk about a definite specification.
Then we can ask whether foo meets the spec or not.
If you ask whether a given https implementation meets
the https specifications, then quite possibly it does.
So in this sense the technology is not "broken".
But if you ask whether https makes the world safe
for naifs to conduct e-commerce, by protecting them
from all possible spoofs and MITM attacks, then no,
it certainly does not do that. There are some who
rashly claimed it was supposed to do that, so in
this sense it is quite broken. It fails to meet
the broader spec.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: An attack on paypal
--- "James A. Donald" <[EMAIL PROTECTED]> 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.
I disagree. That attack is more akin to a "Hi, I'm calling from
{insert bank here} and we need your CC info to update your file."
That doesn't mean credit cards [nor your bank] are flawed. It means
you're an idiot for giving out the information.
Note that this "attack" doesn't actually exploit the automated side of
things. It doesn't learn the secret key [password] nor does it decrypt
packets [via https]. The attack is based on you giving out the
secrets, and alas, no crypto can really stop that [unless you stop
letting the users have the secrets].
So your "conclusions" are a bit off.
Tom
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
