Ontwikkeling van een sluitende authenticatie van gebruikers van web 2.0 communitywebsites

Ontwikkeling van een sluitende authenticatie van gebruikers van web 2.0 communitywebsites Pascal Vyncke

Promotor: prof. dr. ir. Koen De Bosschere Begeleiders: dr. ir. Michiel Ronsse, dr. Jonas Maebe Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar 2008-2009

VOORWOORD

ii

Voorwoord Het internet is niet meer weg te denken uit ons leven. Enorme aantallen mensen komen samen op communitywebsites (sociale netwerksites). Omdat sommige mensen zich niet altijd aan de regels houden, worden zij dan verwijderd van de website. Mensen blokkeren is spijtig genoeg niet zo eenvoudig. Mijn interesse voor dit onderwerp komt doordat ik er zelf elke dag mee geconfronteerd wordt vanuit SeniorenNet en Bloggen.be. Aangezien ik zelf reeds lang hoop op een oplossing ter zake, was deze masterproef een uitgelezen kans om het probleem grondig te analyseren en zelf een oplossing proberen te zoeken. Zeer aangenaam was het dat mijn promotor dit zelf aangebrachte onderwerp ook heeft aanvaard. Dit werk is er niet alleen gekomen door mijn interesse in de materie, er zijn nog tal van mensen die, elk op hun manier, hun steentje bijgedragen hebben om dit werk te maken tot wat het nu is. Ik wens hierbij mijn promotor professor Koen De Bosschere te bedanken voor de talrijke keren dat hij de nodige tijd en energie vrijmaakte om mij bij dit project te begeleiden. Ook dank ik hem voor het geboden vertrouwen en de kans om een eigen onderwerp aan te brengen en uit te werken. Ik dank tevens de heren Bertel De Groote en professor emeritus Rogier De Corte voor hun juridisch advies omtrent de Wet Verwerking Persoonsgegevens.

Pascal Vyncke, juni 2009

TOELATING TOT BRUIKLEEN

iii

Toelating tot bruikleen

”De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Pascal Vyncke, juni 2009

Ontwikkeling van een sluitende authenticatie van gebruikers van web 2.0 communitywebsites door Pascal Vyncke Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar 2008–2009 Promotor: prof. dr. ir. Koen De Bosschere Scriptiebegeleiders: dr. ir. Michiel Ronsse, dr. Jonas Maebe Faculteit Ingenieurswetenschappen, Universiteit Gent Vakgroep Elektronica en informatiesystemen Voorzitter: Prof. Dr. Ir. Jan Van Campenhout

Samenvatting In dit werk wordt gezocht naar een methode voor authenticatie waardoor websites vervelende bezoekers kunnen weren. Enerzijds wordt een onderzoek gedaan om het probleem beter te begrijpen en wordt een sterkte/zwakte analyse van de huidige courante systemen uitgevoerd. Anderzijds wordt een nieuw systeem ontwikkeld dat aan de opgelegde eisen voldoet. Door het gebruik van een extra medium (mobiele telefoon) wordt een techniek voor authenticatie ontwikkeld. Door het centraliseren van de databank wordt het mogelijk om zowel de identiteit als reputatie van een gebruiker te delen.

Trefwoorden Authenticatie, web 2.0, ban, ID en reputatie, rating

Development of a secure authentication method for users of web 2.0 community websites Pascal Vyncke Supervisor(s): Koen De Bosschere Abstract—This master thesis studies the problem of the effective authentication of problematic users on community websites. We propose a solution that is based on the unique caller id of their cell phone. On top of that authentication system, we developed a community based reputation system. The whole concept has been implemented and will be made available under the name of YouValid. Keywords—Authentication, web 2.0, ban, ID and reputation, rating

I. I NTRODUCTION

W

EBSITE visitors can cause serious problems on web 2.0 community websites by making arguments, placing spam, slander and other abuse. Currently, moderators can ban such visitors from the website, but they cannot prevent that the same visitors create additional accounts and continue causing trouble. This is a serious problem for many web 2.0 community websites. There are cases of big community websites of hundreds of thousands users that had to be shut down because they were not able to control the problem. Even for websites that succeed in controlling the problem, the moderation effort and cost of fighting recidivist misbehaving visitors is huge. According to a survey among the moderators of www.seniorennet.be, it turns out that misbehaving visitors have to be removed from the system on average 18 times before they finally give up. It is clear that they can do a lot of damage in the meantime. The main problem is that there is currently no effective technical means to uniquely identify web 2.0 website visitors. Hence in practice, (i) users can re-register as often as they want, and (ii) they can create havoc on as many websites as they have access too. In this work, we propose to solve both problems at once by creating a central authentication service with community reputation management. The core idea is that users can only create an account on a web 2.0 website through a dedicated authentication service, which also keeps track of the (bad) reputation of users. Hence, a community website can now decide to refuse a new user because he or she is known to have caused too much trouble on other websites. Thanks to this community-base reputation system, moderators can focus their attention more on possible problem users, leading to faster action and a globally better website experience for all other users. The main challenge in this whole project was to find a good solution for the unique identification of visitors. II. S TATE OF THE ART IN WEBSITE VISITOR IDENTIFICATION

Over 20 technical solutions exist to help a website to identify a visitor. They can be grouped in three categories:

1. based on the visitor’s computer. This solution is easy to break: it suffices to change computers, or to change ip-addresses or mac-addresses. Most users can find ways to circumvent this authentication. 2. based on the visitor’s identity data such as a national identification number, a bank account number, a fingerprint, etc. Unfortunately, fake numerical identifications can be generated automatically, and verifying them world-wide is neither easy nor cheap. Furthermore, there can also be privacy issues with identity data. The few techniques that can be used globally suffer from accuracy problems (e.g. recognition of fingerprints, or of writing style). 3. based on a physical device like a dongle or a digipass. This is an effective means of authentication, but it is fairly expensive, and only affordable for banks or commercial websites. Since a physical device cannot be delivered to the user immediately, it will keep away occasional users. In this work, we propose to combine categories 2 and 3 by combining a mobile phone (a physical device) with a unique identification number (a caller id). III. M OBILE PHONE IDENTIFICATION A nice property of the mobile phone is that almost every internet user has one. The world currently counts 4 billion mobile phone users, three times more than there are internet users. Furthermore, the phone is a physical device, most people do not have access to a large number of mobile phones and acquiring an extra one incurs an additional cost. Finally, the mobile phone is highly standardized, so it can be used globally. Hence if we succeed in uniquely identifying a mobile phone, we can use that identification to identify its owner. It turns out that the caller id is a good way of identifying the phone. When sending SMS messages, it can be easily spoofed, but when making a regular phone call, it cannot, and even more, it is illegal to spoof it; it can only be hidden. Hence, we propose to base the whole authentication procedure on a simple mobile phone call (in theory we could also allow a fixed phone, but given the number of public telephones, this would not work that well). Making a mobile phone call is very simple, and not expensive for the user given that he or she can call a local number or a toll-free number. This solves the user part. The website part is more complex. Implementing the authentication procedure requires an investment in hardware and in software. Therefore, we decided to develop a web service which can be called from any website. This web service is called YouValid. YouValid hides the complexity of the authentication procedure from the community website developer.

The authentication system works as follows. The user registers at a web 2.0 website by creating an account. The website then sends a request to YouVald for a unique authentication code which is then passed on to the user. The user is then asked to make a phone call with his mobile phone to a given phone number (at YouValid), and to enter the authentication code. After the code has been entered correctly, YouValid contacts the website to which the authentication code was originally issued to inform it that the user registered correctly. It also returns a unique YouValid user ID to the website for future communication. Every time a user calls to the service from the same mobile phone, the website will get the same unique code back from YouValid. Hence, YouValid effectively identifies the caller id and also the user provided that he or she always calls from the mobile phone with the same caller ID, no matter how the user registered himself at the web 2.0 website, or from which country he or she is calling. IV. C OMMUNITY- BASED REPUTATION MANAGEMENT By centralizing all authentication requests at YouValid, and by allowing websites to give feedback on their users, it is possible to collect user profile information across websites. This profile information is then shared among the participating websites. They can ask for profile information about their existing or new users, and they can base their admission policy on that information. E.g., a user looking for opportunities to spread spam messages on community websites will quickly find out that over time it is getting increasingly difficult to create new accounts at websites, even at websites he never used before. The operation of YouValid is depicted in Figure 1.

The abuse categories have been defined in collaboration with experienced moderators. It is important to distinguish between several abuse categories because not all categories are relevant for all websites. Examples of abuse categories are spam, slander, pedophilia and wrangler. When a website reports a banned used to YouValid, it also has to give the abuse category and the severity on a scale of 10 within that category. For practical reasons, the 15 ratings are also summarized in one global rating as a weighted average. The weights have also been determined in collaboration with experienced moderators. The ratings are not everlasting. The ratings are decreased weekly, and eventually they become zero again. The rate of decrease depends on the abuse category. B. Privacy An important aspect of the YouValid service is the protection of the privacy of the users. Keeping track of personal data is regulated by the privacy laws in most countries. In Belgium the privacy law protects the individual very well. Because of this law, the user has at any time the right to consult the data YouValid keeps about him. Fortunately, YouValid does not keep information about persons, but about caller IDs. Nevertheless, we decided to send a text message to the mobile phone that was used to authenticate a user whenever the rating increases. C. Scalability The YouValid service is perfectly scalable. The servers can be replicated and installed all over the world, creating the potential of tens of thousands of simultaneously authentications. By using multiple datacenters, almost 100% uptime is possible. The use local phone numbers in different countries allows for a localized service per country or per region. All these phone calls can easily be rerouted to a restricted number of data center, reducing the operational cost of the service. V. C ONCLUSION This abstract describes a user authentication and community based reputation management system. It is based on the caller ID of the mobile phone of a website user. The system is cheap, easy to use, not bound to a particular geographical region, and almost instantaneous for the user. The system is completely implemented and ready to be launched under the name YouValid.com. A potential patent is under investigation.

Fig. 1. Operation of YouValid. Arrows 1 to 6 deal with the registration of a new user on the first website (left). Arrows 7 to 12 deal with the registration of the same user on a different website (right). Arrow 13 is a website that reports a ban. Arrows 14 to 18 return the new rating to other websites. Green arrows are user communication, black arrows are communication between website and YouValid, and red arrows are community feedback.

A. Rating The reputation of a user is expressed as a rating, represented by a list of 15 positive numbers, one per abuse category. Regular users start at zero, and bad behavior will increase the value of a particular category.

INHOUDSOPGAVE

vii

Inhoudsopgave Voorwoord

ii

Toelating tot bruikleen

iii

Overzicht

iv

Extended abstract

v

Inhoudsopgave

vii

Lijst van figuren

xi

Lijst van tabellen

xiii

1 Inleiding 1.1 Probleemstelling . . . . . . . . . . . 1.2 Doelstelling . . . . . . . . . . . . . . 1.3 Analyse van het probleem . . . . . . 1.3.1 Soort problemen? . . . . . . . 1.3.2 Blokkeren . . . . . . . . . . . 1.3.3 Anonimiteit . . . . . . . . . . 1.3.4 Recidivisme: 18x . . . . . . . 1.4 Criteria . . . . . . . . . . . . . . . . 1.4.1 Vanuit oogpunt website . . . . 1.4.2 Vanuit oogpunt eindgebruiker 2 State of the art 2.1 Computerafhankelijke systemen 2.2 Persoonsafhankelijke systemen . 2.3 Extra medium . . . . . . . . . . 2.4 Overzicht . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

1 1 2 3 3 4 7 8 8 9 9

. . . .

11 11 12 12 12

INHOUDSOPGAVE

viii

3 Eigen onderzoek 3.1 Wat is uniek aan een persoon? 3.2 SMS activatie . . . . . . . . . 3.2.1 Beschrijving . . . . . . 3.2.2 Onderzoek . . . . . . . 3.3 IMEI nummer . . . . . . . . . 3.3.1 Beschrijving . . . . . . 3.3.2 Onderzoek . . . . . . . 3.4 GSM-identificatie . . . . . . . 3.4.1 Beschrijving . . . . . . 3.4.2 Architectuur . . . . . .

. . . . . . . . . .

14 14 16 16 18 21 21 22 23 23 25

. . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 28 29 33 34 40 42 42 44 44 48 50 52 54 55 58 58 61 62 63 63 66 66 67 68 68 68

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

4 Gecentraliseerde gsm-identificatie met communityfeedback 4.1 Beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Voordelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Veiligheid: CallerID falsification . . . . . . . . . . . . . . . . . 4.5 Telefoonsysteem . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 SMS rating feedback . . . . . . . . . . . . . . . . . . . . . . . 4.7 Communicatie met website . . . . . . . . . . . . . . . . . . . . 4.7.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.2 Configuratiebestand . . . . . . . . . . . . . . . . . . . 4.7.3 Een code aanvragen . . . . . . . . . . . . . . . . . . . . 4.7.4 Website krijgt activatie binnen . . . . . . . . . . . . . . 4.7.5 Website bant gebruiker . . . . . . . . . . . . . . . . . . 4.7.6 Website trekt ban terug in . . . . . . . . . . . . . . . . 4.7.7 Website krijgt update binnen . . . . . . . . . . . . . . 4.8 Hashwaarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.2 Misbruik . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.3 Berekening rating . . . . . . . . . . . . . . . . . . . . . 4.9.4 Totale rating . . . . . . . . . . . . . . . . . . . . . . . 4.9.5 Aanpassing rating in de tijd . . . . . . . . . . . . . . . 4.10 Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10.1 Schaalbaarheid op serverniveau . . . . . . . . . . . . . 4.10.2 Schaalbaarheid op het niveau van telefonie . . . . . . . 4.10.3 Schaalbaarheid naar website . . . . . . . . . . . . . . . 4.11 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

INHOUDSOPGAVE

ix

4.11.2 Specifieke details . . . . . . . . . . . 4.11.3 Toekomst . . . . . . . . . . . . . . . 4.12 Systeemkosten . . . . . . . . . . . . . . . . . 4.12.1 Eenmalige kosten (geschat budget) . 4.12.2 Maandelijkse kosten (geschat budget) 4.13 Uitwerking in praktijk . . . . . . . . . . . . 4.13.1 Inleiding . . . . . . . . . . . . . . . . 4.13.2 Naam . . . . . . . . . . . . . . . . . 4.13.3 Logo . . . . . . . . . . . . . . . . . . 4.13.4 Website . . . . . . . . . . . . . . . . 4.13.5 Scripts en software . . . . . . . . . . 4.13.6 Demonstratie . . . . . . . . . . . . . 4.13.7 Datacentrum . . . . . . . . . . . . . 5 Toekomstperspectieven en besluit 5.1 Toekomst . . . . . . . . . . . . . . . . 5.2 Toekomstige mogelijkheid: OpenID . . 5.3 Extra mogelijkheden: microbetalingen 5.4 Besluit . . . . . . . . . . . . . . . . . . A Overzicht van beveiligingsmethoden A.1 Cookie . . . . . . . . . . . . . . . . A.2 IP-adres blokkeren . . . . . . . . . A.3 E-mail verificatie . . . . . . . . . . A.4 Captcha . . . . . . . . . . . . . . . A.5 Elektronische identiteitskaart . . . A.6 Registratie per post . . . . . . . . . A.7 Rijksregisternummer . . . . . . . . A.8 Rekeningnummer . . . . . . . . . . A.9 Overschrijving . . . . . . . . . . . . A.10 Verificatie creditcard . . . . . . . . A.11 Unieke karakteristieken computer . A.12 Biometrische gegevens . . . . . . . A.13 Dongle / kaartlezer . . . . . . . . . A.14 MAC-adres . . . . . . . . . . . . . A.15 Unieke machinecode . . . . . . . . A.16 SMS toesturen . . . . . . . . . . . A.17 Java(script) op website . . . . . . . A.18 Externe service . . . . . . . . . . . A.19 Centrale database e-mail adressen .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

70 73 74 74 75 76 76 76 77 77 78 80 81

. . . .

91 91 92 92 93

. . . . . . . . . . . . . . . . . . .

94 94 94 95 96 97 98 98 99 100 101 101 102 103 103 104 104 105 106 106

INHOUDSOPGAVE

x

A.20 Remote fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.21 Auteursidentificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Bibliografie

111

LIJST VAN FIGUREN

xi

Lijst van figuren 1.1 1.2

1.3 1.4 1.5

2.1

Woordwolk categorieën volgens voorkomen. . . . . . . . . . . . . . . . . . . Vraag: ’Ergert u zich soms wel eens aan mensen die op internet aanwezig zijn en zich zeer ongepast gedragen op bvb. forums, gastenboeken, chatboxen, mailgroepen,...’, uitgevoerd bij 2.355 mensen op SeniorenNet. . . . . . . . Bezoekers die de blokkering omzeilen zorgen voor problemen. . . . . . . . . Vraag: ’Durft u soms wel iets te doen of iets meer te zeggen omdat je via het internet anoniem bent?’, bij 2.318 bezoekers op SeniorenNet . . . . . . Vraag: ’Weet u hoe u een ander IP-adres zou moeten krijgen voor je computer (internetverbinding)?’, onderzoek bij 2.206 mensen op SeniorenNet, oktober 2008. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

6 6 7

8

Overzicht state of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Vraag: ’Heeft u een gsm?’ bij 2.714 mensen. . . . . . . . . . . . . . . . . . Verwachte penetratie van vaste en mobiele netwerken in 2012 (in procent) . Ontwikkeling van ICT wereldwijd van 1998-2008 . . . . . . . . . . . . . . . Screenshot SMS spoof programma om als afzender 911 te geven. . . . . . . Screenshot FakeSMS.eu waarbij valse afzender en willekeurig bericht ingegeven wordt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Drie voorbeelden van ontvangen SMS met valse afzender. . . . . . . . . . . 3.7 Verschillende velden uit het SMS protocol . . . . . . . . . . . . . . . . . . 3.8 Opbouw IMEI nummer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Het IMEI nummer van een gsm geeft merk en type terug. . . . . . . . . . . 3.10 Een willekeurig IMEI nummer van een generator opgezocht. . . . . . . . . 3.11 Schematische voorstelling architectuur gsm-identificatie. . . . . . . . . . . .

15 16 17 18

4.1 4.2

29 30

3.1 3.2 3.3 3.4 3.5

Vergelijking technieken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schematische voorstelling registratie bezoeker op een website. . . . . . . .

19 20 21 22 23 24 26

LIJST VAN FIGUREN 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17

Schematische voorstelling tweede registratie en blokkering bezoeker. . . . Sequentiediagram webservice bij registratie. . . . . . . . . . . . . . . . . Sequentiediagram webservice bij melding ban. . . . . . . . . . . . . . . . Logo Asterisk en Loquendo. . . . . . . . . . . . . . . . . . . . . . . . . . Toestandsdiagram telefoonsysteem. . . . . . . . . . . . . . . . . . . . . . Logo Gnokii open source software . . . . . . . . . . . . . . . . . . . . . . Nokia gsm gekoppeld via USB 2.0 aan computer met Linux in VMWare. Schema verzending SMS na binnengekregen ban. . . . . . . . . . . . . . . Logo YouValid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beelden van website YouValid.com . . . . . . . . . . . . . . . . . . . . . Database structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Screenshot demonstratie met weergave privacy gegevens. . . . . . . . . . Screenshot X-Lite VoIP demonstratie . . . . . . . . . . . . . . . . . . . . Foto’s datacentrum van servers met YouValid op. . . . . . . . . . . . . . Relaties webservice, websites en gebruiker. . . . . . . . . . . . . . . . . .

xii . . . . . . . . . . . . . . .

31 32 33 35 37 41 42 43 77 79 87 88 89 89 90

A.1 Enkele captcha voorbeelden. . . . . . . . . . . . . . . . . . . . . . . . . . . 96 A.2 Schema auteursidentificatie. . . . . . . . . . . . . . . . . . . . . . . . . . . 108 A.3 Nauwkeurigheid voor verschillende aantallen van auteurs en berichten. . . . 110

LIJST VAN TABELLEN

xiii

Lijst van tabellen 1.1

Categorieën misbruik gesorteerd volgens voorkomen . . . . . . . . . . . . .

4.1 4.2 4.3 4.4

Gsm-code en landcode per land . . . . . . . . . . . Gewicht voor elke categorie . . . . . . . . . . . . . Gemiddeld aantal dagen blokkering per categorie en Vermindering rating per week in aantal dagen . . .

. . . . . . . . . . . . . . . . . . . . soort overtreding . . . . . . . . . .

. . . .

. . . .

. . . .

4 83 84 85 86

INLEIDING

1

Hoofdstuk 1 Inleiding 1.1

Probleemstelling

Op communitywebsites (sociale netwerksites) kunnen de mensen met elkaar interageren. Tienduizenden of zelfs honderdduizenden mensen komen zo samen op een website. Net zoals in de echte wereld is er steeds een beperkte groep die slecht en deviant gedrag vertoont. Zij scheppen er genot in om anderen te plagen, te pesten of uit te schelden. In ernstigere vormen komen zelfs oplichting, stalking, laster en hacking voor. Het is deze beperkte groep die een groot probleem kan veroorzaken en de sfeer voor al de rest kan verpesten. Het gaat vaak om niet meer dan 0,1% van de bezoekers. De oplossing bestaat erin om bepaalde gebruikers te blokkeren en de toegang te ontzeggen, al dan niet temporeel of definitief. Om dergelijke gebruikers te ontdekken zijn al diverse systemen ontwikkeld. Eens deze (mis)gebruikers gekend zijn, is de uitdaging hen de toegang tot het systeem te ontzeggen. De huidige systemen zijn niet toereikend gebleken aangezien er geen of een minimum aan financiële input of tijd nodig is om zich terug toegang te verschaffen zodat de gebande gebruiker weer actief kan deelnemen aan het communitysysteem. Een gebruiker met slechte bedoelingen kan in praktijk zo goed als onmiddellijk terug toegang krijgen zonder veel moeite of kosten. Een gebande gebruiker kan namelijk eenvoudig een cookie wissen, IP adres wijzigen, een ander (gratis) e-mail adres aannemen, surfen via een anonieme proxyserver, browser/computergegevens faken, enz. Wereldwijd worden alle community websites met dit probleem geconfronteerd, alsook alle

1.2 Doelstelling

2

websites die gebruik maken van interactieve diensten zoals chatboxen, forums, blogs, enz. Niet meer dan eens gaan er zelfs websites of diensten aan ten onder. Voorbeelden te over. De omroep NOS Nederland sloot haar forum (waar ze 2 jaar aan hadden gewerkt) in 2007 doordat ze de gebruikers niet meer onder controle kreeg. VTM sloot in 2002 de chatboxen voor Big Brother doordat ze racistische boodschappen niet meer onder controle kreeg. Zo werd Microsoft MSN genoopt in 2003 om wereldwijd al haar chatrooms te sluiten omdat er teveel ruzies waren, pedofielen niet geweerd konden worden en ze niets konden beginnen tegen spammers [1] [2]. Ook www.SeniorenNet.be is een voorbeeld van een grote web 2.0 communitywebsite bij de wat oudere surfers. www.SeniorenNet.be is de grootste website voor de actieve 50-plussers met een bereik van meer dan 1,3 miljoen unieke bezoekers per maand. Op deze website zijn 150 vrijwilligers voltijds bezig om de website onder controle te houden en bezoekers op tijd te verwijderen van de site bij problemen. Maar zelfs zij krijgen sommige problemen amper of slechts zeer traag onder controle. Een duurzame oplossing dringt zich op, zoniet zouden de meeste community websites ten onder kunnen gaan aan hun eigen succes.

1.2

Doelstelling

Deze masterproef heeft twee doelstellingen. In eerste instantie wordt de ernst van het probleem geanalyseerd en zal er een sterkte/zwakte analyse gemaakt worden van de huidige courante systemen (cookies, IP adres blokkering, e-mail verificatie,...) teneinde een klaar beeld te bekomen waar deze systemen precies falen. In tweede instantie wordt een universele oplossing gezocht voor dit probleem. Er mag niet uit het oog verloren worden dat de implementatie van de geboden oplossing niet te moeilijk mag zijn, en dat de drempel voor de modale gebruiker niet te hoog mag worden en voldoende privacy moet behouden blijven. De toegang ’onmogelijk’ maken voor een gebande gebruiker zal waarschijnlijk niet haalbaar zijn. Teneinde de kansen op recidives maximaal te reduceren dient te worden gezocht naar een oplossing die de nodige weerstand kan bieden.

1.3 Analyse van het probleem

3

Gezien ik webmaster ben van de website SeniorenNet, heb ik de mogelijkheid om van dit instrument gebruik te maken. Enquêtes bij bezoekers of een enquête bij de medewerkers uitvoeren is hierdoor mogelijk. Door gebruik te maken van de reeds bestaande infrastructuur voor het implementeren van de oplossing wordt het financieel haalbaar.

1.3

Analyse van het probleem

Een analyse van het probleem heb ik onder andere gedaan op basis van een enquête die uitgevoerd werd bij de medewerkers van SeniorenNet. Samen hebben ze 144 manjaar ervaring met lastige en vervelende bezoekers.

1.3.1

Soort problemen?

Het gaat om diverse problemen waar een website mee geconfronteerd wordt. In totaal werden ze door de auteur in 15 categorieën ingedeeld. Een sortering van vaak (1) tot minder vaak (15) voorkomend werd gemaakt op basis van onderzoek bij diverse ervaren moderators. Elke moderator gaf bij elk van de categorieën een score betreffende de frequentie van het voorkomen van de inbreuk. Per inbreuk werd het gemiddelde genomen. Op dit gemiddelde werd vervolgens gesorteerd. Het resultaat staat in tabel 1.1. Een grafische voorstelling door middel van een woordwolk (tagclaud) geeft dit duidelijker weer in figuur 1.1. Hoe groter en prominenter een trefwoord aanwezig, hoe vaker het misbruik voorkomt. De problemen kunnen ingedeeld worden in twee soorten: Wettelijk strafbare feiten Niet strafbare feiten

De niet strafbare feiten komen het vaakst voor en zijn tegelijk het ergst voor een website. Naar een website waar steeds wordt ruziegemaakt, waarop je beledigd of gepest wordt, gaat men niet meer terug. Zo verliest een website bezoekers. Het is in de marketingwereld algemeen bekend dat het tot 10 maal duurder is om een nieuwe klant te werven dan een bestaande klant te houden. Het tegengaan van verlies van bezoekers is daarom belangrijk voor de website.


4

Tabel 1.1: Categorieën misbruik gesorteerd volgens voorkomen

Volgorde 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Categorie Ruziemakers (bewust sfeer verpesten,...), beledigingen, pesterijen Bewust negatieve reacties plaatsen om andere bezoekers af te breken Mensen die e-mail adressen van bezoekers verzamelen om ze vervolgens privé te benaderen Reclame / spam Smaad, eerroof van andere mensen Vulgair gedrag / taalgebruik Bedreigingen naar bezoekers of medewerkers Zich uitgeven voor een andere bestaande persoon Illegale plaatsing content (auteursrechtelijk beschermd, virussen,...) Zich uitgeven voor een ander geslacht, andere leeftijd, andere seksuele geaardheid, ander ras... Stalking Racisme, politieke boodschappen Mensen die fraude plegen met het systeem (advertenties omzeilen, hacking,...) Pornografie / kinderpornografie Pedofilie

