[UnoriginalGuy]

Those likely won't be vulnerable even if they implemented their site using the insecure random function. The reason why this works is that you're the only consumer of Java-randomness, as you add additional consumers it becomes infinitely more difficult.

Consumers also don't need to be users, AI players and cards dealt will also consume randomness. You would also need to know the mapping from the random output into the game (e.g. in card games are there multiple decks each assigned 1 value of entropy? 2 decks, 3 decks, etc? Plus any mappings or conversions will make this impossible (as you wouldn't know the real output of the random number generator)).

Ultimately it will likely work pretty reliably locally, but as soon as you stick it on a web service then all bets are off.

[cynicalkane]

In the event tptacek doesn't show up to explain how awfully wrong this is, I'll do my best to fill in.

An attacker who can predict your PRNG and guess a seeded value knows a potentially infinite number of future random numbers. Now all he needs to do is guess what random numbers, from a very small pool of possible numbers, will show up at what time. Devs often code assuming that PRNG numbers aren't predictable at all, so compromising your RNG is like setting your password to "hunter2" in a situation where nobody thinks about limiting the number of guesses.

Such attacks were famously used to steal a lot of money on PlanetPoker, one of the first poker websites. RNG attacks are also deadly in encryption, where it's reasonable for an attacker to be able to make millions of guesses from his laptop computer.

[banthar]

This more probable than you think. Java code is likely to use Collections.shuffle(). That method uses internal Random which is used only for shuffling. Shuffling is unlikely to be used for other purposes than shuffling cards. There isn't that many ways to shuffle them either.

[ivanche]

I worked for 6 years in a company which makes online (gambling) games. I can tell you that anyone who even thinks of using Collections.shuffle() for shuffling cards in production code is an amateur.

[xxs]

shuffle does allow specifying a j.u.Random as second parameter. If you don't use SecureRandom when you have to, it's your own fall.

[ajanuary]

You'd have more luck with fixed-odds games. The APIs for those tend to expose the results of the RNG in ways that are fairly easy to piece together. Some of the API responses will literally tell you enough to know "we picked a random number between 0 and x, and the result was y".