For a website which claims to have more than 94000 BTC wagered, I don't think an argument like "not worth the effort for us" sounds plausible. You just don't want, admit it.
I don't care how it sounds. It's
actually not useful.
Claiming the information is available in other parts isn't a valid excuse too. Is there some place in the website saying this? No? And what about new users?
As was pointed out, a MITM attack would
immediately be detected and the attacker would gain, at most, one bet's worth of coin, regardless of the target.
It depends on the wallet. blockchain.info uses an HTTPS conection, so it's unlikely to be affected. Even if you're affected, the HTTPS conection will be gone and the lock in address box of the browser won't appear.
This is ridiculously incorrect. The wallet used has no bearing on the website at all; it functions identically whether you use a web wallet, desktop wallet, or phone. LuckyBit's website does not, and cannot, interface with any wallet.
About the LAN attack, well, you can take care about your network, but when this goes to your ISP, international routes and so, you lose the control of what goes on.
And so does any MITM attacker. Derp.
But is responsability of the user to verify if the network is secure.
Do you really expect average people to use wireshark in order to detect if there's a MITM happening?
No, I expect the average user's network administrator to. It is your responsibility to secure your network, or report to your network operator to have it secured. It is not LuckyBit's responsibility to take measures to prevent malicious providers from interfering with our clients. We have no reason to expend resources to protect a theoretical user from a theoretical attack that could theoretically steal only one theoretical bet.
It's much more simple having an HTTPS website. If it isn't encrypted, there will be lock on the browser. If it presents an invalid certificate, you'll receive an alert.
No, it's not "much more simple". It's an additional layer of complexity that doesn't solve a problem. If a MITM attack is ongoing, the user won't know the difference - lock or no lock.
3.- MITM have a tool called sslstrip to bypass the SSL connection, so, change the site to SSL will fix nothing about the attack.
sslstrip turns HTTPS traffic in HTTP. But to be effective, the user needs to go further and ignore the lack of HTTPS. Aside of this, there are tools and settings to avoid these types of downgrading, like HSTS.
Viruses and malware frequently adjust browser settings behind the user's back and do exactly this type of thing. A MITM attack would probably be paired with some infection that would facilitate sslstrip/HSTS infection, allowing the operation to complete as desired by the hacker. To a hacker, this additional step is relatively trivial, so
SSL wouldn't pose a significant barrier to the attack you describe.
Well, a more sophisticated attack can try to replace the entire game too.
With what? That makes no sense. The game engine operates independently of the site; even a total rewrite of the front end won't change the operation of the game at all. If a hacker is going to the trouble of rewriting the game frontend, then why not go whole hog and clone the whole game (which
has happened)? It's easier, less risky, and more profitable than bet-hijacking.
And again, the "this never happened" isn't a good reason. You need to consider the possibilities and risks, not the "it never happened".
That was a last point. We
have considered the possibilities and risks. The risks with this model are
smaller than the risks involved in using SSL. The effective result for the user is
not a net gain. This decision was made two years ago and has not been a hindrance for us, nor has it ever led to the loss of customer funds. Using SSL would present increased overhead for us, but not increased security for any party.
But it seems you think it's more simple to deal with an eventual problem than fixing the origin of it. OK, it's your choice. A bad choice, I think, but, well...
It
is more simple to deal with a problem.
This is not a problem. We don't need SSL. There's no personal user data collected by the site - at all. There is no personal information retained by the site - at all. User funds are transmitted via blockchain only - no site authorization ever happens. There is
literally nothing a hacker could interfere with that could pose a risk to our operation or our users. The entire site frontend could be removed entirely and the game will still operate just the same.
SSL's primary purpose is to
secure data sent and received between the operator and the user. We have no private data being transmitted - none. So there is actually no use for SSL for us - it is an unjustifiable expense.
Your theoretical attack can be only executed in a very specific circumstance with a specific target in mind. LuckyBit isn't the target nor does it facilitate that circumstance - therefore, LuckyBit shouldn't even consider that possibility in its design because it simply doesn't have any bearing on the operation either way.
tl;dr: not worth the effort for an attacker, not worth the effort for us. Still.