Strafbare feiten als (kinder)porno, schending van auteursrechten of hacken zijn zwaardere misdrijven maar komen gelukkig minder voor. Een onderzoek bij 2.355 mensen bevestigd dat mensen zich aan dergelijke misbruiken ook daadwerkelijk ergeren. In figuur 1.2 is te zien dat driekwart van de mensen zich hieraan ergeren.

1.3.2

Blokkeren

Het grootste deel van de bezoekers heeft het goed voor met de website en zorgt niet voor ernstige problemen. Er is slechts een klein deel dat wél voor problemen zorgt. Websites wensen deze probleemgroep te blokkeren om zo de goede sfeer te behouden voor alle andere gebruikers. Enkel zo kunnen ze hun bezoekers behouden en verder blijven groeien.


5

Pesterijen

Bewust mensen afbreken

Racisme

Schending auteursrechten

Ruziemakers Kinderporno

Eerroof

S Smaad d

Porno

Fraude

Spam

Pedofilie

Verzamelen e-mail adressen

Beledigingen

Bedreigingen Illegale content

Vulgair taalgebruik

Stalking

Uitgeven voor iemand anders Uitgeven voor iemand anders

Hacken

Figuur 1.1: Woordwolk categorieën volgens voorkomen.

De slechte gebruikers moeten echter eerst ontdekt worden. Het achterhalen van dit soort gebruikers kan op diverse manieren gebeuren. Enerzijds kan dit door technologische oplossingen die gebruikerspatronen analyseren, of door het effectief laten opvolgen van de verschillende rubrieken op een website door vrijwilligers. De laatste optie wordt op SeniorenNet gebruikt. Welke techniek ook gebruikt wordt, op een bepaald moment beslist iemand dat een gebruiker de regels overtreden heeft en moet worden uitgesloten van verdere deelname. Op dat moment gaat men over tot blokkering van de persoon. Deze blokkering lost het probleem nog niet op. Uit onderzoek blijkt dat in praktijk met de bestaande technieken 31% tot 68% van de bezoekers die geblokkeerd worden, de blok-


6

Ja, zeer regelmatig

Ja, regelmatig

Ja, af en toe

Ja, komt al eens voor

Ja, al enkele keren gehad in het verleden

Neen, nog nooit

Figuur 1.2: Vraag: ’Ergert u zich soms wel eens aan mensen die op internet aanwezig zijn en zich zeer ongepast gedragen op bvb. forums, gastenboeken, chatboxen, mailgroepen,...’, uitgevoerd bij 2.355 mensen op SeniorenNet.

kering omzeilen om vervolgens terug binnen te komen en opnieuw voor overlast te zorgen1 . Grafisch is dit voorgesteld in figuur 1.3. Hierdoor blijft de sfeer onaangenaam op de website, met tevens frustraties voor moderators van de website die machteloos staan.

Figuur 1.3: Bezoekers die de blokkering omzeilen zorgen voor problemen.

Op basis van eigen onderzoek op SeniorenNet. Afhankelijk van de rubriek gaat het van 30,97% tot 67,80% 1


1.3.3

7

Anonimiteit

Op internet zijn er net als in de gewone maatschappij mensen die vervelend doen, tegen de stroming ingaan en zaken doen die niet mogen. In het echte leven komen dit soort mensen vaak in contact met politie en belanden mogelijk in de gevangenis. Op internet is het anders. Je bent er anoniem of op zijn minst naamloos. Een website heeft vanuit technisch standpunt niet meer dan het IP-adres van een gebruiker. Buiten dit IP-adres weet men nagenoeg niets anders over de gebruiker. Uit onderzoek blijkt dat de anonimiteit mensen aanzet om het minder nauw te nemen met de gangbare regels. De resultaten van een enquête bij 2.318 vijftigplussers wordt grafisch voorgesteld in figuur 1.4. Bijna 1 op 4 vijftigplussers geeft eerlijk toe dat ze wel eens iets meer durfden te doen of te zeggen op internet omdat men anoniem is, terwijl ze dit in het echte leven nooit zouden gedaan hebben. Waarschijnlijk zal dit aantal ongetwijfeld meer zijn omdat er mensen zijn die dit niet durfden toe te geven.

Figuur 1.4: Vraag: ’Durft u soms wel iets te doen of iets meer te zeggen omdat je via het internet anoniem bent?’, bij 2.318 bezoekers op SeniorenNet

De zowat enige gangbare techniek voor het buitenhouden van mensen is door hun IP-adres te blokkeren. Uit onderzoek blijkt dat dit weinig nut heeft. Op de grafische voorstelling van de resultaten in figuur 1.5 is te zien dat een kwart van de vijftigplussers weten hoe ze aan een ander IP-adres kunnen geraken.

1.4 Criteria

8

Figuur 1.5: Vraag: ’Weet u hoe u een ander IP-adres zou moeten krijgen voor je computer (internetverbinding)?’, onderzoek bij 2.206 mensen op SeniorenNet, oktober 2008.

1.3.4

Recidivisme: 18x

Dit alles vertaalt zich ook in het recidivisme. Gemiddeld blijkt dat moderators iemand 18x opnieuw moeten blokkeren alvorens de persoon het opgeeft en van de website wegblijft. Dit betekent een enorme inspanning die moet geleverd worden vanuit de website. 18 keer opnieuw dient de slechte gebruiker door een moderator ontdekt en geblokkeerd te worden. In praktijk betekent dit dat een probleem weken tot maanden blijft aanslepen voordat men eindelijk van de persoon af is. Het geduld van zowel moderator als andere bezoekers wordt hiermee op de proef gesteld. Het vinden van een systeem waarbij een gebruiker moeilijk terug binnen kan komen is daarom van groot belang.

1.4

Criteria

Om na te gaan of een systeem bruikbaar is worden een aantal belangrijke criteria gedefinieerd waaraan het systeem dient te voldoen. De criteria worden in twee groepen ingedeeld. Enerzijds vanuit het standpunt van de website (die het systeem gaat gebruiken om bezoekers buiten te houden, bijvoorbeeld SeniorenNet), anderzijds vanuit het standpunt van de eindgebruiker (de persoon die op de website komt).

1.4 Criteria

1.4.1

9

Vanuit oogpunt website

Vals negatieven. Hoe groot is de kans dat een gebruiker die bewust werd geblokkeerd toch verkeerdelijk door het systeem binnen gelaten wordt, zonder dat de gebruiker hiervoor iets speciaal gedaan heeft. In dit geval faalt het systeem. Bijvoorbeeld: website zet blokkering op IP-adres. Het IP-adres van de gebruiker wijzigt automatisch door zijn provider, waarna deze terug binnenkan; zonder bewust de blokkering te omzeilen. Drempel omzeilen. Indien de website een gebruiker bewust geblokkeerd heeft, hoe moeilijk is het dan voor een gebruiker om de blokkering te omzeilen? De moeilijkheidsgraad is een combinatie van tijd, kennis en geld die een gebruiker moet investeren om de blokkering te omzeilen. Wereldwijd. Het systeem zou ideaal wereldwijd moeten kunnen ingezet worden. Het heeft weinig nut om een systeem te ontwikkelen dat slechts in een kleine regio of één enkel land kan gebruikt worden. Ontwikkeltermijn. Hoelang duurt het voordat het systeem in praktijk kan worden gebracht? Dit is de termijn voor onderzoek en ontwikkeling die nog nodig is voordat het systeem realistisch in praktijk kan worden gebracht. Kost/gebruiker. Hoeveel kost het de website per gebruiker? Ideaal zou zijn dat er geen kost per gebruiker is (naast een eventuele eenmalige opstartkost). Startkosten. Dit zijn de kosten om het systeem in praktijk te integreren en te starten. Hoe hoger deze kosten, hoe minder websites dit financieel kunnen of willen opbrengen. Opbrengsten. Is het mogelijk aan het systeem geld te verdienen? Indien het mogelijk extra inkomsten kan genereren, zal dit een groot pluspunt zijn.

1.4.2

Vanuit oogpunt eindgebruiker

Vals positieve. Hoe groot is de kans dat een gebruiker die niets verkeerd gedaan heeft toch verkeerdelijk uitgesloten wordt? Privacy. Gebruikers zijn erg gesteld op hun privacy. Men is meestal wel bereid om een gedeeltelijke toegeving te doen, maar bepaalde gegevens zoals een foto, geboortecertificaat of thuisadres zijn er meestal teveel aan.

1.4 Criteria

10

Gebruiksvriendelijkheid. Ideaal is dat de gebruiker niets van het systeem merkt. Indien het systeem tóch zichtbaar is voor de gebruiker moet het zo eenvoudig mogelijk zijn. Kosten. Hoeveel kost het de gebruiker om op de website te komen? Bij een te grote kost zullen bezoekers vermoedelijk afhaken.

STATE OF THE ART

11

Hoofdstuk 2 State of the art Literatuuronderzoek over dit onderwerp geeft 21 systemen. Elk systeem werd apart onderzocht en beoordeeld op de voordelen en nadelen. Een uitgebreide beschrijving per systeem is te vinden in appendix A. Elk van de state of the art systemen is onder te verdelen in één van volgende drie categorieën: computer afhankelijk, persoonsafhankelijk of het gebruik van een extra medium. Elke categorie heeft vergelijkbare voordelen en nadelen, met elk specifiek systeem zijn eigen accenten hierin.

2.1

Computerafhankelijke systemen

In deze categorie worden beveiligingssystemen die gebruikmaken van technische kenmerken of geheugen van de computer onderverdeeld. Het betreft zowel eenvoudige systemen als cookies, IP-adres en MAC-adres, als de meer ingewikkelde systemen zoals unieke karakteristieken van de pc en remote fingerprinting. Positief aan beveiligingssystemen in deze categorie is dat de gebruiker zo goed als geen weet heeft van deze systemen. Alles verloopt buiten het gezichtveld van de gebruiker wat een goede gebruiksvriendelijkheid geeft. De meeste systemen zijn vaak niet afhankelijk van de regio waar de gebruiker woont waardoor ze wereldwijd ingezet kunnen worden. Negatief aan elk van de systemen is dat ze relatief eenvoudig te omzeilen zijn waardoor de veiligheid van het systeem onvoldoende wordt voor een goede authenticatie voor een website.

2.2 Persoonsafhankelijke systemen

2.2

12

Persoonsafhankelijke systemen

Een systeem dat gegevens gebruikt die afhankelijk zijn van de gebruiker zélf en zich niet baseert op de technische hardware die een gebruiker heeft worden onder deze categorie geplaatst. Enkele voorbeelden van dergelijke systemen zijn e-mail verificatie, het ingeven van het rijksregisternummer, biometrische gegevens of auteursidentificatie. Het uniek zijn van de persoonsafhankelijke kenmerken geeft een bruikbare methode voor een correcte authenticatie. Het probleem is in de meeste gevallen het controleren van deze gegevens op echtheid. Wanneer bijvoorbeeld iemand zijn rijksregisternummer ingeeft kan je moeilijk nagaan of dit toch niet van iemand anders zou zijn. Tevens is het moeilijker om persoonsafhankelijke systemen op wereldwijde schaal te introduceren doordat ze regionale verschillen vertonen. Denk hierbij aan bijvoorbeeld het rekeningnummer. Bij het in praktijk brengen van systemen in deze categorie komt meermaals naar voor dat mensen niet altijd even bereid zijn om deze gegevens te delen met een website. Je rijksregisternummer of vingerafdruk geven aan een willekeurige website roept privacyvragen op.

2.3

Extra medium

Sommige systemen maken gebruik van een extra medium zoals bijvoorbeeld een dongle, kaartlezer, de elektronische identiteitskaart of het registreren per post. Door het gebruik van een extra medium wordt het omzeilen van de beveiliging doorgaans moeilijker. De beveiliging verhoogt hierdoor, maar tegelijkertijd is het systeem zeer duidelijk aanwezig voor de gebruiker wat dan weer de gebruiksvriendelijkheid doet dalen. Het grootste nadeel van systemen in deze categorie is dat het toepassen op wereldschaal moeilijk of duur is. Regionale verschillen of de relatief hoge kost per dongle maken het financieel erg bezwarend.

2.4

Overzicht

Een analyse van elk van de onderzochte systemen werd samengevat in volgende tabel 2.1.

Opbrengsten

Vals positieve

Privacy

***

*

***** *****

*****

*****

*

*****

***** ***** *****

*

*

***** *****

*****

*****

*

*

***** ***** *****

****

*

***** *****

*****

*****

*

****

****

*

*

***** *****

*****

*****

*

*

***** **

**

**

***** ***

****

****

*

***

***

****

Kosten voor gebruiker

Startkosten

Gebruiksvriendelijkheid

Kost/gebruiker voor site

Ontwikkeltermijn

Wereldwijd

Drempel omzeilen

13

Vals negatieve

2.4 Overzicht

Computer afhankelijke systemen Cookies IP‐adres E‐mail verificatie Captcha Karakteristieken computer MAC‐adres Unieke machinecode Java(script) Remote fingerprinting

***

***** *****

***** *****

**

***** *

*****

*****

*

***

***** ***** *****

***** **

***** *

*****

*****

*

***

***

***** *****

***

**

***** ****

*****

*****

*

***

****

***** *****

**

**

***** **

**

**

*

**

***

***** *****

Persoonsafhankelijke systemen Rijksregister‐ nummer Rekening‐ nummer Biometrische gegevens Auteurs‐ identificatie Externe service E‐mail adres database

****

*

**

*****

*****

*****

*

****

*

**

*****

****

*

**

*****

*****

*****

*

****

*

**

*****

***

**

***** *

****

****

*

***

*

**

****

**

***

**

**

***

**

*

**

***** ***** *****

****

****

****

**

****

****

*

****

****

***

****

**

**

**

*****

*****

*

****

***

***** *****

***

*****

***

*

*****

*

***

****

*****

Extra medium eID

***** ***** *

Registratie per post Overschrijving Kredietkaart SMS toesturen Dongle

****

**

***** ****

*

**

*

****

*

*

*****

****

***

***** ***

*

***

*

*****

*

*

*****

***** ***

**

***

*****

*****

*

*

***

***** ***** ***** **

*

**

****

*****

***

***

***

***** ***

*

**

*

*****

**

*

*****

***** ****

***** **

EIGEN ONDERZOEK

14

Hoofdstuk 3 Eigen onderzoek De state-of-the-art studie geeft aan dat er nog onvoldoende goede techniek voorhanden is om bepaalde bezoekers blijvend te weren uit websites en die bovendien voldoet aan de belangrijkste criteria. Het doel van deze masterproef is dan ook om een oplossing te ontwikkelen.

3.1

Wat is uniek aan een persoon?

Het uniek identificeren van een persoon is het doel. De specifieke identiteit weten is minder of helemaal niet belangrijk. Indien dezelfde persoon terug wil inschrijven op een website, wil de website weten dat het om dezelfde persoon gaat. Via de bestaande internetprotocollen is dit niet mogelijk. Het IP-adres, MAC-adres, cookies,... voldoen niet. De oplossing bestaat erin om een extra criterium erbij te betrekken. Iets dat niets te maken heeft met de computer, maar wat eigen is aan de persoon zélf. Dit zijn de belangrijkste unieke kenmerken voor een persoon die mogelijk gebruikt kunnen worden voor elektronische identificatie: Identificatiekaart (eID) Kredietkaart Telefoonnummer Rijksregisternummer

3.1 Wat is uniek aan een persoon?

15

Postadres Bankrekeningnummer Biometrische gegevens Schrijfstijl GSM / telefoon

Voor een aantal van deze kenmerken werden reeds technieken ontwikkeld, maar zonder een afdoende oplossing te bieden. Vooral de mobiele telefoon trekt de aandacht. Deze gsm combineren met internet kan voor een unieke identificatie zorgen. Iedereen heeft tegenwoordig zijn eigen gsm, zeker wie beschikt over internet. Na een eigen onderzoek op de website SeniorenNet bij 2.700 mensen blijkt zoals op figuur 3.1 te zien is dat 98,10% van de 50-plussers op internet over een gsm beschikt. Bij jongeren zal dit percentage vermoedelijk nog hoger liggen.

Figuur 3.1: Vraag: ’Heeft u een gsm?’ bij 2.714 mensen.

Zo zijn er in 2007 per honderd inwoners in België 97,8 gsm-abonnees [29]. Ook wereldwijd doet de gsm het enorm goed. Er zijn begin 2009 wereldwijd 4 miljard abonnementen voor mobiele telefoons, waarvan tweederde in ontwikkelingslanden [30] [31]. Men voorspelt tegen 2013 dat er 6 miljard abonnementen zullen zijn. De verwachte groei van de wereldwijde penetratie in 2012 ten opzichte van 2008 is groot. De grafiek 3.2 uit een onderzoek van McKinsey [32] geeft dit grafisch weer.

3.2 SMS activatie

16

Figuur 3.2: Verwachte penetratie van vaste en mobiele netwerken in 2012 (in procent)

Bovendien zijn er meer mensen die de mobiele telefoon gebruiken dan internetgebruikers, zodat ervan uit kan gegaan worden dat het gebruik van de gsm in combinatie met het internet geen probleem mag vormen. Op de grafiek 3.3 uit [33] is in het donkerblauw het aantal mobiele telefoongebruikers aangeduid en de driehoekjeslijn staat voor zijn het aantal internetgebruikers.

3.2 3.2.1

SMS activatie Beschrijving

Het nieuw ontwikkelde systeem betreft een toegangssysteem waarbij de bezoeker van een website een code krijgt op die website. Deze code dient men vervolgens via SMS te versturen naar het nummer van die website. De website is in dit geval de website waarop de eindgebruiker daadwerkelijk wenst te registreren. De website ontvangt de SMS en kan op basis van de code herkennen bij welke registratie deze hoort. Het gsm-nummer is zichtbaar bij een SMS waardoor de afzender gekend is.

3.2 SMS activatie

17

Figuur 3.3: Ontwikkeling van ICT wereldwijd van 1998-2008

Door het laten toesturen van de code is er enkel een kost voor de bezoeker die zeer beperkt is. Een SMS naar een gewoon nummer kost zo’n 0,10 euro. Voor de website zijn er nauwelijks kosten aan verbonden waardoor het hebben van honderdduizenden bezoekers geen financiële drempel zou zijn. Indien de website de gebruiker blokkeert, wordt het gsm-nummer toegevoegd in een eigen blacklist. Wanneer dezelfde gebruiker zich opnieuw wil inschrijven, dient deze opnieuw een SMS te versturen. Op het moment dat de SMS binnenkomt bij de website wordt het nummer van de afzender herkend in de blacklist. De activatie van de registratie wordt zo niet toegelaten. Resultaat is dat de bezoeker niet meer binnen kan. De enige mogelijkheid om de beveiliging te omzeilen is een ander gsm-nummer te verkrijgen. Dit is minder eenvoudig. Het kost geld (10 euro of meer), men kan niet zomaar aan een grote hoeveelheid nieuwe nummers geraken en vaak dient een nieuw nummer geactiveerd te worden. Hierdoor is er een financiële drempel. Maar ook een tijdsdrempel. Het kopen en activeren van een nieuw nummer neemt tijd en energie in beslag. De kans dat iemand dit 18x opnieuw zou doen zoals nu het geval is, zal klein zijn. Het systeem is internationaal en op grote schaal bruikbaar. Het ontvangen van SMS berichten vanuit het buitenland is zonder problemen mogelijk. Lokale nummers in elk land kunnen, maar zijn niet nodig. Het versturen van een SMS naar het buitenland kost vaak niet zoveel extra. Binnen Europa is de limiet recent verlaagd naar 0,11 euro per sms [34]. Het is bovendien ook bruikbaar om mogelijk voor extra financiële inkomsten voor de website te zorgen. In plaats van een gewoon gsm-nummer te gebruiken, kan men een verkort nummer gebruiken wat extra geld opbrengt per sms.

3.2 SMS activatie

3.2.2

18

Onderzoek

Er werd onderzoek gedaan naar de haalbaarheid en veiligheid van het systeem. SMS spoofing bleek een struikelblok. De afzender van een SMS kan eenvoudig geveinsd (spoofing) worden. Zo is het mogelijk om een SMS te versturen vanaf eender welk nummer als afzender. Hierdoor valt het volledige systeem in het water gezien de authenticatie afhangt van het gsm-nummer. Een eerste mogelijkheid bestaat erin gebruik te maken van het programmatje ’SMS spoof’. Dit is gratis te downloaden voor de iPhone en Palm. Op de foto 3.4 is een screenshot te zien waarbij de afzender 911 wordt gegeven, en de ontvanger ook kan gekozen worden. Wie wil kan het programma vrij eenvoudig vinden 1 .

Figuur 3.4: Screenshot SMS spoof programma om als afzender 911 te geven.

Een grotere bedreiging vormt het commercieel uitbaten van SMS spoofing door diverse websites wereldwijd. Ook in het Nederlands is er een dergelijke website beschikbaar: FakeSMS.eu. Een screenshot is te zien in figuur 3.5. Op deze website kan op een eenvoudig manier SMS berichten worden verstuurd naar één of meerdere ontvangers, waarbij het bericht en in het bijzonder de afzender willekeurig kan gekozen worden. In Google ’SMS spoof download’ als trefwoorden ingeven geeft honderden websites. Een rechtstreekse link is http://www.waste.org/˜terje/palm/SMSspoof/SMSspoof-1.1.zip 1

3.2 SMS activatie

19

Figuur 3.5: Screenshot FakeSMS.eu waarbij valse afzender en willekeurig bericht ingegeven wordt.

Deze SMS spoofing werd naar aanleiding van het onderzoek uitgetest. Er werden 2 websites gekozen waarop een betalende account aangemaakt werd. Vervolgens werden SMS berichten verstuurd met valse afzender, die daadwerkelijk aankwamen. Op de foto’s in figuur 3.6 zijn de ontvangen berichten te zien. Merk op dat de laatste cijfers bij de eerste 123456 zijn, en bij de andere SMS het omgekeerde: 654321. Deze testnummers ’lijken’ nog realistisch met het +32485 als prefix. Er werd eveneens succesvol uitgetest dat ook volledig onbestaande nummers kunnen verzonden worden. Zo werd een SMS met afzender 123123 verstuurd en ontvangen. De verklaring ligt in het SMS protocol (PDU protocol). Op figuur 3.7 is een voorbeeld SMS te zien met elk van de velden eronder uitgelegd.

3.2 SMS activatie

20

Figuur 3.6: Drie voorbeelden van ontvangen SMS met valse afzender.

De 2 velden waar een pijl bij staat zijn 2 identificatienummers van een SMS. De rode pijl geeft de afzender aan. Deze afzender wordt ingevuld door de afzender zelf. Deze wordt niet gecontroleerd door het (gsm)-netwerk. Dit is vergelijkbaar bij het IPprotocol: de afzender kiest zelf wat hij in het veld ’afzender’ plaatst. De zwarte pijl geeft het unieke nummer aan van de provider waar de SMS vandaan komt. Het blijkt echter ook niet mogelijk te zijn om hiermee providers die SMS spoofing toelaten te blokkeren. Grote providers als Proximus of Base controleren de afzender niet van een SMS, waardoor ook SMS spoofing mogelijk blijft via applicaties zoals de iPhone of Palm. Daarom werd uiteindelijk het idee van SMS activatie verlaten en werd gezocht naar een alternatief.

3.3 IMEI nummer

21

Voorbeeld SMS:

Base, Proximus,… hebben elk hun eigen nummer. Vervalsen afzender mogelijk

Figuur 3.7: Verschillende velden uit het SMS protocol

3.3 3.3.1

IMEI nummer Beschrijving

Het IMEI nummer is een nummer dat uniek is aan elke gsm en verwerkt zit in de hardware. Overal ter wereld heeft iedere mobiele telefoon een IMEI nummer. Het nummer wordt in de gsm-standaard onder andere gebruikt voor communicatie met het netwerk (naast het IMSI, TMSI, MS-ISDN, MSRN, LAI en CI nummer). Het is het enige nummer uit voorgaande reeks dat door de gebruiker zélf op te vragen is. Door *#06# in te drukken op een gsm wordt het IMEI nummer getoond.

3.3 IMEI nummer

22

Het IMEI nummer bestaat uit 19 cijfers en is opgebouwd zoals in figuur 3.8.

Figuur 3.8: Opbouw IMEI nummer.

De website zou dit IMEI nummer kunnen vragen aan de bezoeker. Aangezien elke gsm maar één IMEI nummer heeft, kan een persoon steeds herkend worden indien deze hetzelfde IMEI nummer ingeeft. De website kan zélf nagaan of het ingegeven IMEI nummer echt is of vals.

3.3.2

Onderzoek

Gedetailleerder onderzoek brengt een aantal nadelen naar boven. Zo blijkt het IMEI nummer niet volledig uniek te zijn over de ganse wereld. Volgens CEIR (Central Equipment Identity Register) zou 10% van de in gebruik zijnde nummers niet uniek zijn [35]. Dit kan vals positieve reacties geven en zo een persoon die toevallig hetzelfde IMEI heeft, blokkeren. Gezien het een gewoon nummer is, kunnen mensen ook zelf IMEI nummers bedenken. Een controlegetal op het IMEI nummer kan het willekeurig gokken van nummers moeilijker maken. Een oplossing zou kunnen zijn om naast het IMEI nummer ook het merk en typenummer van de mobiele telefoon te vragen. Deze gegevens kunnen eveneens nagegaan worden via de website van International Numbering Plans, en kan zo als extra beveiliging dienen. De kans dat iemand een nummer zelf raadt waarbij het controlegetal correct is, en ook het merk en type juist zijn, is relatief klein. Een demonstratie is op de foto 3.9 gemaakt waarbij het IMEI nummer van een gsm is opgezocht op de International Numbering Plans website en waaruit effectief blijkt dat het merk en typenummer opgezocht kunnen worden. Toch is dit uiteindelijk geen veilige oplossing. De website van International Numbering Plans is openbaar toegankelijk. Mensen kunnen het zelf verzonnen nummer opzoeken en nagaan bij welke gsm het hoort [36].

3.4 GSM-identificatie

23

Figuur 3.9: Het IMEI nummer van een gsm geeft merk en type terug.

Het bestaan van generatorscripts maakt het kwaadwillige bezoekers nog eenvoudiger. Met deze generators kan je correcte IMEI nummers genereren, waarbij je tevens het merk en type gsm kan kiezen [37]. Op figuur 3.10 is er een demonstratie getoond. Links zie je het programma met een IMEI nummer gegenereerd voor een Siemens M35i. Indien dit fake nummer gecontroleerd wordt op de officiële website van Numbering Plans komt het nummer inderdaad overeen met een Siemens M35i. Daardoor is ook het idee van identificatie op basis van IMEI nummer niet bruikbaar in praktijk.

3.4 3.4.1

GSM-identificatie Beschrijving

De wereldwijde beschikbaarheid van gsm maakt het interessant om tóch een oplossing te vinden gebruikmakend van de mobiele telefoon. Door de auteur werd een concept voor een nieuw systeem ontwikkeld waarbij de gebruiker van de website dient te bellen naar een speciaal telefoonnummer. Vervolgens dient deze een opgegeven code in te geven via het gsm-toestel om zichzelf te kunnen activeren. Door het inbellen is het gsm-nummer van de beller gekend en kan worden geregistreerd. Indien de gebruiker achteraf wordt geblokkeerd, dan komt zijn nummer in de blacklist.


24

Figuur 3.10: Een willekeurig IMEI nummer van een generator opgezocht.

