Here are a few good readings and materials that summarize very well how to choose a good, strong and secure password in the modern world.

How Secure Your Password is?

Let’s head over to How Secure is My Password to find out.

Bruce Schneier’s Choosing a Secure Password

The article was published in 2014 but still relevant in today’s world. It lays out several studies on password strength and simply points out that

Pretty much anything that can be remembered can be cracked.

But there is still one scheme that seems to work, so-called “Schneier scheme”:

So if you want your password to be hard to guess, you should choose something that this process will miss. My advice is to take a sentence and turn it into a password. Something like “This little piggy went to market” might become “tlpWENT2m”. That nine-character password won’t be in anyone’s dictionary. Of course, don’t use this one, because I’ve written about it. Choose your own sentence – something personal.

For example:

• WIw7,mstmsritt… = When I was seven, my sister threw my stuffed rabbit in the toilet.
• Wow…doestcst = Wow, does that couch smell terrible.
• Ltime@go-inag~faaa! = Long time ago in a galaxy not far away at all.

Schneier also adds a few more rules on top of how to choose a good password:

1. Never reuse a password you care about. Even if you choose a secure password, the site it’s for could leak it because of its own incompetence. You don’t want someone who gets your password for one application or site to be able to use it for another.
2. Don’t bother updating your password regularly. Sites that require 90-day—or whatever—password upgrades do more harm than good. Unless you think your password might be compromised, don’t change it.
3. Beware the “secret question.” You don’t want a backup system for when you forget your password to be easier to break than your password. Really, it’s smart to use a password manager. Or to write your passwords down on a piece of paper and secure that piece of paper.
4. One more piece of advice: if a site offers two-factor authentication, seriously consider using it. It’s almost certainly a security improvement.

Source: https://www.schneier.com/essays/archives/2014/02/choosing_a_secure_pa.html

Jeff Atwood’s Password Rules are Bullshit

TL;DR: There is one rule to bring them all, and in the darkness bind them, the length. Whatever you want, just make sure it’s long enough to be a reasonable password.

In detail,

1. Password rules are bullshit
   • They don’t work.
   • They heavily penalize your ideal audience, people that use real random password generators. Hey, guess what, that password randomly didn’t have a number or symbol in it. I just double checked my math textbook, and yep, it’s possible. I’m pretty sure.
   • They frustrate average users, who then become uncooperative and use “creative” workarounds that make their passwords less secure.
   • They are often wrong, in the sense that the rules chosen are grossly incomplete and/or insane, per the many shaming links I’ve shared above.
   • Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won’t take my word for it, read this 2016 NIST password rules recommendation. It’s right there, “no composition rules”. However, I do see one error, it should have said “no bullshit composition rules”.
2. Enforce a minimum Unicode password length
   • It’s simple. Users can count. Most of them, anyway.
   • It works. The data shows us it works; just download any common password list of your choice and group by password length.
   • The math doesn’t lie. All other things being equal, a longer password will be more random – and thus more secure – than a short password.
   • Accept that even this one rule isn’t inviolate. A minimum password length of 6 on a Chinese site might be perfectly reasonable. A 20 character password can be ridiculously insecure.
   • If you don’t allow (almost) every single Unicode character in the password input field, you are probably doing it wrong.
   • It’s a bit of an implementation detail, but make sure maximum password length is reasonable as well.
3. Check for common passwords
4. Check for basic entropy
5. Check for special case passwords

Source: https://blog.codinghorror.com/password-rules-are-bullshit/

Two more bonus readings from Jeff: Hacker, Hack Thyself & The God Login.

Troy Hunt on Password Strength Indicators

Troy uses a true sample to demonstrate why Password Strength Indicators sometimes help people choose dumb choices, and points out that

Password strength meters which simply run JavaScript in the client and apply basic mathematics are woefully inadequate. Likewise, websites applying similar maths to enforce “strong” passwords in no way guarantee that actual strong passwords will be chosen. All these calculators neglect the human element of passwords and that’s an enormously important part of the picture.

He also suggests:

Fundamentally, it’s an education issue and the key tenets people need to understand boil down to the risks of password reuse and, of course, what genuinely constitutes a strong password.

Source: https://www.troyhunt.com/password-strength-indicators-help-people-make-dumb-choices/

UK NCSC’s Password Guidance

The UK NCSC (part of GCHQ – Uk equiv to NSA) published a good discussion document a while back that contains some useful password guidance that simplifies the password policy, including:

1. Change all factory-set default passwords.
2. Take advantage of good password manager software.
3. Eliminate password expiry policy to avoid placing more burden on users.
4. No sharing passwords
5. Use technical controls to defend against automated guessing attacks, rather than relying on users to generate complex passwords.
6. Never re-use passwords between work and home.
7. Account lockout, throttling, and protective monitoring are powerful defenses against brute-force attacks on enterprise systems and online services.
8. Never store passwords as plain text, always hashing and salting before storing them.

Source: UK NCSC’s Password Guidance

Microsoft Password Guidance

It provides Microsoft’s recommendations for password management based on current research and lessons from their own experience as one of the largest Identity Providers in the world.

Here is some advice to IT admins:

• Maintain an 8-character minimum length requirement (and longer is not necessarily better).
• Eliminate character-composition requirements.
• Eliminate mandatory periodic password resets for user accounts.
• Ban common passwords, to keep the most vulnerable passwords out of your system.
• Educate your users not to reuse their password for non-work-related purposes.
• Enforce registration for multi-factor authentication.
• Enable risk-based multi-factor authentication challenges

Source: Microsoft Password Guidance

Security Baseline for Windows 10 and Server v1903

The new Windows Feature Update brings very few new Group Policy settings but the new draft baseline did drop a few policies that were recommended before. One of them is the dropping of the password-expiration polices that require periodic password changes.

Why are we removing password-expiration policies?
First, to try to avoid inevitable misunderstandings, we are talking here only about removing password-expiration policies – we are not proposing changing requirements for minimum password length, history, or complexity.
Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem.
If it’s a given that a password is likely to be stolen, how many days is an acceptable length of time to continue to allow the thief to use that stolen password? The Windows default is 42 days. Doesn’t that seem like a ridiculously long time? Well, it is, and yet our current baseline says 60 days – and used to say 90 days – because forcing frequent expiration introduces its own problems. And if it’s not a given that passwords will be stolen, you acquire those problems for no benefit. Further, if your users are the kind who are willing to answer surveys in the parking lot that exchange a candy bar for their passwords, no password expiration policy will help you.
Our baselines are intended to be usable with minimal if any modification by most well-managed, security-conscious enterprises. They are also intended to serve as guidance for auditors. So, what should the recommended expiration period be? If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration? And if they haven’t implemented modern mitigations, how much protection will they really gain from password expiration?
The results of baseline compliance scans are usually measured by how many settings are out of compliance: “How much red do we have on the chart?” It is not unusual for organizations during audit to treat compliance numbers as more important than real-world security. If a baseline recommends 60 days and an organization with advanced protections opts for 365 days – or no expiration at all – they will get dinged in an audit unnecessarily and might be compelled to adhere to the 60-day recommendation.
Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.

Source: Security baseline (DRAFT) for Windows 10 v1903 and Windows Server v1903

The network stack does several seemingly impossible things. It does reliable transmission over our unreliable networks, usually without any detectable hiccups. It adapts smoothly to network congestion. It provides addressing to billions of active nodes. It routes packets around damaged network infrastructure, reassembling them in the correct order on the other side even if they arrived out of order. It accommodates esoteric analog hardware needs, like balancing the charge on the two ends of an Ethernet cable. This all works so well that users never hear of it, and even most programmers don’t know how it works.

Read more here.

Here are some of the highlights:

• The differences between military and civilian IT
  • In the military, the scale of IT is larger.
  • In the military, the work pressure can be extreme.
  • In military IT, the operating environment can be very harsh.
  • In the military, the tech is often bigger and badder.
  • In the military, processes are extremely regimented.
  • The workforce skews are very young, about half of the enlisted members are under the age of 25.
• Some things about life in IT are universal

/via Spiceworks/

I’m 56 years old and learning to code.

Why? Because I love it. And I’ve got a knack for it.

That doesn’t mean it’s easy. It’s hard. And that’s OK.

I love losing myself in an algorithm challenge. I love squeezing in a few extra minutes testing just one more thing. I love thinking “maybe I’ve got it this time.” And getting to “Yes! It finally works!”

But here’s the thing. I’ve never been one for hobbies. I don’t like activities that don’t pay. I can’t keep on doing something simply for the fun of it.

What I work on during my off time has to have some economic upside for me.

OK, coding pays. It can pay big. So what’s the problem?

Well, before I could fully embrace myself as a 56-year-old programming rookie, I had to deal with my Critical Inner Self (let’s call him CIS for short).

Learning all this stuff is hard enough without my CIS whispering in my ear the whole time.

If I can give my CIS an epic beat-down, then I should be able to handle anyone who appears to work on his behalf. And these agents of CIS often appear out of no where, asking critical questions.

/via freeCodeCamp at Medium/