While the power struggle between Google and the Certificate Authorities (CAs) continues, online security remains a work in progress despite the urgent need for better machine identity protection.
Following the release of Google Chrome 68 next week, the browser will begin flagging all HTTP sites without a valid TLS certificate as “not secure,” aiming to warn users with an extra notification in the address bar. TLS certificates establish and validate the identity of a machine during an HTTPS session.
This move by Google has intensified pressure on website owners to switch to HTTPS in an attempt to bolster security.
It comes as no surprise that the urgency to adopt HTTPS is big: Chrome, after all, is the most popular web browser in the world, holding 54.12% of the browser market, according to StatCounter.
The fear of alienating consumers is real as more and more people opt to shop, share and do their banking online.
Adding to this urgency, the vast majority (87%) of Internet users will not complete a transaction if they see a browser warning on a web page, according to Ipsos research from earlier this year. Furthermore, 58% of respondents will go to a competitor’s website to complete the purchase.
Not everyone in the cyber community shares this urgency. Some cyber security experts like Paul Moore remain skeptical that a site doesn’t have vulnerabilities only because it deploys TLS.
And, director of the Canadian Institute of Cybersecurity at the University of New Brunswick, Ali Ghorbani, said almost all sites with login or data collection don’t need to use HTTPS.
Plus, the switch to TLS may not be bullet proof since we know that there are a number of HTTPS sites with valid certificates that are, in fact, malicious phishing sites. As an example, iterations of PayPal, which is one of the most phished websites in the world, are used by cybercriminals to direct users to fictitious sub domains to steal their credentials.
These look-alike sites make visitors think they’re interacting with a trusted website prompting time-strapped users to regularly click through them out of sheer convenience. And it’s precisely this type of user behavior that can really open the floodgates to attacks.
While warnings and pop ups might emerge on these websites, many visitors are often so impatient to get to a page or complete a transaction that they ignore the warnings in order to skip to finish.
This is made worse on mobile devices where screen size is comparably smaller than on laptops and desktops. What’s more, mobile devices are considered even riskier for other reasons – they often blur the line between personal and corporate communications, impelling hackers to use these platforms and access enterprise credentials via chats.
Extended validation (EV) certificates require enterprises to invest more time and effort than the certificates validated by a domain or an organization (DV or OV certificates).
Certificate authorities (CAs) including DigiCert and GlobalSign argue that EV certificates offer a higher level of assurance against fraudulent use. EV certificates verify that a trusted third party (the CA) has authenticated an organization’s identity and scrutinized information for domain names considered high-risk for phishing and other counterfeit activities.
Because they maintain a database of names contained in previously rejected certificate requests, the case goes, they raise the bar of due diligence.
Or do they?
Still, others argue EV certificates may be far too dependent on the user behaving a certain way in order for this security mechanism to work.
According to security researcher Scott Helme, the problem with EV certificates is that they place some pretty big requirements directly on the user. Specifically, the user must first know the domain name of the company they want to visit as well as the company’s legally registered name, he said in a post on his website.
On top of that, the user must also validate that the name and domain are correctly shown by the browser.
Deloitte’s report, Mobile device security risks: Keeping data safe also highlights that the most vulnerable link in the system remains, as it always has been, the users. As the battle between Google and CAs goes on, Deloitte maintains that companies are not at the mercy of the attackers, despite the risks associated with the use of mobile devices.
Much depends on the perspective.
Enterprises that adopt a user-centric philosophy will continue to generate value provided by technology by embracing risk and managing it in a way that’s productive for their business. But what about the machines?
Banks, specifically, should take a closer look at the fundamentals of securing the machine identities used by banking applications. Machines talk to other machines, whether they’re servers, laptops, applications or mobile devices. And we all know how important it is for those communications to be secure, particularly when it comes to mobile banking.
Encryption gives users the assurance that their machine (or mobile device) is communicating with the machine it should be talking to and that those communications are secure from eavesdropping. This is where the keys and certificates become absolutely essential as the tools that the machine uses to validate the machine identities on both sides of the communications.
Still, whether user or machine authentication is the issue at hand, the complexity that comes with securing communications shouldn’t be perceived as a predicament. On the contrary.
The very developments perceived as bigger security risks also create opportunities for new solutions, according to Michael Wyatt, managing director, Deloitte & Touche LLP, and identity management solution leader in the company’s Advisory’s Cyber Risk Services quoted in the report.
This is certainly the case for machine identity protection. Companies must be diligent in preventing phishing attacks and other malicious behavior before they strike. An important component of this diligence is achieving total visibility of the keys and certificates that govern a company’s machine identities. Find out how Venafi can help.