178 lines
4.5 KiB
TeX
178 lines
4.5 KiB
TeX
% =========================================================================== %
|
|
% Encoding: UTF-8 (žluťoučký kůň úpěl ďábelšké ódy)
|
|
% =========================================================================== %
|
|
|
|
% =========================================================================== %
|
|
\nn{Introduction}
|
|
|
|
% =========================================================================== %
|
|
\part{Theoretical part}
|
|
|
|
\n{1}{Purpose}
|
|
What this write-up is attempting to achieve.
|
|
|
|
|
|
\n{1}{Terms}
|
|
Introduce relevant terms.
|
|
|
|
|
|
\n{1}{Cryptography primer}\label{sec:cryptographyprimer}
|
|
Pre-requisities necessary for following up.
|
|
|
|
\n{2}{Hash functions}
|
|
Explanation.
|
|
\n{3}{Uses and \textit{mis}uses}
|
|
The good the bad and the ugly of hash usage (including or in some cases
|
|
excluding salting, weak hashes, split hashes (Microsoft)).
|
|
\n{3}{Threats to hashes}
|
|
Rainbow tables, broken hash functions...
|
|
|
|
\n{2}{Encryption}
|
|
Generally.
|
|
\n{3}{The key exchange problem}
|
|
\n{3}{The key protection problem}
|
|
|
|
|
|
\n{1}{Brief passwords history}\label{sec:history}
|
|
|
|
\n{2}{Purpose over time}
|
|
|
|
\n{2}{What is considered a password}
|
|
|
|
\n{2}{Problems with passwords}
|
|
\n{3}{Arbitrary length requirements (min/max)}
|
|
\n{3}{Arbitrary complexity requirements}
|
|
\n{3}{Restricting special characters}
|
|
|
|
|
|
\n{1}{Password strength validation}
|
|
Entropy, dictionaries, multiple factors.
|
|
|
|
|
|
\n{1}{Web security}\label{sec:websecurity}
|
|
The internet being the vast space of intertwined concepts and ideas, is a
|
|
superset of the Web, which is the part of the internet zoomed in on in this
|
|
section.
|
|
|
|
\n{2}{Browsers}\label{sec:browsers}
|
|
What they are, what do they do, how do they relate into the security aspect
|
|
(privileged process running untrusted code on user's computer), history,
|
|
present, security focus of the dev teams, user facing signalling (padlock
|
|
colours, scary warnings).
|
|
|
|
\n{2}{Cross-site scripting}\label{sec:xss}
|
|
|
|
\n{2}{Content Security Policy}\label{sec:csp}
|
|
|
|
\n{1}{Sandboxing}\label{sec:sandboxing}
|
|
\n{2}{User isolation}
|
|
Admin vs regular user, privilege escalation, least-privilege principle,
|
|
zero-trust principle.
|
|
\n{2}{Process isolation}
|
|
Sandbox escape.
|
|
\n{2}{Namespaced isolation}
|
|
Sandbox escape.
|
|
|
|
|
|
\n{1}{Data storage}
|
|
Among the key aspects of any security-minded system (application), the
|
|
following are certain to make the count:
|
|
\begin{enumerate}
|
|
\item data integrity
|
|
\item data authenticity
|
|
\item data confidentiality
|
|
\end{enumerate}
|
|
|
|
\n{2}{Integrity}
|
|
|
|
\n{2}{Authenticity}
|
|
|
|
\n{2}{Confidentiality}
|
|
|
|
\n{2}{Encryption-at-rest}
|
|
|
|
|
|
\n{1}{Compromise checking and prevention}
|
|
|
|
\n{2}{HIBP and similar tools}
|
|
|
|
\n{2}{OWASP Top 10 for the implementers}
|
|
|
|
\n{2}{Password best practices}
|
|
|
|
|
|
% =========================================================================== %
|
|
\part{Practical part}
|
|
|
|
|
|
\n{1}{Toolchain}
|
|
|
|
\n{2}{Development}
|
|
\n{3}{A word about Nix}
|
|
\url{https://builtwithnix.org/}
|
|
|
|
\n{2}{Production}
|
|
|
|
|
|
\n{1}{Application architecture}
|
|
|
|
\n{2}{Data integrity}
|
|
|
|
\n{2}{Data authenticity}
|
|
|
|
\n{2}{Data confidentiality}
|
|
At rest, only decrypted in memory when correct app key provided.
|
|
|
|
\n{2}{Connection security}
|
|
|
|
\n{2}{User isolation}
|
|
In-application administrator does not posess the capability to see sensitive
|
|
user data. The administrator only sees the number of tracked items and
|
|
(potentially) number of active alerts (for breached credentials) for a given
|
|
user.\\
|
|
Least-privilege principle.\\
|
|
Zero trust principle.
|
|
|
|
|
|
\n{1}{Implementation}
|
|
|
|
\n{2}{Compromise checking}
|
|
Periodicity, alerting mechanisms (email, Telegram..)
|
|
\n{3}{Have I Been Pwned? Integration}
|
|
\n{3}{Local Dataset Plugin}
|
|
|
|
\n{2}{Best practices}
|
|
Describe built-in failovers and fallback mechanisms (request retries),
|
|
collecting exposed app metrics and alerting based on their status.
|
|
|
|
Observability - in-app tracing collected by e.g. Jaeger
|
|
(\url{https://jaegertracing.io}) or \url{https://opentelemetry.io/} - for
|
|
superior performance insights on CPU, storage, network latency and jitter.
|
|
|
|
\n{2}{Database configuration}
|
|
Decribe tuning for performance while also properly securing the DB.
|
|
|
|
The plan is to have 2 DBs: one for raw data (\url{https://postgresql.org}) and
|
|
another one for checksum validation (\url{https://immudb.io/})
|
|
|
|
\n{2}{Deployment recommendations}
|
|
Decribe in detail the following:
|
|
\begin{itemize}
|
|
\item behind a reverse proxy (TLS termination) or inside of a private network
|
|
\item reasonable host security
|
|
\end{itemize}
|
|
|
|
|
|
\n{1}{Validation}
|
|
|
|
\n{2}{Unit tests}
|
|
|
|
\n{2}{Integration tests}
|
|
|
|
\n{2}{Click-ops}
|
|
|
|
% =========================================================================== %
|
|
\nn{Conclusion}
|
|
|
|
% =========================================================================== %
|