Software Design Document

Software Design Document GameTrac Versie Datum Auteur(s) Opmerking 1.0 11/11/10 Matthijssens Roeland Eerste versie 1.1 25/11/10 Matthijssens Roeland Uses cases toegevoegd 1.2 11/12/10 Matthijssens Roeland Spellings fouten, afbeeldingen 1.3 25/02/11 Van Kerkhoven Goedele, Matthijssens Roeland Visueel design toegevoegd 1.4 27/02/11 Matthijssens Roeland Klassen design toegevoegd 1.5 04/03/11 Matthijssens Roeland Bespreking privacy design 1.6 20/05/11 Brecht Van Laethem Updaten database-diagram 1

Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn inhoud. Het team Tom Strickx Brecht Van Laethem Bram Bruyninckx Roeland Matthijssens Gil Moeremans Goedele Van kerkhoven 2

Inhoudsopgave 1 Inleiding 4 1.1 Doel.......................................... 4 1.2 Conventies....................................... 4 1.3 Evolutie........................................ 4 1.4 Acroniemen...................................... 4 1.5 Termen......................................... 5 2 Taak verdeling 5 3 Architecturaal design 5 3.1 Vereisten........................................ 6 3.2 Systeem structuur................................... 6 3.2.1 Multi-tier architectuur............................. 6 3.2.2 Three-tier architectuur............................. 6 3.2.3 Blok diagram.................................. 7 4 Gebruikte technieken 8 4.1 Logic tier........................................ 8 4.1.1 Python..................................... 8 4.1.2 (fast)cgi.................................... 8 4.2 Client tier....................................... 8 4.2.1 (X)HTML................................... 9 4.2.2 CSS...................................... 9 4.2.3 AJAX...................................... 10 4.2.4 Pagina ordening................................ 10 4.3 Database tier...................................... 11 4.3.1 MySQL..................................... 11 5 Databank model 12 6 Relatie beschrijving 13 6.1 Algemeen overzicht.................................. 13 6.2 Gedetailleerde overzicht................................ 14 7 Beschrijving vereisten 17 7.1 Basis vereisten..................................... 17 7.1.1 Inloggen.................................... 17 7.1.2 Uitloggen.................................... 17 7.1.3 Registreren................................... 18 7.1.4 Aanmaken van een spel............................ 18 7.1.5 Registreren op een bestaand spel....................... 19 8 Privacy beschrijving 20 8.1 Wachtwoord encryptie................................. 20 8.1.1 MD5...................................... 20 8.1.2 Rainbow aanvallen............................... 21 8.1.3 Salts...................................... 21 8.2 Gebruikers sessies................................... 22 3

1 Inleiding 1.1 Doel Dit document bepaald het design en samenhang van de software van groep 1. Het project doelt op het modeleren van een portaal web-site voor het aanmaken van location-based spellen. Door middel van gestructureerde diagrammen en modellen wordt een duidelijk overzicht gegeven van de structuur van de software. De modellen dienen als leidraad voor voor de implementatie van de software, en kunnen beschouwd worden als conventie voorschrift om de code duidelijk en consistent te houden. 1.2 Conventies Elke verandering in dit document zal beschreven worden op de eerste pagina. Elke verandering aan dit document vereist specifieke toelating van de design manager of, in geval van afwezigheid, zijn backup. Elke verandering in dit document moet goedgekeurd worden door de design manager of, in geval van afwezigheid, zijn backup. Iedereen die betrokken is bij het project, zei het klanten of staff-leden, krijgt de mogelijkheid om zijn/haar opmerkingen kenbaar te maken. Deze opmerkingen worden door de design manager of zijn backup binnen een realistische tijdspanne behandeld. Wanneer nodig geacht door de project manager of zijn backup zullen maatregelen getroffen worden betreffende deze opmerkingen. 1.3 Evolutie Het Software Design Document (SDD) zal frequent geupdate worden naargelang er nieuwe noden of gebreken bekend raken. Het document zal voorzien worden van een overzicht van deze evolutie, en gekenmerkt worden door een identificatie nummer. Dit nummer is van de vorm x.y. In het geval dat een belangrijke of grote update gedaan wordt zal het versie nummer (het x gedeelte) verhogen. Kleine aanpassingen zullen door een verhoging in het y gedeelte kenbaar gemaakt worden. 1.4 Acroniemen CSS: Cascading Style Sheet: Een techniek om de vormgeving van een set web-pagina s in een enkele file vast te leggen. HTML: HyperText Markup Language: Een opmaaktaal voor de specificatie van documenten, voornamelijk bedoeld voor Web-sites. AJAX: Asynchronous JavaScript and XML: Een term voor het ontwerp van interactieve webpagina s waarin asynchroon gevraagde gegevens worden opgehaald van de webserver. Daardoor hoeven dergelijke pagina s niet in hun geheel ververst te worden en kunnen dmv. javascript functies stukken van de pagina worden aangepast. SQL: Structured Query Language: Een gestandaardiseerde taal die gebruikt kan worden voor taken zoals het bevragen en het aanpassen van gegevens in een relationele databank. ERM: Entity Relationship Model: Een datamodel of diagram voor het grafisch representeren van een conceptueel datamodel. 4

