tex: extend, reword intro, rm vision section
This commit is contained in:
parent
56cc0239d8
commit
721b704457
100
tex/intro.tex
100
tex/intro.tex
@ -7,62 +7,76 @@ are complex and at least twelve characters long. They are only ever used in the
|
|||||||
one place they were created for. And they are definitely getting rotated at
|
one place they were created for. And they are definitely getting rotated at
|
||||||
least once a year. Or are they?
|
least once a year. Or are they?
|
||||||
|
|
||||||
A token so ubiquitous that it becomes tiring for human being to keep track of
|
A token so ubiquitous that it becomes tiring for a human being to keep track of
|
||||||
all the places where it is required in some form or another. At some point, it
|
all the places where it is required in one form or another. At some point, it
|
||||||
almost feels easier to stop caring and use the password intended for \emph{the
|
almost feels easier to stop caring and use the password intended for \emph{the
|
||||||
other site} for this one, too. What harm could that possibly do. The answer is
|
other site} for this one, too. What harm could that possibly do. The answer
|
||||||
unimaginable, depending on the services in question, its relevance to the
|
might well be ``unimaginable'', depending on the service in question, its
|
||||||
person being discussed, and also on \emph{how many other} services also share
|
relevance to the person being discussed, and also on \emph{how many other}
|
||||||
this password. A service requires a registration? No problem, the password will
|
services happen to share this password. Does a service require registration? No
|
||||||
be the name of the cat plus current year, so as to make it more secure. It is
|
problem, the password will be the name of the cat (or dog, or the youngest
|
||||||
the password rotation day again this month, a handful of logins will be
|
child) plus current year, so as to make it more \emph{secure}. It is the
|
||||||
disabled if their passwords are not changed in the next couple of hours. No
|
password rotation day again this month, a handful of logins will be disabled if
|
||||||
worries, it is already covered by a combination of the current month and the
|
their passwords are not changed in the next couple of hours. No worries, it is
|
||||||
name of the specific service for each of them. A neat system. But just in case
|
already covered by a combination of the current month and the name of the
|
||||||
they got forgotten in the fragments of this hectic lifestyle, they need to be
|
specific service for each of them. A neat system. But just in case it got
|
||||||
written down on a sticker note. Not to worry, nobody knows, it is hidden under
|
forgotten and lost in the fragments of this hectic lifestyle, the passwords
|
||||||
the keyboard, it is practically invisible.
|
need to be written down on a sticker note. Not to worry, nobody knows, it is
|
||||||
|
hidden under the keyboard, it is practically invisible.
|
||||||
|
|
||||||
These are all examples of poor password practices on user's side; some might
|
These are all examples of poor password practices on user's side; some might
|
||||||
have been circumstantially helped to, such as the too frequently forced
|
have been circumstantially helped to, such as the too frequent forced password
|
||||||
password rotation, others can be ascribed to users not being sufficiently
|
rotation, others could be ascribed to users not being sufficiently well-versed
|
||||||
well-versed in the intricacies of password hygiene.
|
in the intricacies of password hygiene.
|
||||||
|
|
||||||
Inevitably, these passwords are going to get appropriately treated in the form
|
Inevitably, these passwords are going to get appropriately treated, be in the
|
||||||
of misuse, be it from a nosy colleague that finds the sticker note, or if the
|
form of misuse from a nosy colleague that finds the sticker note, or if the
|
||||||
user account is ever a target of an attack, the password's \emph{only} role, to
|
user account is ever a target of an attack, the password's \emph{only} role, to
|
||||||
protect the access, will likely not stand much chance.
|
gate the access, will likely not stand much of a chance.
|
||||||
|
|
||||||
This thesis tangentially covers user-relating issues like the ones described
|
This thesis tangentially covers user-relating issues like the ones described
|
||||||
above, but rather than attempting to go for prevention, it mainly focuses on
|
above, but rather than attempting to remedy them with prevention, it mainly
|
||||||
dealing with the acute consequence of such behaviour: a password breach. The
|
focuses on dealing with the acute consequence of such behaviour: a password
|
||||||
thesis consists of two parts. The theoretical one offers an overview of
|
breach. The thesis consists of two parts: a theoretical one, which provides
|
||||||
password-related topics and frames the password as well as security topics in
|
theoretical background to concepts and processes used in the so called
|
||||||
the web context in order to provide necessary context for the second part of
|
\emph{practical} part, which describes what exactly has been done and how.
|
||||||
the thesis. Cryptography topics such as hashing, encryption and entropy are
|
In the theoretical part, password hash functions and hash cracking are mentioned,
|
||||||
mentioned, and within the browser context a special spotlight is given to the
|
and within the browser context a special spotlight is given to Content Security
|
||||||
protocols powering the web: HTTP and TLS.
|
Policy and Cross-site scripting. Program's configuration schema is conceived,
|
||||||
|
the choices of local and online data sources are explained, and recommended
|
||||||
|
deployment set-up is described.
|
||||||
|
|
||||||
The practical part discusses the architecture, decision making, implementation
|
The practical part discusses application architecture decisions, development
|
||||||
details and validation methods utilised when building a web application that
|
process, implementation details and validation methods utilised when building
|
||||||
enables users to monitor the breach status of their credentials by utilising an
|
the subject web application. The program does not have too many
|
||||||
online API service and local data imported into the program by the operators of
|
dependencies and is relatively lightweight, which means that anybody with even
|
||||||
the tool. The program does not have many dependencies and is relatively
|
little experience should be able to potentially run their own private instance,
|
||||||
lightweight, which means that anybody with even little experience should be
|
if they so choose.
|
||||||
able to potentially run their own private instance, if they so choose.
|
|
||||||
|
|
||||||
The purpose of the program is to allow users to learn if their credentials were
|
The purpose of the program is to allow users to learn if they were breached,
|
||||||
breached, while the reason for the breach might even be considered secondary in
|
and the application developed as an integral part of this thesis should enable
|
||||||
importance. Breach data is not a publicly traded commodity and is relatively
|
them to quickly and privately check potential compromise status against
|
||||||
|
configured local and online data sources. Of course the quality of the
|
||||||
|
compromise monitoring depends on access to quality data, which is partially in
|
||||||
|
the purview of the application operator.
|
||||||
|
|
||||||
|
Breach data is not exactly a publicly traded commodity and can be relatively
|
||||||
hard to make sense of, given that we are talking about literal
|
hard to make sense of, given that we are talking about literal
|
||||||
\emph{terrabytes} of data available, if there is even the slightest interest to
|
\emph{terrabytes} of data available, if there is even a slightest interest to
|
||||||
find it online. Breaches happen, and of course, can inform the decision to stay
|
find it online. Breaches do happen, and can, of course, inform the decision to
|
||||||
or leave the service, but there is not always a choice element involved, or
|
stay or leave the service, but there is not always a choice element involved,
|
||||||
only a limited amount. Either way, knowledge is light and as such precedes
|
or only a limited amount. Either way, knowledge is light and as such precedes
|
||||||
informed decision-making. Abstracting away the ugly parts and offering users an
|
informed decision-making. Abstracting away the ugly parts and offering users an
|
||||||
understandable interface would likely result in their improved security
|
understandable interface might likely result in their improved security
|
||||||
posture, if anything.
|
posture, if anything.
|
||||||
|
|
||||||
|
As per the security posture of the users, in order not to weaken it, the
|
||||||
|
in-application administrative-level users should only be able to configure
|
||||||
|
online and local data sources and initially set up user accounts but should
|
||||||
|
\emph{not} have access to users' search queries or credential entries.
|
||||||
|
Sensitive user data should be encrypted at rest and not even
|
||||||
|
administrative-level users should be able to read them.
|
||||||
|
|
||||||
The author has been striving to utilise modern tooling and development
|
The author has been striving to utilise modern tooling and development
|
||||||
practices in an effort to build a maintainable and long-lasting piece of
|
practices in an effort to build a maintainable and long-lasting piece of
|
||||||
software that serves its users well. When deployed, it could provide real
|
software that serves its users well. When deployed, it could provide real
|
||||||
|
@ -1,33 +1,8 @@
|
|||||||
% =========================================================================== %
|
% =========================================================================== %
|
||||||
\part{Theoretical part}
|
\part{Theoretical part}
|
||||||
|
|
||||||
\n{1}{Vision}
|
|
||||||
|
|
||||||
The thesis consists of two main parts: a theoretical one that provides
|
|
||||||
theoretical background to concepts and processes used in the other one - so
|
|
||||||
called \emph{practical} part, which then describes what exactly has been done
|
|
||||||
and how.
|
|
||||||
|
|
||||||
The application developed as part of this thesis should enable users to quickly
|
|
||||||
and privately check their credentials' compromise status against configured
|
|
||||||
local and online data sources. Of course the compromise monitoring depends on
|
|
||||||
access to quality data, which is in the purview of the application
|
|
||||||
administrator.
|
|
||||||
|
|
||||||
In-application administrative-level user is able to configure online and local
|
|
||||||
data sources, initially set up user accounts but does not have the access
|
|
||||||
users' search queries or credential entries, or more broadly, is not able to
|
|
||||||
read sensitive user information. This is enabled by the architectural decisions
|
|
||||||
the application has taken, whereby sensitive user data is encrypted and not
|
|
||||||
even administrative-level users are able to read them.
|
|
||||||
|
|
||||||
|
|
||||||
\n{1}{Cryptography primer}\label{sec:cryptographyprimer}
|
\n{1}{Cryptography primer}\label{sec:cryptographyprimer}
|
||||||
|
|
||||||
\n{2}{Encryption}
|
|
||||||
|
|
||||||
\textbf{TODO:} add \emph{why} we care and how it's going to be used.
|
|
||||||
|
|
||||||
\n{2}{Hash functions}
|
\n{2}{Hash functions}
|
||||||
|
|
||||||
Hash functions are algorithms used to help with a number of things: integrity
|
Hash functions are algorithms used to help with a number of things: integrity
|
||||||
|
Reference in New Issue
Block a user