Perpetual IT

You don’t have to pay to vote in the US.

Up until recently, you wouldn’t have necessarily known that, were you to have run a Google search for how or where to vote. Such a search would have been polluted with scammy ads like this one offering “same-day processing” of voter registration for $129:

That ad, which directs to a site from PrivacyWall.org, is the first ad in a Google search for “register to vote” that was run in an analysis done by watchdog Tech Transparency Project (TTP). On Monday, after it got called out by TTP, Google removed that kind of ad from search results.

PrivacyWall’s CEO Jonathan Wu told Reuters that its service makes it easier for voters to register online without giving more data than is necessary, and that it doesn’t share data for any purpose other than voter registration.

Wu defended the $129 charge, saying that the fee covered mail, staffing and other costs.

Our goal is to create choice where none may exist. In order to make this possible, we charge consumers a fee which is clearly disclosed.

We will not let Google arbitrarily thwart our efforts to protect consumer privacy and to increase voter turnout.

TTP found that nearly one-third of the ads that appeared when its analysts searched on the terms “register to vote,” “vote by mail,” and “where is my polling place – 189 out of 613 – directed users to sites that tried to extract personal information for marketing purposes, to install deceptive browser extensions, or to “bombard people with misleading or useless ads.”

You can see it in action in this video, which steps through one of the scammy ads as it drains personally identifying information (PII) including political party, name, home address, date of birth, the last four digits of your Social Security Number (SSN), taxpayer ID, and a photo ID such as driver’s license, passport or national ID. In other words, plenty of bait for the phish hook.

Finally, you get this great, money-saving “deal”: if you’re not in a rush, “delivery” only costs $69. It would be tempting, were it not $69 more than the $0 you need to spend to register to vote.

That’s not exactly what you’d expect from a company like Google, given its commitment to “protect our users from harm and abuse, especially during elections,” TTP pointed out.

Violative ads

None of this is kosher. Google’s ad policies prohibit misrepresentation, collecting user data for unclear purposes, and unwanted software. TTP says that the ads it sniffed out may also run afoul of Federal Trade Commission (FTC) regulations banning “unfair or deceptive advertising.”

A Google spokeswoman told Reuters that it hasn’t figured out how the ads got through its approval process, which uses a combination of automated and manual review:

We have strict policies in place to protect users from false information about voting procedures, and when we find ads that violate our policies and present harm to users, we remove them and block advertisers from running similar ads in the future.

Chameleon ads blended in

TTP’s report pointed out that recent changes for how Google features its search ads made it tough to distinguish ads from organic search results. In January, Google started to use the same type face and color scheme for ads as for search results, distinguishing the ads only with a little “Ad” icon and enabling ads to stealthily creep into search results.

All of a sudden, people who had never clicked on ads were suddenly, mistakenly clicking on those sneaky little things. Users were not pleased.

Amanda Goetz, vice president of marketing at the Knot Worldwide, a wedding planning group, told the New York Times that Google’s redesign, in which ads and organic search results shared font size, spacing and color, was a “transition to this almost deceptive dark pattern.”

It was an odd choice, the NYT suggested, given recent data privacy and government antitrust probes of the search behemoth.

Designing the ads to be chameleons that blend in with search results isn’t surprising, of course. Google is forever tinkering with its ads design. It is, after all, a company that runs on ads. As the NYT pointed out, Google once tested 41 shades of blue to find which one users liked best.

Fortunately, Google apparently moved fast to strip out the scammy, misleading voting ads. It had no choice, really: doing otherwise would have bucked the trend of the internet companies that have moved to protect elections and would undercut its own pledges to protect elections: in February, it pledged to offer voters “quality, authoritative information” on its search engine, among several other initiatives for the 2020 presidential elections. It also stopped allowing political organizations to micro-target citizens based on their online activities when they buy ad space on Google and YouTube.

Facebook, for its part, has introduced new election security measures, including a promise to increase transparency by showing the confirmed owner of a Page and by labeling state-controlled media on their Page and in the platform’s Ad Library.

In November 2019, Twitter banned political ads altogether.

Yesterday was both a Tuesday and four weeks since the last major Firefox update, making it the official release date for the latest version.

There are now three mainstream flavours of Firefox to choose from: 68.10ESR, 78.0ESR and 78.0.

