This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Voor project 4 moesten wij voor het individuele onderdeel een advies geven over de inrichting van de \emph{Centrale Bank}.
Voor project 4 moesten wij voor het individuele onderdeel een advies geven over het \emph{efficient inrichten van de Centrale Bank}.
Aan het eind van het eerste deel van het project moet \'e\'en van de adviezen van de studenten worden gekozen en uitgewerkt de rest van de loop van het project.
Wij moeten tijdens de loop van het project letten op vijf onderdelen: \emph{beheren, analyseren, adviseren ontwerpen en realiseren.}
@@ -41,7 +41,9 @@ \subsection{Kwaliteitseisen}
Wij hebben een document met kwaliteitseisen voor de groep van de code, bank, ATM voor de groep.
Deze is op Github terug te vinden.
Ook individueel heb ik kwaliteitseisen voor de centrale bank opgesteld. \\
Ook individueel heb ik kwaliteitseisen voor de centrale bank opgesteld.
Al mijn individuele eisen heb ik toegepast in dit verslag.
De eisen van de groep gaan meer over de automaat, en hier zijn dus maar een paar punten van verwerkt. \\
In figuur \ref{fig:gitmodel} is het model wat wij gebruiken op onze Git pagina, \href{https://github.com/Gewad/Project4Bankalicious}{Project4Bankalicious}.
Ieder groepslid werkt op zijn individuele branch, en als je klaar bent met jouw onderdeel, dan wordt hij in test gemerged.
Als er geen problemen lijken te zijn op de test beslissen wij in een groep of wij test naar de master kunnen schrijven.
All mijn en de groep's documentatie is terug te vinden op Github.
Al mijn en de groep's documentatie is terug te vinden op Github.
\begin{figure}[!h]
\centering
\includegraphics[height=1in]{git.pdf}
\includegraphics[height=0.7in]{git.pdf}
\caption{git model}
\label{fig:gitmodel}
\end{figure}
@@ -92,16 +94,17 @@ \section{Communicatie}
\subsection{Server of servers?}
Er zijn kort gezegd twee opties om de server(s) op te zetten.
Of wel \'e\'en centrale server, or meerdere losse servers die met elkaar praten.
Of wel \'e\'en centrale server, of meerdere losse servers die met elkaar praten.
Hieronder zal ik uitleggen welke ik gekozen heb en waarom.
\subsubsection{Verbonden servers}
Het veiligste idee is om meerdere servers te hebben.
Als een van meerdere servers uit zou vallen, zou het systeem nog steeds werken.
Ook is dit systeem schaalbaar, je zou namelijk makkelijk nog een server op een andere lokatie kunnen zetten.
De servers moeten de database gegevens met elkaar syncronizeren.
Ook is dit systeem schaalbaar, je kan de ballast van de ATM's verdelen over de servers.
De servers moeten de database gegevens met elkaar synchroniseren.
Elke update van een database zou via een query moeten doorgestuurd naar de andere database.
Omdat wij echter geen twee server locaties ter beschikking hebben voor het project is dit geen handig idee.
Er moet een protocol zijn om netjes op volgorde (met een queue), en programeertaalonhafhanelijk data te versturen over het netwerk.
Er moet een protocol zijn om netjes op volgorde (met een queue), en programeertaalonhafhankelijk data te versturen over het netwerk.
Wij hebben over twee protocollen les gehad van docenten, en ik zal een van deze twee kiezen in mijn advies.
\subsubsection{MQ}
Message queueing werkt met een \emph{comsumer} een een \emph{producer}.
Message queueing werkt met een \emph{consumer} een een \emph{producer}.
De producer zal eerst een queue aan berichten maken, die de zogenaamde \emph{message broker} bijhoudt.
Als de producer klaar is met zijn lijst van berichten, ofwel batch genoemd, zal de broker deze een \emph{topic} geven en naar de consumer sturen.
Als echter tien ATM's allenmaal een batch tegelijk naar de server sturen, zal de server misschien niet snel genoeg zijn om dit in een keer te verwerken.
Als echter tien ATM's allemaal een batch tegelijk naar de server sturen, zal de server misschien niet snel genoeg zijn om dit in een keer te verwerken.
Ook is het niet nodig om met een batch te werken, omdat je niet heel veel data in een keer hoeft te sturen.
Als een ATM 100 euro opvraagt, dan is dat maar een message.
De enige keer dat dit prachtish is, is bij het versturen van de pincode en de RFID code tegelijkertijd.
De enige keer dat dit practisch is, is bij het versturen van de pincode en de RFID code tegelijkertijd.
Maar dit zou ook in twee messages gedaan kunnen worden.
Daarom raadt ik dit protocol niet aan.
Daarom raad ik dit protocol niet aan.
\subsubsection{MQTT}
MQTT werkt in tegenstelling van MQ niet met batches, maar met enkele messages, en is dus erg licht.
De server kan dus sneller berichten verwerken.
Het werkt inplaats van met batches met subsriptions.
De publisher stuur berichten naar de server, en de subsribers kiezen wat ze hier mee doen.
Het werkt in plaats van met batches met subscriptions.
De publisher stuurt berichten naar de server, en de subscribers kiezen wat ze hier mee doen.
De subscriber kan uit drie opties kiezen.
Deze niveaus heten \emph{Quality of Service}.
Ik raadt dit protocol aan omdat het lichter is dan MQ, zodat de server niet overbelast raakt.
Ik raad dit protocol aan omdat het lichter is dan MQ, zodat de server niet overbelast raakt.
Voor het bank project hebben wij QoS-2 nodig, omdat je anders per ongeluk bijvoorbeeld twee keer hetzelfde bedrag kan afschrijven.
\begin{description}
@@ -182,15 +186,15 @@ \subsubsection{SSL tot TLS}
SSL en TLS zijn protocollen voor de communicatie security tussen de client en server.
Als dit protocol gebruikt wordt is het communicatieverkeer niet zo maar af te luisteren.
Er is echter grote problemen met SSL, er zijn veel aanvallen die je makkelijk of een versluiteld netwerk kunt uitvoeren, zoals de een POODLE attack.
Er is echter grote problemen met SSL, er zijn veel aanvallen die je makkelijk over een versleuteld netwerk kunt uitvoeren, zoals de een POODLE attack.
Deze attack komt er op neer dan als een aanvaller genoeg request stuurt naar de server of de client, hij de encryption kan kraken.
Dit probleem komt voor in SSL1, SSL2, en SSL3.
Ook in TLS, die opvolger van SSL, zijn in oude versies al kwetsbaarheden gevonden om de encryptie te kraken.
SSL en TLS zijn protocollen voor de communicatie security tussen de client en server.
Als dit protocol gebruikt wordt is het communicatieverkeer niet zo maar af te luisteren.
Sinds juni 2018 zijn alle SSL protocollen verboden te gebruiken voor organizaties that vallen onder het PCI DSS (Payment Card Industry Data Security Standard).
Sinds juni 2018 zijn alle SSL protocollen verboden te gebruiken voor organisaties die vallen onder het PCI DSS (Payment Card Industry Data Security Standard).
Nieuwe versies zoals TLS 1.1 en TLS 1.2 mogen nog wel hiervoor worden gebruikt.
Ik raad aan om ons banksysteem ook aan deze regelgeving te houden, en TLS 1.2 te gebruiken.
@@ -214,17 +218,17 @@ \subsubsection{Plain text}
\subsubsection{Encrypt de hele database}
Een andere veiligere optie is om de database lokaal te versleutelen.
Stel de gebruiker stuurt een pincode naar de server, dan unencrypt de server die pincode in de database, en vergelijkt de pincodes.
Een encryptie algoriste zoals AES of DES zijn voor dit project geschikt, omdat het in veel programeertalen beschikbaar is.
Stel de gebruiker stuurt een pincode naar de server, dan decrypt de server die pincode in de database, en vergelijkt de pincodes.
Een encryptie algoritme zoals AES of DES zijn voor dit project geschikt, omdat het in veel programeertalen beschikbaar is.
Dit is nodig omdat sommige groepjes misschien in andere talen hun bank willen schrijven.
Een keysize van 64 bit is genoeg, omdat het zo ongeveer 550 jaar kan duren om dit te ontsluitelen.
Een keysize van 64 bit is genoeg, omdat het zo ongeveer 550 jaar kan duren om dit te ontsleutelen.
AES werkt op het laagste niveau met 128 bits, wat te veel is.
Je offert ook snelheid op als je te veel bits gebruikt.
Je levert snelheid in als je te veel bits gebruikt.
DES kan met 64 bit werken, en deze raad ik aan om te gebruiken.
Dit is al een stuk veiliger dan een plain text wachtwoord, maar het heeft nog steeds een nadeel.
Als een hacker de key om de database te ontsluitelen te pakken krijgt, dan kan hij alle wachtwoorden achterhalen.
Ook zullen dezelfde wachtwoorden zichtbaar zijn, omdat de ge\"encripte wachtwoorden er hetzelfde uitzien.
Als een hacker de key om de database te ontsleutelen te pakken krijgt, dan kan hij alle wachtwoorden achterhalen.
Ook zullen dezelfde wachtwoorden zichtbaar zijn, omdat de ge-encrypte wachtwoorden er hetzelfde uitzien.
Mijn advies is om ook dit systeem niet te gebruiken, al is het een stuk veiliger dan plain text.
Het zou voor een schoolprojectje goed genoeg zijn, sinds zelfs grote bedrijven deze fouten nog maken, maar het is beter om de later beschreven manieren te gebruiken.
@@ -234,20 +238,21 @@ \subsubsection{Encrypt de hele database}
\subsubsection{Hashing}
Naast de hele database te versleutelen kan je ook de individuele pincodes and RFID codes hashen.
Het verschil tussen een hash en een ge\:encrypte string is dat je een hash niet terug kunt zetten naar het origineel met een key.
Het verschil tussen een hash en een ge-encrypte string is dat je een hash niet terug kunt zetten naar het origineel met een key.
Een hash kan je wel zelf terugrekenen.
Naast de hele database te versleutelen kan je ook de individuele pincodes and RFID codes hashen.
Het moet een langzame hashinging methode zijn omdat je anders als hacker snel wachtwoorden zou kunnen raden.
Goede hashing aloritmes hiervoor zouden kunnen zijn: \emph{scrypt, bcrypt of PBKDF2}.
Het moet een langzame hashing methode zijn omdat je anders als hacker snel wachtwoorden zou kunnen raden.
Een goed algoritme hiervoor zou SHA1 kunnen zijn.
Md5 is hier bijvoorbeeld niet voor geschikt omdat het erg snel is.
Sinds SHA1 in veel talen beschikbaar ik, adviseer ik deze te gebruiken.
Het moment dat de gebruiker bijvoorbeeld een pincode invoert, zal deze gehashed worden.
Zodra deze bij de database aankomt zullen de hashes worden vergeleken.
Dit is veiliger dan de hele database te encrypten, omdat de gegevens niet meer geunencrypt hoeven te worden.
Je hebt jammer genoeg nog steeds het probleem dat je versleutende data met elkaar kunt vergelijken.
Dit is veiliger dan de hele database te encrypten, omdat de gegevens niet meer decrypt hoeven te worden.
Je hebt jammer genoeg nog steeds het probleem dat je versleutelde data met elkaar kunt vergelijken.
Gebruikers met hetzelfde wachtwoord zullen ook dezelfde hash hebben.
Je hebt ook zogenaamde rainbow tables.
Dit zijn tabellen waar mensen de hashes al voor je hebben uitgerekend.
Zo kan je ook snel door de meer zware hashing aloritmes heen gaan, en zijn deze ook niet veilig.
Zo kan je ook snel door de meer zware hashing algoritmes heen gaan, en zijn deze ook niet veilig.
\hfill
@@ -261,18 +266,18 @@ \subsubsection{Hashing and Salting}
Ze zijn op te lossen door midden van \emph{Salting}.
Ik raad dan ook aan om dit systeem te gebruiken voor de beveiliging.
Dit is een voor iedere gebruiker random gegenereerde string die je opslaat in de database.
Het idee is om gevoelige gegevens, als ze worden ingevoerd aan deze string to koppelen, waarna je ze door een hashing algoritme stuurt.
Het idee is om gevoelige gegevens, als ze worden ingevoerd aan deze string te koppelen, waarna je ze door een hashing algoritme stuurt.
Het resultaat sla je op in je database.
Als de gebruiker een pincode invoert dan zal eerst de pincode ge\"incrypt moeten worden.
Als de gebruiker een pincode invoert dan zal eerst de pincode ge-encrypt moeten worden.
Dit moet in de Arduino gebeuren sinds data tussen de computer en Arduino kan worden afgeluisterd.
Hierna zal een een session based hash worden gebruikt om de data nog meer te versluitelen.
Dit wordt gedaan omdat je als hacker magnetiche straling kan opvangen van de Arduino.
Hierna zal een een session based hash worden gebruikt om de data nog meer te versleutelen.
Dit wordt gedaan omdat je als hacker magnetische straling kan opvangen van de Arduino.
Als een hacker genoeg data weet te verzamelen kan hij je encryptie kraken als je geen session based systeem hebt.
Hier wordt geen hashing gebruikt die ook op de server wordt gebruikt omdat je anders weet hoe de server wachtwoorden vergelijkt in de database.
Hierna stuurt de Arduino deze string via de computer naar de server.
Op de server zal de binnenkomende pincode gedecrypt worden.
Hierna zal de salt worden toegevoegd, en zal de string worden gehashed.
Dan wordt hash vergeleken worden met de hash in de database.
Dan wordt de hash vergeleken met de hash in de database.
Hieronder is visueel weergegeven wat mijn model is om een pincode veilig te vergelijken naar de database te krijgen. De laatste hash zal vergeleken worden met de hash in de database.
Als de server een command terug stuurt, zal simpelweg het command encrypten, en daarna hashen met de sessionhash.
@@ -287,7 +292,7 @@ \subsubsection{Hashing and Salting}