1
0

tex(theoret.): update how citations are done

This commit is contained in:
surtur 2023-08-18 18:02:20 +02:00
parent f4d5f6b29a
commit c47338f8ad
Signed by: wanderer
SSH Key Fingerprint: SHA256:MdCZyJ2sHLltrLBp0xQO0O1qTW9BT/xl5nXkDvhlMCI

@ -162,7 +162,7 @@ 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}.
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.
@ -214,18 +214,20 @@ represents that a password is:
\end{itemize}
\obr{Short arbitrary password length
limit~\cite{larsklint}}{fig:arbitrarypasswdlengthlimit}{.8}{graphics/arbitrarypasswdlengthlimit.jpg}
limit}{fig:arbitrarypasswdlengthlimit}{.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}.
The error message in above the password input field depicted in
Figure~\ref{fig:arbitrarypasswdlengthlimit} is wrong for multiple reasons, and
it is a classic example of short arbitrary length requirement~\cite{larsklint}.
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.
(NIST) in this regard is a minimum of 64 and a maximum of 256 characters,
which, as they put it, \emph{should be sufficient for most users' needs}.
\n{3}{Restricting special characters}
@ -235,20 +237,21 @@ used to protect privileged access. Ways of achieving the same may vary but the
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.
injection attacks'' or ``angle brackets may be used in XSS attacks''. Instead,
the real message it often unwittingly 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}
passwords}{fig:forbiddencharacters}{.8}{graphics/forbiddencharacters.jpg}
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}
validator displayed in
Figure~\ref{fig:forbiddencharacters}~\cite{forbiddencharacters}. NIST's
recommendations on this matter 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.