CGI: Common Gateway Interface: Een standaard voor dataoverdracht tussen client en de server WSGI: Web Server Gateway Interface: Een simpele universele interface voor communicatie tussen web-servers en web-applicaties in Python geschreven. MD5: Message-Digest algorithm 5: Een veelgebruikte cryptografische hashfunctie met een 128-bit hashwaarde. SHA2: Secure Hash Algorithm 2: De tweede versie van het secure hash algoritme. 1.5 Termen Apache: Software voor het hosten van web-servers. Location-based spellen: Spellen waarbij de virtuele en de echte wereld elkaar aanvullen. JavaScript: Een programmeertaal die veel gebruikt wordt om webpagina s interactief te maken en webapplicaties te ontwikkelen. Wilma: Een multifunctionele linux-server voor de studenten van de faculteit Wetenschappen van de VUB. 2 Taak verdeling De design manager is verantwoordelijk voor het onderhouden en aanpassen van het design document. Het is zijn taak om het team op de hoogte te houden van de veranderingen in het design. Wanneer problemen opduiken in het design is het de verantwoordelijkheid van de design manager om het design aan te passen. In het geval van kleine aanpassingen is het de design manager toegelaten zonder toestemmingen het design aan te passen. Bij grote aanpassingen zal de toelating van de project manager nodig zijn. In beide gevallen is het de taak van de design manager om de rest van het team op de hoogte te houden van de veranderingen. De teamleden kunnen ten alle tijden feedback geven over problemen of tekortkomingen van het design. Deze problemen zullen geanalyseerd worden door de designmanager en indien nodig zullen aanpassingen aangebracht worden in het design. In geval van grote problemen zal een aanvraag voor een vergadering ingediend worden zodat het probleem besproken kan worden met alle betrokkenen. Wanneer een probleem ontdekt wordt is het de betrokkenen toegelaten suggesties te geven om het design te verbeteren, of aan te passen. De effectieve taakverdeling is terug te vinden in het SPMP. 3 Architecturaal design De architectuur van de software is het hoogste niveau van design. Op dit niveau wordt beschreven hoe de organizatie van het gehele systeem in zijn werk gaat. Dit niveau abstraheert van de componenten van de software en de onderlinge relaties en kenmerken van componenten. In deze sectie zal een overzicht gegeven worden over de gebruikte architectuur. De beschrijving van de subsystemen, en de communicatie tussen deze subsystemen zal tevens beschreven worden. 5

