tex: add stuff on hashes and passwords

tex/references.bib

@@ -239,4 +239,100 @@
 	note={{Available from: \url{https://www.techradar.com/news/this-well-intentioned-chrome-feature-is-causing-serious-problems} [viewed 2023-05-23]}}
 }
 
+@misc{mcmillan,
+	howpublished = {[online]},
+	author = {Robert McMillan},
+	publisher = {Wired},
+	year = 2012,
+	month = jan,
+	day = 27,
+	title = {{The World's First Computer Password? It Was Useless Too}},
+	note={{Available from: \url{https://www.wired.com/2012/01/computer-password/} [viewed 2023-05-24]}}
+}
+
+@misc{nisthistory,
+	author = {{National Institute of Standards and Technology}},
+	publisher = {NIST},
+	title = {Passphrase},
+	howpublished = {[online]},
+	note={{Available from: \url{https://csrc.nist.gov/glossary/term/Passphrase} [viewed 2023-05-24]}}
+}
+
+@misc{speakeasy,
+	publisher = {Legends of America},
+	author = {Kathy Alexander},
+	title = {{Speakeasies of the Prohibition Era}},
+	year = 2022,
+	month = dec,
+	howpublished = {[online]},
+	note={{Available from: \url{https://www.legendsofamerica.com/ah-prohibitionspeakeasy/} [viewed 2023-05-24]}}
+}
+
+@misc{asciirfc20,
+	series =    {Request for Comments},
+	number =    20,
+	howpublished =  {RFC 20},
+	publisher = {RFC Editor},
+	doi =       {10.17487/RFC0020},
+	author =    {Vint Cerf},
+	title =     {{ASCII format for network interchange}},
+	pagetotal = 9,
+	year =      1969,
+	month =     oct,
+	note = {{Also available from \url{https://www.rfc-editor.org/info/rfc20}}},
+}
+
+@techreport{iso10646,
+type = {Standard},
+key = {ISO/IEC 10646:2020},
+author = {{ISO/IEC 10646:2020}},
+year = {2020},
+title = {{Information technology -- Universal Coded Character Set (UCS)}},
+address = {Geneva, CH},
+institution = {International Organization for Standardization}
+}
+
+@misc{larsklint,
+	author = {{Lars Klint}},
+	publisher = {Twitter},
+	year = 2016,
+	month = {{June}},
+	day = 30,
+	title = {{Excuse me @EtihadAirways, why do you insist on making my passwords worse?}},
+	howpublished = {[online]},
+	note={{Available from: \url{https://twitter.com/larsklint/status/748615185762484224} [viewed 2023-05-24]}}
+}
+
+@misc{etihad,
+	author = {{Etihad Airways}},
+	publisher = {Twitter},
+	year = 2016,
+	month = {{June}},
+	day = 30,
+	title = {Reply to Lars Klint},
+	howpublished = {[online]},
+	note={{Available from: \url{https://twitter.com/EtihadAirways/status/748626413306150912} [viewed 2023-05-24]}}
+}
+
+@misc{forbiddencharacters,
+	author = {{Nick Heer}},
+	publisher = {Twitter},
+	year = 2017,
+	month = jul,
+	day = 18,
+	title = {{This does not give me confidence in your password security, @YourAlberta. (cc. @troyhunt)}},
+	howpublished = {[online]},
+	note={{Available from: \url{https://twitter.com/nickheer/status/887196833872658432} [viewed 2023-05-24]}}
+}
+
+@misc{ncsc,
+	author = {{National Cyber Security Centre}},
+	year = 2018,
+	month = nov,
+	day = 18,
+	title = {{Password policy: updating your approach}},
+	howpublished = {[online]},
+	note={{Available from: \url{https://twitter.com/nickheer/status/887196833872658432} [viewed 2023-05-24]}}
+}
+
 % =========================================================================== %

tex/text.tex

@@ -82,35 +82,161 @@ Pre-requisites necessary for following up.
 
 
 \n{2}{Hash functions}
-Explanation. What are hash functions
 
-\n{3}{Uses and \textit{mis}uses}
-The good, the bad and the ugly of hash usage (including or in some cases
-excluding salting, weak hashes, split hashes (Microsoft)).
+Hash functions are cryptographic algorithms used to help with a number of
+things: integrity verification, password protection, digital signature,
+public-key encryption and others. Hashes are used in forensic analysis to prove
+authenticity of digital artifacts, to uniquely identify a change-set within
+revision-based source code management systems such as Git, Subversion or
+Mercurial, to detect known-malicious software by anti-virus programs or by
+advanced filesystems in order to verify block integrity and enable repairs, and
+also in many other applications that each person using a modern computing
+device has come across, such as when connecting to a website protected by the
+famed HTTPS.
 
-\n{3}{Threats to hashes}
-Rainbow tables, broken hash functions\ldots
+The popularity stems from a common use case: the need to identify a chunk of
+data. Of course, two chunks of data, two files, frames or packets could
+always be compared bit by bit, but that can get prohibitive from both cost and
+energy point of view relatively quickly. That is when hash functions come in,
+since they are able to take a long input and produce a short output, named a
+digest or a hash value.
 
+\n{3}{Rainbow tables}
 
-\n{1}{Brief passwords history}\label{sec:history}
+As passwords are in more responsible scenarios stored not directly but as
+hashes, attackers that would be interested in recovering the passwords really
+only have one option (except finding a critical vulnerability in the hash
+function): rainbow tables. Rainbow tables are lists of pre-computed hashes
+paired with the passwords that were used to create them. When attackers gain
+access to a password breach that contains hashes, all it takes is to find a
+match within the rainbow table and reversely resolve that to the known
+message: the password.
 
-\n{2}{Purpose over time}
+\n{1}{Passwords}\label{sec:passwords}
 
-\n{2}{What is considered a password}
+Passwords have been in use since the ancient times, apparently already the
+Roman sentries used passwords or \textit{watchwords} to discern who was allowed
+to enter an area. The Roman army had a special system of distributing passwords
+among the encampment members on a wooden tablet. Fast forward a couple of
+thousand years, during the days of the Prohibition Era in the United States, it
+was the secret ``speakeasies'' that were protecting their illegitimate
+alcohol-serving business using passwords~\cite{speakeasy}~\cite{nisthistory}.
+During the World War II.\ the US paratroopers' use of passwords has evolved to
+even include a counter-password.
+
+According to McMillan, the first \textit{computer} passwords date back to
+mid-1960s' Massachusetts Institute of Technology (MIT), when researchers at the
+university built a massive time-sharing computer called CTSS. Apparently,
+\textit{even then} the passwords did not protect the users as well as they were
+expected to~\cite{mcmillan}.
+
+Traditionally, passwords were expected to be memorised, but the large number of
+password-protected \emph{services} these days can make this impractical.  To
+list a few common examples, access to a bank account, electronic mailbox,
+personal computer encrypted disk are all protected by some form of a password.
+
+A password still often consists of a \textit{string} of characters typed into a
+prompt but its function is still the same: as per NIST it enables the
+\textit{verifier} to infer the \textit{claimant}'s identity via a secret the
+claimant holds.
+
+There are always some arbitrary requirements applied to what the password can
+be, only some turn out to smarter than others.
+
+Despite the impression given by the word ``password'', it does not need to be
+an actual word, while a non-word (in the dictionary sense) may indeed be harder
+to guess, which is a desirable property of passwords. A memorized secret
+consisting of a sequence of words or other text separated by spaces is
+sometimes called a passphrase. A passphrase is similar to a password in usage,
+but the former is generally longer for added security.
+
+\n{2}{Program-imposed constraints}
+
+Some of the following examples might be a bit anecdotal and more of an
+exception than a rule, nevertheless, when presented by a large-enough program
+creator/service provider, their decisions reach a sufficient amount of
+population, enough that the author will call them influential. They form how
+users think when creating password and affect what users expect from other
+services they happen to visit and use from that point on, as well.
+
+\n{3}{Short arbitrary length}
+
+It has been observed that a requirement for a ``strong'' password generally
+represents that a password is:
+
+\begin{itemize}
+  \item longer than 7 characters,
+  \item shorter than 11 characters,
+  \item begins with a letter and ends with a number OR
+  \item begins with a number and ends with a letter.
+\end{itemize}
+
+\obr{Short arbitrary password length
+limit~\cite{larsklint}}{fig:forbiddencharacters}{.8}{graphics/arbitrarypasswdlengthlimit.jpg}
+
+This is wrong for multiple reasons, and it is a classic example of short
+arbitrary length requirement. It essentially prevents users from using
+passphrases, makes using a password manager impractical and all of that has
+apparently been done ``because of security''~\cite{etihad}. Moreover, this
+might be an indicative of the fact that instead of storing passwords hashed (as
+it should be), they might be storing them in \textbf{plain text}.
+Otherwise, what reason could exist for the limit to be 10 characters?
+The recommendation of the US's National Institute for Standards and Technology
+(NIST) in this regard is a minimum of 64 and a maximum of 256 characters, which
+should be sufficient for most users' needs.
 
-\n{2}{Problems with passwords}
-\n{3}{Arbitrary length requirements (min/max)}
-\n{3}{Arbitrary complexity requirements}
 \n{3}{Restricting special characters}
+
 Service providers have too often been found forbidding the use of so called
 \textit{special characters} in passwords for as long as passwords have been
 used to protect privileged access. Ways of achieving the same may vary but the
-intent stays the same: prevent users from inputting characters into the system,
-which the system cannot comfortably handle, for one reason or another.
+intent stays the same: preventing users from inputting characters into the
+system, which the system cannot comfortably handle, for ``reasons'', which are
+usually something dubious along the lines of ``an apostrophe may be used in SQL
+injection attacks'' or ``angle brackets may be used in XSS attacks''. Instead
+the real message it announces is pointing right to the serious shortcomings of
+password handling of the site in question, as passwords should never be
+re-displayed in a context that is prone to Cross Site Scripting (XSS), and the
+passwords should always be hashed before being sent to the database anyway,
+leaving us with only alphanumeric characters, rendering the SQLi fears
+baseless.
 
+\obr{Forbidden special characters in
+passwords~\cite{forbiddencharacters}}{fig:forbiddencharacters}{.8}{graphics/forbiddencharacters.jpg}
 
-\n{1}{Password strength validation}
-Entropy, dictionaries, multiple factors.
+Note that ``Passw0rd!'' would have been a perfectly acceptable password for the
+validator displayed in Figure~\ref{fig:forbiddencharacters}.
+NIST's recommendations on this are that all printing ASCII~\cite{asciirfc20}
+characters as well as the space character SHOULD be acceptable in memorized
+secrets and Unicode~\cite{iso10646} characters SHOULD be accepted as well.
+
+\n{3}{Character composition requirements}
+
+There is a tendency to come up with bad passwords when there are character
+composition requirements in place, too.  The reality is that instead of
+creating strong passwords directly, most users first try a basic version and
+then keep tweaking characters until the password ends up fulfilling the minimum
+requirement.
+The \emph{problem} with that is that it has been shown, that people use similar
+patterns, i.e. starting with capital letters, putting a symbol last and a
+number in the last two positions. This is also known to cyber criminals
+cracking passwords and they run their dictionary attacks using the common
+substitutions, such as "\$" for "s", "E" for "3", "1" for "l", "@" for "a" etc.
+The password created in this manner will almost certainly be bad so all that is
+achieved is frustrating the user in order to still arrive at a bad password.
+
+\n{3}{Other common issues}
+
+Some services don't allow users to paste into passwords fields (disabling them
+using JavaScript), thereby essentially breaking the password manager
+functionality, which is an issue because it encourages bad password practices
+such as weak passwords and likewise, password reuse.
+
+Another frequent issue is forced frequent password rotation. Making frequent
+password rotations mandatory contributes to users developing a password
+creation pattern and is further a modern-day security anti-pattern and
+according to the British NCSC the practice ``carries no real benefits as stolen
+passwords are generally exploited immediately''~\cite{ncsc}.
 
 
 \n{1}{Web security}\label{sec:websecurity}