ESR is short for Extended Support Release, often preferred by IT departments because it gets security fixes at the same rate as the regular version, but only takes on new features in a staggered fashion – in other words, users of the ESR versions are shielded from sudden switches in appearance, user interface and workflow.

This time you can choose from 68.10ESR (the numbers to the left and right of the dot add up to the current major version number, in this case 78), which is Firefox with the look-and-feel of about a year ago plus 10 updates’ worth of security fixes, or 78.0ESR, which is largely the same as the regular version, as the numbers reveal.

Every time the ESR version “catches up” with the regular version’s features, Mozilla releases old-style and the new-style ESR versions in parallel so there’s always an overlap period in which to try out both before switching over.

The new Firefox 78.0 does have some visible changes, notably the addition of a special web page called the Protections Dashboard, accessible by putting about:protections in the address bar.

This gives you a summary of any trackers blocked recently, a button to entice you to sign up for Firefox’s breach alerts, and a link to the Firefox password manager.

We were underwhelmed by this feature, given that we couldn’t figure out how to drill down into the list of trackers that the browser had blocked – all we could see was a count of how many social media trackers, cross-site tracking cookies, tracking code (we presume this refers to JavaScript), fingerprinters and cryptominers had shown up each day over the past week.

Also, Firefox 78 no longer supports TLS 1.0 or TLS 1.1, which are older versions of the TLS security protocol that is now de rigueur for web servers.

Those older flavours of TLS were due to be retired earlier this year by all the major browser makers, on the grounds that TLS 1.2 offers better security using newer cryptographic algorithms, and has already been out for more than a decade.

The demise of these outdated TLS versions was deferred, however, when it became obvious that some US government sites that were considered useful and reliable sources of coronavirus information still hadn’t been upgraded and would therefore suddenly become inaccessible.

Well, Firefox has now killed off both TLS 1.0 and TLS 1.1, so that if you visit a site that doesn’t support TLS 1.2 or later, you will be blocked with an error like this:

You can opt back into TLS 1.1 and TLS 1.0 by pressing the blue button, but this isn’t a one-off setting for the site you are currently visiting and will leave the old TLS versions enabled for all your browsing, which might be more liberal than you really want.

We couldn’t find an obvious way to turn TLS 1.1 and TLS 1.0 back off after clicking the blue button above, but it can be done using Firefox’s advanced about:config page, which gives you direct access to all the many Firefox settings in a text-style list.

If you browse to about:config and search for the options with names that start security.tls, you’ll see the option you use to turn TLS 1.0 and TLS 1.1 back off:

Clicking on the line that says security.tls.version.enable_deprecated will flip the setting from true, which means that the old and less secure TLS flavours are allowed, back to the default setting of false, which causes the old versions to be blocked.

What to do?

At the moment [2020-07-01T11:00Z], the security fixes in the new version are a mystery!

The release notes directed us to the official security fixes page, but there wasn’t any entry for Firefox 78.

That could mean that there weren’t any major bugs fixed, or simply that current security advisory isn’t out yet.

We’re assuming the latter – otherwise we think there would be a list with zero items on it, which isn’t the same as no list at all – and so we fetched the update anyway.

We suggest you do the same: go to the Hamburger (three lines) icon at the top right of the Firefox winow, then Help > About Firefox to check for the latest version and download it if needed.

(Note that on some Linux distros, Firefox updates are provided by the distro itself, not downloaded directly by Firefox, so you may need to do a system update to find and fetch the latest version.)

Update 1. [2020-07-01T21:40Z] Security Advisory MFSA2020-24 was issued after this article was published. The advisory lists 14 CVEs, of which eight are classed as “high” risk, but none as “critical”. Update 2. [2020-07-02T0:15Z] Firefox 78.0.1 quickly followed 78.0, apparently to fix a non-security bug that “could cause installed search engines to not be visible when upgrading from a previous release.”

---

Our chums over at online IT publication The Register just spotted an interesting code change in the Chromium browser from last week.

Google, it seems, is joining Apple in limiting the maximum validity of web security certificates – those digitally signed blobs of data that put the S in TLS and the padlock in your address bar – to just one year.

The code change is headlined Enforce 398-day validity for certificates issued on-or-after 2020-09-01, and it looks like this:

Enforce publicly trusted TLS server certificates have a lifetime of 398 days or less, if they are issued on or after 2020-09-01.

Certificates that violate this will be rejected with ERR_CERT_VALIDITY_TOO_LONG and will be treated as misissued.