Wanneer de gebruiker opnieuw een account wenst aan te maken op de website, zal deze zich opnieuw dienen te activeren. Hetzelfde telefoonnummer zal herkend worden waarna de gebruiker kan geweerd worden. De gebruiksvriendelijkheid ligt hoger dan bij het versturen van een SMS. Bellen met een gsm kan iedereen, terwijl niet iedereen even goed overweg kan met SMS-berichten. Bij een onderzoek naar aanleiding van deze masterproef op SeniorenNet bij 2.400 mensen blijkt dat 31,6% moeite heeft (of echt niet kan) om SMS-berichten in te typen en te versturen2 . De voordelen van het eerder ge¨ıntroduceerde SMS-systeem blijven gelden. Het systeem is gratis voor de website, de bezoeker moet een klein bedrag voor het telefoontje betalen aan zijn eigen gsm-provider. Bovendien is de ingebouwde drempel dezelfde: het verkrijgen van een nieuw gsm-nummer kost moeite, tijd en geld. Het systeem heeft een tweetal nadelen: Privacy. De website kent het telefoonnummer van de gebruiker. Toch dient dit nadeel 2414 mensen op SeniorenNet, oktober 2008. Vraag: ’Kan je relatief goed teksten ingeven via het systeem van de gsm waarbij je voor elk cijfer een knop hebt en voor elke letter 1, 2 of 3 keer achter elkaar moet drukken? Het systeem om te SMS’en dus? (het gaat om het ingeven van de teksten, niet om het sms’en zelf)’ 2


25

niet zwaar door te wegen gezien de gemiddelde gebruiker vermoedelijk niet door heeft dat het telefoonnummer werd bewaard. Het telefoonnummer werd automatisch verkregen door te bellen en werd niet door de gebruiker ingegeven. Startkosten. Het ontwikkelen van de nodige infrastructuur voor dit systeem is significant. Naast het aanvragen van een telefoonlijn dient ook het nodige voorzien te worden zodat software de aanvragen kan verwerken, de ingegeven nummers kan achterhalen, enz.

3.4.2

Architectuur

Een schematische voorstelling van de architectuur in figuur 3.11 wordt stap voor stap besproken. 1. Een bezoeker surft naar de website. Hij registreert zich hierop. 2. De website vraagt een unieke code aan zijn communicatiemodule. 3. De website krijgt van de communicatiemodule een unieke code terug, bvb. 1234. 4. De website toont op de webpagina de code aan de bezoeker, samen met het telefoonnummer waar deze naartoe moet bellen. 5. De bezoeker neemt zijn gsm en belt naar het nummer. Deze geeft ook de unieke code 1234 in. 6. De communicatiemodule stuurt nu naar de website een bericht om mee te delen dat de gebruiker met unieke code 1234 geactiveerd heeft, en dat zijn telefoonnummer X is. De website kan nu al dan niet de activatie toelaten, afhankelijk van het feit dat het telefoonnummer X in de blacklist voorkomt.


26

2 3

Website

Communicatiemodule

6

4 5

1

User

Figuur 3.11: Schematische voorstelling architectuur gsm-identificatie.

GECENTRALISEERDE GSM-IDENTIFICATIE MET COMMUNITYFEEDBACK

27

Hoofdstuk 4 Gecentraliseerde gsm-identificatie met communityfeedback 4.1

Beschrijving

De nadelen van het voorgestelde gsm-identificatiesysteem worden opgelost door het invoeren van een gecentraliseerd gsm-identificatiesysteem, terwijl de voordelen behouden blijven. In het voorgestelde systeem zal één website/bedrijf alle technische infrastructuur voorzien. Websites die gebruik willen maken van de dienst hoeven zich hierop enkel maar in te schrijven en zelf geen technische infrastructuur te voorzien. Door middel van een aantal (standaard) scripts wordt de communicatie voorzien met de centrale dienst. De startkost wordt drastisch verlaagd. Voor de website zelf zijn er zeer beperkte kosten voor infrastructuur of geavanceerde scripts. Bellen naar een vast nummer vraagt een beperkte kost voor de gebruiker; het telefoontje duurt onder normale omstandigheden minder dan een minuut. De mogelijkheid bestaat dat bepaalde websites de kosten op zich wensen te nemen door gebruik te maken van een gratis 0800-nummer. Het privacyprobleem wordt tevens sterk gereduceerd. De centrale dienst zal niet het gsmnummer (CallerID genoemd) doorgeven, maar in de plaats hiervan een unieke hashwaarde. Hierdoor blijft de privacy van de gebruiker behouden ten opzichte van elke website waarop deze zich inschrijft. Enkel de betrouwbaarheid van de centrale dienst is hierdoor nog van belang en niet meer van de individuele websites.

4.2 Voordelen

28

Een extra voordeel betreft de mogelijkheid voor het integreren van zwarte lijsten. Elke bekende pedofiel zou bijvoorbeeld in een lijst opgenomen kunnen worden. Telkens wanneer deze wil registreren op de website kan een extra code meegegeven worden die waarschuwt (of bvb. enkel voor jongerenwebsites). In België is dit erg omstreden. Recent lokte de website StopKinderPorno.com zeer veel protest uit en werd door de overheid van het internet gehaald [38]. In andere landen zoals de Verenigde Staten is men echter op zoek naar een dergelijk systeem [39] [40]. Door te centraliseren komt er tevens een extra mogelijkheid bij: informatie met elkaar delen. Op deze manier kan de community onderling informatie uitwisselen. Websites kunnen aan elkaar doorgeven dat een bepaalde gebruiker ongewenst is, waardoor deze gebruikers veel beter geweerd kunnen worden op alle aangesloten websites. Hiermee wordt een combinatie gemaakt van identificatie en reputatie (ID en reputation). Dit is een element dat diverse problemen kan oplossen voor websites. Niet enkel de identificatie van een persoon, maar ook zijn reputatie (verleden). Het is vergelijkbaar met de echte wereld. De kracht van identiteitskaarten ligt niet enkel in het feit dat iedereen kan ge¨ıdentificeerd worden, maar vooral dat de politie vervolgens via een databank kan opvragen wat je verleden is, je strafblad en of je nog openstaande boetes hebt. Op het internet kunnen websites op deze manier nagaan of een gebruiker gekend is voor spam, illegale content of ruziemaken en zo al dan niet kan beslissen om de gebruiker toe te laten op de website. Een volledige voorstelling van de mogelijkheden en relaties is samengevat in het schema in figuur 4.17.

4.2

Voordelen

Om de voordelen van het voorgestelde systeem samen te vatten werden de verschillende onderzochte technieken in een tabel samengebracht. De tabel 4.1 is vergelijkbaar opgesteld met het overzicht uit de state-of-the-art studie.

Gebru uiker

We ebsite

4.3 Architectuur

29

False negative g Drempel omzeilen Wereldwijd Ontwikkeltermijn Kost/gebruiker Startkosten Opbrengsten False positive Privacyy Gebruiksvriendelijkheid Kosten

** *** ** ** *** ** nee ** ***** ***** *****

***** ** ***** **** ***** *** nee ***** ** **** ****

*** * ***** **** ***** ***** nee *** **** ** *****

***** **** ***** **** **** *** mogelijk

***** **** ***** **** ***** **** mogelijk

***** ** **** ***** 2

***** ***** 1 **** ***** 2

1: onafhankelijke controleerbare organisatie (contracten overheid,…) 2: 0800 nummer kan gebruikt worden

Figuur 4.1: Vergelijking technieken.

4.3

Architectuur

Een schematische voorstelling is te vinden op de figuur 4.2. Een bespreking van elke stap volgt. 1. Een bezoeker surft naar de website. Hij registreert zich hierop. 2. De website vraagt een unieke code aan de centrale dienst (register). 3. De website krijgt van het register een unieke code terug, bvb. 1234. 4. De website toont op de webpagina de code aan de bezoeker, samen met het telefoonnummer waar deze naartoe moet bellen.

4.3 Architectuur

30

5. De bezoeker belt met gsm naar het nummer. De bezoeker komt nu rechtstreeks terecht bij de centrale dienst. Deze gebruiker geeft de unieke code 1234 in. 6. Het register weet aan welke website het de code 1234 uitgegeven heeft, en kan zo de juiste website contacteren. Naar de website wordt toegestuurd dat de gebruiker met unieke code 1234 geactiveerd heeft, en dat de unieke code van de gebruiker hash(CallerID X) is. De website kan nu al dan niet de activatie toelaten, afhankelijk van het feit dat de hash in de blacklist voorkomt.

FFeedback db k

Register

3 6

5 2

Website

4 1

User

Figuur 4.2: Schematische voorstelling registratie bezoeker op een website.

Het proces is identiek indien dezelfde gebruiker zich op een andere website gaat registreren. Op de figuur 4.3 zijn dit de pijlen 7 tot en met 12.

4.3 Architectuur

31

15 16 17 18

Feedback F db k

Register

9 14

8

12 13

3 6

5 11 2

Website

4

10

User 1

7

Website

Figuur 4.3: Schematische voorstelling tweede registratie en blokkering bezoeker.

Community feedback komt er indien de tweede website de gebruiker nu gaat blokkeren, voor bijvoorbeeld spam. De website stuurt dan de hash van de geblokkeerde gebruiker naar de centrale dienst (feedback) in pijl 13, samen met de reden ’spam’. De centrale zoekt op welke websites dezelfde gebruiker zich geregistreerd heeft. Elk van deze websites krijgt nu een update van de reputatie van de gebruiker in de vorm van een rating (pijlen 14 t.e.m. 18). Hoe hoger dit positief getal is, hoe slechter de reputatie. Ook indien de gebruiker zich nu op een andere nieuwe website gaat registreren, krijgt de website de rating van de gebruiker door (in pijl 6 of 9) en kan ze vervolgens beslissen om de gebruiker al dan niet toe te laten, of haar moderators de opdracht te geven om de gebruiker extra in het oog te houden. Het verloop van de interne verwerking op een hoog niveau bekeken wordt getoond op het schema in figuur 4.4. Links bovenaan belt de gebruiker met zijn gsm. Deze geeft de code in, en de callerID wordt vervolgens doorgegeven aan de controle-eenheid. Die gaat de website opzoeken waar de aanvraag vandaan kwam op basis van de ingegeven code in de PendingRequests databank.

4.3 Architectuur

32

Vervolgens kan de rating van de gebruiker opgezocht worden door middel van de feedback informatie (verleden van de gebruiker). Indien er nog geen hash bekend is van de gebruiker wordt een hash gegenereerd. Deze informatie wordt vervolgens door de controle-eenheid gecombineerd en gestuurd via SOAP naar de website waar de gebruiker zich wenst te activeren.

PSTN

Bellen Bellen gsm

Webinterface

CallerID code CallerID, code

Controle

PendingRequests

Rating

FeedbackDB

Hash

Code site CallerID

CallerID Score, datum

Score, datum CallerID, site CallerID, site, hash Hash Hash, code, site, datum, score Hash, code, site, datum, score Code, hash, datum, score

Figuur 4.4: Sequentiediagram webservice bij registratie.

Een tweede belangrijk onderdeel is wanneer een website een ban doorgeeft (zie figuur 4.5). Deze feedback komt via SOAP binnen op de webinterface. De informatie wordt door de controle-eenheid verwerkt. De rating wordt verwerkt in de feedback database en een nieuwe rating wordt aangemaakt.

4.4 Veiligheid: CallerID falsification

33

Vervolgens wordt opgezocht welke websites tevens deze gebruiker geregistreerd hebben. Die informatie gaat terug naar de controle-eenheid die vervolgens elk van de websites gaat contacteren via SOAP om de nieuwe rating (score) van de gebruiker door te geven.

PSTN

Webinterface

Controle

PendingRequests

Rating

FeedbackDB

Hash

Hash, feedback, site Hash, feedback, site Hash, feedback, site

Sites, hash, nieuwe score Sites, hash, nieuwe score Site, hash, nieuwe score Hash, nieuwe score Hash, nieuwe score

Update OK Sites? Sites, hash, nieuwe score

Site, hash, nieuwe score Site, hash, nieuwe score Site hash nieuwe score

Hash, nieuwe score

Figuur 4.5: Sequentiediagram webservice bij melding ban.

4.4

Veiligheid: CallerID falsification

De veiligheid van het systeem werd uitgebreid onderzocht. Het moet zeker zijn dat mensen hun telefoonnummer (CallerID genoemd) niet kunnen vervalsen (CallerID falsification) indien men belt naar de service. Bij SMS was dit wel het geval.

4.5 Telefoonsysteem

34

CallerID’s worden op grote schaal gewijzigd op een legale manier door bedrijven. Bedrijven gebruiken dit bijvoorbeeld om hun honderden uitgaande telefoonlijnen allemaal hetzelfde nummer als CallerID te geven. Elke werknemer heeft een rechtstreeks nummer, maar een klant die terugbelt komt zo steeds bij de receptie terecht en contacteert niet de individuele werknemer. Het gaat hier telkens wel over vaste telefoonlijnen. Er zijn een aantal gevallen bekend van CallerID falsification. In 2004 is er een website Star38.com geweest die deze dienst toegankelijk maakte voor iedereen. Deze werd echter zeer snel gesloten. Er zou tijdelijk een VOIP lek geweest zijn bij een bepaald bedrijf waardoor de CallerID kon worden vervalst. Dit lek werd echter snel terug gedicht. Door middel van het versturen van speciale frequenties nadat opgenomen wordt zou de CallerID kunnen be¨ınvloed worden [41] [42].

Deze voorvallen vormen geen ernstig probleem. In diverse landen waaronder de Verenigde Staten is het nu illegaal om de CallerID te vervalsen. Mensen begaan op die manier een misdrijf indien men het toch zou doen. Bovendien vraagt het zeer veel technische kennis. De reden waarom ook gekozen wordt voor het bellen met een gsm-toestel is omdat hiermee het vervalsen van de CallerID niet mogelijk is. De CallerID wordt via een ander kanaal verstuurd dan de audio. Tot op de dag van vandaag zijn hiervoor geen technieken of gevallen gekend die de CallerID via gsm zouden kunnen vervalsen. Er mag aangenomen worden dat het vertrouwen op de CallerID als authenticatie voor de website voldoende veiligheid biedt.

4.5

Telefoonsysteem

Het systeem dat verbonden is met de telefoonlijn is het belangrijkste onderdeel omdat het de interface is naar de gebruiker. Het bellen en doorgeven van de code gebeurt via de telefoonlijn. Een telefoonlijn werd aangevraagd en gelegd in het datacentrum: 02/888.69.85. De telefoonlijn die toekomt op de server dient ’verstaan’ te worden door de server. Cijfers die de gebruiker indrukt moeten herkend worden, terwijl er ook iets moet gezegd worden

4.5 Telefoonsysteem

35

naar de beller toe. Hiervoor moet de server over capaciteiten beschikken om met de telefoonlijn overweg te kunnen. Internationaal is Loquendo TTS de meest bekende. Het is echter een professioneel en betalend programma. Een gratis open source programma dat hetzelfde werk kan verrichten is Asterisk. Een extra plug-in voor Asterisk zorgt ervoor dat we vanuit PHP kunnen communiceren naar de telefoonlijn.

Figuur 4.6: Logo Asterisk en Loquendo.

Het enige middel voor communicatie met de beller is geluid. Er zijn twee manieren om audio te genereren naar de telefoonlijn: ofwel via een tekst-naar-spraak (text-to-speech) programma, ofwel via op voorhand opgenomen audio. Er werd gekozen voor het systeem met zelf opgenomen audio. Text-to-speech komt onvoldoende natuurlijk over, waardoor het systeem als te artificieel ervaren wordt en de drempel verhoogt voor de gebruiker. Volgende normale stappen komen voor: Verwelkoming van de beller De mogelijkheid om helpinfo op te roepen Vraag naar de code Bedanken voor ingeven van de code ...

Er zijn eveneens foutsituaties die opgevangen dienen te worden: Foute code ingegeven Gebruiker sluit code niet af met # Vervallen (oude) code

4.5 Telefoonsysteem

36

Code reeds geactiveerd Gebruiker zit in zwarte lijst (van centrale service) Te vaak foutieve poging Gebruiker belt via vaste lijn Gebruiker belt met privé nummer Onbekende fout ...

Voor elke situatie werd een tekst opgesteld en ingesproken. Aangezien een vrouwenstem aangenamer overkomt werd hiervoor gekozen. De audio werd opgenomen met professionele audiosoftware Adobe Audition. 44,1 kHz, stereo, 16-bit in WAV-formaat om maximale kwaliteit bij opnames te behouden. De opnames namen ongeveer een halve dag in beslag. Achteraf werd de audio door middel van mastering optimaal gemaakt: ideaal geluidsniveau (amplitude amplify), ruis verwijdering (adaptive noise reduction en FFT (Fast Fourrier Transform) 4096 points noise reduction met profiel) , enz. Pas op het einde werd de audio omgezet naar telefoonkwaliteit [43]. Een overzicht van het volledige systeem dat de gebruiker doorloopt is te zien in figuur 4.7. Elke audio staat in een gele kader. Bij elke pijl staat aangegeven wat het event is. Bij de ontwikkeling werden een aantal beslissingen genomen. Een beschrijving van de werking en de redenen waarom hiervoor gekozen werd zal hieronder gegeven worden. Vaste telefoonlijn Bij het opnemen wordt eerst nagegaan wat het telefoonnummer is van de gebruiker. Het systeem verplicht dat er een gsm-nummer dient gebruikt te worden uit veiligheidsoverwegingen. Indien een gebruiker belt met een vaste telefoonlijn wordt dit opgevangen en hij krijgt hiervoor een audioboodschap. Om na te gaan of iemand belt vanaf een gsm-nummer of een vaste lijn wordt de CallerID geanalyseerd. Een telefoonnummer begint eerst met de landcode (voor België 0032), en dan gevolgd door het nummer van ofwel de gsm of de vaste lijn.

4.5 Telefoonsysteem

37

Figuur 4.7: Toestandsdiagram telefoonsysteem.

4.5 Telefoonsysteem

38

In België begint elk gsm-nummer met het getal 4 (denk aan 0495, 0485, 0476,...). Internationaal is dit in elk land anders. Om het systeem ook toegankelijk te maken voor mensen die vanuit het buitenland bellen, dient dit mee opgenomen te worden in het systeem. Daarom heb ik een reeks codes opgezocht van een aantal belangrijke landen. De landcode vinden van elk land is eenvoudig, het achterhalen van de gsm-codes spijtig genoeg niet. In de tabel 4.1 wordt steeds de landcode vermeld en de kolom ernaast het getal waarmee elk gsm-nummer begint. Deze gegevens werden ge¨ıntegreerd in de software zodat er momenteel 29 landen ondersteund worden. Deze lijst kan in een later stadium uiteraard verder uitgebreid worden. De tabel wordt als volgt gelezen: De landcode van Finland is 00358. Het nummer van een Finse beller zal daarom beginnen met 00358. Indien het om een gsm-nummer gaat, zal daarna het getal 4 volgen, of het getal 50, en dan een nummer. Indien aan één van deze twee voorwaarden voldaan wordt, zal het nummer een gsm-nummer van Finland zijn. Telkens wanneer iemand belt wordt zijn of haar nummer getoetst of het aan één van voorgaande criteria voldoet, zoniet wordt de audio afgespeeld voor vaste lijn. Anoniem bellen Het is mogelijk dat een gebruiker belt met een privélijn. Een eigenschap hiervan is dat de CallerID niet zichtbaar is (indien iemand anoniem belt komt op het scherm ’anoniem’, ’nummer onderdrukt’ of ’nummer onbekend’). Aangezien de authenticatie juist verloopt op basis van de CallerID mag deze gebruiker niet activeren met zijn code. Dit wordt opgevangen en de gebruiker krijgt hiervoor een vriendelijke audioboodschap. Mensen die de nummerweergave uitgeschakeld hebben op hun gsm worden geholpen om dit eenmalig te omzeilen. Er bestaat een speciale code *31# die je voor het nummer kan plaatsen. De gsm-provider herkent deze code en stuurt dan eenmalig de CallerID wel door. Dus in plaats van te bellen naar 028886985, bel je naar *31#028886985. Code Er werd gekozen om de lengte van de code die een gebruiker dient in te geven variabel te maken. Dit is een afweging tussen gebruiksvriendelijkheid en schaalbaarheid. Door de lengte variabel te maken is het eenvoudig om 10x meer codes in omloop te kunnen hebben door gewoon de cijferlengte met één te laten toenemen. Om te weten wanneer de gebruiker de hele code ingaf, wordt gevraagd het cijfer af te sluiten met het teken #. Zo start de verwerking van de code niet alvorens de gebruiker de volledige code ingaf. Het

4.5 Telefoonsysteem

39

kan immers zijn dat de ene gebruiker een code van 3 cijfers dient in te geven, terwijl een andere misschien wel 6 of 7 cijfers dient in te geven. Er wordt voorzien dat een gebruiker vergeet om het #-teken in te drukken. Indien na 10 seconden geen #-teken werd ingedrukt, wordt er een speciale audio afgespeeld om te vragen om alsnog het #-teken in te drukken. Indien de gebruiker dit opnieuw niet doet, zal terug vanaf het begin gestart worden en de volledige audio afgespeeld worden om te vragen de code in te geven. De gebruiker was misschien gestopt omdat deze bvb. een fout had ingedrukt. Codes zijn slechts beperkt bruikbaar. Na een bepaalde periode zijn de codes niet meer te gebruiken om te activeren. De houdbaarheid van een code wordt gekozen door de website waarop de gebruiker zich wil registreren. Zij kunnen in aantal uur kiezen hoelang de code beschikbaar blijft, met een maximum van 7 dagen. De beperking zorgt ervoor dat het aantal codes niet uitgeput geraakt. Zelfs als het systeem extreem populair wordt, kunnen op deze manier codes na een bepaalde tijd hergebruikt worden, waardoor codelengtes korter gehouden kunnen worden en de gebruiksvriendelijkheid maximaal blijft. Nadat een code vervallen is, wordt deze nog niet onmiddellijk opnieuw in circulatie genomen en blijft ze nog een tijd in quarantaine. Momenteel blijft een code nog 1 maand geblokkeerd, al kan deze termijn eenvoudig gewijzigd worden. Dit biedt de mogelijkheid om gebruikers die toch te laat hun code willen activeren een aangepaste boodschap te laten horen. De audioboodschap legt hen dan duidelijk uit dat de code vervallen is en dat ze een nieuwe moeten aanvragen. Na de quarantaineperiode wordt de code terug vrijgegeven en kan ze opnieuw gebruikt worden. Blokkering Er is voorzien dat een gebruiker door de website zelf kan geblokkeerd worden. Dit kan om meerdere redenen voorkomen. Indien de gebruiker op basis van de privacywet stopzetting van de verwerking van zijn gegevens heeft gevraagd zal hij niet meer kunnen activeren. Zo voorkomen we dat iemand met een slechte rating toch terug binnen zou kunnen. Maar ook andere redenen van blokkering kunnen voorkomen. Bijvoorbeeld iemand die het systeem wil aanvallen door (geautomatiseerd) duizenden telefoons te doen naar het systeem.

4.6 SMS rating feedback

40

3 pogingen Indien een gebruiker een foutieve code ingeeft, krijgt hij/zij hiervoor een audio afgespeeld. Het kan bijvoorbeeld voorkomen dat iemand een foutje heeft ingedrukt. Men kan dan opnieuw proberen om de juiste code in te geven. Er is een limiet van 3 pogingen om een code in te geven voor de veiligheid van het systeem. Zo wordt voorkomen dat men duizenden codes zou uitproberen om zo andere codes te kunnen raden. Na 3 pogingen wordt een andere audio afgespeeld en wordt vervolgens de lijn verbroken. Onbekende fout Het systeem is erop voorzien dat indien er een onbekende fout optreedt, er een standaard audio zal afgespeeld worden om de gebruiker hiervan te verwittigen. Op deze manier wordt zo gebruiksvriendelijk mogelijk een onbekend probleem naar de gebruiker toe gecommuniceerd. Aangezien er bij het bellen heel wat moet gebeuren (nummer nazien, hash genereren, code opzoeken in databank, sites contacteren,...) kan het gebeuren dat er ergens iets faalt of bvb. de database uitligt. In plaats van plots niets meer te horen, wordt dit opgevangen via een audioboodschap. Gepersonaliseerde activatie Doordat we weten voor welke website de gebruiker zich wilde registreren dankzij de code is het mogelijk om een andere boodschap af te spelen afhankelijk van de website. Zo kan de bevestiging voor SeniorenNet anders zijn dan bijvoorbeeld voor Bloggen.be. Verschillende audio-opnames werden hiervoor al gemaakt, met inbegrip van een algemene boodschap die geen verwijzing geeft naar een welbepaalde website. In een later stadium zou het kunnen dat websites die betalen voor de dienst een gepersonaliseerde boodschap kunnen geven naar de gebruiker, terwijl kleine websites die gratis gebruik maken van het systeem bij activatie enkel maar een algemene audio laten afspelen. Bij de ontwikkeling van de software en database werd reeds rekening gehouden met deze voorziening.

4.6

SMS rating feedback

Omwille van privacy redenen (elders uitgebreid uitgelegd) dient de gebruiker verwittigd te worden wanneer zijn rating omhoog gaat. Dit dient via SMS te gaan. Een SMS geautomatiseerd versturen via een website is minder eenvoudig. Enerzijds kan

4.6 SMS rating feedback

41

hiervoor een contract worden aangegaan met een extern bedrijf. Prijzen van een SMSbericht liggen hierdoor ongeveer dubbel zo hoog als een normaal SMS bericht 1 . Anderzijds kan ervoor gekozen worden om zelf een systeem te ontwikkelen voor de verzending van SMS berichten. Voor deze oplossing werd gekozen. Er werd gebruik gemaakt van de speciale open source software Gnokii (figuur 4.8) die het mogelijk maakt om te communiceren met de gsm via Linux. Een opstelling werd gemaakt met een nieuwe Nokia gsm en SIM-kaart.

Figuur 4.8: Logo Gnokii open source software

In datacentra zijn gsm-toestellen niet toegelaten. Daarom is het niet mogelijk om de gsm rechtstreeks te koppelen met de centrale service in het datacentrum. Als oplossing werd de gsm bij de auteur thuis gekoppeld aan een Windows Vista pc en door middel van VMWare een virtuele Linux machine geplaatst waarop Gnokii werkt. Een foto van de opstelling waarbij de Nokia gsm aangesloten is op de pc door middel van USB is te zien op 4.9. Omwille van firewall en veiligheidsredenen is het niet mogelijk om vanaf de webserver in het datacentrum rechtstreeks contact te maken met de pc thuis om een sms te laten versturen. Daarom werd het omgekeerd. De Linuxmachine thuis maakt via een crontabopdracht elke minuut contact met de webserver en vraagt de lijst op van te verzenden SMS-berichten. Gezien dit om een gewone http vraag gaat, is dit wel perfect veilig. De thuiscomputer krijgt via de http vraag de lijst van de berichten en nummers waarnaar SMS berichten verstuurd dienen te worden. Een ontwikkeld script verwerkt deze gegevens en gaat vervolgens door middel van Gnokii commando’s SMS-berichten versturen met de gsm. Een van de goedkoopste is SMSbox, die echter 0,19 cent/sms vraagt; en een reeks extra eisen stelt ivm verbruik per maand,... 1

