76 lines
4.4 KiB
TeX
76 lines
4.4 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 human being to keep track of
|
|
all the places where it is required in some 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.
|
|
|
|
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.
|
|
|
|
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
|
|
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.
|
|
|
|
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.
|
|
|
|
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 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
|
|
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
|
|
informed decision-making. Abstracting away the ugly parts and offering users an
|
|
understandable interface would likely result in their improved security
|
|
posture, if anything.
|
|
|
|
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
|
|
value.
|
|
|
|
Terminology is located in Appendix~\ref{appendix:terms}, feel free to give it a
|
|
read.
|
|
|
|
% =========================================================================== %
|
|
|