Re: New Credit Card Scam (fwd)

2005-07-12 Thread Jason Holt


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)

2005-07-12 Thread James A. Donald
--
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)

2005-07-12 Thread Lance James

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)

2005-07-11 Thread Adam Fields
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]


Re: New Credit Card Scam (fwd)

2005-07-11 Thread Lance James

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]