4.7 Communicatie met website

42

Figuur 4.9: Nokia gsm gekoppeld via USB 2.0 aan computer met Linux in VMWare.

Het voordeel hiervan is dat het systeem goedkoper SMS-berichten kan versturen. In de gsm steekt momenteel een gewone SIM-kaart. Momenteel is het een gewone Proximus Pay&Go kaart, maar dit kan bijvoorbeeld gewijzigd worden naar een abonnement met bvb. 5.000 SMS’en per maand of zelfs onbeperkt aantal SMS’en om de kosten verder te drukken. Er werd voorzien dat telkens wanneer een ban gerapporteerd wordt, er ook een SMS verstuurd wordt naar het gsm-nummer van de gebruiker. Het schema in figuur 4.10 geeft nog een volledige verduidelijking.

4.7 4.7.1

Communicatie met website Inleiding

De nodige communicatie gaat over en weer tussen het centrale systeem en de website op een client-server gebaseerde wijze: Een activatiecode aanvragen Activatie door gebruiker meedelen Ban meedelen van gebruiker


43

Figuur 4.10: Schema verzending SMS na binnengekregen ban.

Update score meedelen van gebruiker Ban terug intrekken

Voor communicatie is gekozen voor SOAP (Simple Object Access Protocol). SOAP is een protocol dat XML-berichten verstuurt over http. De website kan communiceren met de service door middel van standaard gemaakte scripts die de website kan integreren in haar bestaande webpagina’s. In totaal gaat het om 5 PHP-scripts met telkens één functie die men krijgt, één configuratiefile en een reeks libraryfiles waar de websitebeheerder niets mee moet doen. Deze laatste voeren het échte werk uit (maar door inkapseling (encapsulation) en informatie verberging (information hiding) hoeft de gebruiker hier niets van te zien). Om de integratie voor de website zo eenvoudig mogelijk te maken is er voorzien dat bij elke aanvraag de website zelf een referentie kan meekiezen. Dit is een string van maximaal 255 tekens die men kan meesturen. Het voordeel hiervan is dat men de eigen interne ID of interne referentie van haar tabel mee in het veld geeft. Bij een respons geeft het systeem


44

deze string ook mee terug, zodat de website snel en eenvoudig kan opzoeken waar wàt bij hoort. Dit maakt het mogelijk dat de website gewoon verder kan blijven werken met de eigen interne referenties of ID’s zonder teveel te moeten aanpassen in de eigen databank. Men is op deze manier niet verplicht om gebruik te maken van de ID’s die door het systeem zelf worden gegenereerd. Men heeft dus de keuze: ofwel de ID’s gebruiken die door het systeem geleverd worden (en dus moet men een aantal aanpassingen doen om hiermee te kunnen werken en bewaren), ofwel de interne ID’s meesturen via een variabele (mix van beide kan uiteraard ook). Naast een referentie kan ook een sectie worden meegegeven. Dit is ook steeds een stringvariabele van maximaal 255 karakters die men zelf mag kiezen. Deze kan gebruikt worden om mee te geven over welk onderdeel van de website de aanvraag ging. Indien een website bvb. meerdere onderdelen heeft (forum, chat,...) en een gebruiker moet voor elk van de onderdelen apart activeren, kan men via deze manier meegeven voor welk onderdeel de aanvraag was. Zo wordt het mogelijk gemaakt dat dezelfde website toelaat dat dezelfde gebruiker op verschillende onderdelen van de website apart kan activeren, en toch eenvoudig kan terugvinden welke activatiecode voor wélk onderdeel bedoeld was. Zo wordt extra flexibiliteit geboden naar de website toe. Het is uiteraard geen verplichte variabele, maar steeds optioneel.

4.7.2

Configuratiebestand

Het configuratiebestand met naam config vars.inc.php kan de gebruiker eenvoudig aanpassen. In principe kan dit bestand automatisch gegenereerd worden voor de website en hoeft deze hier ook niets voor aan te passen. In het bestand staat de websiteID en de url’s van de webservice.

4.7.3

Een code aanvragen

In het voorbeeldbestand website vraagt code.php staat de functie die de website oproept om een code aan te vragen aan de webservice. Het bestand bestaat vooral uit een reeks variabelen die uitgelegd worden en die bijna allemaal optioneel zijn voor maximale gebruiksvriendelijkheid. De website (client) vraagt aan de webservice (server) de code. Voor maximale flexibiliteit zijn er dus wel een reeks variabelen die een website kan opgeven:


45

De taal van de gebruiker ($language). Zo wordt een telefoonnummer gekozen zodat de gebruiker in zijn eigen taal verwelkomd zal worden. Indien deze variabele niet doorgegeven wordt, zal de standaardwaarde gekozen worden van de taal van de website. Zo is bvb. een Nederlandstalige website die zich registreert waarschijnlijk in 99,9% van de gevallen tevreden met een Nederlandstalig telefoonnummer. De geldigheid van de code ($validity). De website kan kiezen hoeveel minuten de code geldig blijft om te activeren, gaande van minimum 1 minuut tot maximaal 7 dagen. Indien men niets doorgeeft wordt 24 uur (1.440 minuten) als standaard genomen. Type telefoonnummer ($phonenumberType). Men kan kiezen uit een gewoon lokaal nummer, gratis nummer, 0900-nummer,... Het land ($phonenumberCountry). Afhankelijk van het land wordt een lokaal nummer genomen indien dit mogelijk is. Eigen referentie ($myReference) De referentie die men zelf mag kiezen en eenvoudiger maakt voor integratie van het systeem in de eigen website; optioneel en zelf te kiezen. Eigen sectie ($mySection) Dit kan men meegeven indien men wil weten voor welk onderdeel van de site de gebruiker de code aanvraagt; optioneel en zelf te kiezen. Uitgebreide output ($VERBOSE OUTPUT) Normaal gezien is er geen output, maar door deze variabele op true te zetten krijgt men uitgebreide debugoutput. Een website beschikt dus over een zeer grote flexibiliteit voor het aanvragen van een code. Het kan het type telefoonnummer kiezen, het land en de taal. Op deze manier kan gekozen worden voor het meest ideale telefoonnummer dat voldoet aan de wensen van de website.

Een website kan zeer eenvoudig een code aanvragen door een gewone oproep: $responsedata = CodeRequest($websiteID, $language, $validity, $phonenumberType, $phonenumberCountry, $myReference, mySection, $url code request, $VERBOSE OUTPUT); Vervolgens kan men uit de variabele $responsedata alle informatie halen. Men krijgt volgende informatie terug: De code die de gebruiker dient in te geven


46

Datum/tijd wanneer de code werd uitgegeven Datum/tijd tot wanneer de code geldig is Een unieke activatieID; deze is uniek voor elke activatie en zal worden teruggegeven indien de gebruiker ook activeert. Dit is de reguliere manier om een activatie van een gebruiker te koppelen met de originele aanvraag van de code. De taal van het telefoonnummer Het telefoonnummer waar de gebruiker naartoe dient te bellen De eigen referentie die de site meestuurde (string door haar gekozen). Dit is de optionele manier om een activatie van een gebruiker te koppelen met de originele aanvraag van de code De sectie die de site zelf meestuurde (string door haar gekozen).

Opvragen gaat op eenvoudige wijze, bvb. $responsedata[’code’] voor de code of $responsedata[’phonenumber’] voor het telefoonnummer. In het voorbeeld PHP script dat men krijgt, staat in commentaar een voorbeeld hoe men elke variabele kan gebruiken, samen met een voorbeeld voor het afhandelen van fouten. Alle communicatie die via SOAP wordt gedaan, is verborgen voor de gebruiker. Dit zijn de berichten die in werkelijkheid worden verstuurd via http. De vraag voor een code (gestuurd door het script vanaf de site die code aanvraagt): POST /webservice/code request.php HTTP/1.0 Host: www.youvalid.com User-Agent: NuSOAP/0.7.3 (1.114) Content-Type: text/xml; charset=ISO-8859-1 SOAPAction: ” Content-Length: 961 <SOAP-ENV:Envelope SOAP-ENV:encodingStyle= ’http://schemas.xmlsoap.org/soap/encoding/’ xmlns:SOAP-ENV=’http://schemas.xmlsoap.org/soap/envelope/’ xmlns:xsd=’http://www.w3.org/2001/XMLSchema’


47

xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance’ xmlns:SOAP-ENC=’http://schemas.xmlsoap.org/soap/encoding/’> <SOAP-ENV:Body> <ns5943:getCode xmlns:ns5943=’http://tempuri.org’> <websiteID xsi:type=’xsd:string’>1234567 DU 1000 0 BE <myReference xsi:type=’xsd:string’> bla bla bla 32b7 <mySection xsi:type=’xsd:string’>mySection

Het antwoord van de webserver is opnieuw een SOAP bericht in XML-formaat over http: HTTP/1.0 200 OK Date: Wed, 06 May 2009 21:49:27 GMT Connection: close X-SOAP-Server: NuSOAP/0.7.3 (1.114) Content-Type: text/xml; charset=ISO-8859-1 Content-Length: 970 <SOAP-ENV:Envelope xmlns:SOAP-ENV=’http://schemas.xmlsoap.org/soap/envelope/’ xmlns:xsd=’http://www.w3.org/2001/XMLSchema’ xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance’ xmlns:SOAP-ENC=’http://schemas.xmlsoap.org/soap/encoding/’ xmlns:tns=’urn:Coderequest’> <SOAP-ENV:Body> <ns1:getCodeResponse xmlns:ns1=’http://tempuri.org’> 69956


48

2009-05-06 23:49:27 2009-05-07 16:29:27 387981382265 DU 028886985 bla bla bla 32b7 mySection

In het XML formaat zijn de variabelen te herkennen samen met de doorgestuurde waarden ervan. De website hoeft geen kennis te hebben van deze XML berichten, gezien het analyseren van deze XML-bestanden en omzetten in bruikbare variabelen in de PHP programmacode voor de gebruiker reeds wordt gedaan in de aangeleverde scripts.

4.7.4

Website krijgt activatie binnen

Op het moment dat een gebruiker belt naar het systeem en zijn code correct heeft ingegeven, zal de betreffende website worden verwittigd. Hiervoor gaat er een SOAP oproep naar een pagina die staat op de server van de website. Deze url is gekend bij de service en wordt telkens opgeroepen wanneer iemand op die website activeert. Het telefoonsysteem gaat een oproep doen naar de url en stuurt hierbij volgende variabelen terug: De gebruikte activatiecode door de gebruiker De activatieID die exact overeenkomt met de ID gegeven bij aanvraag van de code zodat de aanvraag en activatie aan elkaar kunnen gekoppeld worden. De datum/tijd dat de gebruiker de activatie deed. De gebruikersID die activeerde. Dit is een unieke hashwaarde van het telefoonnummer. De totale score (rating) van de gebruiker.


49

Datum sinds wanneer de gebruiker voor het eerst gekend is bij de webservice (van eender welke website) Het totaal aantal websites waar de gebruiker op geregistreerd is. Het totaal aantal websites dat doorgegeven heeft de gebruiker geband te hebben. Een variabele die extra informatie geeft over de gebruiker. Dit zou het mogelijk maken om in de toekomst extra info door te geven dat het bvb. een admin gebruiker is,... De taal van de gebruiker Het land waar het gsm-nummer vandaan komt waarmee de gebruiker activeerde. Het gsm-nummer zelf blijft geheim, maar zo heeft de website wel een idee uit welk land het telefoonnummer kwam. De referentie doorgegeven door de website zelf bij het aanvragen van de code; dit is de extra manier om eenvoudig de aangevraagde code te linken met de activatie. De doorgegeven sectie van de website waar de gebruiker zich op wilde registreren. De gedetailleerde rating per misbruikcategorie van de gebruiker.

Elke variabele is ook hier toegankelijk gemaakt, bvb. de variabele $input[’user total sites registred’] geeft in de PHP code voor de website onmiddellijk het aantal websites waar de gebruiker geregistreerd is. Er is voorzien dat de website down is op het moment dat de gebruiker zich via telefoon heeft geactiveerd. In dat geval gaat de webservice de informatie bewaren in een aparte tabel die als wachtlijn gaat fungeren met een servicediscipline FCFS (First Come First Served). Een speciaal crontab programma wordt elke minuut opgeroepen en zal de gefaalde activaties alsnog proberen te bezorgen bij de website. Elke minuut wordt opnieuw een poging gedaan totdat de website terug bereikbaar is en de activatie kan ontvangen. Op deze manier zorgen we ervoor dat een gebruiker die aan de telefoon hoorde dat zijn activatie correct was, ook daadwerkelijk bezorgd werd bij de website, zelfs indien deze tijdelijk onbereikbaar was. De wachttijd nadat een website terug werkt is op deze manier gemiddeld < 1 minuut. De capaciteit van de database om gefaalde activaties te bewaren in de wachtlijn is in


50

principe eindig (gezien de harde schijf beperkt is). Maar de database kan zonder problemen tientallen miljoenen records bewaren, waardoor de kans op een overflow van de wachtlijn verwaarloosd kan worden.

4.7.5

Website bant gebruiker

Op het moment dat een website beslist om een gebruiker te bannen, heeft men de mogelijkheid om dit ook te melden aan de webservice. Zo werken alle websites samen op een communitygebaseerde manier om de reputatie van een gebruiker correct te houden. Zo profiteert elke website van de knowhow van een andere om een gebruiker ook sneller te kunnen weren. Het doorsturen van een ban is even eenvoudig als bvb. een code aanvragen. Een voorbeeldcode werd hiervoor gemaakt in het website vraagt ban.php bestand. Ook bij het doorgeven van een ban is voorzien dat de website eigen interne variabelen kan meegeven om beter te werken met het systeem. Er is ook rekening gehouden met toekomstige mogelijkheden: namelijk dat een website de webservice kan gebruiken om haar eigen interne administratie op orde te houden. Men kan bij de ban namelijk naast een eigen interne referentie ook de naam van de moderator meegeven die de ban uitvoerde en een eigen interne reden opgeven. Deze gegevens kunnen door niemand anders gezien worden, behalve door de website die ze doorgaf. In de toekomst kan zo een adminmodule gemaakt worden waarbij de website gegevens kan opvragen van alle doorgestuurde bans. Men kan zo ook gaan selecteren op alle uitgevoerde bans door bijvoorbeeld een welbepaalde moderator. Dit kan zeer handig zijn. Het moderatorwerk is vaak kwestie van interpretatie. Websites werken dikwijls met vrijwilligers als moderators. Het is niet ondenkbaar dat een moderator om één of andere reden wraak wil nemen of verkeerde mensen bewust gaat bannen. Ook met betaalde moderators valt dit risico niet volledig uit te sluiten. Het is dan achteraf perfect mogelijk om alle bans van een bepaalde moderator ongedaan te maken en zo de rating te herstellen van de mensen die verkeerdelijk geblokkeerd werden. Hetzelfde systeem kan ook handig zijn om statistieken te maken voor de website, of om bijvoorbeeld een andere moderator toe te laten om via het systeem op te zoeken wie de gebruiker blokkeerde en waarom.


51

Bij de doorzending van een ban zijn er een reeks variabelen die men kan of moet meegeven. De verplichte zijn: De userID van de persoon die men wil bannen. Dit is de unieke hashwaarde die men meekreeg op moment van activatie van de gebruiker. De categorie van reden waarom men de gebruiker heeft geband. Een getal dat de categorie van misbruik voorstelt (abuse category).

Tevens kan men een aantal optionele velden mee geven: De ernst van het vergrijp. Men kan op een schaal van 0 tot 10 doorgeven hoe ernstig men de overtreding vond. Deze waarde is mee bepalend voor de berekening van het aantal extra punten dat zal komen bij de rating van de gebruiker. De reden van blokkering. Dit is een string van 255 karakters die men kan meegeven. Deze informatie kan gezien worden door andere websites. Drie velden die opnieuw helpen om de integratie van de website en gebruiksvriendelijkheid van de service te verbeteren. Er kan een interne reden opgegeven worden, een interne referentie en de naam van de moderator die de blokkering doorvoerde.

De aanvraag is opnieuw zeer eenvoudig en slechts één enkele regel: $responsedata = ReportBan($websiteID, $userID, $reasonCategory, $seriousnessLevel, $reason, $internal bannedBy, $internal reason, $internal reference, $url ban report, $VERBOSE OUTPUT); De webservice reageert en stuurt via SOAP een aantal gegevens terug. Zo worden volgende gegevens teruggestuurd: De userID, de hashwaarde van de zonet gebande persoon. De banID. Een unieke code voor elke ban wordt uitgegeven. De bedoeling is dat de website deze banID bewaart. Met deze code kan achteraf een ban terug worden ingetrokken en de rating van een persoon terug hersteld worden naar het originele niveau. De interne referentie die de site zelf kon meesturen indien gewenst.


52

Datum/tijd sinds wanneer de gebruiker geband is. Dit is normaal de huidige datum/tijd tenzij bvb. indien de gebruiker reeds geband werd door dezelfde website, dan wordt de originele datum/tijd teruggegeven.

Ook hier zijn alle variabelen bijzonder eenvoudig toegankelijk via PHP, bijvoorbeeld $responsedata[’banID’] geeft de banID terug. Op het moment dat de website de ban instuurt, wordt een nieuwe rating van de persoon berekend en bewaard in de databank. Deze nieuwe rating wordt bovendien meegedeeld aan elke website waarop de gebruiker geregistreerd is. Elk van deze websites wordt gecontacteerd via SOAP en krijgt een update. Indien de website op dat moment down zou zijn, wordt de aanvraag bewaard in een aparte tabel in de databank die als wachtlijn gaat fungeren met een servicediscipline FCFS (First Come First Served). Een apart crontabprogramma zal vervolgens elke minuut proberen om de bewuste website te contacteren met de nieuwe rating van de persoon. Op deze manier wordt elke website ervan verzekerd steeds de updates te ontvangen, ook al is men tijdelijk down geweest.

4.7.6

Website trekt ban terug in

Het is voorzien dat een website de ban van een gebruiker terug intrekt. De reden hiervoor kan zeer divers zijn. Een website geeft uiteindelijk de gebruiker een tweede kans, de moderator maakte een fout of er was iets anders mis wat aanleiding geeft om de ban terug ongedaan te maken. Enkel en alleen de originele website die de ban rapporteerde aan de webservice kan de ban terug intrekken. Dit door de userID (de hashwaarde) samen met de banID terug te sturen via de functie die uitgewerkt is in website trekt ban terug in.php. Hier staat eenvoudige voorbeeldcode om de ban terug in te trekken. De website geeft dus 2 variabelen mee (verplicht): De userID waarover het gaat. Dit is dus de unieke hashwaarde van de gebruiker. De banID. De ID die men terugkreeg op het moment dat de gebruiker werd geband.


53

Een ban terug intrekken kan met volgende eenvoudige functie: $responsedata = Dropban($websiteID, $userID, $banID, $url ban drop, $VERBOSE OUTPUT); Als antwoord krijgt men normaal een ’OK’ terug; tenzij er een fout is in de gegevens en bijvoorbeeld de banID foutief is. Op het moment dat een ban terug ingetrokken wordt, gaat de webservice de rating van de gebruiker herstellen zoals deze origineel was. Dit kan worden uitgevoerd doordat bij het aanpassen van de rating specifiek wordt bijgehouden wat de originele rating was en hoeveel erbij gekomen is. Op het moment dat een ban terug ingetrokken wordt, zal de nieuwe rating de huidige zijn, waar de bijgekomen punten terug afgetrokken worden. Merk dus op dat er niet hersteld wordt naar de originele rating, maar dat het effectief bijgevoegde aantal punten er terug afgetrokken wordt. Dit is verschillend voor 2 redenen. De eerste reden is dat indien meerdere websites een ban geven op dezelfde gebruiker, en één ervan de ban terug intrekt, het herstellen naar het originele aantal zou maken dat meerdere bans worden uitgewist. Een tweede reden is dat er elke week punten afgetrokken worden van de rating van de gebruiker. Door het zomaar te herstellen op het originele aantal, gaan zo een aantal weken aftrek verloren en is de gebruiker alsnog benadeeld. Bijvoorbeeld: persoon X heeft op 1 januari een rating van 10; bij een extra ban wordt zijn rating met 3 punten verhoogd naar 13. Stel dat elke week de rating met 1 punt verlaagd wordt. Na 8 weken wordt zijn laatste ban terug ingetrokken. Indien nu de rating terug hersteld zou worden naar 10 zou de gebruiker nadeel ondervinden. Zijn huidige rating is op dat moment 13-8 = 5. Na herstel zou het dan terug op 10 vallen. Moest de laatste ban nooit uitgevoerd geweest zijn, zou de gebruiker intussen op 2 staan. Door het origineel toegevoegde aantal terug af te trekken van de huidige score (5 - 3 = 2) krijgt de gebruiker zijn werkelijke rating en ondervindt hij geen nadeel van de terug ingetrokken rating. Op moment van intrekking van de ban wordt zijn nieuwe rating meegedeeld aan elke website waarop de gebruiker zich geregistreerd heeft. Zo wordt dus elke website ge¨ınformeerd over het feit dat de rating van de gebruiker verlaagde. Er werd tevens voorzien dat indien de website down zou gaan, dit opgevangen wordt.


4.7.7

54

Website krijgt update binnen

Het laatste script dat de website voorziet is om updates van een gebruiker binnen te krijgen. Deze updates geven door dat de rating van een gebruiker verhoogd is (na een ban) of juist verlaagd is (na het intrekken van een ban). In de pagina website krijgt userupdate.php staat een voorbeeldscript uitgewerkt voor de website zodat ze dit snel en eenvoudig kan integreren. De website krijgt een oproep die gedaan wordt door de webservice en waarbij volgende variabelen gegeven worden: De gebruikersID die activeerde. Dit is een unieke hashwaarde van het telefoonnummer. De totale score (rating) van de gebruiker. Datum sinds wanneer de gebruiker voor het eerst gekend is bij de webservice (van eender welke website). Het totaal aantal websites waar de gebruiker op geregistreerd is. Het totaal aantal websites dat doorgegeven heeft de gebruiker geband te hebben. Een variabele die extra informatie geeft over de gebruiker. Dit zou het mogelijk maken om in de toekomst extra info door te geven bvb. dat het een admin gebruiker is,... De taal van de gebruiker. Het land waar het gsm-nummer vandaan komt waarmee de gebruiker activeerde. Het gsm-nummer zélf blijft geheim, maar zo heeft de website wel een idee uit welk land het telefoonnummer kwam. De referentie doorgegeven door de website zelf bij het aanvragen van de code; dit is een extra manier om eenvoudig de aangevraagde code te linken met de activatie. De gedetailleerde rating per misbruikcategorie van de gebruiker.

4.8 Hashwaarde

55

Merk op dat hier niet de sectie meegegeven wordt van de gebruiker. Hier is dit niet zinvol aangezien het over een gebruiker gaat. Indien deze op een website gekend is op meerdere secties (forum, chat,...) geldt de nieuwe score uiteraard voor elk van die secties. Elke variabele is ook hier zeer toegankelijk gemaakt, bvb. de variabele $input[’user total sites registred’] geeft in de PHP code voor de website onmiddellijk het aantal websites waar de gebruiker geregistreerd is.

4.8

Hashwaarde

Wanneer een gebruiker zich activeert via het telefoonsysteem krijgt de website via SOAP een XML waarin een herkenningscode staat voor de gebruiker. Deze unieke code is niet het gsm-nummer van de gebruiker, maar een hashwaarde daarvan. De belangrijkste reden hiervoor is behoud van privacy. De website kent op deze manier het gsm-nummer niet van de gebruiker, waardoor dit nummer ook niet misbruikt kan worden. Gebruikers hoeven zich geen zorgen te maken dat ze na een registratie gaan opgebeld worden door een callcenter om hen iets te verkopen. Bovendien moet dit de drempel verlagen zodat mensen weten dat ze ten opzichte van de website anoniem blijven. Om te voorkomen dat websites onderling hashwaarden gaan doorgeven van gebruikers wordt ervoor gezorgd dat de hashwaarde afhangt van de website. De hash van het gsmnummer van dezelfde persoon zal dus anders zijn naar elke website. Zo dient de centrale dienst altijd gecontacteerd te worden en is het omzeilen van de dienst niet mogelijk. De hashwaarde wordt als volgt berekend (waarbij $ staat voor een variabele): $UserIDForWebsite = sha1($UniqueCode1 . sha1($WebsiteID . md5($UniqueCode2. $callerID) . $RandomStringUserid)); Om de string afhankelijk te maken van de website worden er 2 waarden opgenomen die afhankelijk zijn van de website waar de hash naartoe gaat. $RandomStringUserid en $WebsiteID zijn twee waarden die uniek zijn voor elke website. $RandomStringUserid is een willekeurige string van +- 40 karakters die wordt gegenereerd bij registratie van de website, $WebsiteID is een positief natuurlijk getal dat uniek is voor de website. $UniqueCode1 en $UniqueCode2 zijn twee geheime strings die mee in de hash worden opgenomen. Het zijn strings die voor elke website en elke gebruiker hetzelfde zijn. Zij

4.8 Hashwaarde

56

fungeren als een soort van paswoord en moeten het moeilijker maken om de exacte string te achterhalen waarvan de hashwaarde wordt berekend. $callerID is het telefoonnummer van de gebruiker die op dat moment inbelt.

Er worden 2 hashalgoritmen gebruikt. MD5 (Message-Digest algorithm 5) en SHA-1 (Secure Hash Algorithm 1). Het MD5 algoritme wordt gebruikt om het telefoonnummer te combineren met een geheime code tot een string van vaste lengte van 128-bit of 32 hexadecimaal. MD5 alleen is echter niet voldoende veilig. Er zijn voldoende methoden in de literatuur beschreven die aanvallen kunnen uitvoeren op MD5 om zo de originele string te kunnen achterhalen. Daarom wordt de MD5 string gecombineerd met SHA1. De MD5 string samen met een tweede unieke code die afhangt van de website wordt gecombineerd en een hash van berekend. Dit geeft een 160 bit of 40 karakter hexadecimale string. Deze string wordt op zijn beurt opnieuw gecombineerd met een unieke code en er wordt opnieuw een 160 bit of 40 karakter hexadecimale string gemaakt. Deze laatste string is de unieke code van de gebruiker die naar de website wordt gestuurd. Het originele telefoonnummer achterhalen is extreem moeilijk. Het SHA-1 algoritme zou in plaats van 2ˆ80 op 2ˆ69 operaties mogelijk kunnen achterhaald worden [44]. Dit zou echter niet volstaan. Vervolgens zou men opnieuw een SHA1 met 2ˆ69 moeten achterhalen, en dan nog een MD5 string. Een complexiteit van 2ˆ69 is vooralsnog zeer moeilijk. Tienduizenden tot honderdduizenden computers en de nodige financiën zouden ervoor nodig zijn om dit te kraken. Het is niet van vitaal belang dat het originele telefoonnummer zou kunnen achterhaald worden. Het zou de veiligheid van het systeem niet teniet doen, enkel de voordelen van privacy minder sterk maken. Het is echter bijna niet denkbaar dat iemand dergelijke energie wil steken in het reverse engineeren van de hash. Hash algoritmen hebben nog een tweede nadeel. Er is een kans dat 2 strings afgebeeld worden op dezelfde hashwaarde. Dit is ook logisch om in te zien. Langere strings worden afgebeeld op een kortere string. Gezien de set van mogelijke lange strings veel groter is dan de set van kleinere strings is het normaal dat er ’botsingen’ optreden en dubbele hashstrings voorkomen.