Apple announced back in February 2020 that it was going to start doing this in its Safari browser.

Safari comes as part of the macOS distribution on Macs, so it’s always available and widely used.

Even if it’s not the first choice for most Mac users, it’s commonly fired up as an “alternative” browser, for example when you want to be logged onto the same site using two different accounts, or logged on in one browser but not logged on in another.

And Safari, or at least its programmatic core known as WebKit, is the only browser code allowed on iOS.

The dangers of stolen certificates

As you probably know, web certificates have two parts: a public key, presented to the world to identify your server; and a private key, used by your server to prove that it really does own the public key it is presenting as its identity.

You can think of the public key like the blue slip (or white disk, or pink sheet, or or whatever colour it is in your country) that goes with your car to show that it’s registered to the owner YOUR NAME, and you can think of the private key as the formal ID you show when you need to prove that you really are the person YOUR NAME listed on the slip.

The slip isn’t meant to be a secret – in some countries it’s a sticker that actually goes on the vehicle – and the data on it can be copied easily, because it doesn’t really mean anything without your ID to vouch for it.

Well, in the context of web certificates, crooks who get hold of your private key are like car thieves with a clone of your ID: they can pass themselves off as you and therefore convince people that your property belongs to them.

And if crooks can set up a server that can “prove” it’s yours, those same crooks can trick other people into trusting fake content on their fake site as if it were yours, vouched for cryptographically by you.

Of course, crooks can bask in the trust conferred by your certificate without stealing your private key, for example by hacking into your site and modifying or adding fake or malicious content to your server.

If the content comes from your site, then it will automatically have the imprimatur of your certificate and thus be vouched for by you and your brand.

But crooks who get hold of your private key can go much further than that, and they can do it without having to rely on your server at all – they can effectively create a clone of your server, pretty much anywhere in the world they like, where you can’t easily shut it down or remove the offending content.

If they use your name, brand, logos and everything – including your web certificate – then anyone who visits their bogus server will almost certainly be willing to trust as if it were yours.

Why only one year?

Apple’s argument is that the longer the life left in a certificate, the longer that crooks have to abuse it if it’s stolen or turns out to have been fraudulently signed, so why not cap the upper limit at a single year?

