Ah, yes. True. But all they got were credit cards - it was a version of skimming. Again, no attack on the secure transaction system.
3 is the best choice. The encryption is nowadays pretty reasonable (has not always been so) and you have some hope that your carrier has things set up reasonably.
If your banking password is snatched you are screwed. Setting up an https connection over an already encrypted path helps prevent this - as it can help avoid man-in-the-middle attacks - ones like spoofing your bank’s web site and thus grabbing your password.
Spoofing bank web sites is reasonably easy of you have total control of the traffic. Just sitting to the side and listening to the traffic won’t let anyone get your password, as the communication is encrypted over https. Where it gets harder to spoof a bank’s site is that https requires a valid certificate to authenticate against. This is why certificate signing is such a big deal, and why certificate authorities that don’t play by the rules are a seriously bad thing. If you can get a certificate that says you are bank X, you can do big damage. The problem with spoofing is that many people don’t notice if the bank access is not going over https. (That little lock icon). So no certificate is needed to fool you.
To be clear there is nothing that is unhackable given the appropriate resources and minimal access. The only reliable method is the assume that information will be disclosed and take steps to mitigate the risk by methods like considering a banks fraud reimbursement policies as a part of the selection process.
As an example MacOS and IOS have over 150 trusted CAs and over 75 are EV validated. If any one of those CAs was compromised through either criminal or state actors they could issue certificates that would produce the above indicated green lock icon.
The web of trust has been extended to the point where it will only protect you from the least sophisticated attacks. And if you are on a company PC they quite probably added in an SSL intercepting proxy that will de-encrypt and re-encrypt the data. Even the major, highly related security companies that produce these produce like Palo Alto and Mcafee either downgrade the intended security or break core protocols. Most IT departments still resort to security through obscurity while following an outdated trusted computing model. Some of this is due to the undue complexities of current systems, other times it is driven by user intolerance to true security and other times it is due to an culture of fear induced desire to outsource functions in order to have an external scape goat. But the main challenge is a lack of qualified applicants and budget for headcount.
The SSL cert process if very much optimize around the revenue streams of the involved parties and the expense of security. With such a broad group of white listed authorities it is very unlikely that they are all secure and free of state influence.
The difficulty is that while securing communication between parties with established relationships is feasible it does not present a simple monetization model. As the main goal is to protect against low level attacks and to instill consumer confidence this is unlikely to change.
SSL everywhere is like locking your front door. It may prevent a timid amateur from breaking in but a seasoned amateur thief or a professional knows that can gain entry faster than using a key with a couple of swift kicks.
Note that even WPA2 is quick to break in this era, hopefully you are not using WEP as it is even worse.
A determined assailant can either use public cloud resources or commercial services to break WPA2 keys from just packet dumps.
Plus your home is probably starting to fill with internet of things devices, which are typically poorly secured, never updated and almost always forgotten.
You should still follow best practices to limit your attack surface, but just do so in parallel with other risk mitigation techniques.
One large tip, never save critical passwords in your browser,
As an example why, if you are in using chrome (this is an issue in all browsers but this is the fastest example)
Enter the following in the URL bar,
chrome://settings
scroll to the bottom and click on
Show advanced settings…
Find the “Manage passwords” link under “Passwords and Forms” and click on it.
Select an entry and click on show
While mac users may be asked for their password there is a simple workaround for that too from terminal.
To be fair chrome intentionally doesn’t hide the fact that this is possible.
And in fact they take the high road and admit that obfuscation would just be theater.
As of this date there are no good solutions to protect passwords and most of the widely used two factor authentication method are actually fraught with many of the same risks as password-driven systems.
The point is that there are no known unhackable systems. While above responders have provided links and information to known vulnerabilities, or more correctly delayed public notice of known vulnerabilities, the only safe stance to take is that all systems have either been compromised or will be compromised in the future.
We live in an era where you can scan the entire internet for a vulnerability in well under an hour for only a few hundred bucks.
Yet most “zero-day” exploits will not be publicly reported until the vendor has a fix or until 60 days after a private disclosure.
Add in the lag time for OS updates and product updates, both due to user intervention, tiered updates or update check intervals and the possibility of even patching a known exploit before intrusion happens becomes unlikely.
Incorrect, there are many methods like privilege escalation or remote code execution that can enable this even from unprivliged or non-privilaged methods of access.
Here is a recent example, which was unpatched by over a month by Oracle
Strictly speaking, Leish’s statement is correct… but the catch is that there are often ways to access the administrative features remotely which are not known or intended by the designers, so you can’t actually tell for sure if “its administrative features cannot be accessed remotely”.
Depends if you consider “arbitrary code execution” as access to admin features. Pwning a site may simply bypass all the admin crud and directly inject malware, or execute an appropriate database query to vomit up all the credit cards. Access to the web site’s admin interface is likely not needed.