3.1 Vereisten De gekozen architectuur zal moeten voldoen aan de volgende vereisten Uitbreidbaarheid: Het moet eenvoudig zijn om functionaliteit toe te voegen aan het systeem. Flexibiliteit: Het moet eenvoudig zijn om bestaande functionaliteit aan te passen, om aan nieuwe vereisten te voldoen. Eenvoud: Het systeem moet eenvoudig te begrijpen zijn voor buitenstaanders. Dit verhoogt eveneens de mogelijkheid om teamleden aan te werven, of te vervangen. Herbruikbaarheid: Voldoende abstractie moet hergebruik van het systeem, of stukken van het systeem mogelijk maken. Efficientie: De gekozen architectuur is efficient als het probleem effectief wordt opgelost, zonder nodeloze kosten, tijd, of inspanningen. 3.2 Systeem structuur Deze sectie beschrijft de structuur van het systeem. Om een goed begrip van het gebruikte systeem te garanderen zal eerst dieper ingegaan worden op het type van de architectuur die gehanteerd zal worden. Namelijk de Multi-tier architectuur en meer specifiek de Three-tier architectuur. 3.2.1 Multi-tier architectuur De multi-tier architectuur beschrijft een client-server architectuur waarin de componenten van het systeem logisch onafhankelijke proccessen zijn. Deze architectuur gaat ervan uit dat de software componenten in twee groepen gesplitst kunnen worden : de service-providers en de service-requesters. De providers kunnen allerhande systemen zijn bijvoorbeeld databank servers, ftp-servers, etc... De requesters zijn de software componenten die de gebruikers hanteren bijvoorbeeld web-browsers, email-clients, etc... De meest gebruikte versie van deze architectuur is een die slechts uit 3 zulke software componenten is opgebouwd. Ook voor dit project zal een three-tier architectuur gebruikt worden. Het feit dat deze architectuur ideaal is voor web-aplicaties, zoals dit project, heeft een sterke impact gehad op de keuze voor deze architectuur. 3.2.2 Three-tier architectuur Voor de portaal web-site werd dus gekozen voor een three-tier architectuur. Dit is een architectuur die slechts uit 3 componenten bestaat. deze componenten zijn gebruikers interface of client-tier Logic-tier of middel-tier, dit component wordt ook wel bussiness-logic genoemd. Databank of database-tier. Wanneer we dit toepassen op een web-applicatie zoals de portaal web-site krijgen we Web-browser Web-server Databank server 6

Het splitsen van het systeem in kleinere deel systemen geeft enkele belangrijke voordelen. Omdat elk van de subsystemen makkelijker is om te implementeren dan 1 groot systeem vergemakkelijkt het development process. Ook zorgt de modulariteit van het geheel ervoor dat subsystemen makkelijk kunnen aangepast worden onafhankelijk van de andere subsystemen. We zullen nu een beschrijving van de subsystemen geven. Client tier: Dit is de bovenste laag van de applicatie en is hetgeen de gebruiker van het systeem te zien krijgt. In het geval van een web-applicatie zal de client-tier bestaan uit een web-browser die op de Desktop van de gebruiker draait. De browser zal gebruikt worden om binnen de site te navigeren en om informatie over de spellen en spelers op te vragen. Bijvoorbeeld op welke spellen heb ik me ingeschreven?. JavaScript, HTML, CSS en AJAX zijn enkele technieken die gebruikt zullen worden om de gebruikersinterface te ontwerpen. Logic-tier: Deze module draait op een server en dient om alle berekeningen te maken en beslissingen te nemen op basis van de informatie beschikbaar in de databank. Deze applicatie dient dus als brug tussen de gebruikersinterface en de databank. Wanneer een gebruiker zou opvragen op welke spellen heb ik me ingeschreven? berekent de logic-tier op basis van wat in de database staat welke spellen op het scherm van de gebruiker zullen verschijnen. De logic tier is vaak opgesplits in meerdere modules en is op zijn beurt dus ook multi-tiered. Database-tier Dit subsysteem bestaat uit een of meerdere databank servers. Hier wordt de informatie bijgehouden voor latere referentie. Deze module bewaart de data op een neutrale manier, onafhankelijk van de logic-tier en de client-tier. MySQL zal gebruikt worden voor deze module. 3.2.3 Blok diagram Een blok diagram is een voorstelling van een Three-tier architectuur voorzien van een voorbeeld van hoe de architectuur gebruikt wordt voor de portaal web-site. 7

