• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Brute force credit card Attacks



<< Hmm, wise not to require passwords, we wouldn't want security now would we? >>


It's the new "customer friendly" tactic to improve transaction speed. Why bog down the customer with one more thing to enter when validating a credit card?
 
Not surprising but if more sites required the "credit card ID" (3 digit number on back of card) that would decrease the liklihood of them getting the number by 1000x.

Also any internet transaction should be checking the number of attempts to an IP. Allowing somebody to sit there and drum away on random numbers is sad.
 
Having integrated with many different merchants in the past, I could write a program to do this very thing in a very short time. Whilst the storefront may require you to login to reach their payment pages, that doesn't mean you can't simply login, get to the payment page, extrapolate all the form fields, and brute force away.

Many merchants don't require any form of authentication aside from a simple "merchant key." Nevermind the fact that these "merchant keys" are often easily obtainable. Having this information, you're thereby circumventing the storefront, and brute forcing directly against the provider. Most providers (Verisign, Authorize.net) do not limit the number of attempts so long as the order_id (or whatever key you define) are different.

I do agree with Skoorb though. The storefront should, at a very minimum, limit the number of transaction attempts by at least the ip. We do this very thing in our framework. We allow them three attempts to successfully process their card (maybe they mistyped their card number, etc.), then we fail the transaction and notify the user.
 
I'm having a difficult time feeling any sympathy for a merchant who gets nailed with the gateway fees because of a brute-force credit card number attack an the processing service. A strong password at the terminal, and requiring that password on all transactions virtually eliminates the problem. I get these attempts quite frequently. None has ever gotten through.

Russ, NCNE
 
This is pure BS:



<< Some merchants have complained that Authorize.Net is to blame, because only a login name ? and not a password ? is required on many systems to ?run? a credit card check. >>



If the account is setup to require only the login, then the merchant hasn't configured the terminal correctly. There IS an option to require password authentication. They are either too lazy, or to stupid to use it.

These whiners should RTFM.

Russ, NCNE
 
Back
Top