30

This is happening in Visa/MasterCard/American Express, etc. I tried checking in many payment apps and payment gateways that if I enter the correct debit card number, name, valid date, and wrong CVV number, I am able to receive OTP. however, the transaction is unsuccessful due to validation at the last for wrong CVV.

But shouldn't it suppose to verify before I get the OTP? What's the reason, Isn' it a security issue?

Akshansh Shrivastava
  • 439
  • 1
  • 4
  • 10
  • 1
    Even I experienced this issue with paypal also . amount deducted with wrong CVV. – Tejas Pandya Jul 02 '19 at 12:41
  • 5
    @TejasPandya That's not the same issue at all. In the OP's case the "transaction is **unsuccessful**". – DocRoot Jul 02 '19 at 16:02
  • 3
    @DocRoot im not telling that its a same scenario . Im just representing another scenario in which even after invalid OTP amount can be deducted in that flow – Tejas Pandya Jul 03 '19 at 04:57

4 Answers4

90

But shouldn't it suppose verify before I get the OTP? What's the reason, Isn' it a security issue?

This is absolutely NOT a security issue! quite the opposite it's a protection.

Lets go through the steps.

  1. You put in card details.
  2. You put in CVV
  3. You put in the OTP.

The payment is processed if and only if the combination of all of it are correct.

Now assume a scenario where it tell's you the CVV is wrong before the 2FA that is just going to simply give the attacker a chance to better attack.Now the attacker knows the CVV is wrong and can simply change that.While in the correct scenario attacker will have to break 2 Factor authentication to gain that information

