I need to know on what basis I can assess the trustworthiness of application usage (accessing private accounts) on public networks.

As an example, I'd like to play Diablo 2 LoD while I'm at an Internet cafe, but I'm worried about someone sniffing my network traffic and capturing my battle.net credentials. How can I tell if the password is being sent securely, or in cleartext?

  • 2
    Can you clarify what you mean by "internet cafe"? Do you mean using public wifi from your own computer, or using a computer provided by the cafe? In the former case security of your credentials is not too hard, but it is impossible in the latter case.
    – nealmcb
    Commented Sep 21, 2011 at 17:24

4 Answers 4


One way of checking this would be to run a packet sniffing tool such as wireshark, as this can give you information about the protocols being used, and can show you similar information to what someone else would see if they're sniffing your connection.

I'm presuming here that Battle.NET uses HTTP(S) for authentication so essentially you'd be looking for the difference between a plaintext HTTP connection and an HTTP(S) connection.

In practical terms a good way to do this is to close as many other programs before you run the sniffer, to minimize noise and make it easier to isolate the relevant traffic. If you can identify what IP addresses the servers run on you can set-up a capture filter on wireshark for only those IP addresses, which would make it even easier.

Then start the sniffer and log-in to Battle.NET. Once you're logged in stop the sniffer and examine the output.

what you're looking for is the protocol that's in use for the connection if you see connections using HTTP and you can see the contents of the connection (right-clicking one of the packets that's sent to the server in wireshark and using the "follow TCP Stream" should show you some details.)

If the connection is using HTTP(S) then you shouldn't see any plain text after the connection is established, whereas if it's using HTTP you'll see plain text detail of the traffic being sent back and forth.

Another quick and dirty check would be to save the packet capture file from your login and use a string search tool (like findstr in windows or grep in linux) to check for your password or username. If you see them then they're being sent in the clear, if you don't then they're at least being obfuscated, and may be being encrypted.

There's still some other risks, especially if you're using someone elses computer in an internet cafe as they could install keyloggers if they wanted to and/or modify trusted certificate authorities which could allow them to intercept traffic sent over SSL.

Bottom line is that if you use a system controlled by someone else on their network it's likely that they can get access to data you process at that time.

  • I will check with wireshark. Commented Sep 21, 2011 at 15:48
  • 2
    Note that this takes some experience / professional knowledge. You have to discern which packets constitute the login, perform repeated testing (determine challenge / response, encryption, etc.), and be able to recognize common obfuscation (base64 encoding, etc) that may insecurely hide a plaintext password from search tools.
    – Jeff Ferland
    Commented Sep 21, 2011 at 16:40
  • @Jeff Ferland true it does require some looking/experience. If you can determine that SSL is definitely used for the connection (identify the destination IP address/Hostnames) and you've no reason to believe that rogue certs are in play you should be reasonably safe from sniffing in the traditional sense. Commented Sep 21, 2011 at 18:46
  • Am I missing something? because this proposal sounds to me like "shoot the revolver at your foot and see if it hurts. If it doesn't then it's safe". In other words, if you determine in the packet information after the fact that the password was sent plaintext, then you just shot yourself in the foot. Correct? Commented Sep 29, 2011 at 19:35
  • 1
    Well Gotta say that wasn't the intent. The intent would be to check in a controlled environment first, to determine whether you would be sending them when trying later in an untrusted environment. Commented Oct 1, 2011 at 9:54

"Credentials" and "Internet Cafe" in the same sentence...

Any publicly available computer is susceptible to be the host of a keylogger. From a slightly paranoid point of view, your credentials are toast as soon as you type them on the keyboard, regardless of what happens on the network.

Now if you bring your own machine (e.g. the "Internet Cafe" is actually a WiFi hotspot -- in a venture commercializing hot beverages, if you want -- and you have your laptop with you), then you can consider the access to be no worse than Internet in general. Granted, network sniffers are more often encountered in public WiFi hotspot, but that does not really change things at a fundamental level: if there is a protocol weakness which can be exploited in that situation, then it could also be exploited when you connect from your home.

  • I generally apreciate a mild level or paranoia, but the home situation depends on how you are connecting at home: wired or wireless, and what physical exposure exists.
    – this.josh
    Commented Sep 22, 2011 at 7:30
  • 2
    I would replace "paranoid" with "practical". I've always had this urge to install keyloggers on countless internet cafe's. With just a few $$ you could get a load of information ranging from personal details to even financial info sometimes. For some reason, I never gave in to this urge. Doubt many others in my place would have done the same...
    – Christian
    Commented Sep 22, 2011 at 10:12
  • 1
    @Christian +1 for "For some reason, I never gave in..."
    – Rory Alsop
    Commented Sep 22, 2011 at 10:34
  • What about the risk of someone making an ad-hoc wifi spot with the same name as the public one? Then the attacker could do a man-in-the-middle attack, could he not? Commented Sep 29, 2011 at 19:32

There is no good answer to your question.

The obvious answer doesn't work. The obvious way to test this is simply sniff the wire, and see if your password goes across it. You can run simple tools like 'ngrep' or 'Snort' to search the network for you, so that you don't have to deal with complicate tools.

But this doesn't work. This only tells you if the application has made an obvious error. The problem is that most systems do not make obvious errors, but subtle ones.

Take Diablo2 LoD as an example. It uses a challenge/response mechanism to logon, so that your password isn't sent across the wire.

But a hacker can sniff the wire and capture both the challenge and response. The hacker than try a billion passwords per second to see if they match the challenge/response. If you've chosen an easily guessed password, the hacker will quickly discover it.

What I'm saying is that Diablo2 LoD is secure against the most obvious kind of password sniffing, but is not adequately secure against a dedicated hacker, unless you choose a long/complex password that they cannot guess, even at one billion attempts per second.

The same is true of pretty much every protocol. They are all "insecure" after a fashion. It simply is a question of how much effort hackers have spent cracking it. I reverse engineered Diablo2 LoD back in the day, but haven't played it for 10 years, so I don't know there state of the art. There might be a simple hacker tool out there for sniffing and cracking passwords, or there may not. If there such a tool, you'd be a in danger playing it at a cafe. If such a tool doesn't exist, then you are probably safe.


I'm not trying to get into the "open source is good" mantra, but this is one place where it makes sense. If the application is open source, you can easily asses its behavior. A closed-source application is much more difficult, and I'd argue that one with some form of anti-cheat system is even more difficult. D2, for example, had both an anti-cheat mechanism and a cd-drm mechanism (if my memory is right). Where to start? Packet sniffing could be a good starting point. Still I think you're in for a few nights if you want to end up with a good conclusion...

  • +1, true, but actual analysis of a complex third-party program can be very difficult.
    – sharptooth
    Commented Sep 22, 2011 at 14:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .