Chrome and Firefox increase their password warnings, but Safari lags behind

Software designers have to strike a careful balance between letting users do what they want and alerting them to mistakes while avoiding pestering them so often that the warnings go ignored. Worst of all, an app could prevent someone from carrying out an action they want to take, leading them to abandon the app in frustration.

Nowhere is this more fraught than in Web browsers, especially considering that every major operating system ships with an in-house version, even as competition remains in place. People can switch easily, and browser makers know this. If your browser cautions, blocks, or nags you too much, you can just find one that’s less harsh—and I think this philosophy has led companies to allow more security issues to slip past.

Starting around 2015, Google’s Chrome and Mozilla Foundation’s Firefox have changed their approach a lot because of security issues relating to outdated cryptographic standards used in web server digital certificates. It’s spread to many less technical areas. Apple’s Safari, however, has mostly erred on the side of quietly deterring and deflecting without alerting, and there are good reasons it should change.

A password to the wise

One of the most dangerous points of interception when logging into a website is when you enter your username and password, especially if you can’t use two-factor or two-step authentication to confirm the login.

Until recently, only 40 percent of sites that had a login page used a mandatory secure connection for that page—in other words, they let you connect with plain http instead of https. Over the last year, the Mozilla Foundation says that’s increased to 70 percent. But that still leaves a big risk.

Mozilla

The issue is code or HTML injection on non-secured Web pages. You can see how easy this is, because many ISPs and some Wi-Fi hotspots will stick a pop-up dialog into your regular browsing session. This requires them to intercept the HTML arriving from a remote website, rewrite part of it to inject JavaScript, and deliver the modified results to your browser, which accepts it without a complaint.

Any non-secured page can be rewritten by anyone who manages to stick themselves in the middle, whether on a café network or somewhere in the Internet’s recesses if they manage to tap into connections between a web server and its users. That can include criminals of course, as well as government operations that operate without a specific warrant or a consensus on the legality of interception.

As a result, both Chrome and Firefox now warn you in slightly different ways when they detect a login form on a non-secure page, to deter you from submitting a password there.

In January, starting with Firefox 51, Mozilla will show a lock icon with a red slash through it when a non-secure page collects a password. In future releases, it will be even more severe: a dropdown security warning will appear in any password field warning that the form page isn’t secure.

Google

Google is taking a different approach starting with Chrome 56, released in late January. It marks all non-secure pages with login forms with a gray Not Secure message and an info (circle i) icon. Later, they’ll change that to a red warning and red text.

Safari could offer the same, but there’s no roadmap in its development blog or the Safari Technology Preview to do so.

Taking the next step

There’s a useful additional step that browser makers and apps that store passwords could take, though it requires a layer or more of opt-in to make it safe.

I store passwords both in Safari (and iCloud Keychain) and using 1Password, and when they’re unlocked, I can retrieve them. These options and others already check when you autofill passwords that the site that you’re on matches precisely the one on which you stored a password—lookalike names or phishing attempts don’t produce matches. (1Password currently warns when you try to fill a password on an non-secured page that was originally stored on a secure one, which is a good alert.)

Google

But if you have some of your passwords memorized, you still might wind up typing one in on a spoofed login page by mistake. In 2015, Google released a Chrome extension, Password Alert, that monitors for Google-only passwords entered on non-Google sites.

It would seem to be a relatively trivial matter—even if you had thousands of passwords stored—for a browser to monitor keystrokes in any password field (whether used that way or specified as such in the HTML form code) for a password that isn’t appropriate to the site. Because passwords are stored locally, your keystrokes wouldn’t need to be sent off elsewhere.

While this might be great to help you avoid phishing—hey, it would have helped John Podesta, big time—it’s also a tool you could offer to install and enable on the computers of people you know who ask you for computer help, like friends and relatives.

A nice fat warning that says, “This appears to be a password hijacking attempt: you didn’t store the password you’re entering for this site,” could deter more relatively naive users than any number of lectures about checking domain names.

Apple would be the likeliest company to offer this first, because Safari has richly integrated password storage. I’d love to see Apple take some of the same approach with passwords and Safari that it’s brought to overall operating system security with iOS. There’s so much benefit with such little effort. Apple has restricted automatic use of Flash and other media plug-ins along with other browser makers, but it hasn’t pushed hard enough in other areas.

In the meantime, Google and Mozilla seem determined to keep cranking harder at reducing opportunities for exploitation. Ultimately, those two organizations want 100 percent of the web to be delivered over secure connections. It’s a good goal and achievable.