4 Gebruikte technieken 4.1 Logic tier 4.1.1 Python Python is een geinterpreteerde hoog niveau programeertaal. De filosofie van de taal benadrukt gebruiksvriendelijkheid, en leesbaarheid van de code zonder in te boeten voor kracht en expressiviteit. Python ondersteunt meerdere programmeer paradigma s maar biedt het meeste ondersteuning voor een object gerichte stijl (OO). Python werd gekozen als programmeertaal voor het project om de volgende reden: Python heeft dynamische typering. Python is een zeer expresieve taal, waardoor complexe stukken code op een elegantere, leesbaardere, vaak kortere manier kunnen neergeschreven worden dan in talen als C++ en JAVA. Python heeft een zeer goede ondersteuning voor object gericht programmeren, en het was een vereiste van het project dat een OO-stijl gehanteerd werd. 4.1.2 (fast)cgi Een eerste keuze om de Apache server met de code te laten comuniceren was door gebruik te maken van WSGI. Dit was niet mogelijk omdat de code op de Wilma server moet draaien, en er geen ondersteuning gegeven wordt voor WSGI. Als alternatief werd dan voor CGI gekozen. Maar omdat CGI scripts traag zijn, omdat voor elke request naar de server de python interpretor opnieuw moet worden opgestart, hebben we geopteerd om over te schakelen naar fast-cgi. Fast-CGI zal de python interpretor slechts een keer runnen, en de requests doorsturen naar deze interpretor, wat veel performantiewinst betekent. 4.2 Client tier Voor de gebruikers interface zal gebruik gemaakt worden van een web-browser. Om de interface te maken zal dus gebruik gemaakt worden van technieken als (X)HTML, AJAX, CSS en javascript. Het belangrijkste aan het design van de gebruikers laag van het systeem is eenvoud en bruikbaarheid. 8

4.2.1 (X)HTML HTML is de dominantie manier om web-paginas op te bouwen, en wordt door vrijwel elke webbrowser ondersteund. De structuur van HTML laat toe om op een eenvoudige manier paginas te genereren op de server. Alle nodige technieken om het project tot een goed einde te brengen worden ondersteund door HTML. Bijvoorbeeld links naar paginas, embedded fotos en interactieve forms. 4.2.2 CSS Cascading Style Sheets zullen gebruik worden om de opmaak van de site op een generische manier te bepalen. Het gebruik van CSS laat toe om de volledige opmaak aan te passen zonder de eigenlijke HTML structuur te veranderen. Daarenboven kunnen meerdere CSS-files gemaakt worden, zodat de gebruiker de layout van zijn pagina zelf kan kiezen. Hiervoor zullen een aantal standaard CSS files voorzien worden. Indien mogelijk zullen CSS files van de gebruiker toegelaten worden. Voor de voorziene CSS files is het belangrijk dat het de web-site een elegant en aantrekkelijke uitstraling geeft. Om dit te bekomen is het kiezen van een goede kleurencombinatie belangrijk. Als er niet voor een harmonieus kleurenpallet gekozen wordt zal de gebruiker niet meteen aangetrokken worden om de web-site te gebruiken. Om een aantrekkelijk kleurenpallet te kiezen kan gebruik gemaakt worden van Kuler van Adobe, op kuler.adobe.com. Figuur 1: Voorbeelden van kleuren palletten Op basis van deze kleuren schemas kunnen dan een aantal thema s opgesteld worden, die verwerkt worden in de CSS files. Bijkomend kan een achtergrond afbeelding of lettertype gebonden worden aan een thema. Zoals vermeld kunnen de gebruikers dan kiezen welk van de thema s hen het meeste aanspreekt. Bij het aanmaken van de CSS en dus het voorzien van een mapping van het kleurenpallet op de pagina-layout zal een goede keuze gemaakt moeten worden over welke kleuren waarvoor gebruikt zullen worden. Wanneer er bijvoorbeeld een palet gekozen wordt met complementaire kleuren, zal het nuttig zijn om bepaalde vlakken een opvalendere kleur te geven dan andere. Figuur 2: Voorbeeld van positie van contrasterende kleuren 9

