Let’s see, software: hackable to the extent that expensive software (starting with Windows operating system) is easily used by non-paying users. Websites, appear to be easily hackable by those in the know. My question really deals with https webpages, which are usually used for payment and checkout, etc.
Are these unhackable? Or what?
Https is used for much more than just payment gateways. There is a school of thought that suggests any website that requires authentication should be https end to end for all content. I tend to agree with this.
Very simple sites are probably close to unhackable. But anyone who claims unhackability is not going to be doing so with real confidence. Even tiny a server with a read-only file system is probably subject to some hitherto unknown exploit if you set the stakes high enough to interest people with an interest in finding holes.
Complex websites tend to be backended by databases, and you get such glorious problems as SQL injection vulnerabilities. It only takes one careless bit of code to open the door, and your site is pwned before you realise. Obligatory XKCD.
So you are saying that https is unhackable? If so, why is it not the standard?
You can’t say anything as simple as “https is unhackable”. Someone, somewhere has the needed credentials to be allowed in, and depending on how careful they are, it might be possible to get those credentials without ever interacting directly with the https site. At best, all you can say is that the https protocol does not itself enable any vulnerabilities. More realistically, you should say that the https protocol does not enable any known vulnerabilities.
Got it, thanks for this explanation. It’s the credentials which could possibly be “stolen” then. So, what is it that makes the https protocol (at the present moment) unhackable?
This was comment on the value of https. The problem is that many many sites use https for the authentication phase, and then drop back to http. Great, so once authenticated you are minimally subject to MitM attack reading your traffic. Such as all your email.
Https is more expensive in terms of cycles to implement and thus slows things down. Although this is probably a specious argument now. Https only protects against certain exploits anyway. It doesn’t do much to make a site any less hackable. It does protect users of the site against certain attacks.
Https itself has been subject to some unfortunate bugs in implementation and deployment. OpenSSL and the Heartbleed exploit in particular, but there have been plenty of others. Poor deployment choices can also result in vulnerabilities.
Here’s the Wikipedia page on the security protocols used by https.
Search for the word “deprecated”. Notice it appears several times.
The difference between the deprecated versions or ones not deprecated is that there is no publicly known weakness … yet.
In addition, these depend on sites keeping their keys private. That’s not exactly 100%.
There is also a weakness in the certificate authority that tells you whether the certificate of a site actually is issued to that site. Some authorities have basically gone rogue and caused all sorts of problems. There’s a couple in China that are being naughty.
You’re talking about several different things here that are only slightly related.
HTTPS (really HTTP over TLS) provides an encrypted channel between your web browser and a web server. The encryption it provides (today) is fairly good. If an eavesdropper intercepts an encrypted stream between your web browser and your bank, it is very unlikely that he will be able to decipher it.
That is completely unrelated to what is happening on the server. If the web application is vulnerable to an SQL-injection attack (as mentioned above) it doesn’t matter that the server is using HTTPS. HTTPS will happily take my malicious request, encrypt it, and send it to the server, which will decrypt it, and send it to the database.
It also doesn’t matter if a site is using HTTPS is the infrastructure it’s running on is vulnerable. They could be running some outdated network service on the same box as the web server or database which is vulnerable to a memory exploit that lets me run arbitrary code. Or maybe they forgot to change the default password on a forgotten monitoring daemon somewhere. Or maybe the secretary can easily be tricked into emailing me an admin password.
HTTPS itself has potential problems. If a certificate authority is compromised (in any of the above ways) I can start signing TLS certificates and pretending to be hosts that I am not. Oops, I just got your bank password. Even though it’s encrypted, I snuck my encryption keys onto your network with my forged certificate, so I can read everything you send.
Nothing is “unhackable.” Even a one-time pad (a mathematically perfect form of encryption) is useless if the bad guy manages to get the key. Or if the good guy generates the key the wrong way. Or if he’s tricked into doing so.
So good security comes down to properly-trained engineers doing their best to monitor and mitigate threats. That means using established best-practices, keeping software up-to-date, not writing their own shitty software, and regularly auditing code and your network design to look for vulnerabilities. And then fixing them.
As long as people are involved, nothing is unhackable.
In this comm chain, what about when I talk to my bank, say, over a not-hard-to-hack wifi?
Assuming https is implemented correctly by your bank and your web browser, and assuming none of the associated credentials have been compromised, then having an insecure link in between them should not be a problem. Modern crypto algorithms do not require any of the interactions between the parties to be secret.
Of course there are still two "assuming"s in that sentence.
Given sufficient time and funding, you can hack just about anything.
The people who think their system is unhackable are probably the most vulnerable.
On the subject of associated credentials. Lenovo had a big scandal a few years ago. Computers came with superfish which put additional certificates so that they could put up additional ads into encrypted web pages. The additional ads were bad enough but they way they did it opened up the possibility for man in the middle attacks.
A more coherent question is hackable by whom. Secure payment systems are not presently hackable by non-state actors, but the NSA and perhaps other governments can do it.
Another important distinction is between “hacking” in the sense of unauthorized remote access and “hacking” in the sense of any unauthorized access. If somebody goes through the effort to put malware on your system or to use social engineering to get your passwords, then all bets are off even if you’re using the most advanced encryption that humans have.
If you really wanted to be sure that your system was unhackable, you’d need to start by examining the hard drive holding your programs with an electron microscope or something similar (make sure its display isn’t computerized!) to check the pattern of magnetic domains, convert them to 1s and 0s by hand, and then check the relevant portions of your computer’s CPU to determine the opcodes for its machine language, and then manually check what the program represented by your disc’s magnetic domains does what it’s supposed to do. Oh, and be sure to trace all the wiring between the disc and the processor, too, to make sure there’s nothing in between that could re-interpret the data. Anything less than that, and you’re potentially vulnerable to a Kernigan attack.
What do you mean by “secure payment systems”? TJ Maxx, Home Depot, and Target all were famously hacked, with millions of credit card numbers harvested.
The secure payment system wasn’t hacked. What was hacked was their customer database. This is part of the problem you see, companies place a lower bar on securing stuff that won’t cost them money. Banks are very keen that the actual payment gateways are secure. It is very hard to actually move money around by hacking the systems that move the money. So criminals go for the soft targets. And customer databases are a great one. The stolen credit cards numbers will be on-sold and used, probably only once, to effect things like triangulation scams.
Hacking a secure payments system would mean the ability to enter the system as an arbitrary customer and siphon money from their account in some manner, or make purchases on that system as that customer.
I am pretty sure that in the Home Depot and Target hacks the point of sale terminals were hacked and not the customer database.
Can you elaborate a little on this? As it happens, I was in the dog park shuffling stuff, or preparing to, with my Amex app, my Chase app, and my PayPal all open.
In a public park. I chose not to use the free AT&T.
So these three situations are different, right?
Is it easypeasy to read whatever I type in situations 1 but harder in 2? And between 1 and 3, which is easier to read? And (to confirm), you say that even if my password is snatched in any of the three situations HTTPS is still tight? I don’t understand that in the least.
I chose door number 3, BTW. Was that idiotic?
I was referring to the systems that encrypt your financial data for transactions on the internet, when properly implemented. Obviously, there’s lots of other ways to get that data aside from the transport layer encryption, as in the cases you cite.