4.8 Hashwaarde

57

De kans is echter bijzonder klein dat op vergelijkbare strings dergelijke botsingen optreden. Hashalgoritmen als MD5 en SHA-1 zijn juist ontworpen om licht verschillende strings op totaal andere hashwaarden af te beelden. Maar gezien het feit dat de hashwaarde de unieke identificatie is van de gebruiker voor de website, is het belangrijk om rekening te houden met een eventuele botsing. Daarom wordt na elke berekening van de hashwaarde nagegaan of deze uniek is en nog niet voorkwam voor de betreffende website. In het (zeer zeldzame) geval dat dit toch zo zou zijn, wordt er een andere hashwaarde berekend. Dit op volgende wijze: $UserIDForWebsite = sha1(rand(99999,99999999) . $UniqueCode3 . $UniqueCode1 . sha1($WebsiteID . md5($UniqueCode2. $callerID) . $RandomStringUserid));

Het gaat om dezelfde functie, waarbij echter wat in het vet cursief aangeduid is, wordt toegevoegd. Er wordt een random waarde genomen, in combinatie met een derde unieke en geheime string. De $UniqueCode3 moet normaal zorgen voor de zekerheid dat de hashwaarde een totaal andere waarde zal geven. Om de zekerheid nog te verhogen is er een randomwaarde toegevoegd. Na generatie van deze nieuwe hashwaarde wordt opnieuw nagegaan of deze nog niet gekend is in de databank. Theoretisch gezien blijft de kans namelijk bestaan dat deze al aanwezig is, al is deze kans astronomisch klein. Indien dit tóch zou voorvallen, wordt voorgaande functie opnieuw uitgevoerd in een while-lus totdat wel een nieuwe hashwaarde wordt gevonden. De functie rand(99999,99999999) zorgt ervoor dat bij elke nieuwe uitvoering van de functie telkens een andere waarde in de hash komt, zodat de hashwaarde telkens anders is. Merk op dat de hashwaarde enkel uniek moet zijn ten opzichte van de website waarnaar ze gestuurd wordt. Het is geen probleem indien er eenzelfde hashwaarde zou optreden naar verschillende sites toe. De combinatie hashwaarde en website is uniek. Wanneer er tussen de service en de website wordt gecommuniceerd, is uiteraard steeds de website gekend, zodat de juiste gebruiker kan teruggevonden worden door middel van de hash. Dit geeft als extra voordeel dat bij het opzoeken van een hashwaarde in de database veel minder records moeten doorlopen worden en gewerkt kan worden met een index op de websiteID. Zo kan het terugvinden van een hashwaarde veel sneller.

4.9 Rating

58

De hashwaarde is echter niet meer uniek te bepalen op basis van enkel het telefoonnummer. Er kon namelijk ook gebruik gemaakt zijn van een random waarde. Daarom is ervoor gekozen dat de hashwaarde eenmalig berekend wordt voor een gebruiker voor elke website apart. Deze hashwaarde wordt mee bewaard in de databank. Indien dezelfde gebruiker naar dezelfde site terugbelt, wordt de originele hashwaarde opgezocht in de databank en niet opnieuw berekend. Zo is het steeds perfect mogelijk om te achterhalen welke waarde moet gestuurd worden naar welke website.

4.9 4.9.1

Rating Algemeen

Elke gekende gebruiker krijgt een rating (groter dan of gelijk aan 0) die zijn reputatie voorstelt. Hoe hoger deze rating, hoe slechter de gebruiker. Er is een rating per misbruikcategorie en een totale rating over alle categorieën heen. Uit de enquête blijkt dat 75,0% van de moderators niet enkel een totale rating wensen maar ook per categorie. Toch heeft ook 25,0% geen boodschap aan de specifieke informatie en wil gewoon een algemene rating. 70,4% van de moderators geeft aan dat ze een gebruiker sneller zouden blokkeren indien deze reeds gekend is voor een vergelijkbaar feit op een andere website. Om de rating zoveel mogelijk te modelleren volgens normaal verwachtingspatroon, wordt rekening gehouden met diverse onderdelen: Geschiedenis gebruiker Ernst vergrijp Soort vergrijp Gewicht van site die gebruiker blokkeert

Uit onderzoek bij de moderators blijkt dat een gebruiker die zich net geregistreerd heeft, meer kans heeft om geblokkeerd te worden dan een gebruiker die al lang gekend is. Gebruikers zijn meestal van bij het begin af slecht. Wanneer iemand pas na lange tijd (maanden

4.9 Rating

59

of jaren) geblokkeerd wordt, blijkt dit vaak het gevolg te zijn van onenigheid met de moderators. Dit soort blokkeringen is voor andere websites minder erg dan iemand die bijna onmiddellijk voor problemen zorgt. Iemand die minder dan 30 dagen gekend is op de website krijgt hierdoor extra punten in de rating. Mathematisch wordt de berekening gemaakt door het aantal dagen gekend op de website af te trekken van het getal 30. Indien dit getal groter dan 0 is, wordt dit getal gedeeld door 3 zodat het totaal aantal tussen 0 en 10 ligt. Indien het getal kleiner is dan of gelijk aan 0, blijft het op 0 en telt er niets extra bij de rating. Formeel:

Waarbij de notatie (...)+ gebruikt wordt om de grootheid max(0,...) aan te duiden. Indien het een positieve waarde heeft wordt die waarde genomen, indien het een negatieve waarde heeft, wordt 0 genomen. Een ban van een grote website is belangrijker dan een ban van een kleine website. Grote websites hebben beter opgeleide en gecontroleerde moderators, terwijl kleine websites mogelijk bestaan uit één enkele gefrustreerde moderator. Hiervoor worden twee parameters berekend die gebruikt worden in het model. Enerzijds de PageRank. Deze PageRank is berekend door Google. De rank ligt tussen 0 en 10 en geeft aan hoe belangrijk de website wordt geacht door Google. Hoe meer websites linken naar de betreffende site, hoe hoger de rank. Een kleine website of een site die juist gestart is, krijgt daarom een PageRank van 0. Deze PageRank wordt opgehaald door middel van een speciaal programma dat dagelijks via crontab loopt. Elke rank die ouder is dan 1 week wordt opnieuw opgehaald zodat de recentste rank gekend is. Anderzijds wordt een OwnRank berekend. Deze ranking wordt gemaakt voor elke website die gekend is bij de service. Ook deze rank wordt via crontab dagelijks gestart, maar voor elke website slechts wekelijks bijgewerkt. Het is een exponentiële schaal die op volgende manier berekend wordt: de website met het hoogste aantal verschillende registraties van bezoekers wordt genomen. Dit aantal wordt nummer 10 op de schaal. Dit getal wordt voorgesteld als het getal X. Van X wordt het logaritme genomen. Dat getal wordt gedeeld

4.9 Rating

60

door 10. Voor elk getal van de schaal dat overblijft (0-9) wordt dit getal vermenigvuldigd met het inverse logaritme. Formeel:

Voorbeeld: Stel 35201 is het aantal gebruikers dat de grootste website heeft. De schaal wordt:

Indien een gebruiker slechts op één website geband wordt, maar op vele andere sites gekend is en daar niet op wordt geband, dan wordt de ban minder belangrijk geacht. Het is mogelijk dat de persoon een probleem heeft met een moderator en dus niet algemeen slecht is. Daarom dient de rating minder sterk verhoogd te worden in dit geval. De parameter wordt daarom berekend op basis van het aantal websites waar de gebruiker op geband is, en daar wordt het aantal websites van afgetrokken waarop de gebruiker niet geband is. Om er zeker van te zijn dat de gebruiker reeds enige tijd gekend is op de site, worden enkel sites meegeteld waar de gebruiker langer dan 30 dagen op gekend is. Dit laatste getal wordt beperkt tot 5 om positieve feedback niet teveel te laten meetellen in verband met misbruik (zie verder). In formulevorm geeft dit: Aantal = ((# bans op andere websites voor eender welke misbruikcategorie) (#sites meer dan 30 dagen gekend en niet geband)) Indien de gebruiker in het verleden ook al een ban heeft gekregen uit dezelfde misbruikcategorie, wordt er een extra van 10 punten bijgerekend. Een recidivist is namelijk slechter dan iemand die iets voor de eerste keer deed. De rating moet aan diverse criteria voldoen en van diverse factoren afhangen. Zo moet er ook rekening gehouden worden met het feit dat het systeem misbruikt zou kunnen worden om iemands rating te be¨ınvloeden.

4.9 Rating

4.9.2

61

Misbruik

Er moet rekening gehouden worden met het feit dat mensen de rating willen be¨ınvloeden, zowel positief als negatief. Een mogelijke negatieve be¨ınvloeding kan op volgende manier. Door zeer veel kleine websites te registreren op de service, vervolgens iemand zijn gsm te lenen (’stelen’), op elk van de sites te activeren, en vervolgens de gsm terug te geven. Vervolgens laat men de gebruiker op elk van de websites blokkeren waardoor de rating zou toenemen. Om dit te voorkomen werden de PageRank en OwnRank ingevoerd. De PageRank geeft de grootte van de website aan. Kleine websites die maar kort bestaan en amper bezoekers trekken hebben een PageRank van 0. De OwnRank geldt voor het aantal registraties gekend bij de dienst. Pas na een minimum aantal registraties stijgt de OwnRank van 0 naar 1. Dit aantal ligt hoger dan redelijker wijze mag aangenomen worden dat iemand zomaar aan verschillende gsm’s kan geraken om te frauderen. Indien zowel de PageRank als de OwnRank 0 zijn, zal de doorgegeven ban niet meetellen, om zo deze negatieve be¨ınvloeding tegen te gaan. Dergelijke praktijken komen bovendien al snel aan het licht gezien het feit dat bij elke ban de gebruiker per SMS wordt op de hoogte gebracht. Een mogelijke positieve be¨ınvloeding kan op volgende manier: Door zeer veel kleine websites te registreren op de service. Vervolgens registreert men zichzelf op al deze websites en blokkeert men zichzelf niet. Doordat de gebruiker nu gekend is op vele sites die hem niet blokkeren krijgt hij een betere score. De be¨ınvloeding is er enkel indien de gebruiker effectief een ban binnenkrijgt. Door dit soort van positieve be¨ınvloeding zal het aantal punten dat bij de ranking bijkomt iets lager liggen. Bijvoorbeeld 5 extra punten in plaats van 6. Dit wordt gedeeltelijk tegengegaan door te verplichten dat de gebruiker al langer gekend moet zijn op de websites alvorens het positief meetelt. Slechts na 1 maand zal dit kunnen meetellen voor positieve be¨ınvloeding. Ten tweede werd de positieve be¨ınvloeding beperkt tot maximaal 5 punten op een totaal van 60, waardoor de invloed beperkt wordt.

4.9 Rating

4.9.3

62

Berekening rating

Bij een binnenkomende ban wordt het aantal punten berekend dat zal bijgeteld worden bij de huidige rating van de persoon. Hierbij worden alle hiervoor uitgelegde waarden gebruikt. Elk van de waarden ligt tussen 0 en 10. Elke waarde wordt vermenigvuldigd met een parameter pi om bepaalde parameters meer of minder belangrijk te maken. In het huidige systeem zijn alle pi = 1, maar in de toekomst zou bvb. de PageRank minder belangrijk kunnen worden terwijl bvb. de OwnRank als belangrijker wordt geacht. Elk van de parameters kan bovendien verschillend zijn afhankelijk van de misbruikcategorie. Om te voldoen moet de som van alle parameters pi gelijk aan 6 zijn, zodat na optelling de totale waarde tussen 0 en 60 blijft liggen. De 6 waarden die opgeteld worden gaan vervolgens gedeeld worden door 6 om terug tussen 0 en 10 te liggen, en vervolgens afgerond tot een natuurlijk getal.

4.9 Rating

4.9.4

63

Totale rating

De gebruiker heeft een rating voor elk van de 15 misbruikcategorieën. Door moderators wordt echter ook gevraagd naar een totale rating. In dit geval is men niet ge¨ınteresseerd in gedetailleerde informatie maar in een totale reputatie van de gebruiker. Hiervoor gaan elk van de categorieën opgeteld worden om zo een totale som te geven in een totale rating. Omdat echter elk van de overtredingen niet als even zwaar worden ervaren, dient er nog een gewicht te worden gegeven aan elk van de categorieën. Zo is het zondigen tegen spam minder erg dan stalking of pedofilie. Om de totale rating zoveel mogelijk te laten overeenkomen met wat mensen als natuurlijk ervaren voor ernst van overtredingen werd door middel van een enquête de ernst van elk van de categorieën nagegaan bij de moderators. Voor elke categorie werd daarna de gemiddelde ernst berekend en dan hierop gesorteerd. Vervolgens werd er een normering toegepast zodat het laagste getal (3,7 voor spam) het gewicht 1 kreeg. Elk van de categorieën werd hierop berekend. Vervolgens werden de gewichten afgerond tot op 1 cijfer na de komma. De resultaten zijn te vinden in tabel 4.2. Deze gewichten worden nu gebruikt voor het samentellen van de verschillende ratings om een zo betrouwbaar en natuurlijk mogelijk resultaat te bieden voor totale reputatie (groter dan of gelijk aan 0) van een gebruiker.

4.9.5

Aanpassing rating in de tijd

Mensen vinden het normaal dat iemand zijn of haar leven kan beteren. Zo mag een ban je niet de rest van je leven blijven achtervolgen. Daarom wordt de rating hier ook op aangepast. Er is gekozen om elke week een bepaald aantal punten af te trekken van de rating. Hoeveel er precies wordt afgetrokken werd als volgt berekend.

4.9 Rating

64

Voor een zwaarder vergrijp wordt een langere termijn genomen dan voor een lichter vergrijp. Hiervoor werd ook een enquête uitgevoerd en werd nagegaan hoe lang mensen vinden dat iemand moet worden uitgesloten na een bepaalde overtreding. Dit werd nagegaan voor elk van de misbruikcategorieën, en telkens werd gevraagd hoelang men de persoon wilde weren na een lichte of zware overtreding die paste in de betreffende categorie. Het gemiddeld aantal dagen om geblokkeerd te blijven bij een overtreding is te vinden in tabel 4.3. In het finale systeem is er meer onderscheid tussen licht en zwaar, namelijk op een schaal van 0 tot 10. Hiervoor werden zowel de lichte als de zware overtredingen samengeteld. Indien mensen aangaven dat men ’nooit’ nog mocht terug binnenkomen werd 3 jaar gerekend. Op internet is 3 jaar zeer lang. Vervolgens werd het totaal aantal dagen berekend dat men zou blokkeren, en vervolgens een gemiddelde. Dit werd berekend met volgende PHP script dat de resultaten verwerkte. $query = ’SELECT * from specials.thesisonderzoek opgekuist ’; $result = $mysql->Query($query); $totaalpercentage = 0;

while ($data = $mysql->Fetch Array($result)) { $i = 0; while ($i <= 15) { if (trim(strtolower($data[’q9 l ’.$i])) == ’nooit’) { $totaal l[$i] += 1095; } else { $totaal l[$i] += $data[’q9 l ’.$i]; } $i++;

} $i = 0; while ($i <= 15) { if (trim(strtolower($data[’q9 z ’.$i])) == ’nooit’) { $totaal z[$i] += 1095; }

4.9 Rating

65 else { $totaal z[$i] += $data[’q9 z ’.$i]; } $i++;

} }

Om de vermindering per week te berekenen werd uitgegaan van het feit dat iemand de zwaarste sanctie kreeg met een rating van 10 negatieve punten. Na het aantal berekende dagen in de misbruikcategorie moet iemand met score 10 terug op 0 kunnen komen. Dit wordt gedaan door 10 te delen door het aantal dagen dat de persoon zou moeten geblokkeerd worden, en dit vervolgens te vermenigvuldigen met 7 om het per week te krijgen.

Dit geeft voor elk van de categorieën de getallen in tabel 4.4. De cijfers in de laatste kolom worden in het systeem gebruikt om elke week af te trekken van de rating van de gebruiker. Hiervoor werd een programma geschreven dat door de server automatisch elke week wordt gestart. Indien de score na aftrek kleiner dan 0 wordt, zal de score terug naar 0 gebracht worden. Ratings onder 0 zijn niet mogelijk. De totale rating wordt steeds herberekend op basis van de nieuwe ratings van elk van de misbruikcategorieën. De verlaging wordt niet automatisch meegedeeld aan elke website die een rating kent van de gebruiker. Deze wordt enkel meegedeeld aan nieuwe sites waar de gebruiker zich op registreert, of bij specifieke vraag van een website om de score opnieuw toe te sturen. Dit heeft als doel om het verkeer te verminderen dat over en weer moet gaan tussen de websites en de centrale dienst. Indien elke week de nieuwe score van de honderdduizenden gebruikers naar de honderden ingeschreven sites wordt gestuurd, dan zou dit schaalbaarheidsproblemen opleveren. Bovendien is de gebruiker reeds gekend bij de site en zij weten dat de score langzaam afneemt.

4.10 Schaalbaarheid

4.10

66

Schaalbaarheid

De schaalbaarheid (scalability) van het systeem werd eveneens onderzocht.

4.10.1

Schaalbaarheid op serverniveau

De belasting van een enkele oproep is zeer klein. Eén enkele goed geconfigureerde Linuxserver kan op deze manier eenvoudig tienduizenden oproepen tegelijk verwerken. Een zwaardere server of een extra server kan het dubbele aan indien nodig. Alle bellers worden gelijktijdig verwerkt. Gezien de lage serverload die elke gebruiker vraagt, kan er door processor-sharing voor gezorgd worden dat iedereen als het ware gelijktijdig bediend wordt. Omdat het systeem ervoor gaat zorgen dat gebruikers toegelaten worden op een website, is het vervelend indien het systeem zou uitliggen. Indien het systeem succesvol is zouden bezoekers in één klap op honderden of duizenden sites niet meer kunnen registreren. Om dit te voorkomen in de toekomst zou hiervoor een eenvoudige aanpassing kunnen gemaakt worden om de uptime te maximaliseren. Niet enkel aan de kant van het datacentrum kan een aanpassing gebeuren (meerdere servers die invallen voor elkaar bij problemen). Ook aan de kant van de website kan in de scripts een aanpassing doorgevoerd worden. Dit is volledig transparant voor de website, het gaat dan enkel om wat de scripts op de achtergrond doen. Er zou op geregelde tijdstippen (bvb. wekelijks) een aanvraag kunnen gebeuren naar de webservice met de vraag om een lijst te krijgen van alle servers die beschikbaar zijn. Zo kunnen servers geplaatst worden in meerdere datacentra ter wereld. Op het moment dat één van hen down gaat en het script geen verbinding meer krijgt met zijn gewone server, gaat het de andere servers af in het lijstje. Op deze manier is de kans op downtijd bijna nihil. De kans dat meerdere servers in onafhankelijke datacentra tegelijk plat gaan is zeer klein. Elk van de servers in de verschillende datacentra dient over dezelfde informatie te beschikken. Hiervoor wordt een synchronisatie tussen de servers continu uitgevoerd zodat elk van de servers identieke informatie bevatten (op vertragingen van een aantal seconden na). Bij het uitvallen van een server beschikken alle andere servers over de volledige database. Indien de server hersteld wordt, zal er eerst een synchronisatie gebeuren met een van de actieve databanken alvorens de server terug benaderd kan worden door websites.

4.10 Schaalbaarheid

4.10.2

67

Schaalbaarheid op het niveau van telefonie

Het is mogelijk om meerdere telefoonlijnen te koppelen aan dezelfde server. Het aantal verschillende telefoonnummers is virtueel onbeperkt. Voor elke website kan op deze manier eenvoudig een apart telefoonnummer aangevraagd worden. Wereldwijde telefoonnummers zijn tevens geen probleem. Het is mogelijk om op een server die in Brussel staat telefoonlijnen te laten toekomen met een buitenlands nummer. De prijzen zijn hiervoor bovendien ook niet zo hoog. Enkele prijzen die geldig waren in april 2009 voor een telefoonlijn van volgende landen: Nederland: 16,53 euro per maand Frankrijk: 12,96 euro per maand Verenigd Koningkrijk: 13,91 euro per maand Verenigde Staten: 11,43 euro per maand Thailand: 30 euro per maand Rusland: 120 euro per maand

Het is ook mogelijk om de zones te kiezen van het telefoonnummer. Zo zou voor België zowel een 03, 02 als 09 nummer genomen kunnen worden, en voor de Verenigde Staten bijvoorbeeld een telefoonnummer per staat. Deze kunnen allemaal toekomen op dezelfde server. Ook mogelijkheden om te kiezen zijn voorzien. Zo kan een gratis 0800-nummer verbonden worden met hetzelfde systeem en kan een bedrijf zo de telefoonkosten op zich nemen in plaats van de beller om zo de drempel nog verder te verlagen. Ook 0800-nummers van het buitenland kunnen gekoppeld worden. Een probleem zou ontstaan indien een groot aantal gebruikers tegelijk naar hetzelfde nummer zouden bellen. Voor een gewoon nummer betekent dit in praktijk dat een 10-tal gelijktijdige oproepen op hetzelfde nummer geen probleem vormen. Wanneer dit aantal echter systematisch hoger gaat liggen zijn speciale lijnen nodig. Dit zijn speciale E1 connecties die moeten gelegd worden en die zeer duur zijn. De eenmalige setupkost kan hiervoor oplopen tot 50.000 euro voor de connectie en nog eens 4.000 euro

4.11 Privacy

68

voor speciale hardware voor de server. Voordeel is echter wel dat met deze speciale connecties er tot tienduizenden gelijktijdige telefoonoproepen afgehandeld kunnen worden op hetzelfde nummer. Om het E1-connectieprobleem op te lossen kan geopteerd worden om voor elke website een apart telefoonnummer aan te vragen. Dit komt financieel voordeliger uit.

4.10.3

Schaalbaarheid naar website

Het aantal berichten naar een website blijft beperkt. Enkel bij aanvraag van een registratie, een ban of een activatie zijn er berichten. Deze berichten worden via SOAP verstuurd en zijn relatief klein. Zelfs bij zeer veel gebruikers en websites vormt het geen probleem voor het dataverkeer. De (SOAP) aanvraag van een code is 1.188 bytes, het (SOAP) antwoord is 1.192 bytes. Een enkele 1 Mbps datalijn van de server naar het internet kan zo 52 request- en responsaanvragen verwerken. Het is vandaag de dag geen uitzondering meer dat dataservers met het internet verbonden zijn via een gigabit lijn; SeniorenNet heeft bvb. een uplink die mag gaan tot 2 Gbps. Deze lijn zou tot 105.042 request- en responsaanvragen per seconde kunnen verwerken, wat meer is dan verwacht kan worden van dit systeem. Grotere datalijnen zijn bovendien te verkrijgen indien dit toch nodig zou blijken. Communicatie gebeurt via SOAP wat een protocol is dat maximale ondersteuning geeft naar elke soort van webserver. Hierdoor kan virtueel elke website ter wereld het systeem integreren, ongeacht of die nu gemaakt is in PHP, JSP, ASP, Perl of een andere technologie.

4.11

Privacy

4.11.1

Algemeen

Het ontwikkelde systeem valt onder de Wet Verwerking Persoonsgegevens (WVP). Rond deze wetgeving werd daarom ook uitgebreid onderzoek gedaan. De werking van het systeem werd bijgestuurd om volledig in orde te zijn met huidige en toekomstige wetgeving. In eerste instantie werd er na eigen onderzoek een vraag tot advies geformuleerd aan de Privacy Commissie, zonder resultaat. Artikel 29 uit de WVP stelt dat de commissie

4.11 Privacy

69

enkel advies geeft aan ’Regering, van de Wetgevende Kamers, van de Gemeenschaps- of Gewestexecutieven, van de Gemeenschaps- of Gewestraden, van het Verenigd College of van de Verenigde Vergadering bedoeld in artikel 60 van de bijzondere wet van 12 januari 1989 met betrekking tot de Brusselse instellingen, of van een toezichtscomité’. Advies werd verkregen door de heren Bertel De Groote van het departement Handelswetenschappen en Bestuurskunde van de Hogeschool Gent en tevens van professor emeritus Rogier De Corte. De verwerking van de gegevens valt onder de WVP die stelt in artikel 1 §1 dat alles wat voldoet aan volgende beschrijving onder de WPV valt: ’iedere informatie betreffende een ge¨ıdentificeerde of identificeerbare natuurlijke persoon’. Als identificeerbaar wordt beschouwd ’een persoon die direct of indirect kan worden ge¨ıdentificeerd, met name aan de hand van een identificatienummer of van één of meer specifieke elementen die kenmerkend zijn voor zijn of haar fysieke, fysiologische, psychische, economische,culturele of sociale identiteit’. Tevens stelt de wet in Art. 3. § 1. ’Deze wet is van toepassing op elke geheel of gedeeltelijk geautomatiseerde verwerking van persoonsgegevens, alsmede op elke niet-geautomatiseerde verwerking van persoonsgegevens die in een bestand zijn opgenomen of die bestemd zijn om daarin te worden opgenomen.’. Met het gsm-nummer dat wordt bewaard via een geautomatiseerd systeem kan iemand ge¨ıdentificeerd worden, door bijvoorbeeld gewoon naar het nummer te bellen. Het gaat hierbij wel om een naamloos gegeven, dat echter niet mag verward worden met een anoniem gegeven. Bij naamloze gegevens is er geen naam aanwezig, maar kan de identiteit indien gewenst wel achterhaald worden (zoals bij een gsm-nummer), terwijl bij anonieme gegevens dit niet het geval is. De wet WVP is dus van toepassing, want de enige uitzondering staat vermeld in Art. 3. § 2. ’Deze wet is niet van toepassing op de verwerking van persoonsgegevens die door een natuurlijk persoon in activiteiten met uitsluitend persoonlijke of huishoudelijke doeleinden wordt verricht.’, welke duidelijk niet van toepassing is. Momenteel is er geen specifieke wetgeving rond negatieve lijsten (ook wel zwarte lijsten genoemd). Hier komt echter op relatief korte termijn verandering in. Er zijn ontwerpen in de maak om dit ook wettelijk te bepalen. Bij negatieve lijsten gaat het om informatie die doorgegeven wordt en die een negatieve invloed kan hebben op iemands mogelijkheden of

4.11 Privacy

70

vrijheden. Gezien het systeem een rating doorgeeft waarop een website kan beslissen om iemand te blokkeren, gaat het hier dus om een negatieve lijst. Om ook voor de toekomst veilig te blijven werd gezocht naar een oplossing om ook te blijven voldoen aan alle wettelijke voorwaarden en eisen. De wet behoudt een aantal rechten voor iemand waarvan de persoonsgegevens worden verwerkt. In artikel 2 van de WVP wordt het recht gegeven ’Iedere natuurlijke persoon heeft in verband met de verwerking van persoonsgegevens die op hem betrekking hebben, recht op bescherming van zijn fundamentele rechten en vrijheden, inzonderheid op bescherming van zijn persoonlijke levenssfeer.’. Er moet duidelijk opgegeven worden wat het doel is. Artikel 4 § 1 maakt dit duidelijk ’voor welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden te worden verkregen’. Persoonsgegevens mogen volgens artikel 5 verwerkt worden ’wanneer de verwerking noodzakelijk is voor de uitvoering van een overeenkomst waarbij de betrokkene partij is of voor de uitvoering van maatregelen die aan het sluiten van die overeenkomst voorafgaan en die op verzoek van de betrokkene zijn genomen;’. In artikel 9 § 1 wordt ook gezegd dat er een aantal gegevens moeten verstrekt worden indien persoonsgegevens worden verwerkt, onder andere de naam en het adres van de verantwoordelijke voor de verwerking en, in voorkomend geval, van diens vertegenwoordiger. Spijtig genoeg is de WVP wetgeving niet altijd evengoed voorzien voor de elementen die worden ontworpen in deze thesis, waardoor er een aantal aanpassingen of speciale constructies moeten gemaakt worden.

4.11.2

Specifieke details

Er werd onderzocht of het bewaren van enkel een hashwaarde van het gsm-nummer (en dus het gsm-nummer zelf niet meer) zou voorkomen dat het systeem onder de WVP zou vallen en dus geen verdere problemen in verband met privacy zou kunnen veroorzaken. Hierover zijn echter de meningen verdeeld, maar uiteindelijk kan worden aangenomen dat het blijft gaan om persoonsgegevens en dat de WVP hier van toepassing blijft. Rechters zouden in deze zin de uitspraak kunnen doen. Ook al zou de hashwaarde strikt in één richting werken, waarbij met de hashwaarde zelf het originele telefoonnummer niet kan worden teruggevonden, dan nog kunnen rechters uitspraak doen oordelend dat de WVP van toepassing is. Dit omdat het een verwerking blijft van een origineel persoonsgegeven. Bovendien zou het niet meer bewaren van het gsm-nummer ook het nut van het systeem geen goed doen, omdat mensen dan strikt anoniem zouden blijven. Ook bij een klacht van

4.11 Privacy

71

bvb. de politie zou dan geen gsm-nummer gegeven kunnen worden. Het verwerken van de persoonsgegevens is toegelaten indien er een contract is met de gebruiker en in dit contract de verwerking wordt uitgelegd zodat de verwerking noodzakelijk is voor de uitvoering van het contract. Een contract is voor de wet echter niet enkel schriftelijk en getekend op papier. Daarom is het mogelijk dat een gebruiker die zich registreert bij een website een contract aangaat indien dit duidelijk gespecificeerd is in de algemene voorwaarden. Bovendien vereist de wet dat de gebruiker steeds weet wie de verantwoordelijke is van de verwerking van de persoonsgegevens. Om aan deze eisen te voldoen werd voorzien dat elke website die aansluit bij de centrale dienst een standaard tekst moet opnemen in de algemene voorwaarden voor registratie van haar gebruikers. Elke gebruiker gaat op deze manier een contract aan met de website zélf waarop hij op dat moment registreert. De verantwoordelijke voor de verwerking wordt zo de website waarop de gebruiker zich registreert. In de voorwaarden wordt vervolgens aangegeven dat de effectieve verwerking wordt gedaan door het centrale systeem. Gezien er negatieve informatie kan worden doorgegeven over een gebruiker, kan het voorkomen dat iemand met een zeer slechte rating zijn informatie wil schrappen, om op deze wijze zijn daden uit te wissen. In artikel 12 § 1 staat ’Eenieder is bovendien gerechtigd om wegens zwaarwegende en gerechtvaardigde redenen die verband houden met zijn bijzondere situatie, zich ertegen te verzetten dat op hem betrokken gegevens het voorwerp van een verwerking vormen.’ Om zeker te zijn dat iemand de verwijdering kan vragen van de gegevens wordt beroep gedaan op de uitzondering die in art. 12 § 1 staat ’behalve wanneer de rechtmatigheid van de verwerking gesteund is op de in artikel 5, b) en c) bedoelde redenen’. Namelijk door een contract aan te gaan met de gebruiker kan hij hiervan de verwijdering niet vragen. Wel is het mogelijk dat de gebruiker het contract verbreekt. Hierdoor moet de verwerking van de persoonsgegevens stoppen. Let echter wel dat enkel de verwerking stopt, de gegevens op zich dienen niet verwijderd te worden. Bij het opzeggen van het contract is het toegelaten om nog eenmalig een verwerking te doen alvorens de verwerking te stoppen. Het is hierdoor mogelijk om elk bestaand lid te verwittigen dat de gebruiker om stopzetting vraagt van zijn gegevens en nog de huidige rating door te spelen. Pas daarna mag er geen verwerking meer zijn van de gegevens en mag de rating niet meer doorgegeven worden aan nieuwe websites die zich registreren bij het systeem.

