RE: 3D Secure Vulnerabilities?

[NAHAR ANSHU /NIG/CRP]

Title: RE: 3D Secure Vulnerabilities?

WE HAVE ALREADY IMPLEMENTED VISA 3D AT OUR BANK. 1. LET ME REITERATE: VISA 3D DOES NOT SPECIFY HOW THE ISSUER AUTHENTICATES THE CARDHOLDER. THEREFORE AS AN ISSUER YOU ARE ABSOLUTELY FREE TO IMPLEMENT WHATEVER AUTHNTICATION AND PERSONAL ASSURANCE MECHANISM YOU WANT TO.   2. vBv IS AN ASP SERVICE PROVIDED BY VISA. THIS WOULD HELP THE ISSUERS TO "TRY" VISA 3D, WITHOUT HAVING TO INVEST IN TECHNOLOGY.   EVEN THE PRESENT vBv SERVICE IMPLEMENTS "SSL", WHICH IS GOOD ENOUGH TO ENSURE THAT MERCHANT DOES NOT SCREEN SCRAP, AND ALSO ENSURES THAT THE CARDNUMBER GOES DIRECTLY TO VISA, AND THAT THE MERCHANT DOES NOT "POSE" AS THE ISSUER OR VISA. IN FACT AT PRESENT THE PASSWORD NEVER GOES TO THE ISSUER AT ALL.   3. YOUR POINT REGARDING TWO STEP TRANSCATION PROCESS IS ABSOLUTELY VALID. VISA 3D SPECS DO NOT PREVENT THE MERCHANT FROM SUBMITTING A DIFFERENT AMOUNT FOR AUTHORIZATION. THE ONLY SAVING GRACE IS THAT THE CARDHOLDER CAN DISPUTE THE TRANSACTION AND THE MERCHANT WILL NOT BE ABLE TO DEFEND IT.   4. HAVING HAD SOME EXPERIENCE WITH LIVE IMPLEMENTATION OF VISA 3D, I CAN TELL YOU THAT ISSUER CAN IF IT SO WISHES IMPLEMENT A GREAT DEGREE OF PROTECTION FOR ITS CARDHOLDERS.   HOWEVER WE ARE AT PRESENT USING vBv SERVICE FROM VISA FOR OUR PILOTS. 1. I AM NOT HAPPY WITH THE REGISTRATION PROCESS. IN FACT THE WEAKEST LINK AT PRESENT IS THE ENROLLMENT PROCESS.   2. THERE IS NO PROVISION FOR THE CARDHOLDER TO GO BACK TO THE REGISTRATION SITE AND REVIEW HIS TRANSACTIONS, OR CHANGE THE PASSWORD.   -----Original Message----- From: Jack A. Hudson [mailto:[EMAIL PROTECTED]] Sent: Friday, October 26, 2001 10:17 AM To: 'NAHAR ANSHU /NIG/CRP' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: 3D Secure Vulnerabilities? Thanks for you’re response.  My comments are inline. #1 AS PER IMPLEMENTATION THE POP HAS TO COME FROM THE ISSUING BANK. THE TRANSACTION FLOW IS AS FOLLOWS: 1. CARDHOLDER ENTERS THE CARD NUMBER 2. THE SOFTWARE IMPLMENTED AT MERCHANT'S SITE SENDS REQUEST TO VISA DIRECTORY. 3. VISA DIRECTORY CHECKS IF THE CARD IS A REGISTERED 3D CARDS AND RESPONDS TO MERCHANT WITH THE ISSUER'S AUTHENTICATION URL. 4. THE MERCHANT REDIRECTS THE CARDHOLDER TO ISSUER'S AUTHENTICATION URL. 5. THE CARDHOLDER IS AUTHENTICATED BY THE ISSUING BANK. (CHARGE IS ALSO DISPLAYED TO THE CARDHOLDER) 6. ISSUER PASSES THE SECRET CODE TO THE MERCHANT THROUGH VISA. 7. MERCHANT MAY NOW SUBMIT THE CHARGE. NOTE: 1. IT IS UPTO THE ISSUING BANK, HOW IT VALIDATES THE CARDHOLDER, DIGITAL CERTIFICATES, HARDWARE TOKENS, OR PASSWORDS. 2. IT IS ALSO UPTO THE ISSUING BANK HOW THEY ASSURE THAT TEH CARDHOLDER IS INDEED GIVING THE PASSWORD TO THE ISSUING BANK. 3. WHERE ISSUING BANKS ARE USING VISA'S ASP SERVICES, THERE IS A PROVISION OF A "PERSONAL ASSURANCE MESSAGE". THIS "PAM" IS GIVEN BY THE CARDHOLDER TO VISA DURING THE REGISTRATION PROCESS. I understand the transaction flow.  But I don’t think this answers the first question..  VbV authenticates the cardholder, but who authenticates the password dialog.  How do you know the password dialog isn’t a look-alike, impersonating a real VbV password dialog?  Are you saying the PAM gives a low tech way to authenticate the dialog? I.e. if it weren’t the real dialog, the PAM wouldn’t be right.  Wouldn’t a simple screen scrapper, reading the DOM at the issuer URL circumvent that?   #2   THERE IS NO QUESTION OG PASSWORD BEING BLASTED: 1. THE PASSWORD ACCEPTANCE PAGE IS "POPPED-UP" BY ISSUING BANK. 2. OR VISA IF ASP SERVICES ARE BEING USED BY THE ISSUING BANK. The password IS blasted? There’s no encryption or secret keys or something being used to keep the password out of criminal hands?  It’s just sent over as text?  If so, passwords will probably be nearly as easy for fraudsters to steal as the CC#’s.   #3 IF THE SOMEONE USES THE CARD NO AT A NON 3D SITE, THEN THE TRANSACTION MAY BE DISPUTED. IT WOULD NOT BE A NON-REPUDIABLE TRANSACTION. I understand.  But, the point is, it doesn’t improve the situation.  That can be done today.  And something like 79% of consumers aren’t comfortable with the “zero-liability” response they’re getting today (i.e. because that’s the percentage that say credit card theft is their number 1 barrier to online shopping).   #4   ANSWERED IN THE ABOVE TRANSACTION FLOW. Umm..  Where…  The transaction flow you described stops after authentication is done.  It doesn’t even     I don’t see where your transaction flow addresses my question.  Let me try to clarify.  The question is, what prevents a higher amount from being submitted in your step 7 than is displayed in step 5?  In fact, the merchant could display one transaction and submit another, couldn’t they?  Or does the CAVV embed transaction information so the displayed and submitted transactions can be matched before authorizing?       -----Original Message----- From: NAHAR ANSHU /NIG/CRP [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 25, 2001 8:34 AM To: 'Jack A. Hudson' Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: 3D Secure Vulnerabilities?     -----Original Message----- From: Jack A. Hudson [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 25, 2001 3:26 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 3D Secure Vulnerabilities?   I've read the merchant implementation guide for 3D secure.  Verified by Visa is definitely a step forward.  But, to me it seems overly merchant-oriented.  I mean, merchants are protected pretty well from fraudulent cardholders.  But the cardholder is only marginally safer as a result of this technology.  Or am I missing something?  Here are some of the reasons (questions) I feel that 3D secure still leaves the consumer vulnerable in internet transactions. 1)       The merchant pops up a daughter window for password collection on behalf of the issuing bank.  How can the cardholder be sure the merchant isn't just popping up a look-alike window to collect and keep their password?  AS PER IMPLEMENTATION THE POP HAS TO COME FROM THE ISSUING BANK. THE TRANSACTION FLOW IS AS FOLLOWS: 1. CARDHOLDER ENTERS THE CARD NUMBER 2. THE SOFTWARE IMPLMENTED AT MERCHANT'S SITE SENDS REQUEST TO VISA DIRECTORY. 3. VISA DIRECTORY CHECKS IF THE CARD IS A REGISTERED 3D CARDS AND RESPONDS TO MERCHANT WITH THE ISSUER'S AUTHENTICATION URL. 4. THE MERCHANT REDIRECTS THE CARDHOLDER TO ISSUER'S AUTHENTICATION URL. 5. THE CARDHOLDER IS AUTHENTICATED BY THE ISSUING BANK. (CHARGE IS ALSO DISPLAYED TO THE CARDHOLDER) 6. ISSUER PASSES THE SECRET CODE TO THE MERCHANT THROUGH VISA. 7. MERCHANT MAY NOW SUBMIT THE CHARGE. NOTE: 1. IT IS UPTO THE ISSUING BANK, HOW IT VALIDATES THE CARDHOLDER, DIGITAL CERTIFICATES, HARDWARE TOKENS, OR PASSWORDS. 2. IT IS ALSO UPTO THE ISSUING BANK HOW THEY ASSURE THAT TEH CARDHOLDER IS INDEED GIVING THE PASSWORD TO THE ISSUING BANK. 3. WHERE ISSUING BANKS ARE USING VISA'S ASP SERVICES, THERE IS A PROVISION OF A "PERSONAL ASSURANCE MESSAGE". THIS "PAM" IS GIVEN BY THE CARDHOLDER TO VISA DURING THE REGISTRATION PROCESS.   2)       The user enters their password in this dialog and the issuer checks it.  But how is the password checked for correctness?  It is just blasted over to the issuing bank for validation?  If so, that seems to raise other security concerns (i.e. couldn't a false-merchant intercept the transmission of the password?)   Or does 3D secure use the password as a "secret key" to avoid this problem, since doing so removes the need to transmit the password over the Internet? THERE IS NO QUESTION OG PASSWORD BEING BLASTED: 1. THE PASSWORD ACCEPTANCE PAGE IS "POPPED-UP" BY ISSUING BANK. 2. OR VISA IF ASP SERVICES ARE BEING USED BY THE ISSUING BANK.   3)       Because the cardholder enters a password, they may feel comfortable that their card is safe with that merchant.  But, even if the merchant implements VbV and prompts for a password, once the credit card number is stored in their database, it is just as vulnerable to theft as a non-VbV enrolled card.  A VbV card can be stolen and used at any merchant that doesn't prompt for the password.  Merchants are right to feel protected by VbV.  But why should consumers feel protected when they see the password prompt? IF THE SOMEONE USES THE CARD NO AT A NON 3D SITE, THEN THE TRANSACTION MAY BE DISPUTED. IT WOULD NOT BE A NON-REPUDIABLE TRANSACTION. 4)       Let's say the cardholder enters their password correctly and the merchant proceeds to submit the transaction.  What (aside from eventual human detection) prevents them from submitting a higher amount than the cardholder authorized at the password prompt?  For example, the password prompt shows transaction details of 14.95.  But when the transaction is sent to the acquirer for authorization, what prevents the amount from increasing to, say 149.55 (which the merchant could claim as accidental)? ANSWERED IN THE ABOVE TRANSACTION FLOW.   5)       The merchant implementation guide says, if the password is entered wrongly, the merchant cannot submit the charge.  But, what is to prevent them?  They could submit the charge as a card-not-present transaction (i.e. without the CAVV), and reassume liability if a chargeback results. TRUE!   Thanks     "This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI or its subsidiaries and associated companies (including ICICI Bank) "ICICI Group", are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group. Before opening any attachments please check them for viruses and defects." "This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI or its subsidiaries and associated companies (including ICICI Bank) "ICICI Group", are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group. Before opening any attachments please check them for viruses and defects."