In dit voorbeeld is het duidelijk dat de groene kaders meer aandacht naar zich trekken. Het is dus belangrijk om op voorhand te beslissen welke items moeten opvallen. 4.2.3 AJAX Asynchronous JavaScript and XML zal gebruikt worden om de pagina s interactief te maken. Het laat toe om stukken van een pagina aan te passen, en op de achtergrond requests naar de server te sturen. Dit heeft 2 grote voordelen. Ten eerste heeft de gebruiker minder vertraging in het browsen, want de pagina s kunnen deels aangepast worden, zonder een hele nieuwe pagina te moeten aanvragen. Ten tweede zal het de server een last sparen aangezien het de stukken HTML die op elke pagina getoond wordt slechts een keer moet genereren in plaats van voor elke request. De banners en het logo zijn bijvoorbeeld stukken van de HTML die niet zullen veranderen. 4.2.4 Pagina ordening De grootste prioriteit bij het ordenen van een pagina is de eenvoud van gebruik. De meest gebruikte functionaliteiten zullen daarom op vrijwel elke pagina beschrikbaar gemaakt worden. Uniformiteit en efficiëntie komen op de tweede plaats. Om de uniformiteit te garanderen zullen een aantal templates opgesteld worden. Op basis van deze templates kunnen dan paginas ontwikkeld worden, zonder de web-site als een geheel chaotisch te maken. Figuur 3: Voorbeeld van login pagina Paginas die ongeveer dezelfde karakteristieken vertonen als de login en registreer pagina zullen dit template volgen. Als leidraad voor het ontwikkelen van een visueel design kan de layout van facebook gebruikt worden. Het voordeel hiervan is dat veel mensen reeds bekend zijn met de opstelling van zulke site, en zich dus meteen vertrouwd voelen met de manier van ordening. Op basis daarvan is de keuze gemaakt dat de site in een aantal kolommen verdeeld zal worden (typisch drie kolommen waarvan de middelste het breedst zal zijn). In deze kolommen kan dan de informatie makkelijk gerangschikt 10

worden. Door de verdeling in kolommen zullen de AJAX scripts makkelijk stukken van de pagina van inhoud veranderen, zonder de statische kolommen aant te passen. Figuur 4: Voorbeeld van startpagina Figuur 5: Voorbeeld van spel pagina 4.3 Database tier 4.3.1 MySQL MySQL is een relationeel database management systeem dat als een server draait en ondersteuning geeft voor multi-user acces. MySQL is een zeer veel gebruikte database voor zowel grootschalige als kleinere applicaties. MySQL is op veel vlakken beter dan het alternatief SQLite, alleen op portability scoort SQLite beter. Maar omdat er een web-applicatie gebouwd wordt is portability geen groot probleem. Omdat een web-applicatie toelaat veel gebruikers tegelijk requests te sturen is MySQL een betere keuze. SQLite 11

heeft ook volgend nadeel: elke keer er naar de database geschreven wordt zal SQLite de database afsluiten, waardoor andere request zullen moeten wachten. MySQL heeft dit probleem niet, en is dus beter geschikt voor web-applicaties dan SQLite. Enkele redenen waarom er voor MySQL gekozen werd: Een grote community Open-Source Zeer goede performantie Zeer betrouwbaar Makkelijk te gebruiken Goede integratie van Python met MySQL 5 Databank model Een ERM wordt gebruikt om een overzicht te geven van de structuur van de gebruikte database. 12

6 Relatie beschrijving Het klassen model geeft een overzicht van hoe de verschillende modules en klassen binnen de applicatie in verband staan met elkaar. Het beschrijft tevens welke functionaliteiten de verschillende klassen moeten implementeren. Het geeft ook een beeld van de requirements (terug te vinden in het SRS) die door de klassen verwezenlijkt worden. 6.1 Algemeen overzicht Deze sectie geeft een algemeen overzicht van de samenhang tussen de verschillende componenten. 13

Figuur 6: Algemeen overzicht Het belangrijkste aan dit figuur is de inheritance-relatie tussen gebruikers en administrators, en tussen spellen en templates. 6.2 Gedetailleerde overzicht Om esthetische redenen wordt het gedetailleerde overzicht in twee figuren opgedeeld. De onderlinge relaties tussen de verschillende componenten gelden zoals weergegeven in het algemeen overzicht. De requirements die gemodeleerd worden door bepaalde operaties of attributen werden als commentaar in de figuur geplaatst. 14

Figuur 7: gedetailleerd design van een gebruiker 15

Figuur 8: gedetailleerd design van een spel 16

