The rate they try becomes very non frequent when they use multiple card validation apis. I'm not sure how it can be related when it's different pan numbers, different source ips etc.
Enumerating CVC2 with a single PAN is a different story.
I agree with the seperate card. That was my seperate card and luckily the amount was not quite big because of that.
>Weak point was a password that lead to another merchant not using 3D secure
Well leaking a password shouldn't cause leaking a whole ass credit card data imo. The same data is printed on physical receipts the markets print, sometimes 4 digits, sometimes 10 digits. It's still possible to brute force from unattended physical receipts on the market.
hey, great work. I couldn't find the specifics of the benchmark. Is there, by any chance you compare 1 instance of single threaded redis running on 64vcore to a multithreaded key-value store?
Can we see such disparity in benchmark even if we run Ncore instances of redis in parallel?
Thats what i did. I did not try to cheat. Running N redises is a completely different product. You will have n listening ports and your loadtest program will need to connect to each one of them. The power of dragonfly is that it hides all this complexity. You are saying that comparing single threaded redis to df is unfair, and i say - comparing n redises to df is unfair because you compare different products.
If it was leaked somewhere else, i think they wouldn't bother logging in some unrelated account of mine in an ecommerce website.