tex: add stuff on hashes and passwords
This commit is contained in:
parent
3423d01c5b
commit
7f957a1788
Binary file not shown.
After Width: | Height: | Size: 28 KiB |
Binary file not shown.
After Width: | Height: | Size: 30 KiB |
|
@ -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]}}
|
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]}}
|
||||||
|
}
|
||||||
|
|
||||||
% =========================================================================== %
|
% =========================================================================== %
|
||||||
|
|
158
tex/text.tex
158
tex/text.tex
|
@ -82,35 +82,161 @@ Pre-requisites necessary for following up.
|
||||||
|
|
||||||
|
|
||||||
\n{2}{Hash functions}
|
\n{2}{Hash functions}
|
||||||
Explanation. What are hash functions
|
|
||||||
|
|
||||||
\n{3}{Uses and \textit{mis}uses}
|
Hash functions are cryptographic algorithms used to help with a number of
|
||||||
The good, the bad and the ugly of hash usage (including or in some cases
|
things: integrity verification, password protection, digital signature,
|
||||||
excluding salting, weak hashes, split hashes (Microsoft)).
|
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}
|
The popularity stems from a common use case: the need to identify a chunk of
|
||||||
Rainbow tables, broken hash functions\ldots
|
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}
|
\n{3}{Restricting special characters}
|
||||||
|
|
||||||
Service providers have too often been found forbidding the use of so called
|
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
|
\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
|
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,
|
intent stays the same: preventing users from inputting characters into the
|
||||||
which the system cannot comfortably handle, for one reason or another.
|
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}
|
Note that ``Passw0rd!'' would have been a perfectly acceptable password for the
|
||||||
Entropy, dictionaries, multiple factors.
|
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}
|
\n{1}{Web security}\label{sec:websecurity}
|
||||||
|
|
Reference in New Issue