7 Beschrijving vereisten 7.1 Basis vereisten In deze sectie zullen de basis vereisten van de portaal web-site besproken worden. De manier waarop dit zal gebeuren is aan de hand van use-case diagrammen deze worden opgebouwd gebruik makend van use-case analyses. Het doel hiervan is een grafische voorstelling te bieden van de functionaliteit die het systeem biedt in functie van de actors, hun doelen en afhankelijkheden tussen de taken. 7.1.1 Inloggen Om in te loggen zal de gebruiker naar de login-pagina moeten surfen. Daar zal hij de mogelijkheid krijgen om zijn gegevens in te vullen. Wanneer hij zijn gegevens naar de server post, zal er geverifieerd worden of deze gegevens juist zijn en indien dit niet het geval is zal een foutboodschap getoond worden. Wanneer de server de gegevens aanvaardt, en de gebruiker dus ingelogd wordt, zal in de database een sessie voor de gebruiker aangemaakt worden. Ook zal een unieke code in een cookie geplaatst en doorgestuurd worden naar de gebruiker zodat voor de volgende requests de juiste sessie uit de database gehaald kan worden. Eventueel kan de server dan ook de nodige html als response sturen zodat de gebruiker doorverwezen wordt naar de home-pagina. 7.1.2 Uitloggen Om uit te loggen zal de gebruiker op de logout knop drukken. Hierdoor zal de server zijn sessie in de database als inactief zetten, zodat de volgende keer er een request gedaan wordt met zijn cookie, en dus ook zijn unieke code, toch opnieuw zijn gegevens gevraagd zullen worden. Ook zal de gebruiker naar de home-pagina doorverwezen worden. 17

7.1.3 Registreren Om te registreren zal de gebruiker naar de registratie pagina surfen. Daar worden de nodige gegevens gevraagd. Nadat de gebruiker zijn gegevens gepost heeft, zal de server deze gegevens verifiëren. Net als bij het inloggen zal de server foutmeldingen weergeven wanneer nodig. In het geval dat de gebruiker alle nodige informatie heeft gegeven wordt een nieuw account aangemaakt in de database. Daarna zal de gebruiker naar de login-pagina doorverwezen worden, en kan hij met zijn gegevens inloggen. 7.1.4 Aanmaken van een spel Om een spel aan te maken zal de gebruiker naar de juiste pagina moeten surfen, waar om de nodige gegevens gevraagd wordt om een spel aan te maken. Om het zoeken van spellen te vergemakkelijken zal ieder spel van een naam, en een van de speltypes voorzien moeten zijn, eventueel kan een aantal beschrijvende woorden gegeven worden. Deze informatie zal gecontroleerd worden door de server. 18

Indien alles in orde is zal op basis van de template van het spel-type een spel aangemaakt worden. Dit spel plaatst de server dan in de database. Als tweede stap bij het aanmaken van het spel kan de gebruiker locaties toevoegen aan zijn spel. Dit gebeurt door de locatie waar de QR-tag geplaatst zal worden in te geven, en de informatie die getoond moet worden wanneer de tag gescanned wordt in te geven. Indien er al locaties gespecifieerd werden binnen het spel zal de server een lijst van deze locaties beschikbaar maken zodat locaties aan elkaar gelinkt kunnen worden. 7.1.5 Registreren op een bestaand spel Om zich in te schrijven op een bestaand spel kan de gebruiker een lijst vragen van alle bestaande spellen, of zoeken naar bepaalde woorden die met de tag of naam van de resulterende spellen moet matchen. De server zal de gevraagde spellen oplijsten, waarna de gebruiker op het gewenste spel kan klikken. Dan krijgt de gebruiker de mogelijkheid om zich op het geslecteerde spel in te schrijven. De server zal deze informatie in de database opslaan. 19

