Bullshido (https://en.wiktionary.org/wiki/bullshido) is a term referring to exaggerated or fraudulent claims around martial arts. The origin of the term appears to be related to the site https://www.bullshido.net, which uses the tagline “The Art of Fighting BS” - something I can certainly get behind. (Need to add this site to my reading list....)
I have decided to use the term “InfoSec Bullshido” to describe the sort of BS that floats around InfoSec, with many people believing or promoting it. (With thanks to BW!) To be charitable, I generally assume that people promote such ideas though ignorance or insufficient understanding, though there certainly appear to be some who actively encourage mistaken beliefs through a desire to profit from FUD (Fear, Uncertainty, Doubt – https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt).
The comic above (https://xkcd.com/936/), by the (brilliant, in my opinion) cartoonist known as xkcd, beautifully captures a major issue in Information Security – password complexity. (I actually found this cartoon in a paper on cryptography I used as a reference for a course I took. Amazing!)
In general, I think we can break password policies down into several areas, including math, hardware, software, and wetware.
Math:
The mathematical side of password complexity focuses on the entropy (https://en.wikipedia.org/wiki/Entropy_%28information_theory%29) of the password, which refers to the amount of “randomness”, and the probabilities associated with attempting to “brute force” the password by trying every conceiveable value. The challenge here is that “random” is a loaded term in mathematics, and that computers (being deterministic beasts, mostly) generally use pseudorandom number generators, which are algorithms used to generate apparently random sequences. Mathematical attacks generally focus on things like attempting to determine patterns in these generators, or in the seed values on which they are based. Check out Lavarand (https://en.wikipedia.org/wiki/Lavarand) for a hint of how complex these questions actually are, though in practice, most of us need to simply assume that the math is valid and implemented correctly.
One interesting note here is that human-generated passwords are generally NOT fully random, and there are a number of attacks which can be used to dramatically reduce the time required to “crack” them. A topic for another time.
Hardware:
I won’t discuss this here, except to note that computer chips designed for high-end graphics are often used for password cracking as well, and the level of sophistication is constantly growing.
Software:
This is where it starts to get more relevant for more people. The security of a system depends not only on the math and the hardware, but also assumes that everything is implemented correctly. The best possible mathematical algorithm won’t be effective if it’s not implemented correctly, and it’s vitally important to ensure that a system you design isn’t easy to bypass. For example, a well-designed system will limit the number of login attempts, to prevent someone from simply automating a process which will try each possible password value until they get in.
Password storage is another important area, which I will probably discuss in more detail at some future date. For now, just note that you want to ensure that you never store passwords in plain text, and always need to protect your account list.
Wetware:
This is the human side of things – you know, the REALLY complicated part... We are not very good at remembering random strings, but are VERY good at patterns, and are very creative around making things easier.
Which brings us to password complexity rules, and the BS associated with them.
Password complexity rules are generally associated with the US NIST (National Institute of Standards and Technology) standard “Electronic Authentication Guideline”, published in 2004 (https://csrc.nist.gov/CSRC/media/Publications/sp/800-63/ver-10/archive/2004-06-30/documents/sp800-63-v1-0.pdf), which highlights the difference between system-defined and user-defined passwords, and spends significant effort (section A.2.1) discussing the human side of the equation:
“Since Shannon used a 27 character alphabet it may seem that the entropy of user selected passwords would be much larger, however the assumption here is that users will choose passwords that are almost entirely lower case letters, unless forced to do otherwise, and that rules that force them to include capital letters or non-alphabetic characters will generally be satisfied in the simplest and most predictable manner, often by putting a capital letter at the start (as we do in ordinary English) and punctuation or special characters at the end, or by some simple substitution, such as $ for the letter “s.” Moreover rules that force passwords to appear to be highly random will be counterproductive because they will make the passwords hard to remember. Users will then write the passwords down and keep them in a convenient (that is insecure) place, such as pasted on their monitor. Therefore it is reasonable to start from estimates of the entropy of simple English text, assuming only a 27-symbol alphabet.”
The notes on human behaviour are quite valid (though there has been a LOT of research in this area in the 70-odd years since Shannon published his original paper in 1948), and the standard goes on the discuss the use of dictionary attacks, which use English words and variations on them, including “leetspeak” (https://en.wikipedia.org/wiki/Leet), though the standard doesn’t mention the term. The problem, though, is near the end of the standard, where, along with mentioning longer passphrases and describing an approach which would “grade” passwords and accept those which meet some minimum entropy standard, the document states:
“Consider a system that used:
a minimum of 8 character passwords, selected by subscribers from an alphabet of 94 printable characters,
required subscribers to include at least one upper case letter, one lower case letter, one number and one special character, and;
Used a dictionary to prevent subscribers from including common words and prevented permutations of the username as a password.”
THIS is what led to years of unnecessarily-complex password rules and policies, and all the pain and heart-ache associated with them. People write down their passwords, use the same password for every system, follow patterns which are trivial for machines to break, and so on.
Part of the problem is that the person who drafted the 2004 NIST standard was not a security expert, and his research was based on a white paper written in the 1980’s (https://gizmodo.com/the-guy-who-invented-those-annoying-password-rules-now-1797643987).
He DID say he was sorry, though.
The problem for us is that silly humans picked up on the “easy” rules (easy for a computer, however hard for a human) rather than working to develop a system to “grade” passwords according to their level of entropy, then spent a generation trying to justify these “rules”. Most of those people probably aren’t even aware of the source of the policy, and even fewer have actually read it (or skimmed – it’s pretty dry stuff for a non-crypto person).
Fortunately, though it will take years to percolate through the industry, the standard was updated in 2017, as NIST Special Publication 800-63B – Digital Identity Guidelines (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf). This new document abandons the prior password complexity rules in favour of a more nuanced discussion. Hopefully, technology professionals will now also be more nuanced in their approach to passwords and stop all the BS... though I won’t hold my breath.
Cheers!
Comments