tex: extend, reword intro, rm vision section

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
 least once a year. Or are they?
 
-A token so ubiquitous that it becomes tiring for human being to keep track of
-all the places where it is required in some form or another. At some point, it
+A token so ubiquitous that it becomes tiring for a human being to keep track of
+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
-other site} for this one, too.  What harm could that possibly do. The answer is
-unimaginable, depending on the services in question, its relevance to the
-person being discussed, and also on \emph{how many other} services also share
-this password. A service requires a registration? No problem, the password will
-be the name of the cat plus current year, so as to make it more secure. It is
-the password rotation day again this month, a handful of logins will be
-disabled if their passwords are not changed in the next couple of hours. No
-worries, it is already covered by a combination of the current month and the
-name of the specific service for each of them. A neat system.  But just in case
-they got forgotten in the fragments of this hectic lifestyle, they need to be
-written down on a sticker note. Not to worry, nobody knows, it is hidden under
-the keyboard, it is practically invisible.
+other site} for this one, too.  What harm could that possibly do. The answer
+might well be ``unimaginable'', depending on the service in question, its
+relevance to the person being discussed, and also on \emph{how many other}
+services happen to share this password. Does a service require registration? No
+problem, the password will be the name of the cat (or dog, or the youngest
+child) plus current year, so as to make it more \emph{secure}. It is the
+password rotation day again this month, a handful of logins will be disabled if
+their passwords are not changed in the next couple of hours. No worries, it is
+already covered by a combination of the current month and the name of the
+specific service for each of them. A neat system.  But just in case it got
+forgotten and lost in the fragments of this hectic lifestyle, the passwords
+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
-have been circumstantially helped to, such as the too frequently forced
-password rotation, others can be ascribed to users not being sufficiently
-well-versed in the intricacies of password hygiene.
+have been circumstantially helped to, such as the too frequent forced password
+rotation, others could be ascribed to users not being sufficiently well-versed
+in the intricacies of password hygiene.
 
-Inevitably, these passwords are going to get appropriately treated in the form
-of misuse, be it from a nosy colleague that finds the sticker note, or if the
+Inevitably, these passwords are going to get appropriately treated, be in 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
-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
-above, but rather than attempting to go for prevention, it mainly focuses on
-dealing with the acute consequence of such behaviour: a password breach. The
-thesis consists of two parts. The theoretical one offers an overview of
-password-related topics and frames the password as well as security topics in
-the web context in order to provide necessary context for the second part of
-the thesis. Cryptography topics such as hashing, encryption and entropy are
-mentioned, and within the browser context a special spotlight is given to the
-protocols powering the web: HTTP and TLS.
+above, but rather than attempting to remedy them with prevention, it mainly
+focuses on dealing with the acute consequence of such behaviour: a password
+breach. The thesis consists of two parts: a theoretical one, which provides
+theoretical background to concepts and processes used in the so called
+\emph{practical} part, which describes what exactly has been done and how.
+In the theoretical part, password hash functions and hash cracking are mentioned,
+and within the browser context a special spotlight is given to Content Security
+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
-details and validation methods utilised when building a web application that
-enables users to monitor the breach status of their credentials by utilising an
-online API service and local data imported into the program by the operators of
-the tool. The program does not have many dependencies and is relatively
-lightweight, which means that anybody with even little experience should be
-able to potentially run their own private instance, if they so choose.
+The practical part discusses application architecture decisions, development
+process, implementation details and validation methods utilised when building
+the subject web application. The program does not have too many
+dependencies and is relatively lightweight, which means that anybody with even
+little experience should be 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
-breached, while the reason for the breach might even be considered secondary in
-importance. Breach data is not a publicly traded commodity and is relatively
+The purpose of the program is to allow users to learn if they were breached,
+and the application developed as an integral part of this thesis should enable
+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
-\emph{terrabytes} of data available, if there is even the slightest interest to
-find it online. Breaches happen, and of course, can inform the decision to stay
-or leave the service, but there is not always a choice element involved, or
-only a limited amount. Either way, knowledge is light and as such precedes
+\emph{terrabytes} of data available, if there is even a slightest interest to
+find it online. Breaches do happen, and can, of course, inform the decision to
+stay or leave the service, but there is not always a choice element involved,
+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
-understandable interface would likely result in their improved security
+understandable interface might likely result in their improved security
 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
 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

tex/part-theoretical.tex

@@ -1,33 +1,8 @@
 % =========================================================================== %
 \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{2}{Encryption}
-
-\textbf{TODO:} add \emph{why} we care and how it's going to be used.
-
 \n{2}{Hash functions}
 
 Hash functions are algorithms used to help with a number of things: integrity