4.11 Privacy

72

De constructie waarbij de gebruiker een contract aangaat met elke website waar hij zich registreert, biedt hierdoor een voordeel voor het systeem (en uiteindelijk een nadeel voor de gebruiker). Indien iemand wenst dat de verwerking van zijn rating stopt, moet hij het contract verbreken met elke website. Een contract verbreken met één website heeft namelijk slechts tot gevolg dat enkel de gegevens van die specifieke website niet meer verwerkt mogen worden, maar nog wel alle andere gegevens van de andere websites (gezien hij met elk van die andere nog een contract lopende heeft). Een gebruiker heeft hierbij nog wel een wapen in handen. Hij kan het contract verbreken waarbij hij recent werd geband. Hierdoor mag de informatie van de ban niet meer verwerkt worden naar de andere aangesloten websites en mag deze niet meer meetellen in zijn rating. Een ban zou zo onzichtbaar worden voor de andere websites. Er mag bovendien niet meegegeven worden dat er beschikking is over negatieve informatie (zonder in detail te gaan), gezien de gegevens niet meer verwerkt mogen worden. De wet laat echter een oplossing toe voor dit zwakke punt. Het is volledig wettelijk in orde om te bewaren dat de gebruiker om stopzetting vroeg, en hierna elke dienstverlening te weigeren. Daarom werd er voor gekozen dat de gebruiker centraal geblokkeerd wordt vanaf het moment dat een gebruiker stopzetting vraagt na een negatieve rating. Hierdoor kan de gebruiker zich niet meer registreren op één van de aangesloten websites. Door volledige dienstverlening te weigeren heeft het totaal geen zin voor een gebruiker om na een negatieve rating stopzetting te vragen. Men krijgt daarna geen toegang meer op geen enkele van de aangesloten websites. Dit gevolg weegt zwaarder door dan een eventuele negatieve rating. In de wet staat in artikel 10 § 1 ’De betrokkene die zijn identiteit bewijst, heeft het recht om vanwege de verantwoordelijke voor de verwerking te verkrijgen [...] verstrekking in begrijpelijke vorm van de gegevens zelf die worden verwerkt, alsmede alle beschikbare informatie over de oorsprong van die gegevens’ en de procedure hiervoor is ’daartoe richt de betrokkene een gedagtekend en ondertekend verzoek aan de verantwoordelijke voor de verwerking’. Er moet ook op gereageerd worden: ’De inlichtingen worden onverwijld en ten laatste binnen vijfenveertig dagen na ontvangst van het verzoek meegedeeld’. Het probleem is echter dat indien iemand zijn identiteit bewijst (in praktijk wordt kopie van paspoort gevraagd) dit niet voldoende is. Enkel met de naam of adres kunnen we geen

4.11 Privacy

73

gegevens terugvinden. De wetgever hield geen rekening met het feit dat er, zoals in dit systeem, wel persoonsgegevens worden bewaard (het gsm-nummer) zonder dat de naam of adres van de persoon in de databank gekend zijn. Toch vormt dit juridisch geen probleem. De persoon moet zijn gsm-nummer mee vermelden in dit geval waardoor de opzoeking wél kan gebeuren. Met het feit dat men zo gegevens van iemand anders kan opvragen (door het gsm-nummer op te geven van iemand anders) dient geen rekening gehouden te worden. De wetgever gaat ervan uit dat mensen niet frauderen. Wij als centrale systeem moeten hier geen rekening mee houden en gewoon de gevraagde gegevens verstrekken. Om het nog gebruiksvriendelijker te maken en de schriftelijke procedure zoveel mogelijk te vermijden (aangezien dit kostbare werkuren vraagt) is het mogelijk om online de gegevens rechtstreeks op te vragen. De gebruiker kan dan eenvoudig via de website alle gegevens opvragen. Indien iemand echter overgaat tot de schriftelijke procedure zijn we nog steeds verplicht om ook via de schriftelijke weg te reageren. De gevolgde procedure via de website gaat verder dan wat strikt wettelijk verplicht is. Het is positief naar de gebruiker toe dat we open en eerlijk zijn over de gegevens. De voorgestelde aanpassingen in het systeem werden in praktijk uitgewerkt.

4.11.3

Toekomst

Er werden twee specifieke aanpassingen gedaan aan de architectuur om ook in orde te zijn voor toekomstige wetgeving rond negatieve lijsten. Een eerste aanpassing zorgt ervoor dat de negatieve rating niet onbeperkt blijft meetellen. De wetgever gaat ervan uit dat iemand zijn leven betert. Een negatieve rating mag je dus niet heel je leven blijven achtervolgen (geen finaliteit). Daarom werd ervoor geopteerd om de rating op 0 te zetten indien van een gebruiker gedurende 2 jaar geen bans meer worden ingestuurd. Merk op dat de vermindering per week hiervoor niet werd aangepast. De vermindering per week blijft zoals berekend op basis van de enquêtes. Pas op de dag dat er 2 jaar lang geen ban gekend wordt, zal de rating op 0 geplaatst worden. Wanneer iemand een rating van 200 heeft, en er zou per week één punt afgaan, zou deze na 2 jaar nog een rating hebben van 94. Na 1 jaar en 364 dagen is zijn rating 94, één dag

4.12 Systeemkosten

74

later wordt deze dan gereset tot 0. Indien binnen de 2 jaar een nieuwe ban binnenkomt, begint vanaf die dag terug de 2 jaar te lopen. Een tweede aanpassing heeft tot doel schadeclaims te voorkomen. Een gebruiker gaat in de toekomst een forfaitaire schadevergoeding kunnen vragen van duizenden euro indien er een fout werd gemaakt in een negatieve lijst. De geleden schade moet hierbij zelfs niet bewezen worden. Om dit gevaar te voorkomen is het eenvoudig om de gebruiker te verwittigen op het moment dat een negatieve rating wordt ingevoerd. Indien de persoon verwittigd wordt heeft deze de mogelijkheid om bij een fout dit alsnog recht te zetten, waardoor de schadevergoeding niet meer van toepassing is. De wetgever heeft dit ingebouwd met het idee dat mensen soms al jaren op negatieve lijsten staan zonder dit zelf te weten. De gebruiker dient hiervoor gecontacteerd te worden. De enige mogelijkheid hiervoor is het gsm-nummer. Daarom werd in het systeem ge¨ıntegreerd dat er een sms wordt verstuurd. Zo wordt de gebruiker verwittigd en is het systeem juridisch in orde. Het zou ideaal zijn indien de aanpassing van de rating pas zou gebeuren 24 uur nadat de SMS werd verstuurd. Dat is op dit moment in het systeem niet het geval, maar dit kan bij invoering van de betreffende wet uiteraard eenvoudig aangepast worden.

4.12

Systeemkosten

Om het systeem in praktijk uit te werken, dienen we over de nodige hardware te beschikken. Een schatting van de kosten zijn in volgende tabellen weergegeven. De kosten zijn gegroepeerd als eenmalige en als maandelijks terugkerende kosten.

4.12.1

Eenmalige kosten (geschat budget)

2 servers die elkaars back-up zijn. Raid voor het tegengaan van falen van een harde schijf, zodat het systeem nog blijft doorlopen. (2 x 4117 euro voor een Quad Core Intel Xeon L5420, 2.5GHz, 2x6M Cache, 1333MHz FSB , 16GB Memory, 667MHz

4.12 Systeemkosten

75

(8x2GB Dual Ranked FB DIMMs) , 1 TB RAID 1, plus 1 TB voor back-up). Samen: 8234 euro 24 Port Fast Ethernet Stackable Switch: 349 euro Open source Asterisk, open source Gnokii, open source Linux server: 0 euro Installatiekosten, aanvraag telefoonlijn in datacentrum, extra kabels,... 200 euro Testkosten: telefoonkosten om naar het systeem te bellen en uit te testen 120 euro Eenmalige kost datacenter: contract aangaan, installatiekost rack,... 120 euro

TOTAAL (excl. 21% BTW) eenmalig: 9.023 euro

4.12.2

Maandelijkse kosten (geschat budget)

Een Belgisch 02-nummer met meerdere oproepen tegelijk mogelijk 14 euro Datacenter: 2 x 116 euro voor racks, plaats, huur,... 232 euro Dataverkeer: 1 Mbit, voldoende voor normaal gebruik, kan tot 52 request/responses per seconde aan. Bij groot succes is het vooral deze factor die zwaarder in de kosten zal doorwegen. 100 euro Noodstroom. Indien reguliere stroom uitvalt, zodat het systeem blijft lopen op noodstroom aangeleverd door het datacenter. 25 euro 2e dataprovider. Indien de reguliere glasvezel uitvalt (door bvb. graafwerken), zodat er kan teruggevallen worden op een 2e glasvezel van een andere dataprovider. 50 euro Onderhoud en updaten servers. 2 x 300 euro voor elk van de servers voor update en beveiliging. 600 euro Domeinnaam: 2 x 2 euro, voor 2 domeinnamen, een .com en .be, samen 4 euro. Monitoring: bewakingsfrequentie van elke 3 minuten gedurende 24/7/365, met SMS melding bij problemen door externe service. 22 euro

TOTAAL (excl. 21% BTW) maandelijks: 1.047 euro

4.13 Uitwerking in praktijk

4.13

Uitwerking in praktijk

4.13.1

Inleiding

76

Voor deze masterproef werd het volledig systeem, in praktijk gerealiseerd. Gezien het systeem een groot potentieel heeft, wordt ook gepland dit naar de toekomst toe daadwerkelijk te commercialiseren. Om een concept om te zetten in een werkbaar product dienen er een aantal extra elementen te worden voorzien. Denk hierbij aan het bedenken van een naam, een logo, een domeinnaam registreren, een website ontwerpen , voorbeeldscripts maken, enz.

4.13.2

Naam

Een eerste belangrijk onderdeel van commercialisering van het project is het bedenken van een naam. Omdat het systeem wereldwijd gebruikt zou kunnen worden was een .com domeinnaam gewenst. Het vinden van een vrije .com domeinnaam is minder evident. Zowat 90 miljoen dergelijke domeinnamen zijn geregistreerd [45]. Zowat elke combinatie die uitgeprobeerd werd is reeds bezet. Bovendien is het nodig dat de naam Engelstalig is, goed in de mond ligt en goed te onthouden is. Het is belangrijk dat een naam meer vanuit de marketing gekozen werd dan vanuit ingenieursstandpunt. Daarom is het niet nodig om de technologie te verwerken in de naam (dus niet spreken over gsm, authenticatie,...) maar iets dat een gewone gebruiker kan aanspreken. De naam YouValid.com die de lading dekt werd bedacht. ’You’ van de persoon waarover het gaat, en ’Valid’ van validatie. ’Jij wordt gevalideerd’ of ’jij bent gevalideerd’ wil de naam dus betekenen. Zo is het een korte en duidelijke marketingnaam voor de gecentraliseerde gsm-identicaitie/authenticatie met communityfeedback. De domeinnaam www.YouValid.com werd geregistreerd op 25 maart 2009. Eveneens werden YouValid.be, YouValidate.com, YouValidate.be en YouAreValid.com geregistreerd. Dit om cybersquatting (domain squatting) te voorkomen en zeker te zijn dat de url’s naar dezelfde dienst verwijzen.


4.13.3

77

Logo

Ontwerp van een aantrekkelijk en functioneel logo is de volgende stap. Voor YouValid werd uiteindelijk het logo ontworpen in figuur 4.11.

Figuur 4.11: Logo YouValid

Het groene ventje slaat op de ’you’ (jij). De V stelt het teken voor dat je gebruikt bij het afvinken. De groene kleur werd gekozen omdat dit gevoelens als veilig en ’in orde’ oproept. Hiermee straalt het logo de naam uit: jij wordt (of bent) correct gevalideerd. Het logo is dus niet vanuit technologisch standpunt bekeken, maar vanuit het standpunt van de eindgebruiker.

4.13.4

Website

Volgende stap is het maken van een website. Hiervoor werd enerzijds een design gemaakt, en anderzijds de inhoud van de website. Het design dient professionalisme uit te stralen en duidelijk te zijn. Het gaat om een zakelijke dienst. Belangrijk is om de website te richten naar 2 verschillende doelgroepen, en bij het ontwerp hiermee rekening te houden: Website ontwikkelaars Eindgebruikers


78

De website voor de ontwikkelaars moet reclame maken voor het systeem, samen met de nodige technische informatie en mogelijkheden van het systeem. Gezien er vanuit gegaan mag worden dat de ontwikkelaars informatici zijn die Engels kunnen, mag deze website in het Engels staan. Later kan eventueel gekozen worden om ook dit onderdeel te vertalen naar meerdere talen voor internationalisering. De website voor de eindgebruikers is de site die de mensen zien die van de dienst effectief gebruik maken. Het YouValid systeem is normaal gezien transparant voor de gebruiker. Toch is er een website nodig die bijvoorbeeld extra informatie kan leveren in verband met privacy (bijvoorbeeld het opzoeken welke gegevens in de databank worden bijgehouden) en om eventueel bij problemen extra informatie te vinden. Deze website bevat dus totaal andere informatie dan die voor de ontwikkelaars. Bovendien beschikken vele eindgebruikers niet zomaar over de kennis van meerdere talen, waardoor deze website in meerdere talen moet ontwikkeld worden. Om te starten zal de website enkel in het Nederlands beschikbaar zijn, maar later dus ook in het Engels, Frans, Duits en later ongetwijfeld nog vele andere talen. De pagina’s werden hiervoor ontworpen en ingevuld met de nodige teksten en informatie. Enkele screenshots zijn te zien op foto 4.12.

4.13.5

Scripts en software

Het volledige systeem werd ontwikkeld in PHP als scriptingtaal op een Apache webserver met een MySQL database. De structuur van de tabellen is schematisch voorgesteld in figuur 4.13. Bij de ontwikkeling van het project werd rekening gehouden met het feit dat het gebruikt zou worden door externe websites. Zo werden er voor elk van de onderdelen voorbeeldscripts gemaakt in PHP. Men kan deze in de toekomst downloaden en aanpassen aan de eigen eisen. De PHP code gebruikt geen functies die op een standaard PHP installatie niet beschikbaar zouden zijn. Zo wordt maximale ondersteuning nagestreefd. Om het zo gebruiksvriendelijk mogelijk te maken werden alle functies voor de externe websites gemaakt, en gezorgd voor abstractie zodat alles steeds toegankelijk is door telkens één functie op te roepen met een aantal parameters. Er is gezorgd voor maximale encapsulatie


79

Figuur 4.12: Beelden van website YouValid.com

en eenvoud. Alle verwerking van variabelen, input, output en de SOAP communicatie is verborgen voor de gebruiker. Er werd in de standaard scripts uitgebreide commentaar voorzien in het Engels bij elk van de variabelen zodat het duidelijk is wat elk van de variabelen betekent. Ook wordt er rekening mee gehouden dat er fouten in kunnen staan. Aan de kant van YouValid worden variabelen altijd extra nagezien of ze correct doorgegeven zijn. Op deze manier is het mogelijk om in kwestie van een aantal uur een website aan te passen om te werken met YouValid. Bij wijze van experiment heb ik op slechts één namiddag werk het onderdeel Mailgroepen van SeniorenNet volledig kunnen aanpassen voor Youvalid. Doordat gekozen werd voor SOAP communicatie is het mogelijk om ook websites die geen PHP ondersteunen eenvoudig mee te koppelen aan YouValid. SOAP wordt ondersteund door Java, ASP, C++,... en daardoor is dit het protocol bij uitstek naar elke soort van


80

webserver. Momenteel is enkel PHP beschikbaar. Na de lancering zal er ook gewerkt worden aan een JSP en ASP versie om de ondersteuning nog te maximaliseren.

4.13.6

Demonstratie

Bij de presentatie van de masterproef wordt er een live demonstratie gegeven van de werking van het systeem. De demonstratie zal gebeuren op de YouValid website waarbij de gebruiker zijn privacygegevens kan opvragen. Op deze manier wordt niet enkel het telefoonsysteem gedemonstreerd maar ook de rating getoond. De gebruiker kan zeer eenvoudig zijn privacygegevens opvragen. Dit systeem is identiek gebaseerd op het systeem dat externe websites zouden gebruiken. Voor elk van de onderdelen zijn dezelfde scripts gebruikt en verloopt de communicatie dus ook via het SOAP protocol. De gebruiker surft naar de website en krijgt het telefoonnummer en de code te zien om naar te bellen. Deze codes werden verkregen door een SOAP oproep te doen naar de webservice. De gebruiker kan vervolgens bellen naar het telefoonnummer en activeren. Eenmaal geactiveerd via telefoon zal de website automatisch doorschakelen naar een nieuwe pagina. Er is namelijk een Ajax script in verwerkt dat elke seconde automatisch nagaat of er activatie was, en zo ja, doorschakelt naar de pagina voor detail. Bij de activatie via telefoon wordt door de webservice net zoals bij een andere externe website, een SOAP oproep gedaan naar het privacygedeelte om mee te delen dat er activatie was, en wordt dit zo in de databank bewaard. Vervolgens krijgt de gebruiker op de pagina zijn gegevens te zien: sinds wanneer hij gekend is, hoeveel sites hem geblokkeerd hebben, totale rating en detail rating per misbruikcategorie, welke sites hem wanneer geblokkeerd hebben, datum/uur van elke telefonische activatie, enz. U vindt een screenshot van deze pagina in figuur 4.14. Omdat het ook nuttig is via telefoon te horen wat er precies gezegd wordt, zal de demonstratie niet via een gewone gsm worden gedaan omdat het niet gehoord kan worden. Voor de demonstratie werd voorzien dat er via een VoIP programma over het SIP-protocol (Session Initiation Protocol) met een computer kan gebeld worden op de telefoonlijn. Zo kunnen de luidsprekers van de computer gebruikt worden. Het programma X-Lite werd


81

hiervoor gebruikt (een screenshot is te zien in figuur 4.15). Er dient op gedrukt te worden dat dit uitsluitend voor de demonstratie mogelijk is gemaakt. Gewone gebruikers kunnen NIET via VoIP activeren, gezien dit de authenticatiewaarde zou ondermijnen.

4.13.7

Datacentrum

De nodige technische infrastructuur werd voorzien en ge¨ınstalleerd om het concept in praktijk te brengen. Doordat de masterproef in samenwerking is met SeniorenNet, kon het systeem ge¨ımplementeerd worden op een bestaande server van SeniorenNet. Aangezien er beschikking is over een zeer krachtige server die slechts een fractie van zijn capaciteit benut, zijn er nog voldoende resources over om een ganse tijd te groeien. De server met zijn bijzondere configuratie werd ook mee opgenomen in de bestaande backups zodat er tevens een permanente back-up van de volledige software en databank loopt in een ander datacentrum in Nederland. Een brand, blikseminslag, diefstal, vandalisme, overstroming of hacker kunnen er dus niet de oorzaak van zijn dat alle informatie uit de databanken definitief verloren gaat. Om snelle respons bij problemen te garanderen is er dubbele monitoring op de servers. Enerzijds controleren de servers elkaar. Bij een probleem wordt er automatisch een SMS verstuurd. Anderzijds is er een server in de Verenigde Staten die het geheel op afstand bekijkt. Zo worden problemen met bijvoorbeeld de uplink, DNS of routering ontdekt die lokaal in het datacentrum niet ontdekt zouden worden. Tevens is er een Remote Power Switch waarmee op afstand een server bij problemen kan worden gereset, zodat een plaatselijke interventie in het datacentrum zelf niet nodig waardoor kostbare tijd wordt bespaard. Een rechtstreeks en apart IP-adres met aparte dataverbinding naar de servers maakt het mogelijk dat ook bij een zeer zware DDoS-attack op de servers kan ingelogd worden via een aparte toegang zodat dergelijke aanvallen weggefilterd kunnen worden. Er is tevens een extra monitorserver die continu niets anders doet dan het netwerkverkeer van alle servers te monitoren om DDoS-attacks zo snel mogelijk te ontdekken, weg te filteren indien mogelijk of een SMS te versturen indien het niet geautomatiseerd weggefilterd kan worden. Op foto 4.16 zijn de effectieve servers te zien die staan in het datacentrum InterXion te Zaventem. De rode pijl wijst naar de effectieve webserver waar het systeem op draait. Andere foto’s geven de gang aan waar de servers ge¨ınstalleerd staan in het datacentrum. Rechts


82

zijn twee foto’s van de router en switch, waarbij bovenaan de gele kabel de verbinding is met het datacentrum en de glasvezel.


83

Tabel 4.1: Gsm-code en landcode per land

Land

Landcode

Gsm-code

Australië België China Cyprus Denemarken Duitsland Finland Frankrijk Griekenland Hongarije India Indonesië Italië Japan Luxemburg Mexico Nederland Nieuw-Zeeland Oostenrijk Portugal Rusland Spanje Tsjechische Republiek Turkije Verenigd Koninkrijk Zuid-Afrika Zweden Zwitserland

0061 0032 0086 00357 0045 0049 00358 0033 0030 0036 0091 0062 0039 0081 00352 0052 0031 0064 0043 00351 007 0034 00420 0090 0044 0027 0046 0041

4 4 13 99 40 1 4,50 6 6 20, 30, 70 9 8 3 80,90 6 1 6 2 6 9 9 6 6,7 5 7 7,8 7 7


84

Tabel 4.2: Gewicht voor elke categorie

Categorie Reclame / spam Bedreigingen Illegale plaatsing content Stalking Bewust negatieve reacties Smaad, eerroof van andere mensen Uitgeven voor andere bestaande persoon Vulgair gedrag / taalgebruik Racisme, politieke boodschappen Uitgeven voor een ander geslacht Pornografie / kinderpornografie E-mail adressen verzamelen Hacking,... Ruziemakers Pedofilie

Ernst

Gewicht

GEWICHTEN (afgerond)

3,709103 4,038506 4,339797 4,750989 5,628847 5,701217 5,784951 5,799455 6,524349 6,694209 7,581637 7,927935 8,740152 10,86624 11,91261

1 1,088809159 1,170039507 1,280899782 1,517576393 1,537087801 1,559662985 1,563573329 1,759009917 1,804805289 2,044061921 2,137426429 2,356405708 2,929613803 3,21172297

1,0 1,1 1,2 1,3 1,5 1,5 1,6 1,6 1,8 1,8 2,0 2,1 2,4 2,9 3,2


85

Tabel 4.3: Gemiddeld aantal dagen blokkering per categorie en soort overtreding

Categorie

Soort overtreding

Reclame / spam Vulgair gedrag / taalgebruik Bewust negatieve reacties Ruziemakers Uitgeven voor een ander geslacht Illegale plaatsing content Uitgeven voor andere bestaande persoon Smaad, eerroof van andere mensen Racisme, politieke boodschappen e-mail adressen verzamelen Bedreigingen Uitgeven voor een ander geslacht Stalking Vulgair gedrag / taalgebruik Reclame / spam Hacking,... Bewust negatieve reacties Racisme, politieke boodschappen Uitgeven voor andere bestaande persoon Illegale plaatsing content Ruziemakers Pornografie / kinderpornografie E-mail adressen verzamelen Pedofilie Smaad, eerroof van andere mensen Stalking Bedreigingen Hacking,... Pornografie / kinderpornografie Pedofilie

