Re: Using crypto against Phishing, Spoofing and Spamming...
At 03:20 AM 7/18/2004, Enzo Michelangeli wrote: Can someone explain me how the phishermen escape identification and prosecution? Gaining online access to someone's account allows, at most, to execute wire transfers to other bank accounts: but in these days anonymous accounts are not exactly easy to get in any country, and anyway any bank large enough to be part of the SWIFT network would cooperate in the resolution of obviously criminal cases. At least until a few years ago, and probably still today, it was easy to get a non-anonymous account in the US using fake ID. The Know Your Customer laws and other anti-terrorism fallout may have encouraged banks to check SSNs a bit more carefully, but as long as the person whose identity you're stealing doesn't have horrendously bad or good credit, it's probably still not hard. If it costs you $100 in fake ID to get the account set up, and you can burn the phish for $1000, then you win. But credit cards are probably more common and certainly easier to use. Buy laptops or other fungible goods, and sell them on eBay. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
Enzo Michelangeli [EMAIL PROTECTED] writes: Can someone explain me how the phishermen escape identification and prosecution? Gaining online access to someone's account allows, at most, to execute wire transfers to other bank accounts: Some (a lot of?) large-scale phishing is done by or with the aid of international organised crime, who have a great deal of experience in making money disappear (or reappear in cleaned form). Even without that expertise, there are many, many ways to launder the money. One that I heard of recently is to go to small in-debt businesses and offer to pay off their debt, with the business then paying back half that in cash to the phisher. The business has half their debt paid off, and the phisher has converted their wire transfer into untraceable cash. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RP -- Re: Using crypto against Phishing, Spoofing and Spamming...
At 01:39 PM 7/21/2004, Ed Gerck wrote: The PKI model is not tied to any legal jurisdiction and is not a business process. What is meant then by relying-party (RP) and RP Reliance in X.509 and PKIX? I hope the text below, from a work in progress submitted as an IETF ID, helps clarify this issue. the TTP (trusted third party) PKI business model typically described in the early 90s ... had a business exchange between a key owner and a certification authority ... where the key owner paid the certification authority for the issuing of a certificate that bound some information to the public key. The payment of money by the key owner to the certification authority created some sort of legal relationship between the key owner and the certification authority with regard to the certificate. in that environment the key owner then digitally signed something, and sent the something with a digital signature and the certificate to a relying-party. The relying-party was frequently assumed to be making some sort of legal reliance and recourse on the performance of the certification authority. However, w/o payment of funds and/or other legal arrangement between the relying-party and the certification authority there was no legal bases for reliance (unless mandated outside of traditional business context by some gov. mandate) it appears that the GAO working within that semantic structural business context ... has taken some effort to create a legal basis for reliance and recourse between the relying parties and the certification authorities for the federal PKI . It basically has something along the lines of the certification authorities signing a contractual relationship with the GAO. Then all the relying parties also sign a contractual relationship with the GAO then there is recourse for the relying parties on certification authority performance based on the relying parties contract with GAO (for certification authority performance) and the GAOs contract with the certification authorities (for certification authority performance). This is sort of trying to get around the lack of any implied performance and/or contractual relationship (and therefor recourse) because the relying parties haven't actually paid any money to the certification authorities. In the simple case, having any sort of legal obligation between the certification authority and the key-owner ... and any sort of totally different legal obligation between the key-owner and a relying party ... normally would fail to create any sort of legal obligation between (the traditional TTP PKI) certification authorities (described in the early 90s) and the set of relying parties. some of this became mute by the mid-90s with the observation that the traditionally considered identity x.509 certificates represented a significant privacy and liability exposure ... and the retrenching by infrastructures to relying-party-only certificates (effectively account number and public key ... although even a relying-party-only SET certificates could represent a factor of 100-times payload bloat). the other issue that quickly became observed if the relying-party and the certification authority were the same then the relying party would typically have a large superset of the information that they included in any relying-party-only certificate ... and that having the key-owner to return this small subset of information repeatedly to the relying-party (/certification authority) was redundant and superfluous other than possibly contributing huge computational and transmission overheads for no useful purpose. IETF standards tend to be descriptions of protocol and parties role in the protocol. Such syntactical and semantical description of the protocols has rarely included description of any possible syntactical and semantic business relationships especially of the typical kind being proposed in the early 90s for TTP certification authorities. for pkix references see http://www.garlic.com/~lynn/rfcietff.htm and click on Term (term-RFC#) in the RFC's listed by section then click on PKI in the Acronym fastpath section. the current results: public key infrastructure (PKI) see also file:///D:/users/http/rfcterms.htm#t508authentication , file:///D:/users/http/rfcterms.htm#t600encryption , file:///D:/users/http/rfcterms.htm#t770public key file:///D:/users/http/rfcidx12.htm#38203820 file:///D:/users/http/rfcidx12.htm#37793779 file:///D:/users/http/rfcidx12.htm#37783778 file:///D:/users/http/rfcidx12.htm#37703770 file:///D:/users/http/rfcidx12.htm#37413741 file:///D:/users/http/rfcidx12.htm#37393739 file:///D:/users/http/rfcidx12.htm#37093709 file:///D:/users/http/rfcidx12.htm#36533653 file:///D:/users/http/rfcidx12.htm#36473647 file:///D:/users/http/rfcidx11.htm#35623562 file:///D:/users/http/rfcidx11.htm#34473447 file:///D:/users/http/rfcidx11.htm#33793379
Re: Using crypto against Phishing, Spoofing and Spamming...
In message [EMAIL PROTECTED], Ian Grigg writes: Don't be silly. It's not a threat because people generally use SSL. Back in the old days, password capture was a very serious threat. It went away with SSH. It seems to me quite likely that it would be a problem with web browsing in the absence of SSL. Right... It's easy to claim that it went away because we protected against it. Unfortunately, that's just a claim - there is no evidence of that. This is why I ask whether there has been any evidence of MITMs, and listening attacks. We know for example that there were password sniffing attacks back in the old days, by hackers. Hence SSH. Costs - Solution. But, there is precious little to suggest that credit cards would be sniffed - I've heard one isolated and unconfirmable case. And, there is similar levels of MITM evidence - anecdotes and some experiences in other fields, as reported here on this list. I think that Eric is 100% correct here: it doesn't happen because it's a low-probability attack, because most sites do use SSL. I think that people are forgetting just how serious the password capture attacks were in 1993-94. The eavesdropping machines were on backbones of major ISPs; a *lot* of passwords were captured. Furthermore, the technology has improved -- have you looked at dsniff lately, with the ARP-based active attack capability? And credit cards are much easier to grab -- they're probably sent in one packet, instead of several, and the number is a self-checking string of digits. It's also worth remembering that an SSL-like solution -- cryptographically protecting the transmission of credit card number, instead of digitally signing a funds transfer authorization linked to some account -- was more or less the only thing possible at the time. The Internet as a medium of commerce was too new for the banks to have developed something SET-like, and there wasn't an overwhelmingly-dominant client platform at the time for which custom software could be developed. (Remember that Windows 95 was the first version with an integral TCP/IP stack.) *All* that Netscape could deploy was something that lived in just the browser and Web server. SET itself failed because the incentives were never there -- consumers didn't perceive any benefit to installing funky software, and merchants weren't given much incentive to encourage it. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
Steve, thanks for addressing the issues with some actual anecdotal evidence. The conclusions still don't hold, IMHO. Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Ian Grigg writes: Right... It's easy to claim that it went away because we protected against it. Unfortunately, that's just a claim - there is no evidence of that. This is why I ask whether there has been any evidence of MITMs, and listening attacks. We know for example that there were password sniffing attacks back in the old days, by hackers. Hence SSH. Costs - Solution. But, there is precious little to suggest that credit cards would be sniffed - I've heard one isolated and unconfirmable case. And, there is similar levels of MITM evidence - anecdotes and some experiences in other fields, as reported here on this list. I think that Eric is 100% correct here: it doesn't happen because it's a low-probability attack, because most sites do use SSL. The trick is to show cause and effect. We know the effect and we know the cause(s). The question is, how are they related? The reason it is important is that we may misapply one cause if the effect results from some other cause. I think that people are forgetting just how serious the password capture attacks were in 1993-94. The eavesdropping machines were on backbones of major ISPs; a *lot* of passwords were captured. Which led to SSH, presumably, and was pre-credit card days, so can only be used as a prediction of eavesdropping. Question - are we facing a situation today whereby it is easy to eavesdrop from the backbone of a major ISP and capture a lot of traffic? As far as I can see, that's not likely to happen, but it could happen. Secondly, who were the people doing those attacks? Back in 93-94, I'd postulate they weren't criminal types, but hacker types. That is, they were hackers looking for machines. Those people are still around - defeated by SSH in large measure - and use other techniques now. (Hackers had no liability in those days. Criminals do have liability, and are more concerned to cover their tracks. This makes active attacks less useful to them. Criminals are getting braver though.) Thirdly, why aren't we seeing more reports of this on 802.11b networks? I've seen a few, but in each case, the attack has been to hack into some machine. I've yet to see a case where listeners have scarfed up some free email account passwords, although I suppose that this must happen. The point of all this is that we need to establish how frequent and risky these things are. Back in the pre- commerce days, a certain amount of FUD was to be expected. Now however, it's been a decade - whether that FUD was warranted then is an issue for the historians, but now we should be able to scientifically make a case that the posture matches the threats. Because it's been a decade (almost). As far as I can see, there *some* justification for expecting eavesdropping attacks to credit cards. There is a lot more justification with unprotected non-commerce. And in contrast, there is little justification for expecting active attacks for purposes of theft. What this leads to is not whether SSL should have been deployed or changed in its current form (it is fruitless to debate that, IMHO, except in order to lay down the facts) but a discussion of certificates. There seems some justification in suggesting that SSL be (continued to be) deployed in any form. Mostly, IMHO, in areas outside commerce, and mostly, in the future, not now. There seems a lot of justfication for utilising certs as they enable relationship-protection. There seems quite a bit of justification for utilising CA-signed certs because they permit more advanced relationship protection such as Amir's logo ideas and my branding ideas, and more so every day. What there doesn't appear to be any justification for is the effective or defacto mandating of CA-signed certs. And there appears to be a quite serious cost involved in that mandating - the loss of protection from the resultant *very* low levels of SSL deployment. This all hangs on the MITM - hence the question of frequency. It seems to be very low, an extraordinarily desparate attack for a criminal, especially in the light of experience. He does phishing and hacking with ease, but he doesn't like leaving tracks in the infrastructure that point back to him. If the MITM cannot be justified as an ever-present danger, then there is no justification for the defacto mandating of CA-signed certs. Permitting and encouraging self-signed certs would then make deployment of SSL much easier, and thus increase use of SSL - in my view, dramatically - which would lead to much better protection. (Primarily by relationship management on the client side, and also by branding/logo management with the CAs, but that needs to be enabled in code first at the browsers.) (It has to be said that encouraging anon-diffie-hellman SSL would also lead to dramatically improved levels of SSL
Re: Using crypto against Phishing, Spoofing and Spamming...
At 01:54 PM 7/19/2004, Steven M. Bellovin wrote: It's also worth remembering that an SSL-like solution -- cryptographically protecting the transmission of credit card number, instead of digitally signing a funds transfer authorization linked to some account -- was more or less the only thing possible at the time. The Internet as a medium of commerce was too new for the banks to have developed something SET-like, and there wasn't an overwhelmingly-dominant client platform at the time for which custom software could be developed. (Remember that Windows 95 was the first version with an integral TCP/IP stack.) *All* that Netscape could deploy was something that lived in just the browser and Web server. SET itself failed because the incentives were never there -- consumers didn't perceive any benefit to installing funky software, and merchants weren't given much incentive to encourage it. SET couldn't replace online transaction ... the encryption was effectively there for hiding credit card while in-flight ... which SSL was already doing ... but SET was doing at an order to two-orders increase in complexity and overhead. SET didn't provide any additional countermeasure against the major exploits/vulnerabilities (vis-a-vis SSL) ... even with all that complexity. the transaction was still online ... since there are a bunch of other factors involved in authorization ... like credit limit ... not just whether there is impersonation with lost/stoleln numbers. there was still the enormous payload bloat (certificates and signatures increase the size of typical 8583 transaction by two-orders of magnitude) which prevent true end-to-end security operation. As a result the signature was verified at some internet boundary, then the signature and certificate(s) were stripped off and traditional 8583 packet forwarded to the consumer/issuing financial institution. Later at some ISO standards meeting, one of the association business people presented numbers on number of 8583 packets with the signature bit turned on and they positively knew no digital signature was involved. It wasn't even a real PKI ... 1) i.e. the x.509 identity certificates from the early 90s had been depreciated because of the privacy and liability issues ... and the certificates effectively were issuing relying-party-only certificates with the account number and public key. 2) there was no revocation and/or other types of process (which could be considered minimum requirement for a PKI operation) ... they were simply manufactored certificates (a term we coined to describe the SET and SSL infrastructure; contrasting it to PKI). SET specifically stated that the transaction would be online and rely on the existing online infrastructure for determining lost, stolen, revoked, canceled, etc ... as well as all the other stuff an online infrastructure can do with timely and aggregated information (like credit limit) 3) it is trivial to show that for relying-party-only certificates requiring online infrastructure ... that the certificates themselves are redundant and superfluous ... aka the key is registered with the issuing party ... and the transaction is performed by the issuing party. The transaction can be digitally signed (w/o the enormous payload bloat of carrying a certificate) and the issuing party verify the digital signature with an onfile public key w/o having to resort to dealing with a certificate (that the issuing party would have originally generated from the onfile information). From an incentive standpoint the PKI model is effectively orthogonal to standard business processes. The key owner pays something to the issuing party (or at best, the issuing party absorbs the costs). The standard business process has any sort of contract between the key owner and the issuing party. This totally leaves out the relying-party ... which is the primary beneficiary of the PKI model from being a part of the contractual business process ... which would imply little or no legal recourse if something went wrong. GAO has created a facade to address this issue by making the TTP certification authorities sort of agents of the GAO ... and having all relying-parties signed contracts with the GAO., The PKI frequently creates a total disconnect between the parties of the certification contract ... and the relying parties ... which should have recourse in case something went wrong aren't even a part of it. In the specifics of the SET deployment ... the primary potential beneficiaries theoritically were the merchants (from the thoery that SET signed transactions would be considered card-present card-owner present ... and lower the merchants cost for doing the transactions). However the parties paying for the certificates and most of the infrastructure were the issuers and the consumers. Not only may a traditional TTP PKI create legal disconnect for relying parties but in the SET case there was major disconnect between who paid for most of the infrastructure
Re: Using crypto against Phishing, Spoofing and Spamming...
Ian Grigg [EMAIL PROTECTED] writes: Notwithstanding that, I would suggest that the money already lost is in excess of the amount paid out to Certificate Authorities for secure ecommerce certificates (somewhere around $100 million I guess) to date. As predicted, the CA-signed certificate missed the mark, secure browsing is not secure, and the continued resistance against revision of the browser's useless padlock display is the barrier to addressing phishing. I don't accept this argument at all. There are at least three potential kinds of attack here: (1) Completely passive capture attacks. (2) Semi-active attacks that don't involve screwing with the network infrastructure (standard phishing attacks) (3) Active attacks on the network infrastructure. SSL does a fine job of protecting against (1) and a fairly adequate job of protecting against (3). Certainly you could do a better job against (3) if either: (a) You could directly connect to sites with SSL a la https://www.expedia.com/ (b) The identities were more user-friendly as we anticipated back in the days of S-HTTP rather than being domain names, as required by SSL. It does a lousy job of protecting against (3). Now, my threat model mostly includes (1), does not really include (3), and I'm careful not to do things that leave me susceptible to (2), so SSL does in fact protect against the attacks in my threat model. I know a number of other people with similar threat models. Accordingly, I think the claim that secure browsing is not secure rather overstates the case. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
But is it so harmful? How much money is lost in a typical phishing attack against a large US bank, or PayPal? A lot. According to people at the anti-phishing conference earlier this year, six-figure losses are common, and seven-figure not unknown. The kind of phishes we all see, trolling for credit card or ISP account info with spam, are the lowest level kind. The serious ones carefully choose their targets, e.g., ebay sellers with very high positive ratings, or people who live outside the US and have large US bank accounts, and are more likely to send hundreds of messages than millions. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor A book is a sneeze. - E.B. White, on the writing of Charlotte's Web - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
Eric Rescorla wrote: Ian Grigg [EMAIL PROTECTED] writes: Notwithstanding that, I would suggest that the money already lost is in excess of the amount paid out to Certificate Authorities for secure ecommerce certificates (somewhere around $100 million I guess) to date. As predicted, the CA-signed certificate missed the mark, secure browsing is not secure, and the continued resistance against revision of the browser's useless padlock display is the barrier to addressing phishing. I don't accept this argument at all. There are at least three potential kinds of attack here: (1) Completely passive capture attacks. (2) Semi-active attacks that don't involve screwing with the network infrastructure (standard phishing attacks) By (2) I guess you mean a bypass MITM? (3) Active attacks on the network infrastructure. By (3) I guess you mean a protocol level MITM. Then, there is: (4) Active attacks against the client. By this I mean hacking the client, installing a virus, malware, spyware or whathaveyou. (This is now real, folks.) (5) Active attacks against the server. Basically, hacking the server and stealing all the good stuff. (This has always been real, ever since there have been servers.) (6), (7) Insider attacks against client, server. Just read off the data and misuse it. (This has been real since the dawn of time...) Of course, SSL/SB doesn't protect against any of these, and many people therefore assume the thinking stops there. Sadly, no. Even though SSL doesn't protect against these attacks, the frequency cost of these attacks directly impacts on the design choices of secure browsing. SSL does a fine job of protecting against (1) and a fairly adequate job of protecting against (3). Certainly you could do a better job against (3) if either: (a) You could directly connect to sites with SSL a la https://www.expedia.com/ (b) The identities were more user-friendly as we anticipated back in the days of S-HTTP rather than being domain names, as required by SSL. It does a lousy job of protecting against (3). Sorry, I'm having trouble parsing fairly adequate versus lousy job for threat (3)... Both (a) and (b) seem to deserve some examples? I can connect directly to expedia, and https://www.paypal.com/ is friendly enough? (Hmmm... I tell a lie, there is no https://www.expedia.com/ as it redirects.) Now, my threat model mostly includes (1), does not really include (3), and I'm careful not to do things that leave me susceptible to (2), so SSL does in fact protect against the attacks in my threat model. I know a number of other people with similar threat models. Accordingly, I think the claim that secure browsing is not secure rather overstates the case. (1) OK. Now, granted, SSL protects against (1), fairly finely. It does so in all its guises, although the CA-signed variant in secure browsing does so at some additional unneeded expense, as it eliminates certain secure options, being SSCs and ADH. OTOH, this is a really rare attack - actual damage from sniffing HTTP traffic doesn't seem to be recorded anywhere as a real attack on people, so forgive me if I downgrade this one as almost not a threat. (2) Then we come to (2), what i'd call a bypass MITM. Or a phish or a spoof. (I'm not sure what semi active and infrastructure have to do with it.) This one is certainly a threat. When the browser is presented with a URL which happens to purport only to be some secure site, without really being that site, this is a spoof. Your defence is to be careful against this attack. So, your defence is nothing to do with SSL or secure browsing or anything really, literally, (2) is unprotected against by SSL and secure browsing in all their guises. You yourself provide the protection, because SSL / secure browsing does not. Of course. That is my point - secure browsing does not protect against any real present threat. (3) I don't understand at all. But you suggest that it's not your threat and it isn't protected well against. In summary - we are left with one attack that is well protected against, but isn't really seen that much, and could be done with ADH. Then, another attack that you deal with yourself, so that's not really relevant coz you're smart and experienced, and those using browsers on the average are not, and they are hit by the attack. Then there is (3). (And we haven't even begun on (4) thru (7). What then, is a threat model that only includes some threats?) So in sum, I think my argument remains unchallenged: secure browsing fails to secure. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
At 05:55 PM 7/17/2004, Eric Rescorla wrote: Now, my threat model mostly includes (1), does not really include (3), and I'm careful not to do things that leave me susceptible to (2), so SSL does in fact protect against the attacks in my threat model. I know a number of other people with similar threat models. Accordingly, I think the claim that secure browsing is not secure rather overstates the case. there sort of two parts of SSL I believe the original justification was based on perceived integrity issues with the domain name infrastructure and various kinds of hijacking attacks. the client got back a certificate, verified the integrity of the certificate (from a table of certificate authority public keys), verified that it appeared to originate from the certificate owner and then compared the certificate domain name string with the domain name used in the URL. once that was done, there was key-exchange to protect the contents of the transmission. the catch22 was that the domain name infrastructure is also the authoritative agency as to the owner of the domain name. the SSL domain name certification authorities have this horrendously, error prone and expensive problem of getting sufficient identification information from the certificate applicant and attempting to match it with the identification information carried by the domain name infrastructure as to the owner of the domain name. so the first issue is that the integrity of the domain name infrastructure could be attacked with a domain name hijack ... then the attacker applies for a certificate and the identification provided the certification authority and the identification on file with the domain name infrastructure compare ... and the attacker gets a valid certificate. so the certification authorities came up with a proposal to have domain name registers also supply a public key at the time of registration. then future communication with the domain name owner is digital signed ... which the domain name infrastructure can verify with the public key on file. this is a countermeasure against domain name hijacking (improving the integrity of the domain name infrastructure and rising the trust that certification authorities can place in the authoritative agency). the other issue is that the certification authorities can use the public key on file with the domain name infrastructure to turn an expensive, and error-prone identification process into a much simpler and KISS authentication process aka domain name certificate applicants digitally sign their requests ... which are then verified with the public key on file at the domain name infrastructure. the two issues then are that with increased domain name infrastructure trust ... 1) it should reduce the demand for domain name SSL certificates (motivated by integrity concerns about the domain name infrastructure) and 2) it could eliminate the need for domain name SSL certificates since all clients could possibly also use the public keys on file with the domain name infrastructure (in lieu of needing to get public keys from certificates). So now to the key-exchange issue protecting credit-card numbers from evesdropping and harvesting. The issue is that the crooks tend to go after the best fraud ROI (return on investment). The claim is that it is so much more profitable to harvest the merchant transaction file that until that barn door is closed the crooks have little incentive to go after credit card numbers by evesdropping packets in flight. There have been some assertions that there has been no known cases of picking up account numbers from packet evesdropping even where SSL or any other encryption is being used to protect data in-flight. Part of the issue is that evesdropping packets takes a lot more work ... and provides much less return than going after the merchant transaction file. Other scenarios have also been end-point attacks ... where password files are harvested and/or viruses are installed at end-points to harvest information as opposed to doing anything with data in-flight. So, it could be claimed that there is some question about what is cause and what is effect i.e. are the end-point attacks because everything is encrypted or are the end-point attacks occurring because they are so much more profitable and easier. Given that there are significant amounts of non-encrypted traffic ... then the claim could be made that the crooks are getting so much more from end-point attacks ... and until that is addressed ... that attacks on data in flight is somewhat academic (since there is so little evidence about fraud happening from data in flight attacks). The other argument has traditional been that 90 percent of fraud has been insiders, typically also associated with various kinds of end-point attacks (rather than any kind of outsider attack on data in flight). There was some recent
Re: Using crypto against Phishing, Spoofing and Spamming...
Enzo Michelangeli wrote: Can someone explain me how the phishermen escape identification and prosecution? Gaining online access to someone's account allows, at most, to execute wire transfers to other bank accounts: but in these days anonymous accounts are not exactly easy to get in any country, and anyway any bank large enough to be part of the SWIFT network would cooperate in the resolution of obviously criminal cases. Good question. Actually there are two questions we should consider: a) What are the procedures phishermen are using today, procedures that they manifestly *can* get away with? b) Why why why are they allowed to get away with such procedures? Here is something of an answer to question (a): http://www.esmartcorp.com/Hacker%20Articles/ar_Watch%20a%20hacker%20work%20the%20system.htm The details are a bit sketchy, and maybe not entirely to be trusted since they come from self-described crooks, but they are plausible. Still question (b) remains. The described procedures seem to be the e-commerce analog of parking your car in a bad neighborhood with the windows rolled down and the keys in the ignition. That is, I expect that most people on this list could easily think of several things the card-issuers could do that would shut down these attack-procedures, significantly raising the phishermen's work-factor and risk of arrest -- without significantly burdening legitimate merchands or cardholders. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
Enzo Michelangeli wrote: Can someone explain me how the phishermen escape identification and prosecution? Gaining online access to someone's account allows, at most, to execute wire transfers to other bank accounts: but in these days anonymous accounts are not exactly easy to get in any country, and anyway any bank large enough to be part of the SWIFT network would cooperate in the resolution of obviously criminal cases. In practice something like this: Most of the money is wired through to some stolen account, and then moved out of the system to another system. This might be a foreign account, or it might be a non- bank such as a broker/dealer (E*Trade is being hit at the moment, it seems) or it might be a digital gold currency. From there, it is moved once or twice more, than back to the country where the phisher is. This might be the US or Russia, or anywhere else, but those two countries seem to be quite big on this (maybe we should blame Reagan :-) ) A couple of things: it is very hard, but not impossible to reverse a SWIFT style international wire. I've seen it done once, so I know it is not impossible. If the cash has gone, then reversing it doesn't make sense. Also, phishing isn't exactly a recognised and obvious criminal case. Any particular instance might be, but getting to that determination might take months. Further, opening accounts for anonymous purposes is still rather easy in many countries, the chief perpertrator of this being the USA. Finally, every attempt to make money less like money (by closing off easy accounts, for example) results in what some call unintended consequences - the money goes elsewhere. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
At 10:46 AM 7/10/2004, Florian Weimer wrote: But is it so harmful? How much money is lost in a typical phishing attack against a large US bank, or PayPal? (I mean direct losses due to partially rolled back transactions, not indirect losses because of bad press or customer feeling insecure.) misc. recent selections Online Phishing Scams Exploding http://itmanagement.earthweb.com/secu/article.php/3382341 Business faces growing loss from identity theft http://www.vnunet.com/news/1156655 Firms hit hard by identity theft http://www.boston.com/business/technology/articles/2004/07/14/firms_hit_hard_by_identity_theft/ ID theft costing UK billions in taxes http://news.zdnet.co.uk/0,39020330,39160532,00.htm ATM skimmers go hi-tech down under http://www.finextra.com/fullstory.asp?id=12184 Phishing will cost financial firms $400m in 2004 http://www.finextra.com/fullstory.asp?id=12173 Worried firms consider email boycott http://www.vnunet.com/news/1156684 = social engineering has frequently been talking somebody into giving up some information that then can be used for impersonation in later fraudulent transactions. A something you have token of some sort is a lot harder to give-up than shared-secrets for use in something you know authentication. A private key that never leaves the hardware token can't be given up because even the owner doesn't know it. also, conjecture is that it is a lot harder to convince general public to mail off some physical object compared to getting them to divulge some information. hardware tokens don't eliminate social engineering attacks where the victim is talked into performing some transaction on behalf of the attacker ... but they would tend to address the whole vulnerability landscape related to something you know shared-secret authentication paradigms. one of the cost issues with technology for server reputation is that it typically applies to servers that the consumer is visiting for the first time (or visits extremely rarely). the consumer pretty much ignores repetitive information for sites that they visit frequently. it has been that something like ninety percent (or better) of internet transactions are done by the frequently visited sites. so the cost issue is that the reputation technologies basically tend to apply to the millions of low-volume and/or low-revenue sites (in aggregate accounting for 10 percent or less of all transactions) ... which aren't looking to spend a lot of money on such technologies. it is somewhat like the better business bureau use people will tend to contact the better business bureau before they deal with some vendor for the first time but they aren't likely to contact the better business bureau each time they deal with a vendor that they have extensive repeat business with. it at least some scenarios an alternative to the business logo is a better business bureau or gov. licensing logo on a website that provides click-thru to the official site where the consumer can review complaints and/or history about the business in question. i believe that this is somewhat the ebay model ... where past transaction history reputation of individuals can be checked. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
At 10:46 AM 7/10/2004, Florian Weimer wrote: But is it so harmful? How much money is lost in a typical phishing attack against a large US bank, or PayPal? (I mean direct losses due to partially rolled back transactions, not indirect losses because of bad press or customer feeling insecure.) I estimated phishing losses about a month ago at about a GigaBuck. http://www.financialcryptography.com/mt/archives/000159.html You'll also see two other numbers in that blog entry, being $5 billion and $400 million (the latter taken from Lynn's posted articles). Of course these figures are very delicate, so we need to wait a bit to get the real damage with any degree of reliability. Scientific skepticism should abound. Notwithstanding that, I would suggest that the money already lost is in excess of the amount paid out to Certificate Authorities for secure ecommerce certificates (somewhere around $100 million I guess) to date. As predicted, the CA-signed certificate missed the mark, secure browsing is not secure, and the continued resistance against revision of the browser's useless padlock display is the barrier to addressing phishing. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
SET failed due to the complexity of distributing the software and setting up the credentials. I think another reason was the go-fast atmosphere of the late 90s, where no one wanted to slow down the growth of ecommerce. The path of least resistance was simply to bring across the old way of authorizing transactions by card number. I think your other reason was in fact the primary reason. And, of course, the primary enablers of the go-fast approach were, in fact, the very same credit card companies. They made a conscious business decision to treat online transactions the same as conventional transactions -- I forget the details, but it was pretty risk-free for a merchant to do online credit cards, getting low surchage rates. That, coupled with the US law that limited consumer liability to $50, made CCard-over-SSL a no-brainer over SET. From a consumer viewpoint, CC/SSL is more secure then SET ever was. Since it wasn't a CCard transacdtion, my liability under SET was unlimited (at least until Congress caught up to the technology). Looking at the risk management aspect, SET was a big loser for the customer. /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: Using crypto against Phishing, Spoofing and Spamming...
Florian Weimer wrote: There are simply too many of them, and not all of them implement checks for conflicts. I'm pretty sure I could legally register Metzdowd in Germany for say, restaurant service. This indeed is the crux of the weakness of the SSL/secure browsing/CA system. The concept called for all CAs are equal which is an assumption that is easily shown to be nonsense. Until that assumption is reversed, the secure browsing application is ... insecure. (I of course include no CA and self-signed certs within the set of all CAs.) The essence of any fixes in the browsers should be to address the (rather fruitful) diversity amongst CAs, and help the user to make choices amongst the brands of same. Some CAs are more equal than others... and the sooner a browser recognises this, the better. These bodies could issue logo certificates. These certificates would only have value if there is extensive verification. We probably lack the technology to do that cheaply right now, and the necessary level of international cooperation. I'm not sure I understand how logo certs would work, as there is still the possibility of same being issued by CA-Nigeria and having remarkable similarity to those issued by USPTO. Until the CA is surfaced and thrust at the face of the user, each browser's 100 or so root CAs will be a fundamental weakness. Including of course the absence of CA, which is something that is nicely hidden from the user. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
Ian Grigg wrote: This indeed is the crux of the weakness of the SSL/secure browsing/CA system. The concept called for all CAs are equal which is an assumption that is easily shown to be nonsense. Exactly. Browsers simply require sites to have a certificate from any CA. Browswers can't even specify a list of their prefered/acceptable CA... This made it easier for SSL to roll-out, but, like you say, made certificates into commodities and almost meaningless. skip The essence of any fixes in the browsers should be to address the (rather fruitful) diversity amongst CAs, and help the user to make choices amongst the brands of same. Agreed! Some CAs are more equal than others... and the sooner a browser recognises this, the better. Agreed! Except, I think that the user may also be involved in recognizing the more trustworthy CA, e.g. by including also a logo of the CA in the TCA - so I can see, `this site is IBM (since I see their logo) and this was validated by Verisign and/or the USPTO (since I see their `logo certified by` logo(s)). These bodies could issue logo certificates. Exactly! These certificates would only have value if there is extensive verification. We probably lack the technology to do that cheaply right now, and the necessary level of international cooperation. I'm not sure I agree here. I think that many logos (e.g. of international companies) are already well protected by the existing network of trade mark offices. As to smaller companies, they would be protected by the logo but also by including icons/seals of credentials in the Trusted Credentials Area. E.g., getting back to your example, a site such as Perry's, which contain professional crypto information, should be able to get a credential from organizations such as IACR or ACM or Financial Cryptography or... and I guess these places would not give a credential (certainly not to the same logo) for a resturant. So, the site logo becomes more meaningful when accompanied by the Logo Certifying Authority logo, and/or by appropriate credentials. I'm not sure I understand how logo certs would work, as there is still the possibility of same being issued by CA-Nigeria and having remarkable similarity to those issued by USPTO. Let's not pick on Nigeria, but I get your point; but why should you set your browser to trust logo certificates from an LCA you don't trust?? The site can obtain multiple logo certificates if it wants its logo to be internentionally trusted. Until the CA is surfaced and thrust at the face of the user, each browser's 100 or so root CAs will be a fundamental weakness. Including of course the absence of CA, which is something that is nicely hidden from the user. Agreed. We already planned to have the LCA's logo in the TCA but I'll modify the paper (and code) to make this more clear and visible. Thanks! BTW, notice that by default, and considering there is no CA certifying logos yet afaik, you simply have to validate the (regular) certificate on the first time you get a public key from the server... -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com version:2.1 end:vcard
Re: Using crypto against Phishing, Spoofing and Spamming...
* Amir Herzberg: Florian Weimer wrote: * Amir Herzberg: # Protecting (even) Naïve Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites, at http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/trusted%20credentials%20area.PDF The trusted credentials area is an interesting concept. Thanks. However, experience suggests that given the current business models, we cannot build the required logotype registry. All registries which are used on the Internet (for IP address assignments, BGP prefixes, DNS names, and even X.509 certificates) are known to fail under stress. I'm not sure what you mean by `logotype registry`. A body which registers visual elements etc. and assigns them to an owner. Such a registry already exist (off-web), i.e. national trademark offices, e.g. www.uspto.gov. There are simply too many of them, and not all of them implement checks for conflicts. I'm pretty sure I could legally register Metzdowd in Germany for say, restaurant service. These bodies could issue logo certificates. These certificates would only have value if there is extensive verification. We probably lack the technology to do that cheaply right now, and the necessary level of international cooperation. Or, private companies, e.g. verisign, can issue logo certificates, based on the official trademark registers; that shouldn't be hard. But it is, it all boils down to who does the verification, and who pays for it. Identifying someone is not that hard, of course, but how do you know if he or she is authorized to use a resource (be it a trademark or an IP subnet)? As to a registry to hold these certificates - the site (e.g. bank) would probably keep it... and many other places (this is signed i.e. not risky to keep). You still have to handle revocation. Mistakes will happen. 8-/ Finally, of course, until such certificates are available, we simply use the manual binding of logos/icons/names to public keys, on the first time you enter a secure site using a browser with our enchancement. It works great... very convenient, and very clear (see screen shots in paper). Ah, I missed that part. This could be rather helpful if users are able to understand the concept. Have you run any usability tests? BTW, you can emulate it by removing all root CAs from your browser, and just relying on previously stored certificates. Works rather well, although some people who have different threat models sneer at it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
* Hal Finney: Only now are we belatedly beginning to pay the price for that decision. If anything, it's surprising that it has taken this long. If phishing scams had sprung up five years ago it's possible that SET would have had a fighting chance to survive. Wouldn't typical phishing attacks just read like: | We have upgraded our e-commerce server software. In order to use | your PayPal account after August 1, 2004, you have to upgrade your | Elecontric Wallet. This upgrade is free. Download it from: | | http://www.example.com/downloads/set_upgrade.exe I predict that we will eventually move to a SET-like system; not necessarily that exact protocol, but something based on cryptographic authorizations for online purchases rather than the card number based systems in use today. I talked to a financial services provider recently, and they were scared when I proposed that. It brings back horrible memories. To them, the avent of Java-less SSL banking was a real breakthrough. It seems that end-user support issues have plummeted. Even some form of pre-registration of banking sites seems infeasible. In Germany, we have a standard called HBCI which supports smart cards and signed transactions (providing, in theory, end-to-end verifiability), but support overhead seems to be much larger. There still remains the issue that you can provide a good visual approximation to any peace of software just by using JavaScript and HTML. I fear that too many users would fall for that. 8-( In considering such solutions, it is important to distinguish threat models. Phishing is so harmful because it succeeds without even breaking in to users' computers. But is it so harmful? How much money is lost in a typical phishing attack against a large US bank, or PayPal? (I mean direct losses due to partially rolled back transactions, not indirect losses because of bad press or customer feeling insecure.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
At 10:40 AM 7/7/2004, Hal Finney wrote: SET failed due to the complexity of distributing the software and setting up the credentials. I think another reason was the go-fast atmosphere of the late 90s, where no one wanted to slow down the growth of ecommerce. The path of least resistance was simply to bring across the old way of authorizing transactions by card number. both SET SSL encrypted data in transit. an issue is that SET is significantly more complex and provided no additional countermeasure (vis-a-vis SSL) against major remaining exploits like harvesting the merchant transaction file while at rest. there was some issue that SSL was the incumbent ... so SET had to demonstrate significant better ROI to displace it ... rather than significantly higher I with little or no additional R. some SSL: http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 the security proportional to risk reference (using merchant transaction file as example) http://www.garlic.com/~lynn/2001h.html#61 couple minor past refs related to SET business operations http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards another SET issue was that it took a typical ISO 8583 transaction of 60-80 bytes and added a RSA 128 digital signature and issuing certificate of 4k-12k bytes effectively increasing the payload size by a factor of two orders of magnitude. it stripped all the SET overhead off at the internet boundary and transmitted a traditional 8583 message (in part because it was difficult to justify a 100-fold increase in payload size for no obvious benefit) with a flag indicating whether the signature had verified. There was some presentation at an ISO meeting by one of the association business people about the number of 8583 messages with the signature-verified flag turned on and they absolutely knew that there was no SET technology involved (some justification was association was proposing rules that transactions with the flag on would have lower merchant fees). missing is that typical authorization includes a lot of dynamic and aggregation factors (like credit limit) that are totally missing in a simple certificate-based (offline) authentication model. In fact, most infrastructures that involve transactions of any value have migrated and/or are migrating to online infrastructures that involve timely and/or aggregated information something that is missing from a purely offline, certificate-based, static, stale data infrastructure. misc. implications 1) given an online transaction environment, it is then trivial to show that certificates are redundant and superfluous ... because it is possible to access the timely updated copy of the information rather than having to rely on the stale, static copy of the certificate information (designed to satisfy an offline environment requirement) 2) certificate market then becomes relegated to both offline and no/low value (as infrastructures of value migrate to online paradigms) ... there is little/no justification for paying money for certificates if only no/low value infrastructures are involved. 3) w/o significant funding for certificate-based infrastructure, there is little money to underwrite high-integrity certificate-based operations 4) with no high-integrity certificate-based operations, it is difficult to justify using certificates for high-value operations 5) go to #2 as has past frequently noted, the requirement given the x9a10 retail payments working group for the x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payment environments. one of the considerations was being able to accommodate end-to-end integrity ... aka the financial responsible entity for authorizing the transaction also performs the authentication. another issue x9a10 had to address was to address other kinds of risks like the merchant transaction file where the information traditionally has to occur in the clear to support normal business operations (offer something more than the encryption of data in-flight). http://www.garlic.com/~lynn/index.html#x959 lots of posts about certificate infrastructures http://www.garlic.com/~lynn/subpubkey.html#sslcerts misc. stuff on x9.59, identity, authentication, and privacy http://www.garlic.com/~lynn/subpubkey.html#x959 -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
At 10:40 AM 7/7/2004, Hal Finney wrote: SET failed due to the complexity of distributing the software and setting up the credentials. I think another reason was the go-fast atmosphere of the late 90s, where no one wanted to slow down the growth of ecommerce. The path of least resistance was simply to bring across the old way of authorizing transactions by card number. the other issue was rsa public key op overhead (besides extreme payload bloat, extreme additional complexity, and no significant countermeasures for prime exploits compared to e-commerce incumbent SSL). when the initial set specification was published, i did a business profile and a performance profile (including public key operations profile). somebody i knew was playing with bsafe library and tweaked it to run four times faster. I got him to run the set public key op profile on a number of processors. i mentioned the numbers at some set get together and the response from the set people was that it was 100 times too slow (if they had ever run any bsafe they should have realized that it was four times too fast). anyway ... sometime later when they actual set implementations running ... the earlier profile numbers were within a couple percent of measured on actual implementations. i also observed that given nominal extended peak avgs. of 1000/transactions per sec that if SET ever actually became mainstream operational (rather than just toy pilots) ... processing would need something like 100,000 to 250,000 extra processors to handle the RSA op processing load. the counter argument was that SET would take so long to became mainstream ... that by then CPUs might be ten to 100 times faster and it might only require 10,000 to 25,000 (or 1,000 to 2,500) extra processors. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
Florian Weimer wrote: * Amir Herzberg: # Protecting (even) Naïve Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites, at http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/trusted%20credentials%20area.PDF The trusted credentials area is an interesting concept. Thanks. However, experience suggests that given the current business models, we cannot build the required logotype registry. All registries which are used on the Internet (for IP address assignments, BGP prefixes, DNS names, and even X.509 certificates) are known to fail under stress. I'm not sure what you mean by `logotype registry`. Such a registry already exist (off-web), i.e. national trademark offices, e.g. www.uspto.gov. These bodies could issue logo certificates. Or, private companies, e.g. verisign, can issue logo certificates, based on the official trademark registers; that shouldn't be hard. As to a registry to hold these certificates - the site (e.g. bank) would probably keep it... and many other places (this is signed i.e. not risky to keep). Finally, of course, until such certificates are available, we simply use the manual binding of logos/icons/names to public keys, on the first time you enter a secure site using a browser with our enchancement. It works great... very convenient, and very clear (see screen shots in paper). -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com version:2.1 end:vcard
Re: Using crypto against Phishing, Spoofing and Spamming...
There was an early attempt to use cryptography to authenticate online credit card transactions, the SET protocol pushed by Visa and Mastercard in the late 1990s. SET would require PC users to download a digital wallet application which would hold cryptographic credentials that would be used to authorize a transaction. The wallet software would then issue a digital signature when the user approved a purchase. SET failed due to the complexity of distributing the software and setting up the credentials. I think another reason was the go-fast atmosphere of the late 90s, where no one wanted to slow down the growth of ecommerce. The path of least resistance was simply to bring across the old way of authorizing transactions by card number. Only now are we belatedly beginning to pay the price for that decision. If anything, it's surprising that it has taken this long. If phishing scams had sprung up five years ago it's possible that SET would have had a fighting chance to survive. I predict that we will eventually move to a SET-like system; not necessarily that exact protocol, but something based on cryptographic authorizations for online purchases rather than the card number based systems in use today. In considering such solutions, it is important to distinguish threat models. Phishing is so harmful because it succeeds without even breaking in to users' computers. A SET-like system can protect against such scams. Defending against breakin attacks is a harder problem, but that doesn't mean that solving the easier problem is useless. Contrary perhaps to the conventional wisdom, I am optimistic that we will see increases in computer security over the next several years and that break-ins, although not eliminated, will be greatly reduced. This model makes it even more important to move towards cryptographic assurance for payment systems. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
* Amir Herzberg: # Protecting (even) Naïve Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites, at http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/trusted%20credentials%20area.PDF The trusted credentials area is an interesting concept. However, experience suggests that given the current business models, we cannot build the required logotype registry. All registries which are used on the Internet (for IP address assignments, BGP prefixes, DNS names, and even X.509 certificates) are known to fail under stress. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
