No way I would log on to a bank account on a public wifi, say at an airport. However, my question is this: Came to mind that with a public connection I type a text file with many numbers and words, including my 4 digit pin. I copy and paste this into the bank logon and it appears as 4 dots.
Can this still be detected, keylogged? (or are those two separate questions?)
Probably a stupid question. Go for it.
A keylogger is a bit of software running on the machine you’re using. If your machine is compromised it doesn’t matter if you’re using it at home or a public network, the keystrokes can be captured. Some keyloggers capture the cut&paste buffer as well so using that method isn’t safe either.
If you’re machine is clean you should still be wary about banking over a public network since you could run into a man-in-the-middle attack.
Generally, connections to a bank are SSL (the URL starts with https://). This means that they are encrypted between the computers. Someone intercepting your signal would not be able to read it.
I haven’t been following how secure SSL is considered these days, but it does give good, basic protection.
The characters you type into a password field are what’s sent by your computer. They display as dots to keep people from looking over your shoulder. A keylogger would know the keystrokes, but the SSL is encrypting data so someone intercepting the signal would have to decrypt it somehow.
The issue is what’s sent that’s unencrypted. Those can be read.
SSL/TLS has taken a bit of a beating recently. There was the OpenSSL Heartbleed bug last year and the POODLE man in the middle attack. A properly patched and configured TLS implementation is still very secure.
The part I bolder is a user interface feature, and wouldn’t make any difference to a dedicated hacked. It’s just there to keep your nosy relative/roommate/co-worker/stranger behind you in line from reading over your shoulder.
So if I go to an airport and set up a wifi hotspot with my laptop (and lets say I call it JFK-free-WiFi to get people to believe that it is a service provided by the airport) can I see all the information being transmitted over that wifi?
General traffic, maybe. SSL/TLS-encrypted traffic from a bank to its clients, less maybe (I mean you can see the traffic for sure, but it will be encrypted).
In order to effectively see that traffic, you would have to present a fake certficate for that bank to entice the browser to encrypt the traffic in a way that you know how to decrypt. Presumably a bank client’s browser knows the bank’s SSL certificate (or the certificate of a signing authority that knows the bank’s SSL certificate), so the browser will issue a warning to the client that something is up.
You can see all the unencrypted information being transmitted over that wifi.
Well, you can see all the encrypted info too, but it’ll just be useless indecipherable gibberish.
So then what is a man-in-the-middle attack that I should be wary of when dealing with my bank?
It’s exactly what you described. It used to work better when many websites for “noncritical” things like email didn’t use encrypted connections. You get quite a bit of protection from encrypted traffic so the middle man can’t easily read it unless that encryption is compromised.
There are tricks/techniques that try to get you to an unencrypted lookalike site so you pass login data unencrypted…then OOOPS error log in again… at the real site this time. 
There’s another layer of protection you may be able to set up which is a virtual private network (VPN). With a fast connection at home and the right router it’s not hard. In that case all traffic (even the stuff that normally isn’t encrypted is encrypted between you and your router. At that point the traffic is sent on, encrypted or not, from home. Anybody between you and your house sees encrypted packets. There are also paid VPN servers that allow you to route your traffic through their servers similarly.
As an example Watchguard firewall will do packet inspection on HTTPS (secure, encrypted) traffic. To do this, it intercepts all attempts to connect to secure sites, and resends the request as coming from the firewall. It then pretends for the client to be the bank or whatever they are trying to connect to. It generates an on-the-fly certificate claiming to be the destination the client was trying to connect to. In this way, it can check for viruses etc. in the traffic - normally encrypted traffic is unreadable unless you are the NSA, and even then, we think no dice.
However, your browser only believes the certificates it’s given if they are signed with an authority certificate chain that links to the trusted authority certificates in its “trusted” list. For users to avoid the certificate errors, they need to add Watchguard’s root certificate to their trusted list. This can be done easily for a large company domain (group policy push, perhaps), for all PC’s that belong to the domain. It’s close to impossible to force random strangers to accept this certificate properly.
This is the problem with man-in-the-middle trying to spoof a secure site. If you could spoof a properly signed certificate, your skills would be in demand from three-letter agencies the world over.
Other handy hints. When Windows 7 or higher asks “is this network work, home, or public” answer correctly. Public means anyone else could be on the same LAN/WiFi, so disallow public access to shared resources. AT home, we might share our whole C-drive between computers without requiring a password. Not a good idea to do this at Starbucks.
Turn on the Windows firewall (or similar function) when in public. You’d be surprised how easy it is to find a hole in a laptop’s defences, especially if you don’t keep your software updated.
A man-in-the-middle attack is when you think you are talking to your bank, but you are actually talking to someone else pretending to be your bank, and that someone else is also talking to you bank pretending to be you. You send requests to the man-in-the-middle, and the MITM decrypts them, re-encrypts them to send to your bank and gets the response from your bank, and sends it back to you, so the MITM seems to behave exactly like your bank does (and to your bank, the MITM seems to behave exactly like you).
Both links of this chain can be perfectly encrypted against anyone else, but the MITM can still read all of the traffic. On a public wifi, the wifi can act as a MITM, pretending to be just a dumb pipe between you and your bank, while actually recording all of your decrypted transactions.
The reason this doesn’t work for any good bank these days is that your banks web site has a certificate with a public key that allows you to authenticate that you are actually talking to your bank. This makes the MITM’s job of pretending to be your bank much, much more difficult.
The thing to be careful of here is that SSL only kicks if you go to https://www.mybank.com. If you just type in www.mybank.com or http://www.mybank.com, it’ll first go to the insecure HTTP version, which CAN be hijacked by a MITM/rogue router and made to look like the real deal.
In day to day use (at home), going to the HTTP version will usually automatically redirect you to the HTTPS version. But because there’s no authentication going on in the HTTP version, an attacker could display anything he or she wants there and it would look to you like it came from the website.
So if you’re on public wifi, always add the S after HTTP yourself and don’t rely on the HTTP version to redirect you. https://google.com, https://facebook.com, https://yourbank.com, etc. And if you get any sort of security or certificate error, stop what you’re doing and proceed no further. Call the number on the back of your bank card and conduct your transaction over the phone instead, or ask for help with the security issue.
Also, some web “security” software like Avast will do their own MITM attack by installing their own root certificate on your system. This means two things: 1) anybody at Avast can see all your traffic if they wanted to, and so can anyone who hacks Avast 2) Avast doesn’t do proper certificate validation and they will open you up to additional layers of MITM attacks. In the above example, if you’re using Avast and you connect to a fake HTTPS site, a normal browser will return a certificate error, but Avast will silently bypass that and make it look like you’re connected and secured. More info here: The Safe Mac » Avast’s man in the middle
So don’t use Avast, or turn off its web shield, if this worries you. And if you use any other web security software, check to make sure its web scanning doesn’t do the same thing.