yeah_well
  • 3,699
  • 1
  • 13
  • 30
  • 61
    This is an extension of the old rule that one does not reject an invalid username before prompting for the password, because doing so gives an attacker information about what names are valid. Better to let him try to access a nonexistent account than tell him he's wasting his time. – Monty Harder Jul 01 '19 at 18:34
  • 24
    @MontyHarder - Also, despite being somewhat frustrating sometimes, that's why sites also tend to say "Either the username or password entered is incorrect", instead of just telling you which of the two are wrong. – BruceWayne Jul 01 '19 at 20:05
  • 7
    Anecdotally, my bank accepts payments with wrong CVV and correct OTP. I don’t know if that’s the case for the OP’s bank, but it’s an actual risk handling model — completely ignoring CVV in the presence of OTP. – Spc_555 Jul 02 '19 at 05:54
  • 20
    @MontyHarder Despite it being _completely useless as a security measure_ on sites with open registration, as you can check username availability by yourself using the registration form. – user11153 Jul 02 '19 at 14:00
  • 1
    I am using Sodexo food card and it completely ignores the CVV and successfully process the transaction – Akshansh Shrivastava Jul 02 '19 at 14:58
  • @VasilyAlexeev "my bank accepts payments with wrong CVV" - that is unlikely. It is more probable that the payment gateway is not using the CVV as part of the validation. (When prompted, it may only be used on the first transaction or for larger amounts.) – DocRoot Jul 02 '19 at 16:57
  • It actually is a security issue, the CVV is intended as a validator which must not be stored by merchants. And since it is very short it also cannot be stored as a hash. For that reason it is a security feature that only the processor can validate it. – eckes Jul 02 '19 at 18:19
  • @user11153 but getting that information via a bot across all sites is **much** harder because the registration method is non-standard. To a human it is trivial to bypass, but it is enough to substantially delay the process that they'll just move on instead of trying to get at your data. – Nelson Jul 03 '19 at 02:08
  • @Nelson A login method can be non-standard too. That changes nothing. If the attacker targets you it's trivial to change the automated process around such that it can check existing usernames through the registration form if supported by that form. – Hatted Rooster Jul 03 '19 at 13:26
  • @SombreroChicken: Further, even sites that *generally* include a captcha in registration but not logins could include a captcha on login attempts from an IP address where many invalid attempts have originated without facilitating effective false-login-based denial-of-service attacks (making it necessary for a target to solve an otherwise unnecessary captcha isn't exactly an effective "attack"). – supercat Jul 03 '19 at 14:26
  • @BruceWayne "username or password incorrect" is also a more often correct statement. If a user mistypes their username, the system doesnt know thats what is wrong. (Assuming the mistyped username does exist) It might be confusing for some users if it just said "incorrect password" when in fact it was the username that was wrong. – Matt Jul 03 '19 at 17:58
  • 2
    @user11153 This can be avoided by using confirmation emails during a signup process, so I would disagree with your statement about that practice being "completely useless". Upon signup you simply send an email either asking the user to confirm their email, or alert the user that someone has attempted a signup with their email or tell the user to use the "Forgot Password" option if they forget they had an account already. – rickjerrity Jul 03 '19 at 22:50
13

As well as the general rule of not giving the attacker information by rejecting too early, there are some things specific to the payment industry which are somewhat relevant.

Although often presented to the customer as mandatory, the authentication information on a payment is generally used to evaluate risk and to assign liability.

For instance:

  • A payment with no CVV provided at all may be accepted by the issuing bank, but if challenged as fraudulent, the merchant will be liable for the refund. If the payment had been fully authenticated, the card scheme or issuer will assume that liability instead.
  • A payment with an incorrect CVV but correct address, interactive one-time password, and order details consistent with previous behaviour may be accepted as "low risk" by a fraud scoring system.

The reduction of security in both cases is traded for the convenience to the customer. The new version of 3-D Secure (branded as "Visa Secure" and "MasterCard ID Check") is explicitly designed around this idea, with a large amount of automated information capture up-front meaning that interactive authentication will simply be skipped if the transaction is already considered low-risk. The CVV entered is now just one piece of data in this complex analysis.

IMSoP
  • 3,780
  • 1
  • 15
  • 19
2

Developer here. I have worked with a couple systems that send OTP's. Neither required the CVV in order to send it.

As per Vipul Nair's answer, it is good practice to not let an attacker know some input is wrong until the end, so as not to leak what might be wrong. I'd like to add that usually online shops may keep your PAN and other data in their databases, but they are not allowed (by law or by the card issuer) to store your CVV. In some (not all) cases it is the store that sends an OTP, so they would not have a way to validate with your CVV anyway.

Script Kid
  • 215
  • 1
  • 9
-2

Nope, it is not a security flaw. Its instead enhances security. The following 2 cases illustrate why.

Case 1: OTP is only received only if CVV is correct: Since CVVs are commonly 3 digit numbers, it easy to crack - only about 1000 possible combinations. The hacker may try all the possible combinations since cracking this wont take much time. So you CVV can be considered hacked once you get your OTP. Now the hacker has to only crack your OTP which is generally (~ 6 digit number = 1000000 combinations). Total number of combinations needed to hack your account 1000000+1000 = 1001000 combinations. Not much time will be required to generate these many combinations. Hence the card can be hacked easily

Case 2: OTP is received even if CVV is incorrect In this case, you need to get a combination of CVV (3 digits) and OTP (9 digits) correct. Thus the total number of combinations are 10^9. This is about 1000 times the combinations needed in the above case. More number of combinations => More time required to crack and thus hard to crack.

PranavK
  • 1
  • 1
    In Case 1, wouldn't the card issuer block the card long before 1001000 attempts have been made? – Robin Salih Jul 04 '19 at 11:00
  • 1
    This kind of brute force is extremely improbable. It's highly likely that the system would either rate limit the attempts, or simply start blocking them as obvious abuse. And that's just the static CVV part; the OTP system can issue a new token (or require you to wait for a new time-based token) after a very small number of attempts. Knowing that 123456 was incorrect 30 seconds ago tells you nothing about whether it's valid now, but the friction for a user who genuinely made a mistake is low if the OTP system is decently built. – IMSoP Jul 04 '19 at 14:27