Lichte Lichte Lichte Lichte Lichte Lichte Lichte Lichte Lichte Lichte Lichte Zware Lichte Zware Zware Lichte Zware Zware Zware Zware Zware Lichte Zware Lichte Zware Zware Zware Zware Zware Zware

Dagen blokkeren 64,3 157,8 168,1 210,3 239,3 284,2 294,3 298,7 309,5 338,2 427,3 468,5 494,8 500,9 540,6 578,6 606,8 620,4 649,2 661,7 707,8 713,0 726,0 759,1 793,1 798,3 809,3 847,0 1.059,3 1.184,1


86

Tabel 4.4: Vermindering rating per week in aantal dagen

Categorie Reclame / spam Bedreigingen Illegale plaatsing content Stalking Bewust negatieve reacties Smaad, eerroof van andere mensen Uitgeven voor andere bestaande persoon Vulgair gedrag / taalgebruik Racisme, politieke boodschappen Uitgeven voor een ander geslacht Pornografie / kinderpornografie e-mail adressen verzamelen Hacking,... Ruziemakers Pedofilie

Totaal blokkeren

Gemiddeld

Verminderen/week

24806 27009 29024 31774 37645 38129 38689 38786 43634 44770 50705 53021 58453 72672 79670

605 658 707 774 918 929 943 946 1064 1091 1236 1293 1425 1772 1943

0,115 0,106 0,098 0,090 0,076 0,075 0,074 0,073 0,065 0,064 0,056 0,054 0,049 0,039 0,036


87

Figuur 4.13: Database structuur


Figuur 4.14: Screenshot demonstratie met weergave privacy gegevens.

88


Figuur 4.15: Screenshot X-Lite VoIP demonstratie

Figuur 4.16: Foto’s datacentrum van servers met YouValid op.

89


Figuur 4.17: Relaties webservice, websites en gebruiker.

90

TOEKOMSTPERSPECTIEVEN EN BESLUIT

91

Hoofdstuk 5 Toekomstperspectieven en besluit 5.1

Toekomst

Het feit dat het systeem bij de opstart onmiddellijk op SeniorenNet en Bloggen.be kan toegepast worden is een enorm pluspunt om het gelanceerd te krijgen. SeniorenNet heeft een maandelijks bereik van meer dan 1,3 miljoen mensen, Bloggen.be 1,5 miljoen. Het project YouValid is momenteel nog niet gestart. Technisch gezien is alles klaar. Er zijn echter andere redenen om te wachten. Er wordt momenteel nagegaan hoe de technologie beschermd kan worden door middel van een patent en/of hoe er kan samengewerkt worden met andere partners om van het systeem een maximaal succes te maken. Zo zijn er reeds contacten geweest met Dries Buytaert van Mollom en Drupal om samen het systeem te commercialiseren. Dries heeft contacten met diverse grote websites die potentieel ge¨ınteresseerd zijn in het systeem. Om deze reden is de website www.YouValid.com niet beschikbaar voor het gewone publiek en werd de integratie in SeniorenNet ook nog niet in praktijk bekend gemaakt aan de bezoekers. Een eerste bescherming werd reeds gemaakt via i-depot. Het volledige concept, architectuur en uitwerking werd gedeponeerd bij het Benelux Bureau voor Intellectuele Eigendom, voor een minimumtermijn van 5 jaar, met een optie voor onbeperkte verlening.

5.2 Toekomstige mogelijkheid: OpenID

5.2

92

Toekomstige mogelijkheid: OpenID

OpenID is een systeem waarbij gebruikers kunnen inloggen op een website met een gebruikersnaam en wachtwoord. Het bijzondere aan dit systeem is echter dat je dezelfde gebruikersnaam en wachtwoord kan gebruiken op alle sites die het systeem ondersteunen. Vandaag de dag zijn dat al duizenden websites wereldwijd. Het combineren van OpenId en YouValid zou een interessant potentieel kunnen bieden. Dit rechtstreeks combineren werd onderzocht en is niet mogelijk. Wat echter wel kan is dat er een aparte service wordt opgezet die OpenID gaat combineren met het YouValid systeem en zo een centrale ID database wordt. Op deze manier zou een gebruiker slechts éénmaal moeten bellen en met die gebruikersnaam vervolgens in duizenden websites binnen kunnen. Zo wordt de drempel nog verder verlaagd en wordt een waardevol ID systeem gecreëerd. Dit systeem maakt gebruik van YouValid en kan onafhankelijk door derden gemaakt worden.

5.3

Extra mogelijkheden: microbetalingen

Het voorgestelde systeem kan in licht gewijzigde vorm ook toepasbaar zijn voor microbetalingen. Wereldwijd is er vraag naar een goed en gebruiksvriendelijk systeem voor het betalen van kleine bedragen via het internet. Momenteel is hiervoor nog niet veel beschikbaar. Betalingen van enkele eurocenten of euro via Visa zijn erg duur. Het systeem van YouValid kan gebruikt worden voor betalingen door gebruik te maken van betaallijnen. Door het integreren van bijvoorbeeld een 0900-lijn kan de gebruiker op deze manier voor een betaling zorgen. Het systeem kan flexibel gemaakt worden door het gebruik van diverse soorten van betaallijnen. Er bestaan 0900, 0901, 0902, 0903, 0904,... lijnen die elk een andere kostprijs hebben voor de gebruiker. Door elk soort telefoonlijn te koppelen aan het systeem is het mogelijk om een ander bedrag te laten betalen.

5.4 Besluit

93

Een beperkt aantal wijzigingen in de architectuur zijn nodig. Zo is er reeds voorzien dat een website bij aanvraag van een activatiecode kan meegeven wat voor soort telefoonlijn zij wenst. Door extra codes in te voeren voor elk soort bedrag kan zo het juiste telefoonnummer teruggegeven worden. Bij activatie krijgt een website de bevestiging. Normaal gezien gaat het dan vooral om de unieke code (hash) van de gebruiker (als authenticatie). Bij betaling echter gaat het dan juist om de ingegeven code door de gebruiker, zodat de website weet dat er betaald werd. Het concept van microbetalingen kan verder onderzocht worden voor verdere uitwerking.

5.4

Besluit

Er is grote vraag naar een oplossing voor identificatie van gebruikers op het internet. De diverse bestaande technieken blijken onvoldoende nauwkeurig te zijn of ze zijn onhaalbaar op wereldschaal. Door verder onderzoek blijkt dat het niet evident is een sluitende oplossing te vinden. Authenticatie met SMS bleek interessant te zijn, maar door SMS spoofing niet bruikbaar. Het voorgestelde concept met gecentraliseerde gsm-identificatie voor authenticatie van gebruikers met communityfeedback bleek heel wat mogelijkheden te bieden. Ze is schaalbaar op wereldschaal en heeft weinig nadelen. Het enige zwakke punt zou kunnen zijn dat gebruikers weigerachtig staan tegenover het bellen naar een computer om zich eenmalig te kunnen activeren op een website. Het combineren van ID en reputatie blijkt diverse voordelen te hebben die websites kunnen gebruiken om de sfeer op de website beter te kunnen bewaken. Het biedt tevens economische voordelen zoals een werklastvermindering voor moderators. Door het gecentraliseerde systeem dient de gebruiker zich weinig zorgen te maken rond privacy. Het centraliseren laat tevens toe het systeem op korte termijn te lanceren zodat vele websites hiervan gebruik kunnen maken. De nieuwe techniek zal nog verder uitgewerkt worden om daadwerkelijk gecommercialiseerd te worden: schrijven van een handleiding, vertalen in verschillende talen, enz. Er wordt momenteel gezocht naar partners, alsook een patentaanvraag zit mogelijk in de pijplijn.

OVERZICHT VAN BEVEILIGINGSMETHODEN

94

Bijlage A Overzicht van beveiligingsmethoden Elk van de 21 onderzochte systemen wordt in deze appendix kort besproken samen met hun voor- en nadelen.

A.1

Cookie

Op de computer van de bezoeker wordt een klein bestandje bewaard via de browser (cookie). Telkens wanneer deze terug komt op de website kan zo herkend worden dat hij geblokkeerd werd waardoor hij geen toegang krijgt. Sterke punten van het systeem zijn dat het zeer eenvoudig is, waardoor de startkosten en ontwikkeltermijn verwaarloosbaar zijn. Bovendien is er geen kost per gebruiker. Zwakke punten aan het systeem zijn dat het wissen of blokkeren van cookies ervoor zorgt dat het systeem omzeild wordt. Dit kan zeer eenvoudig en zonder veel computerkennis gedaan worden. Cookies zijn meestal niet permanent, waardoor een blokkering vaak maar tijdelijk is. Ook zijn ze computerafhankelijk. Indien de persoon vanaf een andere pc inlogt kan hij alsnog binnen. Bovendien is de kans op vals positieve aanwezig. Indien meerdere mensen van dezelfde computer gebruik maken, worden ze allemaal geblokkeerd.

A.2

IP-adres blokkeren

Het IP-adres waarmee de bezoeker op de website komt, wordt door de website geblokkeerd. Bij de eerstvolgende keer dat hij opnieuw wil inloggen op de website, wordt het IP-adres

A.3 E-mail verificatie

95

herkend en niet meer toegelaten. Er zijn vier sterke punten. Ten eerste zijn er amper kosten verbonden aan het ontwikkelen en integreren van het systeem in de website. Ten tweede is er geen kost per gebruiker en ten derde kan het wereldwijd gebruikt worden. Tot slot is het gebruiksvriendelijk voor eindgebruiker aangezien deze het systeem niet ziet. Er zijn drie zwakke punten aan het systeem. Zo is er ten eerste een hoge kans op vals negatieve. Meestal wijzigt het IP-adres van een gebruiker automatisch. Internetabonnementen van de meeste providers zijn dynamische IP-adressen. Hierdoor wordt de juiste persoon niet meer geblokkeerd, terwijl een onschuldige wel geblokkeerd wordt. Het tweede zwakke punt is dus een reële kans op vals positieve. Gezien IP-adressen roteren bij een provider, zal een andere gebruiker hetzelfde IP-adres krijgen en zo mogelijk niet meer binnen geraken. Ten derde is er een lage drempel om de beveiliging te omzeilen. Het IP-adres is te wijzigen door de gebruiker (bvb. kabelmodem of adsl-modem uittrekken en terug insteken). Ook het gebruik van een anonieme proxysever of het gebruiken van het (onbeveiligd) draadloos internet van iemand anders omzeilt de beveiliging.

A.3

E-mail verificatie

Om zeker te zijn dat het e-mail adres dat ingegeven wordt door een bezoeker op de website correct is, wordt e-mail verificatie gebruikt. Bij het registreren stuurt men een e-mail naar het e-mail adres van de gebruiker. Vervolgens dient deze op een link te klikken waarin een unieke code verwerkt zit. Enkel indien het e-mail adres wel degelijk van de gebruiker is, kan er worden geactiveerd. Dit systeem heeft vier sterke punten. Ten eerste zijn er relatief weinig kosten om het systeem te integreren in de website. Ten tweede is het systeem wereldwijd inzetbaar en ten derde zijn er geen kosten per bezoeker op de website. En tot slot is er weinig kans op vals positieve. De kleine kans dat een gebruiker in iemand anders naam zou kunnen activeren, is zeer klein. Er zijn vier zwakke punten aan e-mail verificatie. Het belangrijkste is dat de beveiliging zonder veel moeite kan worden omzeild. Het is relatief eenvoudig voor gebruikers om aan extra e-mail adressen geraken. E-mail diensten als GMail, Hotmail, Yahoo, enz. maken het mogelijk om binnen een minuut een nieuw e-mail adres aan te maken. Er bestaan tevens

A.4 Captcha

96

’wegwerp’ e-mail adressen of eenmalige adressen waarmee je eenmalig enkele e-mails op kan laten toekomen en vervolgens het adres niet meer gebruikt. Een andere mogelijkheid bestaat erin om een eigen domeinnaam te registreren en zo een ’catch all’ e-mail adres te hebben. Hierbij heeft de gebruiker de mogelijkheid om eender wat voor het @-teken staat altijd te laten toekomen, waardoor een persoon bijna een onbeperkte hoeveelheid e-mail adressen kan aanmaken. Providers in binnen- en buitenland zoals Telenet en Skynet maken het mogelijk voor hun gebruikers om via een webinterface op enkele minuten hun e-mail adres te laten wijzigen. Een tweede zwak punt is een lagere gebruiksvriendelijkheid, gezien het feit dat er extra actie wordt gevraagd van de gebruiker. Een vierde nadeel ligt bij privacy en spam. Gebruikers geven niet zo graag hun e-mail adres, zeker niet in het kader van de actuele spamproblematiek. Een laatste nadeel is de kans op vals negatieve waarbij zonder dat de gebruiker bewust het systeem wil omzeilen, toch terug binnen kan geraken. Mensen wijzigen op internet relatief vaak van e-mail adres, waardoor de koppeling met de originele blokkering niet meer gekend is.

A.4

Captcha

De gebruiker dient bij een captcha een code over te typen die hij ziet. Enkele voorbeelden zijn te zien in figuur A.1. De code is vaak met een speciale achtergrond en moeilijk leesbaar. Het systeem gaat geen gewone gebruikers buitenhouden, maar heeft tot doel om geautomatiseerde registraties tegen te gaan. Captcha is de afkorting van ’Completely Automated Public Turingtest to tell Computers and Humans Apart’.

Figuur A.1: Enkele captcha voorbeelden.

A.5 Elektronische identiteitskaart

97

Het sterke punt voor het systeem is dat automatische registraties zeer moeilijk zijn, vermits er voor elke registratie steeds door een gebruiker de code overgetypt moet worden. Zwak punt is echter dat het systeem enkel geautomatiseerde registraties voorkomt. Een gewone gebruiker die de code overtypt kan wel altijd terug binnen. Het systeem is hiermee eerder geschikt voor het tegenhouden van spambots en minder voor lastige gebruikers.

A.5

Elektronische identiteitskaart

Iedere Belg heeft een elektronische identiteitskaart, ook eID genoemd. Op deze kaart staan zijn persoonsgegevens, foto en een elektronische handtekening. Met deze kaart en een kaartlezer kan de informatie van de identiteitskaart via internet doorgegeven worden en kunnen elektronische handtekeningen geplaatst worden. Sterke punten van de elektronische identiteitskaart zijn dat iedereen exact 1 kaart heeft. Meerdere identiteitskaarten verkrijgen is relatief moeilijk. Een tweede sterk punt is dat het systeem moeilijk te kraken is, of minstens een zeer grote technische kennis vereist. Zowel voor de website als voor de gebruiker is er geen kost verbonden aan het gebruik van de identiteitskaart. Een laatste sterk punt is dat de kans op zowel vals negatieve als vals positieve in principe nihil is. Er zijn vijf zwakke punten. Ten eerste is het systeem niet wereldwijd en wordt het momenteel enkel in België gebruikt. De kans dat het systeem op korte termijn zou doorbreken op wereldschaal is gering. Bepaalde landen zoals de Verenigde Staten zijn gekant tegen het systeem van een identiteitskaart voor iedere burger. Ten tweede gebruiken op dit moment nog erg weinig Belgen de kaart en hebben weinige een kaartlezer. Een derde nadeel is privacy. Mensen geven zeer uitgebreide identiteitsgegevens vrij zoals naam, adres, geslacht, geboortedatum, geboorteplaats, rijksregisternummer en foto. Het is twijfelachtig of mensen op grote schaal dergelijke gegevens willen geven aan websites. Een vierde nadeel is dat het ontwikkelen en integreren van een dergelijk systeem de nodige inspanningen vraagt. Een laatste nadeel sluit hier ook bij aan. De kans is klein dat er eenvormigheid zou zijn indien wereldwijd een elektronische identiteitskaart zou bestaan. Elk land gaat waarschijnlijk zijn eigen accenten leggen, waardoor software voor elk land apart moet voorzien worden met een lange ontwikkeltermijn en startkosten als gevolg.

A.6 Registratie per post

A.6

98

Registratie per post

Een brief(kaart) wordt opgestuurd via de reguliere post naar de gebruiker. Deze brief bevat een pincode die men dient in te geven op de website. Zo is men zeker dat het postadres van de gebruiker echt is. Het systeem wordt o.a. door Google Adsense gebruikt [3]. Voordeel van dit systeem is dat het wereldwijd inzetbaar is en men de zekerheid heeft dat het postadres juist is. Er zijn echter vijf zwakke punten. Vooreerst is er een effectieve kost voor de website per gebruiker die zich op de website wenst te registreren: postzegel, afdrukken brief en de handling. Ten tweede is het relatief traag. Het opsturen per post kan internationaal gaan van enkele dagen tot weken. Hierbij kunnen er twee keuzes gemaakt worden: ofwel laat je intussen de gebruiker binnen, maar dan kunnen gebruikers het wekenlang rekken om vervelend te doen op de website, ofwel laat je gebruikers slechts binnen na activatie, maar dan is er een enorme ongebruiksvriendelijkheid: gebruikers moeten dagen tot weken wachten alvorens ze binnen kunnen op de website. Ten derde dienen de gebruikers hun thuisadres op te geven, wat hen mogelijk het gevoel geeft van inbreuk op hun privacy. Ten vierde kan een gebruiker relatief eenvoudig meerdere codes verkrijgen, ook al heeft hij hetzelfde thuisadres. Hij kan zijn thuisadres telkens lichtjes anders schrijven. De post zal nog steeds de brieven afleveren, maar voor een computer lijkt het een ander adres. Bijvoorbeeld: ’Kerkstraat 10, 2000 Antwerpen’, ’Kerkenstraat 1 0, 2000 Antwerpen’, ’10, Kerkstraat, 2000 Antwerpen-Centrum’ lijken telkens anders maar zullen allemaal toekomen. Tot slot zijn vals positieve een reëel risico bij appartementsblokken. Een adres blokkeren kan onmiddellijk tientallen mensen tegenhouden. Dit toch toelaten zorgt voor diverse fraude mogelijkheden. Iemand die helemaal niet in een appartement woont zou telkens een nieuwe aanvraag kunnen doen: eentje voor bus 1, voor bus 2, bus 3,... terwijl er maar 1 huis staat.

A.7

Rijksregisternummer

Men dient zijn eigen rijksregisternummer in te geven. Dit nummer dient als unieke identificatie van een persoon. Men gaat ervan uit dat iedereen maar 1 rijksregisternummer heeft en zo moeilijk het systeem kan omzeilen. SIS-kaartnummer, Kruispuntbanknummer en paspoortnummer zijn vergelijkbare systemen met dezelfde sterke en zwakke punten. Sterke punten zijn dat een rijksregisternummer uniek is en iedereen zo’n nummer heeft.

A.8 Rekeningnummer

99

Aan de andere kant zijn er aan dit systeem vijf nadelen verbonden. Ten eerste is het niet wereldwijd inzetbaar. In België telt een rijksregisternummer 11 cijfers, in Nederland heeft een Sofi-nummer of burgerservicenummer 9 cijfers, in de Verenigde Staten telt een Social Security Number (SSN) 9 cijfers en in China heeft het RPC 18 cijfers. Ten tweede ligt de gebruiksvriendelijkheid lager omdat de meeste mensen dit getal niet uit het hoofd kennen en dienen op te zoeken. Een derde zwak punt is de privacy. In bepaalde landen zoals de Verenigde Staten is dit nummer zeer gevoelig voor bijvoorbeeld identificatiediefstal. Een vierde zwak punt ligt in de wetgeving. In België is het niet zomaar toegelaten het rijksregisternummer te bewaren. In de wet staat ’Het identificatienummer van het Rijksregister mag niet worden gebruikt zonder machtiging of voor andere doeleinden dan waarvoor die machtiging is verleend’ [8]. De procedure om een machtiging te bekomen is minder eenvoudig te bekomen en kan de nodige tijd in beslag nemen [9]. Een laatste nadeel is dat het relatief eenvoudig is om zelf zo’n nummer te genereren. Zo bestaat het Belgische rijksregisternummer uit volgende gegevens [4]: de eerste 6 cijfers staan voor de geboortedatum in het formaat JJMMDD. Vervolgens 3 cijfers die de dagteller is van de geboortes, waarbij oneven mannen zijn en even vrouwen. De laatste twee cijfers vormen de check digit. Dit getal is het complement van 97 van modulo 97 van het getal. Bijvoorbeeld stel RN = 72020290081. Deze 81 wordt bekomen door 97 - (modulo 97 van 720202900) = 97 - 16 = 81. Voor een Nederlands Burgerservicenummer is dezelfde informatie terug te vinden [5] [6] [7]. Het is een getal dat bestaat uit 9 cijfers. De controle of het een correct nummer is wordt gedaan via de 11 regel. Stel dat het nummer ABCDEFGHI zou zijn, dan dient 9*A + 8*B + 7*C + 6*D + 5*E + 4*F + 3*G + 2*H + (-1*I) een veelvoud van 11 te zijn. Het nummer bevat geen enkele betekenis zoals bij het Belgische wel het geval is. Er zijn 1 miljard / 11 = ca. 90 miljoen geldige nummers te genereren.

A.8

Rekeningnummer

Identificatie van de gebruiker gebeurt door middel van zijn rekeningnummer. De gebruiker wordt gevraagd dit nummer in te geven. Gezien elk rekeningnummer uniek is kan men op deze manier een persoon uniek identificeren. Een eerste zwak punt is dat het systeem moeilijker wereldwijd inzetbaar is. Het rekeningnummer is sterk verschillend per land. Een tweede punt is dat mensen dit omwille van privacy ook niet zo graag willen geven. Een derde zwak punt is dat de gebruiksvriendelijk-

A.9 Overschrijving

100

heid lager ligt doordat niet verwacht kan worden dat elke gebruiker zijn rekeningnummer uit het hoofd kent en dus specifiek dient op te zoeken. Een vierde zwak punt is dat men relatief eenvoudig een vals nummer maken doordat men de opbouw van het nummer kan achterhalen. Voor België is het rekeningnummer in de vorm van ###-#######-## waarbij de eerste 3 cijfers het protocolnummer vormen dat afhankelijk is van de bank. Een lijst is te vinden in [10]. De middelste 5 cijfers zijn uniek bij elke bank. De laatste twee cijfers zijn het controlegetal dat gevormd wordt door de eerste 10 cijfers te delen door 97. In Nederland telt het rekeningnummer negen of tien cijfers, waarbij het laatste getal wordt gevormd door de 11-proef (9*A + 8*B+ 7*C + ... delen door 11 = laatste getal). Voor Europa is er een gestandaardiseerd IBAN nummer. Het IBAN nummer heeft een variabele lengte (max 34 tekens) dat als volgt wordt opgebouwd: landcode (2) + controlegetal (2) + rekeningnummer (max 30). Het controlegetal wordt verkregen door de rekeningidentificatie te nemen, er de landcode achter te plaatsen, alle letters te vervangen door hun positie in het Romeinse alfabet, vermeerderd met 9 (A=10, B=11...Z=35). Vervolgens worden twee nullen aan het einde toegevoegd en wordt de rest genomen van de deling van het zo bekomen getal door 97. Deze rest wordt afgetrokken van 98, welke het controlegetal als resultaat geeft [11]. Op het internet circuleren tevens scriptjes om het controlegetal te berekenen. Het IBAN nummer wordt gebruikt in 45 landen waarbij in elk land de structuur anders is.

A.9

Overschrijving

De gebruiker geeft zijn rekeningnummer op en krijgt een bedrag overgeschreven met eventueel een mededeling. Eenmaal ontvangen dient de gebruiker op de website het ontvangen bedrag en/of de mededeling in te typen. Dit dient dan als soort van pincode, zodat de website dan zeker weet dat het rekeningnummer correct is. Zwakke punten zijn dat er een kost per gebruiker is voor de website. Een tweede punt is de snelheid. Internationale overschrijvingen duren vaak meerdere dagen, naar sommige landen zelfs weken. Er dient ook gedacht te worden aan de privacy en gebruiksvriendelijkheid. Gebruikers kennen hun rekeningnummer vaak niet uit het hoofd en moeten bovendien iets erg persoonlijks meedelen aan een website. Nog een zwak punt is dat het voor een gebruiker mogelijk is om meerdere codes te ontvangen. Mensen hebben vaak een rekening bij meer dan één bank, of meerdere nummers bij dezelfde bank. Ook het bewust aanvragen van meerdere spaarrekeningen bij eenzelfde bank is mogelijk en vaak zonder kosten.

A.10 Verificatie creditcard

A.10

101

Verificatie creditcard

De persoon dient bij dit systeem zijn kredietkaartnummer in te geven dat vervolgens wordt geverifieerd. Er zijn twee mogelijkheden. Ofwel wordt er daadwerkelijk een bedrag afgehouden van de kredietkaart (bvb. 1 eurocent), ofwel wordt enkel het nummer nagekeken zonder een effectieve transactie uit te voeren. Er zijn twee sterke punten. De drempel om de beveiliging te omzeilen is hoog. Mensen hebben soms wel meer dan één kredietkaart, maar gezien het om kredieten gaat, krijgt men er vaak niet veel. Een tweede sterk punt is dat het systeem potentieel geld kan opbrengen. Er kan in plaats van 1 eurocent bvb. 1 euro gevraagd worden. Er zijn vijf zwakke punten. Een eerste is de gebruiksvriendelijkheid. Gebruikers moeten de kredietkaart nemen, het nummer ingeven, vaak ook nog een verificatiecode en mogelijk ook nog een digitale handtekening plaatsen door middel van een kaartlezer/digipass. Een tweede nadeel is privacy en veiligheid. Kredietkaartnummers kunnen eenvoudig misbruikt worden voor fraude. Een derde nadeel is dat er aan elke transactie met een kredietkaart een kostprijs verbonden is. Bij het Belgische Ogone schommelt de kost per transactie van 0,2 tot 0,86 euro, bovenop een maandelijks abonnement dat 30 tot 200 euro kost en een opstartkost van 300 euro [12]. Een vierde nadeel is dat niet iedereen Visa, Mastercard of een andere kredietkaart heeft, waardoor een deel van de potentiële bezoekers uitgesloten wordt. Een laatste nadeel is dat de website uit veiligheidsoverwegingen slechts een deel van het kredietkaartnummer krijgt indien men gebruik maakt van diensten zoals Ogone, waardoor unieke identificatie moeilijk wordt.

A.11

Unieke karakteristieken computer

Op de computer wordt een programma geplaatst dat voor unieke identificatie kan zorgen. Dit zou bvb. in een virusscanner kunnen gebeuren. Door middel van unieke karakteristieken van de computer gaat men deze computer identificeren. Dit kan door bvb. de Windows licentie te gebruiken als unieke sleutel. Al rijst dan de vraag wat te doen met Linux en Apple gebruikers. Men denkt erover na om ook piraterijfilters te integreren in virusscanners zodat gebruikers moeilijker illegale content kunnen downloaden [13] [14]. In Skype werd dit al geprobeerd om gebruikers te identificeren [15] [16]. Dit lokte echter heel wat commotie uit rond privacy en het werkte ook niet op 64-bit machines.

A.12 Biometrische gegevens

102

