kodbraker

For my case, it was almost certain. As it happened single day, the card i use was a virtual card only used in couple big ecommerce websites etc.

If it was leaked somewhere else, i think they wouldn't bother logging in some unrelated account of mine in an ecommerce website.

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?

What's the blogging engine? Looks familiar