It's World (Terrible) Password (Advice) Day!

Frequently change your one random password – that's the ticket

Two-factor authentication?

The great thing about two-factor authentication – which typically comprises being texted a temporary code to your phone after you login with the correct username/password – is that it is an additional layer of different security.

Suddenly, someone needs to not only have your username/password but also your phone (or access to your phone). This is proper security and is currently the best you can do with remote access within a normal budget.

It's not as good as physical security or biometric scanners but it is pretty good. You can be fairly confident that the person who says they are trying to access a system is actually that person. Hurray!

Of course, two-factor auth can also be a pain both for a sysadmin and the user. It adds a layer of expense and complexity and a time delay every time you access a system. But if that is an important system, then it really is a no-brainer. (Ignore the Australian government.)

Should you use two-factor auth for your bank account? Yes. Should you use it for Facebook or Amazon? Um, yes, probably. Which leads to the bigger issue with online security – getting beyond passwords and the users themselves.

Conclusion: use two-factor auth for your important logins (social media, ecommerce, banking). And offer it on every important system you run. Just do it, we know it’s a pain but, hey, so is being hacked.

Stronger systems

While everyone tends to obsess about users and their passwords, the reality – as demonstrated by the constantly changing and occasionally conflicting advice about passwords – is that there is no right answer.

Any system that relies on a simple username/password to gain access is already asking for trouble. The real security effort – and where much of the real focus needs to be – is on what happens behind the scenes.


Android apps prove a goldmine for dodgy password practices


Brute force attacks only work if someone's system is willing to accept thousands of attempts to access an account. As frustrating as locking down an account after x number of wrong attempts can be, it is also a very effective way of warding off such attacks.

Likewise, introducing a two-factor auth system may add hassle but it will also massively increase security. Having intrusion detection systems in place – and someone who actually watches them – can be a more effective use of time and resources than trying to change the behavior of everyone on your system. (NIST actually has a lot of good advice on all this.)

Introducing specific password policies is a double-edged sword. Forcing people to have a password longer than eight characters, with at least one uppercase letter and one number may help with security and make those behind the system feel better.

But such a system becomes completely blind to user frustration as they try, and try again, and try again, to find a password that "works." And then of course there are the small decisions that drive people especially crazy: you can use "#" but not "%", a colon is fine but a semi-colon is a no-no.

Prepare yourself for dealing with lots of password-reset requests, and for frustrating phone calls. But at the same time, don't be an idiot and send passwords over plaintext.

In an ideal world, there would be an agreed standard where systems communicate what sorts of passwords they will accept, and password managers automatically configure a new password and the entire exchange happens with the user simply being able to click on a button.

And, of course, that is exactly what Facebook and Google (and, to a lesser degree, Twitter) are trying to do, leveraging their massively, existing user base to make it easier for companies to get people into their systems securely, while, um, sucking up all their information and selling it to the highest bidder.

We can see the attraction to a "Log in with Facebook" button, but any IT professional that actually uses it should hang their head in shame.

And then, of course, there is the much larger truth: that if everyone used the same system, everyone would be less secure. Safety comes in diversity.

Boiling it all down

So here there is our password/online usage guide for Reg readers – assuming a higher than average proficiency in all things computery.

  1. Use a password manager. And long logins.
  2. Turn on two-factor auth whenever you can – and just deal with the extra step without complaining.
  3. Keep two sets of passwords in your head: one or two easy, disposable ones to be used on sites where you are forced to create an account but don't care about; and another one or two long ones that you can remember but that you never tell anyone about (four or five random words that make sense to you is as good a system as any). Use that one for bank accounts and similar very important systems. If you die in a car crash, people will have to send letters and meet physically to gain access to those accounts: good.
  4. Use two different browsers: one to log in to Facebook, Google, whatever – and one you use for everything else. Don’t let those data-sucking monsters into your everyday online usage.
  5. And lastly, don't waste your time trying to tell anyone else what they should do when it comes to passwords. Either you are wasting your time, or you are setting yourself up as their IT support for the rest of your unhappy existence.

If in doubt, think: WWSD? (What would Snowden do?)

Happy Password Day! ®

Similar topics

Other stories you might like

  • Cisco warns of security holes in its security appliances
    Bugs potentially useful for rogue insiders, admin account hijackers

    Cisco has alerted customers to another four vulnerabilities in its products, including a high-severity flaw in its email and web security appliances. 

    The networking giant has issued a patch for that bug, tracked as CVE-2022-20664. The flaw is present in the web management interface of Cisco's Secure Email and Web Manager and Email Security Appliance in both the virtual and hardware appliances. Some earlier versions of both products, we note, have reached end of life, and so the manufacturer won't release fixes; it instead told customers to migrate to a newer version and dump the old.

    This bug received a 7.7 out of 10 CVSS severity score, and Cisco noted that its security team is not aware of any in-the-wild exploitation, so far. That said, given the speed of reverse engineering, that day is likely to come. 

    Continue reading
  • Google battles bots, puts Workspace admins on alert
    No security alert fatigue here

    Google has added API security tools and Workspace (formerly G-Suite) admin alerts about potentially risky configuration changes such as super admin passwords resets.

    The API capabilities – aptly named "Advanced API Security" – are built on top of Apigee, the API management platform that the web giant bought for $625 million six years ago.

    As API data makes up an increasing amount of internet traffic – Cloudflare says more than 50 percent of all of the traffic it processes is API based, and it's growing twice as fast as traditional web traffic – API security becomes more important to enterprises. Malicious actors can use API calls to bypass network security measures and connect directly to backend systems or launch DDoS attacks.

    Continue reading
  • Zero Trust: What does it actually mean – and why would you want it?
    'Narrow and specific access rights after authentication' wasn't catchy enough

    Systems Approach Since publishing our article and video on APIs, I’ve talked with a few people on the API topic, and one aspect that keeps coming up is the importance of security for APIs.

    In particular, I hear the term “zero trust” increasingly being applied to APIs, which led to the idea for this post. At the same time, I’ve also noticed what might be called a zero trust backlash, as it becomes apparent that you can’t wave a zero trust wand and instantly solve all your security concerns.

    Zero trust has been on my radar for almost a decade, as it was part of the environment that enabled network virtualization to take off. We’ve told that story briefly in our SDN book – the rise of microsegmentation as a widespread use-case was arguably the critical step that took network virtualization from a niche technology to the mainstream.

    Continue reading

Biting the hand that feeds IT © 1998–2022