Everyone in the industry generally agrees that some sort of limit is necessary, as the Chromium source code below reveals. (We’ve edited the comments, which are lines that start // for non-technical clarity.)

Don’t worry if you aren’t fluent in C++ because the basic ideas here are easy to follow.

The code below comes from a function called HasTooLongValidity(), which returns true if a certificate is not to be trusted, and false if it’s OK.

(We think the function should be named the other way around, so that true would mean HasAcceptableValidity() and false that it was no good, but that’s a discussion for another time.)

BR is short for Baseline Requirements, the agreed principles that set minimum standards for certificates:

As you can see above, the limit on certificate lifetime has been reduced many times over the years, from 10 years to 5, then to 3¼ and then again to 2¼.

Now, Google and Apple are homing in on 398 days, which is a full year plus a full month plus at least two extra days.

Should we care?

Not everyone is delighted by this change, given that it was essentially implemented by Apple unilaterally early this year, apparently without industry consensus, and is now being copied by Google in its Chromium browser.

In other words, it feels to some people like a sort of “policy by stealth”, given that with both Apple and Google now behind it, the opinion of everyone else doesn’t matter because everyone else will need to follow suit.

Some observers ask why it’s necessary to have such a strict expiry limits on certificates, given that it’s unneccessary for certificates that have been looked after properly and is therefore largely forcing change for change’s sake.

In the same way that few companies still force regular password changes “just because”, but save password resets for when they’re really needed, why force certificate updates even for people who haven’t had their private keys stolen?

Others ask why a year is seen as “too long” given that certificate authorities such as Let’s Enrcypt are already issuing certificates that are only valid for three months at a time, thanks to a smoothly automated process for renewal.

If millions, or even hundreds of millions, of boutique websites using Let’s Encrypt’s free certificates can manage three-monthly renewals with ease, how can one year be considered too short for certificates from more mainstream, traditional certificate authorities?

What to do?

For what it’s worth, these new limits in Apple’s and Google’s browsers don’t apply to certificates you’ve authorised yourself with signing certificates of your own, so you can set any sort of expiry limits you like in your own ecosystem.

But for the rest of us: any web certificate issued after September 2020 that you hoped would last for two years will be rejected by both Apple’s and Google’s browsers with the error CERT_­VALIDITY­_TOO_LONG.

You can fight it – or you can go with the flow and adapt your certificate renewal workflow to acquire and use one-year certificates.

---

In March, researchers Talal Haj Bakry and Tommy Mysk revealed that Android and iOS apps – including the mind-bogglingly popular, China-owned, video-sharing/often in privacy hot water TikTok – could silently, automatically read anything you copy into your mobile device’s clipboard.

Sexy selfies? Passwords copied from your password manager? Bank account information? Bitcoin addresses? Yes, yes, scary yes, yes. Anything you’ve copied recently, they’ll paste it into themselves. Such data is typically used for advertising and tracking purposes.

The covert content copying is possible not only for a device’s local data, but also on nearby devices, as long as the devices share the same Apple ID and are within about 10 feet of each other. That’s enabled by Apple’s universal clipboard: a clipboard that enables content to be copied on one device and then pasted into an app running on a separate device.

It’s “very, very dangerous,” Mysk told Ars Technica on Friday, after the discovery had bubbled to the surface yet again. The findings hit the headlines anew as Apple released the developer beta of iOS 14 – a release that flags this behavior.

Mysk said that the ability for apps to read content of off nearby devices means that an app on an iPhone could possibly read sensitive data on the clipboards of other connected iOS devices, be they cryptocurrency addresses, passwords, or email messages, even if the iOS apps are running on a separate device.

The iOS 14 developer beta release – which you can download and install now to get an eyeful of this behavior – comes with a feature that’s custom-tailored to spotlight this kind of thing: namely, a banner warning that pops up every time an app reads clipboard contents.

While there are good reasons for some apps to access your clipboard, the apps that Mysk and Bakry found have no clear reason to do so. Here’s Mysk:

These apps are reading clipboards, and there’s no reason to do this. An app that doesn’t have a text field to enter text has no reason to read clipboard text.

How many apps snoop on clipboards, and how often? A whole lot, and quite frequently, as was discovered by many of the people who began testing the beta release. A video, posted on 23 June, had been viewed by over 118,000 people as of Tuesday, 30th June and demonstrates apps getting flagged by iOS 14 as they read content.

The full list of clipboard-scrapers

There are some big names on the list of apps that are doing this. The developers of 10% Happier: Meditation, Hotel Tonight and TikTok have been quick to promise that they’ll knock it off, but according to Ars, as of Monday evening, the developers behind the rest of these apps hadn’t commented yet:

News
– ABC News
– Al Jazeera English
– CBC News
– CBS News
– CNBC
– Fox News
– News Break
– New York Times
– NPR
– ntv Nachricten
– Reuters
– Russia Today
– Stern Nachrichten
– The Economist
– The Huffington Post
– The Wall Street Journal
– Vice News

Games
– 8 Ball Pool
– AMAZE!!!
– Bejeweled
– Block Puzzle
– Classic Bejeweled
– Classic Bejeweled HD
– FlipTheGun
– Fruit Ninja
– Golfmasters
– Letter Soup
– Love Nikki
– My Emma
– Plants vs Zombies Heroes
– Pooking – Billiards City
– PUBG Mobile
– Tomb of the Mask
– Tomb of the Mask: Color
– Total Party Killer
– Watermarbling

Social
– TikTok
– ToTalk
– Truecaller
– Viber
– Weibo
– Zoosk

Other
– 10% Happier: Meditation
– 5-0 Radio Police Scanner
– Accuweather
– AliExpress Shopping App
– Bed Bath & Beyond
– Dazn
– Hotels.com
– Hotel Tonight
– Overstock
– Pigment – Adult Coloring Book to Color
– Sky Ticket
– The Weather Network

… and, Mysk said, TikTok has failed to stop, in spite of having promised that it would.

TikTok caught red-handed

TikTok, the video-sharing social media phenomenon that young people love and their parents love to haul into court over child privacy law violations, has shelled out a changing story about this to media outlets, including Forbes.

First, TikTok owner Bytedance said the problem wasn’t its fault. Rather, it blamed an outdated Google Ads software development kit (SDK) that was due to be replaced.

But as the clipboard warning in iOS 14 has made clear, ByteDance didn’t stop the invasive practice back in April, as it had promised. Now, the iOS 14 warning has caught the company “red-handed,” Zak Doffman writes, “still doing something they shouldn’t.”

Here’s TikTok’s most recent story: the issue is now “triggered by a feature designed to identify repetitive, spammy behavior,” and it’s “already submitted an updated version of the app to the App Store removing the anti-spam feature to eliminate any potential confusion.”

A few things to keep in mind

All these apps copying clipboard content have been doing so surreptitiously. They’ve been tough to spot. The issue underscores what an important update the new warning in iOS 14 is, and Apple plans to credit the researchers for being the impetus for the new notification.

Having said that, we’re not out of the woods yet. Now that Apple’s flagging the behavior, Apple users will benefit from the TikTok update as soon as it ships, but until then, please do keep in mind that the app is reading your clipboard data. To stay on the safe side, you can flush your clipboard by copying an innocuous piece of data.

Android is another issue entirely. Mysk told Ars that the scenario is worse on Android than it is on iOS, given that Android APIs are far more lenient. For example, Android allowed apps running in the background to read the clipboard up until Version 10, as opposed to iOS apps, which can do so only when they’re active, as in, running in the foreground.

Be careful of what you copy on your mobile device. Unfortunately, as the researchers said, we don’t really know what these apps are doing with our content.

If you run a website or a blog, you probably use a cloud provider or a dedicated hosting company to manage your server and deliver the content to your readers, viewers and listeners.

We certainly do – both Naked Security and our sister site Sophos News are hosted by WordPress VIP.

That’s not a secret (nor is it meant to be), not least because most providers identify themselves in the HTTP headers they send back in their web replies, if only as a matter of courtesy:

$ getheaders https://news.sophos.com Connecting... OK.
TLS handshake... OK.
---headers---
server: nginx
date: Mon, 29 Jun 2020 10:21:21 GMT
content-type: text/html; charset=UTF-8
content-length: 0
x-hacker: If you're reading this, you should visit wpvip.com/careers and apply to join the fun, mention this header.
x-powered-by: WordPress VIP host-header: e66d35b329a7c2cff66075eaf4530d13
x-redirect-by: WordPress
location: /en-us/
age: 0
x-cache: miss
strict-transport-security: max-age=31536000
---headers---

Because your choice of hosting provider is usually easy enough for anyone to figure out, you probably already receive your fair share of spam from companies saying, “Hey, I see you use web provider X, and we just happen to have enormous expertise in that area, so why not contact us…”

…and we’re willing to bet that you have lots of reasons why not, including that you don’t much like receiving unsolicited emails trying to drum up business.

We certainly get our fair share of spams of that sort, typically saying they can help us switch providers, optimise our content, boost our Google ranking and so on.

But over the weekend we received a message that was a bit more believable than the rest.

This scam pretended to come from WordPress itself, and claimed that DNS security features would soon be added for our domain:

From: WordPress
Subject: nakedsecurity.sophos.com DNS Update

We’re upgrading your domain DNS for something even better, freely!

We care about your privacy and the protection of your domains, so we will soon be upgrading them, from basic Domain Name System (DNS) to Domain Name System Security Extensions (DNSSEC).

As you probably know, DNS is short for domain name system, and it’s the globally distributed database that turns server names that humans can remember, such as nakedsecurity.sophos.com, into network numbers that computers can use, such as 203.0.113.171.

And DNSSEC really exists – it’s a protocol that adds authentication to DNS data transfers to help stop cybercriminals filling the DNS database with bogus entries and thereby hijacking web traffic.

In fact, you’ve probably heard of DNSSEC, short for domain name system security extensions, because it’s been around for more than 20 years.

On the other hand, you’ve probably never set up DNSSEC or used it directly youself, because it has tyically been a feature used by service providers to help to keep their own DNS databases intact when they exchange data with other DNS servers.

In other words, activating DNSSEC for the server names that your hosting provider looks after for you certainly sounds like a good idea.

So we can understand why some recipients of this scam might click through in order to learn more.

The landing page

The landing page of this scam is surprisingly believable, as you see here, which is what we received when we clicked through for our “free” DNSSEC upgrade:

The page claims to be an “Update Assistant”, with logos and icons that match your service provider, and it even has a How to use this assistant button that actually works:

Of course, the advice here is to put in your usual WordPress password – which is exactly the opposite of what you ought to be doing.

Any data you enter here goes straight to the crooks, and if you don’t have two-factor authentication enabled on your account, the crooks may very well be able to log on to your website or blog right away and take it over completely.

The scam then shows you some fake but believable progress messages to make you think that a genuine “site upgrade” has kicked off, including pretending to perform some sort of digital “file signing” at the end.

Here’s what we saw when we entered a bogus username and passwords on the phishing page:

As you can see, the crooks claim that you’ll be redirected to your own site at the end of the process, but instead you end up at a URL that includes the name of your site preceded by the name of the fake site set up by the crooks.

This produces a 404 error – what we can’t tell you is whether the crooks made a programming blunder and accidentally redirected you to https://[THEIRDOMAIN/your.example instead of directly to https://your.example…

…or whether they intended this all along, to avoid redirecting to you directly to your own login page, which might seem suspicious given that you put in your username and password already.

Auto-customising the page

The clickable links in the emails sent out in this spam campaign include all the data that crooks need to tailor the login page automatically.

The link we received looked like this:

https://[REDACTED].com/?banner=V29yZFByZXNz&url=bmFrZWRzZWN1cml0eS5zb3Bob3MuY29t

If you decode the base64 text used for banner and url, you get the following:

> base.unb64('V29yZFByZXNz')
WordPress
> base.unb64('bmFrZWRzZWN1cml0eS5zb3Bob3MuY29t')
nakedsecurity.sophos.com

By simply encoding new banner names and new URLs, we were able to auto-customise the scam page, like this:

> base.b64('totally.bogus.example')
dG90YWxseS5ib2d1cy5leGFtcGxl
> base.b64('Microsoft Azure')
TWljcm9zb2Z0IEF6dXJl
> > base.b64('www.example.com')
d3d3LmV4YW1wbGUuY29t
> base.b64('HostGator')
SG9zdEdhdG9y // Below left: https://[REDACTED].com/?banner=TWljcm9zb2Z0IEF6dXJl&url=dG90YWxseS5ib2d1cy5leGFtcGxl
// Right: https://[REDACTED].com/?banner=SG9zdEdhdG9y&url=d3d3LmV4YW1wbGUuY29t

We didn’t even need to guess at the banner names that we could use, because the crooks had left the image directory browsable on their phishing site:

[. . . . . .]
[IMG] HostGator.png 25-Jun-2020 19:04 12k [IMG] HostGator_avatar.png 25-Jun-2020 19:06 12k [IMG] HostMonster.png 25-Jun-2020 20:15 12k [IMG] HostMonster_avatar.png 25-Jun-2020 20:17 4k [IMG] KonaKart.png 26-Jun-2020 01:50 16k [IMG] KonaKart_avatar.png 26-Jun-2020 01:50 8k [IMG] Linode.png 25-Jun-2020 19:07 12k [IMG] Linode_avatar.png 25-Jun-2020 19:09 8k [IMG] Magento.png 22-Nov-2018 19:29 12k [IMG] Magento_avatar.png 22-Nov-2018 19:32 8k [IMG] Microsoft Azure.png 25-Jun-2020 20:10 12k [IMG] Microsoft Azure_avatar.png 25-Jun-2020 20:11 4k [IMG] Name Cheap.png 25-Jun-2020 20:22 16k [IMG] Name Cheap_avatar.png 25-Jun-2020 20:23 8k [IMG] Network Solutions.png 25-Jun-2020 19:15 12k [. . . . . .]

In total, the crooks had 98 different ripped-off brand images ready to go, all the way from Akamai to Zen Cart.

What to do?

• Don’t login via links sent in email. If you receive an email that says you need to login to service X, and you do have an account with X, ignore any login links in the email itself. Find your own way to the login page (for example, bookmark it yourself), even if you think the email is genuine. That way you won’t fall for bogus links by mistake.
• Turn on 2FA whenever you can. 2FA is short for two-factor authentication, typically based on one-time codes that are sent to your phone or generated by a special app. 2FA makes your password alone much less useful to the crooks, just in case you ever do give it away by mistake.
• Consider a password manager. Password managers not only pick strong and random passwords automatically, but also associate each password with a specific URL. That makes it much harder to put the right password into the wrong site, because the password manager simply won’t know which account to use when faced with an unknown phishing site.
• Look for an anti-virus with live web filtering. Products such as Sophos Home (free for Windows and Mac) not only block malware from arriving onto your computer but also prevent web connections going out to risky sites in the first place, even if those sites themselves don’t actually contain malware.

---