Re: New Credit Card Scam (fwd)
Jason Holt wrote: On Mon, 11 Jul 2005, Lance James wrote: [...] place to fend off these attacks. Soon phishers will just use the site itself to phish users, pushing away the dependency on tricking the user with a "spoofed" or "mirrored" site. [...] You dismiss too much with your "just". They already do attack plenty of sites, but they also phish because it has a larger return on investment. Security is the process of iteratively strengthening the weakest links in the chain. I'm being misunderstood - Cross-User attack concepts specifically is what I'm referring to. The straight on attacks on sites are definitely a processed phase within the many attack vectors they are performing, I'm just making clear that the businesses need to start working on those weak links. -Lance -J -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: New Credit Card Scam (fwd)
-- Adam Fields <[EMAIL PROTECTED]> > But it's so much worse than that. Not only is there no > standard behavior, the credit companies themselves > have seemingly gone out of their way to make it > impossible for there to be any potential for a > standard. Widely shared secrets are inherently insecure, and no good practices exist to make them secure. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG pPiA9t4S8XPLqBdKsuV/tb+p7tvWdaBMwkYer7hl 4+JSXe6MBo4npe1jgiYmnZNAqOAsX9u+daHcBra01 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: New Credit Card Scam (fwd)
On Mon, 11 Jul 2005, Lance James wrote: [...] place to fend off these attacks. Soon phishers will just use the site itself to phish users, pushing away the dependency on tricking the user with a "spoofed" or "mirrored" site. [...] You dismiss too much with your "just". They already do attack plenty of sites, but they also phish because it has a larger return on investment. Security is the process of iteratively strengthening the weakest links in the chain. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: New Credit Card Scam (fwd)
Jason Holt wrote: I remember the first time a site asked for the number on the back of my credit card. It was a Walmart or Amazon purchase, and with no warning they redirected me to some site with a questionable domain. I thought for sure my session was being hijacked, and my bank had given me no idea what the number was for or whether it was something I was supposed to give out. To me, this is closely related to the discussions we have here about web browser security semantics. With a very good understanding of the underlying PKI, we can usually sort out "secure" from "suspicious" site behaviors with some discussion, but how is the average user (or even the average engineer) supposed to cope? Is there a standard or even just a document somewhere that defines best practices for both server and user behavior with respect to SSL web sites and credit card transactions? Or are we leaving them to forward emails to each other warning them not to give out their 3-digit codes over the phone, and that they had better make sure their Dell doesn't have a DHS keylogger installed... Even with standards in place for the consumer, that's only half of the circle. Phishers/Scammers are evolving rapidly and are either black hats themselves or have access to employing black hats to compromise sites, or perform cross-user attacks on the user. Companies like Amazon are only as secure as how they have devised their infrastructure - and as you and everyone else here knows, SSL is one layer of the "security in depth" infrastructure model. This threat vector has not been addressed by commercial entities that offer transaction services for many reasons, one being that the procurement process takes a long time just to get any security technology in place to fend off these attacks. Soon phishers will just use the site itself to phish users, pushing away the dependency on tricking the user with a "spoofed" or "mirrored" site. -J -- Forwarded message -- Date: Mon, 11 Jul 2005 11:28:50 -0700 To: undisclosed-recipients: ; Subject: New Credit Card Scam I got this from a co-worker today: Apparently, they don't ask for your number, just the 3 digit code on the back. They'll tell you they're calling from your Visa or Mastercard company and that they're trying to verify whether or not you've made a $497.99 purchase from a company in Arizona or something. They'll tell you to call your credit card company if you have any questions, etc, and they never ask for your card number, so it sounds pretty legit, but it's not. If it does happen to you, within a few minutes of the phone call you'll have a charge for $497.99 on your card. You can always call the credit card company yourself and make sure they're the ones wanting to check about fradulent charges, so if you get a call that sounds fishy, just tell them you'll call them back at the number on your card. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: New Credit Card Scam (fwd)
On Mon, Jul 11, 2005 at 09:37:36PM +, Jason Holt wrote: > I remember the first time a site asked for the number on the back of my > credit card. It was a Walmart or Amazon purchase, and with no warning they > redirected me to some site with a questionable domain. I thought for sure > my session was being hijacked, and my bank had given me no idea what the > number was for or whether it was something I was supposed to give out. The 3-digit code is stupid. It protects against one thing and one thing only - someone getting an imprint of the card without copying down the 3-digit number. But only if you never give it out. According to at least several credit card companies, it's supposed to be okay for you to give this code out to vendors when you make a purchase. > To me, this is closely related to the discussions we have here about web > browser security semantics. With a very good understanding of the > underlying PKI, we can usually sort out "secure" from "suspicious" site > behaviors with some discussion, but how is the average user (or even the > average engineer) supposed to cope? Is there a standard or even just a > document somewhere that defines best practices for both server and user > behavior with respect to SSL web sites and credit card transactions? Or > are we leaving them to forward emails to each other warning them not to > give out their 3-digit codes over the phone, and that they had better make > sure their Dell doesn't have a DHS keylogger installed... But it's so much worse than that. Not only is there no standard behavior, the credit companies themselves have seemingly gone out of their way to make it impossible for there to be any potential for a standard. -- - Adam ** I can fix your database problems: http://www.everylastounce.com/mysql.html ** Blog... [ http://www.aquick.org/blog ] Links.. [ http://del.icio.us/fields ] Photos. [ http://www.flickr.com/photos/fields ] Experience. [ http://www.adamfields.com/resume.html ] Product Reviews: .. [ http://www.buyadam.com/blog ] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
New Credit Card Scam (fwd)
I remember the first time a site asked for the number on the back of my credit card. It was a Walmart or Amazon purchase, and with no warning they redirected me to some site with a questionable domain. I thought for sure my session was being hijacked, and my bank had given me no idea what the number was for or whether it was something I was supposed to give out. To me, this is closely related to the discussions we have here about web browser security semantics. With a very good understanding of the underlying PKI, we can usually sort out "secure" from "suspicious" site behaviors with some discussion, but how is the average user (or even the average engineer) supposed to cope? Is there a standard or even just a document somewhere that defines best practices for both server and user behavior with respect to SSL web sites and credit card transactions? Or are we leaving them to forward emails to each other warning them not to give out their 3-digit codes over the phone, and that they had better make sure their Dell doesn't have a DHS keylogger installed... -J -- Forwarded message -- Date: Mon, 11 Jul 2005 11:28:50 -0700 To: undisclosed-recipients: ; Subject: New Credit Card Scam I got this from a co-worker today: Apparently, they don't ask for your number, just the 3 digit code on the back. They'll tell you they're calling from your Visa or Mastercard company and that they're trying to verify whether or not you've made a $497.99 purchase from a company in Arizona or something. They'll tell you to call your credit card company if you have any questions, etc, and they never ask for your card number, so it sounds pretty legit, but it's not. If it does happen to you, within a few minutes of the phone call you'll have a charge for $497.99 on your card. You can always call the credit card company yourself and make sure they're the ones wanting to check about fradulent charges, so if you get a call that sounds fishy, just tell them you'll call them back at the number on your card. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
