94 lines
5.2 KiB
TeX
94 lines
5.2 KiB
TeX
% =========================================================================== %
|
|
\nn{Introduction}
|
|
|
|
Passwords. Everybody reading this text most assuredly recalls at least
|
|
\emph{some} of their own. The security-minded person perhaps even dozens. They
|
|
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 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
|
|
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 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, 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
|
|
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 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 that are used in the so called
|
|
\emph{practical} part, where it is further described 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 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 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 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 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.
|
|
|
|
Terminology is located in Appendix~\ref{appendix:terms}, feel free to give it a
|
|
read.
|
|
|
|
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 a real
|
|
value.
|
|
|
|
% =========================================================================== %
|
|
|