8 Privacy beschrijving Om de privacy van de gebruiker te garanderen zullen enkele keuzes gemaakt worden in verband met veiligheid van de data op de server. Deze keuzes zullen in deze sectie besproken en gemotiveerd worden. 8.1 Wachtwoord encryptie Wanneer een gebruiker zich wil registreren op de site zal om een geheim en persoonlijk wachtwoord gevraagd worden. Dit wachtwoord wordt dan in de database opgeslaan. In de veronderstelling dat de database nooit ongeautoriseerde toegang zou toelaten, en de personen met legitieme toegang tot de database de informatie geheim houden, is het opslaan van de wachtwoorden als plaintext als test geen probleem. Maar aan deze veronderstelling wordt vaak niet voldaan in praktische toepassingen. Extra beveiliging is dus nodig van de wachtwoorden. De enige informatie die op de server nodig is wanneer een persoon zich probeert aan te melden is zijn gebruikersnaam en zijn wachtwoord. Maar eigenlijk is men niet geïntereseerd in het effectieve wachtwoord. Men wil slechts weten of het wachtwoord dat de gebruiker bij het inloggen ingeeft, hetzelfde is als hetgeen hij bij de registratie koos. Hoe minder informatie over een passwoord er op de server staat hoe veiliger het wachtwoord is. Omwille van deze filosofie zal dus bij de registratie niet het passwoord zelf opgeslagen worden, maar een set karakters die gegenereerd werden op basis van het opgegeven wachtwoord. Op die manier kan men vanop de server nooit weten wat het effectieve wachtwoord is. Wanneer een gebruiker zich dan wilt inloggen kunnen op dezelfde manier een set karacters gegenereerd worden op basis van het nieuwe gegeven wachtwoord, en wanneer deze twee gegenereerde strings dezelfde zijn veronderstellen we dat het gegeven wachtwoord het juiste was. Indien deze procedure gebruikt wordt, veronderstelt men drie cruciale eigenschappen van de functie waarmee de string gegenereerd wordt. Het genereren van de set karakters moet deterministisch zijn. Indien dit niet het geval is, kan de string die op basis van een juist wachtwoord gegenereerd werd een mismatch geven. De gegenereerde set karakters moet uniek zijn. Indien hier niet aan voldaan wordt, kan een fout wachtwoord als juist geinterpreteerd worden. Op basis van de gegenereerde set karakters moet het onmogelijk zijn om te achterhalen welk wachtwoord gebruikt werd om de string te genereren. Indien dit wel mogelijk is, had men net zo goed de wachtwoorden zelf kunnen opslaan. 8.1.1 MD5 Secure hash functies doen precies hetgeen nodig is om zulke strings(hashes) te genereren. Meer specifiek zal Message Digest versie 5 gebruikt worden om de wachtwoorden te hashen. Het voordeel van MD5 boven een zelfgeschreven hash functie is de zeer sterke willekeur in de geproduceerde hashes. Een zeer kleine verandering in de input string zal met grote waarschijnlijkheid een zeer groot verschil in de output hash veroorzaken. Een tweede voordeel is de vaste lengte van de geproduceerde hashes. MD5 produceert 128-bit string vaak voorgesteld door 32 hexadecimale waarden. Omdat de lengte van de hash dus constant is kunnen optimalisaties aangebracht worden in de database waar ze worden opgeslaan. Ook kan de lengte van de hash geen indicatie zijn voor de lengte van het originele wachtwoord. 20

8.1.2 Rainbow aanvallen Rainbow aanvallen maken gebruik van een op voorhand berekende tabel om het invers van een cryptografische hash functie te simuleren. Op basis van de tabel wordt geprobeerd de originele text uit een hash te halen. In dit geval is de originele text het wachtwoord. Omdat het gebruik maakt van tabellen is deze aanpak van wachtwoorden kraken veel effectiever dan een brute-force algoritme dat alle informatie moet berekenen. Deze tabellen worden op basis van een groot aantal korte of veel voorkomende wachtwoorden opgebouwd. Langere wachtwoorden in de tabellen opslaan zou veel geheugen gebruiken, en zou niet optimaal zijn. Om meer plaats te sparen worden niet alle wachtwoorden en hashes opgeslaan, maar slechts het begin en eind van een sequentie gegenereerd door herhaaldelijk de hash- en de reverse-functie op te roepen op korte of veelvoorkomende wachtwoorden. Uiteindelijk krijgen we dan een set van beginwaarden, wat strings zijn, en een set van eindwaarden, wat hashes zijn. Figuur 9: Voorbeeld van opgeslagen wachtwoord-hash combinatie Wanneer we dan een hash willen kraken zal over alle eindwaarden gelopen worden om te kijken of dit dezelfde hash is als de gevraagde. Indien dit niet het geval is voor geen enkele waarde in de set, zal op de te-kraken hash de reverse functie toegepast worden, wat resulteerd in een string, die op zijn beurt gehashed wordt. Nu kan dit process herhaald worden met de nieuwe hashe. Wanneer een van de hashes op een gegeven moment toch hetzelfde is als de gezochte hash, wordt in die sequentie het eerste element genomen. Deze string wordt dan gehashed, en indien de bekomen hash overeen komt met de gevraagde, is die string het originele wachtwoord. Indien dit niet het geval is wordt op de bekomen hash de reverse functie toegepast, en wordt dit process herhaald. Indien er nooit een matchende hash gevonden werd faalt de rainbow aanval en is het passwoord niet gekraakt. 8.1.3 Salts Een goede manier om rainbow aanvallen tegen te gaan is natuurlijk om lange wachtwoorden te kiezen. Maar gebruikers dwingen om lange wachtwoorden te kiezen wordt vaak als ongebruiksvriendelijk beschouwd, of brengt andere problemen met zich mee, zoals wachtwoorden opschrijven waar de beveiliging van het wachtwoord minder goed is dan op de server. Om dit probleem aan te pakken bestaat er een techniek die salting heet. Wanneer een wachtwoord gehashed wordt, wordt bij de bekomen 32-letter string een extra string geplakt, waarna deze string opnieuw gehasht wordt. Dit zou normaal gezien het probleem van korte of veel voorkomende wachtwoorden tegengaan, en als gevolg dus ook het gebruik van rainbow tabellen zinloos maken. Maar dan bestaat de mogelijkheid natuurlijk dat op de server gekeken kan worden welke salt gebruikt werd om de wachtwoorden te beveiligen, wat het kraken weer vereenvoudigt. Dus wordt besloten om eerst het wachtwoord te hashen, en daarna de gebruikersnaam. Deze twee 21

