diff --git a/graphics/arbitrarypasswdlengthlimit.jpg b/graphics/arbitrarypasswdlengthlimit.jpg new file mode 100644 index 0000000..0cc55b8 Binary files /dev/null and b/graphics/arbitrarypasswdlengthlimit.jpg differ diff --git a/graphics/forbiddencharacters.jpg b/graphics/forbiddencharacters.jpg new file mode 100644 index 0000000..9aa6045 Binary files /dev/null and b/graphics/forbiddencharacters.jpg differ diff --git a/tex/references.bib b/tex/references.bib index bfe8cb8..de3ac6b 100644 --- a/tex/references.bib +++ b/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]}} +} + % =========================================================================== % diff --git a/tex/text.tex b/tex/text.tex index 93915e7..907d735 100644 --- a/tex/text.tex +++ b/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}