Deze werkwijze leidt tot een zestal zwakke punten. Ten eerste is het weinig waarschijnlijk dat gebruikers dergelijke software op hun computer willen. Ten tweede zal er vermoedelijk een langere termijn overgaan voordat dergelijke software op wereldschaal zou doorbreken. Ten derde rijst de vraag wie dergelijke software zou maken, deze beheren en wat de eventuele kosten zouden zijn voor de website. Indien iedere website apart deze software zou maken zou de computer vol geraken met kleine programmaatjes, met bovendien een sterk verhoogd risico op virusverspreiding door slechte websites. Ten vierde stelt zich het privacy probleem. De software zal rechtstreeks contact maken met de website, en kan zo diverse gegevens (gecodeerd) doorsturen over de gebruiker. De verleiding is dan groot om ook gegevens commercieel te benutten. Een vijfde nadeel is dat de gebruiker van een andere computer wel terug toegang kan krijgen. Tot slot valt ook dit systeem te faken. De software maakt gebruik van bepaalde karakteristieken van de computer die kunnen worden gewijzigd. Zo kan het MAC-adres (Medium Access Control Address) van de netwerkkaart worden aangepast [17] [18]. De CPU-id is niet altijd in te lezen en ook niet altijd uniek [19]. Ook andere gegevens zoals de id-nummers van een harde schijf vallen aan te passen. Bovendien hebben tegenwoordig veel gebruikers meer dan één harde schijf.

A.12

Biometrische gegevens

Het gebruiken van biometrische gegevens zoals vingerafdrukken voor unieke identificatie van een persoon. Sterke punten zijn dat biometrische gegevens uniek zijn voor elke persoon en dat een dergelijk systeem wereldwijd ingezet kan worden. Vijf zwakke punten zijn aan dit systeem verbonden. Ten eerste heeft slechts een beperkt aantal mensen momenteel thuis een vingerafdruklezer. Een tweede nadeel betreft de privacy. De vraag is of mensen wel bereid zijn om hun vingerafdrukken te geven om te kunnen registreren op een website. Het bewaren en verwerken van vingerafdrukken kan ook privacyvragen oproepen. Een derde nadeel is dat de blokkering omzeilen mogelijk blijft. Mensen hebben 10 vingers en kunnen 10 keer opnieuw een andere afdruk genereren. Het is tevens mogelijk om bewust je vingerafdruk te wijzigen door een oneffenheid of ’beschadiging’ op de vinger aan te brengen. Een vierde nadeel zijn de kosten voor de website voor het maken en onderhouden van de software en database voor het verwerken van de vingerafdrukken. Tot slot is met de huidige technologie de gebruiksvriendelijkheid nog niet maximaal. Om een hoge zekerheid te hebben van de vingerafdruk is het vaak nodig om meerdere keren opnieuw de vingerafdruk te nemen.

A.13 Dongle / kaartlezer

A.13

103

Dongle / kaartlezer

Een dongle, hardwaresleutel of kaartlezer kan gebruikt worden om de gebruiker uniek te identificeren. Iedere gebruiker heeft dan zijn eigen sleutel. Dit systeem wordt momenteel veelvuldig door banken gebruikt om de toegang te beveiligen voor online banking. De sterke punten van het systeem zijn dat de blokkering moeilijk te omzeilen valt. De kans op vals negatieve en vals positieve is tevens zeer klein en het systeem valt wereldwijd in te zetten. Er zijn drie nadelen aan verbonden. Een eerste heeft betrekking op de gebruiksvriendelijkheid. Een gebruiker dient een speciale code over te typen. Een tweede nadeel is het financiële aspect. Er is een kost voor de website voor elke gebruiker: namelijk de kostprijs van het toestel, de verzendingskosten naar de gebuiker en bovendien gaat zo’n kaartlezer slechts een beperkte tijd mee (batterijen). Een derde nadeel zijn de relatief dure opstartkosten om het geheel te integreren in de website.

A.14

MAC-adres

Elke netwerkkaart heeft een eigen uniek nummer, het MAC-adres genoemd. Dit adres zou gebruikt kunnen worden om een persoon te identificeren. Dit adres blijft in de loop van de tijd wel hetzelfde, in tegenstelling tot het IP-adres dat wijzigt. Er zijn vijf voordelen aan dit systeem. Zo is er ten eerste een kleine kans op vals positieve omdat een MAC-adres relatief uniek is. Ten tweede is er een kleine kans op vals negatieve. Het adres wijzigt niet spontaan waardoor de kans dat een gebruiker terug binnenkan zonder dit bewust te hebben gedaan relatief klein is. Een derde voordeel is dat de kost voor het integreren in de website laag is. Een vierde voordeel is dat er geen kosten voor de gebruiker zijn. Een laatste voordeel is de gebruiksvriendelijkheid. De gebruiker merkt niets van dit systeem. Er zijn drie zwakke punten aan het systeem van MAC-adres. Ten eerste wordt het MACadres momenteel niet meegestuurd via het TCP/IP-protocol. Het blijft enkel op de MAClaag en wordt tegengehouden op hogere lagen. De kans dat wereldwijd het protocol zal aangepast worden is klein. Ten tweede is het MAC-adres computerafhankelijk. Een gebruiker die op een andere computer werkt kan wel terug binnen. Tot slot is het MAC-adres te wijzigen via software of in het register van Windows.

A.15 Unieke machinecode

A.15

104

Unieke machinecode

Bij dit systeem zou elke computer een unieke code hebben. Deze code is fysiek toegevoegd in de computer met doel een unieke code te zijn die niet kan vervalst worden. Sony heeft dit ingevoerd in de Playstation 3 [20]. Sony gebruikt dit om gebruikers die misbruik maken van het online gamen definitief te blokkeren [21]. Enige oplossing voor een geblokkeerde persoon is een nieuwe Playstation te kopen. Sterke punten van het systeem zijn dat het moeilijk is om de blokkering te omzeilen. Een nieuwe computer kopen is de oplossing. Een tweede sterk punt is dat er geen kost per gebruiker is. Het systeem zou toegankelijk zijn voor iedere website. Een derde sterk punt is dat de gebruiksvriendelijkheid hoog blijft doordat de gebruiker geen weet heeft van het systeem. Er zijn twee zwakke punten. Ten eerste dient elke computer van dit nieuwe systeem voorzien te zijn. Er dient rekening mee gehouden te worden dat er heel wat tijd kan overgaan vooraleer elke fabrikant dit op wereldschaal zou integreren. Tevens neemt het een periode van meerdere jaren in beslag voordat een voldoende groot deel van de gebruikers zo’n nieuwe pc heeft. De identificatie gebeurt op PC-niveau. Dit heeft als gevolg dat indien gebruikers meerdere computers bezitten of wanneer ze gebruik maken van een pc op hun bedrijf of openbare pc, ze tòch toegang zouden krijgen, terwijl een andere gebruiker op een geblokkeerde pc geen toegang meer krijgt.

A.16

SMS toesturen

Bij het registreren en/of inloggen moet de gebruiker zijn gsm-nummer opgeven, waarna hij een SMS ontvangt met vermelding van een code. Deze code gebruikt men om zichzelf te activeren. Een aantal Aziatische banken gebruiken dit systeem [22]. Er zijn drie sterke punten aan dit sms-systeem. Ten eerste weet de website zeker dat het gsm-nummer correct is, en kan ze de persoon uniek identificeren. Ten tweede is het moeilijk om de blokkering te omzeilen. Enkel een nieuw gsm-nummer kopen kan het systeem omzeilen. Tot slot kan er gebruik gemaakt worden van een verkort SMS nummer (zoals 4040), waardoor kosten aan de gebruiker kunnen doorgerekend worden, met commerciële voordelen voor de website.

A.17 Java(script) op website

105

Vijf zwakke punten komen naar voor. Ten eerste is er een kostprijs per gebruiker. Voor een groot aantal gebruikers is dit systeem financieel zwaar, zeker indien het om internationale gebruikers gaat. Ten tweede is er een kost voor het integreren van het systeem in de website. Het koppelen van de website met een sms systeem vraagt de nodige technische kennis en infrastructuur. Ten derde dienen gebruikers hun eigen gsm-nummer op te geven wat vragen rond privacy kan oproepen. Ten vierde zou het systeem kunnen misbruikt worden. Mensen met slechte bedoelingen zouden aan het systeem grote aantallen aanvragen kunnen sturen voor een code naar telkens een ander gsm-nummer. Hierdoor worden grote aantallen sms’en verstuurd, met de nodige financiële gevolgen voor de website. Tot slot rijzen er vragen omtrent de betrouwbaarheid [23]. SMS-berichten kunnen verloren gaan en met een bepaalde vertraging aankomen. Ook is het mogelijke een man-in-the-middle aanval uit te voeren op dit systeem. Op zo’n 100.000 verstuurde codes gaan er 5.300 verloren [24].

A.17

Java(script) op website

Een JavaScript of Java applet wordt op de website pagina geplaatst waar de gebruiker zich moet inloggen of registreren. Dit script of applet gaat vervolgens een aantal computergegevens achterhalen om een gebruiker te identificeren. Het gaat gebruik maken van gegevens die beschikbaar zijn zoals welke plugins ge¨ınstalleerd zijn, browser versie,... Sterke punten zijn vooral de gebruiksvriendelijkheid en de wereldwijde inzetbaarheid. Er is tevens geen kost per gebruiker en het is relatief eenvoudig om een dergelijk programma te maken en integreren in een website. Er zijn een 5-tal zwakke punten te identificeren. Ten eerste kan er onvoldoende informatie verzameld worden om een absoluut unieke identificatie te verkrijgen. Dit heeft als gevolg dat vals positieve en vals negatieve mogelijk zijn. Ten tweede ondersteunt niet elke computer Java applets. Er dient onder bepaalde browsers ook een een veiligheidsbooschap bevestigd worden alvorens deze mag uitgevoerd worden. Ten derde is het omzeilen van de beveiliging niet onmogelijk. Het wijzigen van een aantal parameters dat het script/applet gebruikt zou een andere identificatie geven. Bijvoorbeeld het installeren van een extra plugin of een update van de browser. Een vierde zwak punt is de privacy. Er worden gegevens van de persoon z’n computer gebruikt om deze te identificeren. Tot slot wordt enkel de computer ge¨ıdentificeerd. Als de gebruiker op een andere computer werkt zal hij niet herkend worden.

A.18 Externe service

A.18

106

Externe service

Iedere persoon moet identificatiegegevens toesturen (bvb. geboortebewijs) naar een externe en centrale service. Na controle krijgt men een speciale code toegestuurd die men vervolgens kan gebruiken op een website. Elke website schrijft zich dus in bij de centrale dienst. Een gebruiker moet zich maar eenmalig registreren bij de centrale service en kan dan altijd dezelfde code hergebruiken. Momenteel is dit systeem nog niet in de praktijk, enkel een patent (11/638,226; 13 Dec 2006). Sterke punten zijn dat het moeilijk is om de beveiliging te omzeilen, op voorwaarde dat er een goede controle van het identificatiebewijs wordt gedaan bij de centrale service. Tweede sterk punt is ook dat er slechts een kleine kans is op vals negatieve en vals positieve. Vier nadelen zijn aan het systeem verbonden. Een eerste betreft de privacy. Mensen dienen hun identificatiegegevens op te sturen met onder andere hun naam en adres op. Een tweede nadeel is de gebruiksvriendelijkheid en snelheid. Gezien de procedure via de post verloopt kan het enige tijd duren alvorens men zijn unieke code krijgt. Ten derde is misbruik niet uit te sluiten. Als men de code van een gebruiker kent, kan men zijn nummer gaan misbruiken op websites en zich zo valselijk voordoen voor iemand anders. Gezien het een tekstuele code is, kan deze herhaald worden door anderen en zo misbruikt worden. Tot slot is ook de wereldwijze inzetbaarheid wel mogelijk, maar ingewikkeld. Elk land heeft andere identificatiegegevens. Om betrouwbaar identificatie te kunnen doen en vervalsingen na te gaan vraagt dit de nodige kennis en infrastructuur.

A.19

Centrale database e-mail adressen

Een centrale databank waar mensen (verplicht) hun e-mailadres(sen) moeten opgeven en registreren. Websites kunnen dan nagaan of een opgegeven e-mail adres tot dezelfde persoon behoort of niet. In de Verenigde Staten werkt men aan een dergelijk systeem voor veroordeelden van zedenfeiten [25]. Zij dienen hun e-mailadres(sen) op te geven. Websites die met kinderen en jongeren werken moeten vervolgens bij elke registratie nagaan of het opgegeven e-mail adres niet in deze databank voorkomt. Als sterk punt komt naar voor dat de kans op vals positieve zeer gering is. Indien registratie van e-mail adressen nagezien wordt, is de kans gering dat de verkeerde persoon geblokkeerd

A.20 Remote fingerprinting

107

wordt. Nog een sterk punt is de gebruiksvriendelijkheid gezien alles verloopt buiten het zicht van de gebruiker (op de eenmalige registratie na bij de centrale database). Tot slot is er geen kost verbonden voor de gebruiker noch voor de website. Een zwak punt is dat er wereldwijde wetgeving nodig is om mensen te verplichten hun email adres(sen) op te geven. Tevens kan de beveiliging relatief eenvoudig omzeild worden. De kans is vrij groot dat mensen geen extra e-mail adres hebben dat ze niet registreren hebben.

A.20

Remote fingerprinting

Men gaat een soort van ’vingerafdruk’ maken van de computer om deze te herkennen. Dit kan gebeuren zonder dat de gebruiker dit weet. Het kan op basis van bijvoorbeeld de open netwerkpoorten, besturingssysteem detectie, service analyse,... Op basis van deze vingerafdruk kan herkend worden of het om dezelfde gebruiker gaat [26]. Voordelen zijn de wereldwijde inzetbaarheid en de gebruiksvriendelijkheid. Tevens zijn er weinig tot geen kosten per gebruiker. Al dient rekening gehouden te worden met het feit dat er aparte servers dienen ingezet te worden die continu de analyse maken van de gebruikers. Er zijn vijf nadelen te identificeren aan remote fingerprinting. Ten eerste is het niet gegarandeerd 100% uniek. Zolang er geen interactie is met de gebruiker is het niet mogelijk om een 100% unieke vingerafdruk te maken. Hierdoor zijn vals positieve en vals negatieve niet uit te sluiten. Ten tweede werkt het systeem niet altijd, bvb. bij firewalls. Ten derde is er het snelheidsaspect. Er gaat tijd over voordat het systeem voldoende informatie verzameld heeft om een vingerafdruk te maken. Ten vierde is de beveiliging vermoedelijk te omzeilen indien men weet dat dit soort technieken gebruikt wordt. Men kan bvb. de open poorten bewust gaan wijzigen en zo de vingerafdruk wijzigen. Tot slot dient rekening gehouden worden met privacywetten.

A.21

Auteursidentificatie

Op basis van schrijfstijl gaat een gebruiker ge¨ıdentificeerd [27] worden . Dit kan gebeuren door zeer diverse methoden. Het beste is om meerdere methodes te combineren. Een

A.21 Auteursidentificatie

108

eerste mogelijkheid is het hoofdlettergebruik, spatiegebruik, enz. te analyseren. Dit kan gecombineerd worden met statistische methodes, factor analyse, neurale netwerken (multilayer perceptron), een Na¨ıve Bayes classifier, histogrammen van woordlengtes, Radial basis function, Markov keten (kans opeenvolgende letters), Support Vector Machines, en het Exponentiated Gradient algorithm. Een schema van het systeem [27] staat afgebeeld in figuur A.2.

Figuur A.2: Schema auteursidentificatie.

Het herkennen van berichten gaat in 2 grote stappen. Enerzijds het volledige model opbouwen, anderzijds het herkennen en toewijzen van alleenstaande berichten aan een auteur. Het opbouwen van het model gaat in 4 stappen. In de eerste stap worden de berichten van verschillende auteurs samen genomen waarbij we weten welk bericht van welke auteur komt. In en volgende stap worden een aantal kenmerken gehaald uit de berichten, om vervolgens


109

in de derde stap het effectieve model te genereren. Hier wordt een training uitgevoerd en een auteur identificatiemodel opgebouwd. In de laatste stap worden de testberichten aan het model onderworpen en getest of zij de juiste auteur weergeven. Het herkennen van berichten achteraf wordt gedaan door in eerste instantie de verschillende features eruit te halen. Deze features worden vervolgens door het auteur identificatiemodel gebruikt om het bericht toe te wijzen aan een specifieke auteur. Sterke punten zijn de wereldwijde inzetbaarheid en gebruiksvriendelijkheid. De gebruiker weet niets van het systeem en hierdoor zijn er ook geen privacyproblemen. Er zijn 11 zwakke punten aan dit systeem te identificeren. Ten eerste zijn er belangrijke kosten om het systeem te ontwikkelen en te integreren in de website, met tevens nood aan de nodige technische kennis. Ten tweede is er een niet verwaarloosbare hoeveelheid rekenkracht nodig voor de analyse die niet realtime uit te voeren is. Hierdoor zijn er kosten verbonden per gebruiker aan rekenkracht en hardware. Ten derde dient men er rekening mee te houden dat mensen die kwaad zijn anders beginnen te schrijven: Bijvoorbeeld meer hoofdletters, scheldwoorden, enz. Ten vierde is de schrijfstijl van iemand niet altijd dezelfde over een langere tijd [28] bekeken. Een vijfde nadeel is dat mensen op een andere manier schrijven rond diverse onderwerpen. Zo schrijft men op een andere manier als het om grapjes gaat, dan op een forumrubriek rond een wetenschappelijk onderwerp. Bovendien is er een beperkte betrouwbaarheid van de identificatie. Met 10 berichten en 5 auteurs is er 83% betrouwbaarheid. Indien het om 20 auteurs gaat zakt de betrouwbaarheid naar 70% met een grote kans op vals negatieven en vals positieven. De betrouwbaarheid blijft zakken naarmate het aantal gebruikers stijgt, waardoor het nut voor websites met honderdduizenden gebruikers mogelijk onvoldoende is. Ten zesde valt het systeem te omzeilen indien men weet dat zijn schrijfstijl geanalyseerd wordt. Mensen kunnen bewust hun hoofdlettergebruik of woordgebruik gaan aanpassen. Een ander nadeel is dat er relatief veel berichten nodig zijn voor analyse. Bij 10 berichten en 20 auteurs is de nauwkeurigheid 70%, bij 30 berichten wordt dit 82%. Bij 5 auteurs en 30 berichten per auteur stijgt de nauwkeurigheid tot 95%. Een grafische voorstelling is te zien op de figuur A.3 [27]. Een achtste nadeel is dat er ideaal 300 berichten nodig zijn van één gebruiker. Een gebruiker dient hierdoor reeds langere tijd op een website actief te zijn voordat dit aantal bereikt wordt. Indien een gebruiker al 10 tot 30 berichten kan plaatsen op een website alvorens herkend te worden als slechte gebruiker, heeft deze intussen reeds schade kunnen veroorzaken. Een extra nadeel is dat online berichten vaak te kort zijn. De meeste algoritmen hebben in ideale omstandigheden meer dan 500 woorden/bericht nodig.


110

Een bijkomend nadeel is dat algoritmen taalafhankelijk zijn. Er bestaan diverse algoritmen voor de Engelse taal. Voor het Nederlands of andere talen is vaak nog extra onderzoek en ontwikkeling nodig voordat er gebruik van kan gemaakt worden. Tot slot dienen de meeste algoritmen op voorhand het aantal personen te weten alvorens ze gaan doorgeven welk bericht van welke persoon komt. Op internet weet je het aantal personen meestal niet; mensen hebben zich mogelijk meerdere keren geregistreerd. Gevolg is dat algoritmen niet ideaal werken.

Figuur A.3: Nauwkeurigheid voor verschillende aantallen van auteurs en berichten.

BIBLIOGRAFIE

111

Bibliografie [1] Msn.nl sluit chatboxen. msnnl-sluit-chatboxen, 2003.

http://www.adformatie.nl/nieuws/bericht/

[2] Microsoft sluit chatdienst msn-portaal. http://www.computable.nl/artikel/ nieuws/248881/250449/microsoft-sluit-chatdienst-msnportaal.html, 2003. [3] Google adsense-pincodeproces. https://www.google.com/adsense/support/bin/ answer.py?hl=nl\&answer=35870. [4] Hoe zit de structuur van een rijksregisternummer in elkaar? http://www.ksz.fgov. be/nl/faq/faq_5.htm. [5] Veelgestelde vragen burgerservicenummer. http://www.burgerservicenummer.nl/ Veelgestelde_vragen. [6] Advies wetsvoorstel algemene bepalingen burgerservicenummer. cbpweb.nl/documenten/adv_z2004-1734.shtml, 2005. [7] Wikipedia, burgerservicenummer. Burgerservicenummer. [8] Gegevensstromen rijksregister context. fluxdonnees/fluxdonnees_3.htm, 2009.

http://www.

http://nl.wikipedia.org/wiki/

http://www.ksz-bcss.fgov.be/Nl/

[9] Aanvraag voor het gebruik van het rijksregisternummer. http://www. privacycommission.be/nl/sectoral_committees/national_register/ competences/use-RR.html, 2009. [10] Nationale Bank van België. Lijst van de kredietinstellingen die aan de nationale bank een betalingswaarborg verleenden. http://www.bnb.be/pub/03_00_00_00_00/03_ 05_00_00_00/03_05_02%_00_00/03_05_02_01_00.htm?t=ho\&l=nl.

BIBLIOGRAFIE

112

[11] Iban registry. http://www.swift.com/57387/bic_downloads_documents/pdfs/ IBAN_Registry.pdf, 2009. [12] Ogone abonnementen en prijzen. Prijzen.254.0.html, 2009.

http://astroportal.internetkassa.com/

[13] Riaa wil piraterijfilters bij de eindgebruiker. http://www.disweb.nl/nieuws/ 154-riaa-wil-piraterijfilters-bij-de-eindgebruiker.html, 2008. [14] Willem de Moor. Riaa wil piraterijfilters bij de eindgebruiker. http://tweakers.net/ nieuws/51772/riaa-wil-piraterijfilters-bij-de-eindgebruiker.html, 2008. [15] Skype reads your bios and motherboard serial number. http://www.pagetable.com/ ?p=27, 2007. [16] Dimitri Reijerman. Skype leest bios en serienummer moederbord uit. http://tweakers.net/nieuws/46229/ skype-leest-bios-en-serienummer-moederbord-uit.html, 2007. [17] Poorhouse. Faking your mac address. http://www.thepoorhouse.org.uk/faking_ your_mac_address, 2006. [18] Change mac address. http://fake-mac-address.qarchive.org/. [19] Alireza Shirazi. How to get hardware information (cpu id, mainboard info, hard disk serial, system information , ...). http://www.codeproject.com/KB/system/ GetHardwareInformation.aspx, 2007. [20] Matt Martin. Eif: Home abusers can be turned off and banned, warns sony. http://www.gamesindustry.biz/articles/ eif-home-abusers-can-be-turned-off-and-banned-warns-sony, 2007. [21] Tom Rosens. Sony gaat streng toezien op virtuele ontmoetingsruimte van ps3. http://tweakers.net/nieuws/48909/ sony-gaat-streng-toezien-op-virtuele-ontmoetingsruimte-van-ps3.html, 2007. [22] Enhanced security measures for all standard chartered online banking customers. http://www.standardchartered.com.sg/notice_2fa_faq.html, 2006.

BIBLIOGRAFIE

113

[23] Liam Tung. Westpac: Sms authentication doesn’t help security. http://www.zdnet.com.au/news/security/soa/ Westpac-SMS-authentication-doesn-t-help-security/0,130061744, 339283275,00.htm, 2007. [24] Sms-based systems - neither secure nor reliable. http://www.wikidsystems.com/ learn-more/Problem/sms. [25] Anne Broache. Va. proposal would track sex offenders by e-mail, im. http: //news.cnet.com/Va.-proposal-would-track-sex-offenders-by-e-mail,-IM/ 2100-1028_3-6142987.html, 2006. [26] T. Kohno, andre Broido, and k.c. Claffy, Remote physical device fingerprinting, ieee trans. on dependable and secure computing, 2(2), 2005. [27] R. zheng et al., A Framework of Authorship Identification for Online Messages: Writing Style Features and Classification Techniques, j. am. soc. information science and technology (jasist), 2005. [28] Can, f. and patton, j.m. Change of Writing Style with Time. computers and the humanities 38(1), 61-82, 2004. [29] BF. België: 4 miljoen gsm’s ongebruikt in lade. http://www. demorgen.be/dm/nl/991/Multimedia/article/detail/797435/2009/03/26/ In-Belgie-liggen-4-miljoen-gsm-s-ongebruikt-in-lade.dhtml, 2009. [30] Sam. België 24ste in index ict-ontwikkeling. http://www.demorgen. be/dm/nl/991/Multimedia/article/detail/736266/2009/03/02/ Belgie-24ste-in-index-ICT-ontwikkeling.dhtml, 2009. [31] Matt Simmons. Mobile world celebrates four billion connections. http://gsmworld. com/newsroom/press-releases/2009/2521.htm#nav-6, 2009. [32] Ferry Grijpink Suraj Moraje Sören Buttkereit, Luis Enriquez. Mobile broadband for the masses: Regulatory levers to make it happen. http://gsmworld.com/documents/ McKinsey_Mobile_Broadband_for_the_Masses.pdf, 2009. [33] Susan Teltscher Sanjay Acharya. New itu ict development index compares 154 countries. http://www.itu.int/newsroom/press_releases/2009/07.html, 2009.

BIBLIOGRAFIE

114

[34] Wdp. Bellen en sms’en op vakantie deze zomer goedkoper. http://www.nieuwsblad. be/Article/Detail.aspx?articleid=DMF20090422_040, 2009. [35] What is an imei, the structure of an imei number, central equipment identity register. http://www.gsm-security.net/faq/ imei-international-mobile-equipment-identity-gsm.shtml. [36] Analysis of imei numbers. &sub=imeinr.

http://www.numberingplans.com/?page=analysis\

[37] Lopdgest. Advanced imei generator. http://downloads.vnunet.nl/ download-advanced-imei-generator/windows/mobiele-telefoon/unlock/368/, 2004. [38] België blokkeert voor eerste keer website. http://www.tijd.be/nieuws/ binnenland/Belgie_blokkeert_voor_eerste_keer_website.8173259-438.art, 2009. [39] Bill would make sex offenders submit e-mail addresses. http://news.cnet. com/Bill-would-make-sex-offenders-submit-e-mail-addresses/2100-1028_ 3-6141947.html, 2006. [40] Mick de Neeve. Vs: ’zedendelinquent moet mailadressen afgeven’. http://tweakers. net/nieuws/45517/vs-zedendelinquent-moet-mailadressen-afgeven.html, 2006. [41] Meester Feexer. Beating caller id. http://artofhacking.com/files/BEATCID.HTM, 2000. [42] Dethme0w. Orange boxing / caller id hacking. http://artofhacking.com/files/ OB-FAQ.HTM, 2006. [43] Russ Haines. Digitale Sounddesign. Academic Service, 2002. [44] William Stallings. Cryptography and Network Security. Pearson Prentice Hall, 2006. [45] The domain name industry brief. http://www.verisign.com/static/044518.pdf, 2009.

Ontwikkeling van een sluitende authenticatie van gebruikers van web 2.0 communitywebsites

Recommend Documents