hashes worden dan aan elkaar gehangen, en opnieuw gehashed. Dit zorgt ervoor dat elke gebruiker zijn presoonlijke salt heeft, en rainbow aanvallen dus vrijwel onmogelijk zijn. 8.2 Gebruikers sessies Een veel voorkomend probleem bij online applicaties is dat de server niet kan weten of een bepaalde gebruiker effectief wel de persoon is die het systeem denkt dat hij is. Als eerste stap om een onderscheid te maken tussen verschillende gebruikers wordt vaak verplicht om te registreren, en daarna aanmelden om de site te gebruiken. Wanneer een gebruiker zich dan aanmeld kan op de server een sessie gegenereerd worden die deze gebruiker representeert tot hij zich uitlogt. Door middel van willekeurige unieke keys die in cookies meegegeven worden aan de client, en terug gestuurd bij elke request kan het systeem de persoon identificeren. Wanneer dit systeem toegepast wordt zijn er natuurlijk enkele problemen. Het fenomeen van session stealing komt vaak voor bij dit soort van systemen. Een gebruiker probeert zich in te loggen op een publiek, onbeveiligd netwerk, waarna andere personen het dataverkeer tussen client en server kunnen afluisteren. Wanneer dan de cookie gestuurd wordt kan ook deze data afgeluisterd worden en gebruikt worden om in te loggen op een account die niet tot hem toebehoort. Zelfs grote online bedrijven, zoals Facebook kampen met dit probleem. Een veel gebruikte oplossing is het dataverkeer over HTTPS (HyperText Transfer Protocol Secure) te regelen. Maar dit lost niet alle problemen op die met het gebruik van sessies meekomen. Zo blijven man-in-the-middle aanvallen nog steeds effectief, zelfs over HTTPS. Om dit tegen te gaan kan gebruik gemaakt worden van publieke sleutel encryptie algoritmes of trusted-third-party certificaten, etc. Maar deze oplossingen kosten ofwel extra tijd om te decoderen, of geld om een geldig certificaat te kopen. Voor dit project zal een ietwat zwakkere oplossing gehanteetd worden dan de HTTPS oplossing, omdat men niet over het budget beschikt voor een geldig certificaat. De gebruikte oplossing bestaat uit het genereren van een nieuwe sessie telkens een request gedaan wordt. Het gevolg hiervan is dat de persoon wiens sessie gestolen werd onmiddellijk afgemeld zal worden wanneer iemand anders een request stuurt met zijn sessie, aangezien die van hem niet meer geldig is. Wanneer dit gebeurt meld deze persoon zich weer aan, en de gestolen sessie is vanaf dat punt niet meer bruikbaar. Dit kan echter voor ongemak zorgen van de gebruiker maar het garandeert wel dat er niet in naam van de gebruiker ongewenste handelingen gebeuren. Dit veronderstelt natuurlijk wel dat de sessies kunnen vernietigd worden door bijvoorbeeld uit te loggen. Maar ze zullen ook automatisch verwijderd worden wanneer een sessie voor een aantal minuten niet meer gebruikt werd. 22