From e863e7ca124f55542586a85e3705df2a6ecbbe7c Mon Sep 17 00:00:00 2001 From: leo Date: Mon, 22 May 2023 21:44:52 +0200 Subject: [PATCH] tex: add stuff on data integrity and authenticity --- tex/text.tex | 44 ++++++++++++++++++++++++++++++++++++++------ 1 file changed, 38 insertions(+), 6 deletions(-) diff --git a/tex/text.tex b/tex/text.tex index 4303568..275c20e 100644 --- a/tex/text.tex +++ b/tex/text.tex @@ -566,14 +566,46 @@ possible besides what the application absolutely requires. \n{1}{Application architecture} -\n{2}{Data integrity} -TODO. +\n{2}{Data integrity and authenticity} -\n{2}{Data authenticity} -TODO. +The user can interact with the application via a web client, such as a browser, +and is required to authenticate for all sensitive operations. To not only know +\emph{who} the user is but also make sure they are \emph{permitted} to perform +the action they are attempting, the program employs an \emph{authorisation} +mechanism in the form of sessions. These are on the client side represented by +cryptographically signed and encrypted (using 256 bit AES) cookies. That lays +foundations for a few things: the data saved into the cookies can be regarded +as private because short of future \emph{quantum computers} only the program +itself can decrypt and access the data, and the data can be trusted since it is +both signed using the key that only the program controls and \emph{encrypted} +with \emph{another} key that equally only the program holds. + +The cookie data is only ever written \emph{or} read at the server side, +solidifying the authors decision to let it be encrypted, as there is not point +in not encrypting it for some perceived client-side simplification. Users +navigating the website send their session cookie in \textbf{every request} (if +it exists) to the server, which then verifies the integrity of the data and in +case its valid, determines the existence and potential amount of user privilege +that should be granted. Public endpoints do not mandate the presence of a valid +session by definition, while at protected endpoints the user is authenticated +at every request. When a session expires or if there is no session to begin +with, the user is either shown a \emph{Not found} error message, the +\emph{Unauthorised} error message or redirected to \texttt{/signin}. + +Another aspect that contributes to data integrity from another point of view is +utilising database \emph{transactions} for bundling together multiple database +operations that collectively change the \emph{state}. Using the transactional +jargon, the data is only \emph{committed} if each individual change was +successful. In case of any errors, the database is instructed to perform an +atomic \emph{rollback}, which brings it back to a state before the changes were +ever attempted. + +The author has additionally considered the thought of utilising an embedded +immutable database like immudb (\url{https://immudb.io}) for record keeping +(verifiably storing data change history) and additional data integrity checks, +e.g.\ for tamper protection purposes and similar, however, that work remains +yet to be materialised. -\n{2}{Data confidentiality} -At rest, only decrypted in memory when correct app key provided. \n{2}{Transport security} User connecting to the application should rightfully expect for their data to