Mobilbanksikkerhed og -usability
med fokus på signon
Speciale ved Roskilde Universitetscenter, Datalogi
September 2008
Af: Christina Rudkjøbing og Martin Schultz
Vejleder: Niels Jørgensen
Offentlig version
Tak
til:
BEC for venligt samarbejde (www.bec.dk)
Compaya for at stille sms-gateway til rådighed (www.compaya.dk)
Dette dokument er en let modificeret version
af den originale specialerapport, der er fortrolig.
Bilag 6 er ikke tilgængelig i denne version.
Abstract
In this master’s thesis we have made a proposal
for a two-factor sign-on solution for mobile banking (called STS) and then
investigated how it would be possible to implement such a solution in order to
achieve a desired level of security and usability. This has resulted in the
implementation of a mobile banking prototype. Finally we have tested this
prototype as well as compared it to another two-factor sign-on solution.
We became interested in the subject as we felt
we lacked this kind of service from our own banking solutions and would like to
do routine banking operations on the go, for example checking our balance or
doing small transactions. Therefore we have created STS, which is a web-based
online banking solution for mobile phones, based on using the phone’s inherent
capabilities for text messaging in order to eliminate the need for users to
carry additional security tokens or sheets with one-time passwords (OTP).
Our solution sends a one-time password to the
user in form of a text message which contains a link to the bank’s website. The
user will gain access to their online bank by opening the link in their phone’s
browser, where they can then sign-on using their username and password –
just like in a regular online bank. In order to achieve an acceptable level of
security the solution needs two-factor authentication, in our case the link and
the personal password of the user. The link is based on the URL of the mobile
bank together with a randomly generated password that is connected to the
username and replaces the normal OTP token. The point is that the bank knows
the user’s phone number and that it is very difficult to receive text messages
meant for another phone.
The prototype was created with the purpose of
usability testing our solution with real users and comparing it to a more
traditional two-factor sign-on solution, using one-time passwords. We tested
the prototype with both the STS solution and a traditional sign-on method.
According to our test, and in accordance with the relevant theory we have
studied, we can conclude that the STS approach is easier than traditional
solutions for casual users with a security comparable to existing online
banking solutions. However, the security aspect requires more testing before
STS can be a viable solution.
3 Designforslag til autentificering i en mobilbank
3.1 To-faktor sikkerhed i designforslaget
3.2 STS i forhold til eksisterende to-faktor løsninger
4.2 Autentificering i netbanker
4.3 Sikkerhedstrusler mod netbanker
4.5 Sikkerhedstrusler mod mobiltelefoner
4.6 Mulige trusler mod STS-modellen
5.2 Gyldne regler for interfacedesign
6.1 Definition af usable security
6.2 Teoretisk sikkerhed versus sikkerhed i praksis
6.3 Opnåelse af usable security
6.4 Usable security i mobilbank-prototypen
7.2 Prototypens brugergrænseflade
7.3 Prototypens tekniske struktur
8.2 Brugertest af mobilbank-prototypen
8.3 Resultater og konklusioner fra brugertest af
prototypen
9 Mobilbank-prototypen og BEC’s fremtidige satsninger
9.1 Ny officiel Digital Signatur
1 Indledning
I Danmark har det efterhånden længe været almindeligt for banker at tilbyde deres kunder at lave bankforretninger via netbank. Også muligheden for at ordne sine bankforretninger via mobiltelefonen eksisterer, men netbank via mobiltelefoners browsere er endnu ikke slået igennem på samme vis som pc-baserede netbanker. Vi antager, at der er mange forskellige grunde til dette. Nogle relaterer til brugervenligheden af systemerne, mens andre grunde er mere teknisk funderede. Sidstnævnte gælder blandt andet mulighederne for at transmittere data over mobile netværk, der først inden for de senere år har nået en hastighed, der gør det acceptabelt at surfe på nettet via mobiltelefonen. En anden årsag er de begrænsede ressourcer på selve telefonerne, såsom manglende skærmplads og besværlige input-muligheder. Men også mobiltelefonerne har udviklet sig, og mange har for eksempel langt større skærm end tidligere. Ud over disse tekniske hindringer er der en lang række sikkerhedsmæssige problemstillinger, der kræver genovervejelse i forhold til traditionelle netbanksløsninger, før browserbaserede mobilbanker kan slå igennem.
Der findes dog rundt omkring i verden allerede en række forskellige løsninger til at tilgå sine bankoplysninger via mobiltelefonen. De kan være baseret på eksempelvis sms, mobilens webbrowser eller et java-program installeret på telefonen. De tre nævnte tilgange har hver sine fordele og ulemper i forhold til sikkerhed og brugervenlighed, der sjældent går hånd i hånd. Udfordringen er altså at skabe et system, hvor systemet både er sikkert og nemt at bruge: Der skal skabes ’usable security’ – et begreb, Whitten & Tygar i deres studie af krypteringsprogrammet PGP 5.0 som nogle af de første brugte til at beskrive de forhold, der gør sig gældende, når der skal designes brugervenlige systemer med fokus på sikkerhed (Whitten & Tygar 2000). Se afsnit 6 for en uddybning af hvordan vi forstår begrebet usable security. Før det kan diskuteres, hvad der skaber usable security, er det dog nødvendigt med en gennemgang af traditionel sikkerhed og usability – i dette speciale særligt relateret til netbank på mobiltelefonen.
Der hører flere ting ind under sikkerhed i en mobil netbank, heriblandt sikring af datakommunikationen mellem mobilkunde og bank samt sikring af, at det er den rigtige mobil, der initierer kommunikationen. Dertil kommer sikkerheden lokalt på mobiltelefonen. Hvis mobiltelefonen bliver stjålet, og der for eksempel er installeret en Java-applikation, der giver adgang til kundens bankoplysninger, så bør der stadig kræves id og password for at kunne logge ind.
I dette speciale vil vi primært rette fokus mod vores eget designforslag til, hvordan man kan implementere et sikkert og brugervenligt system til at autentificere brugere, der vil logge på en browserbaseret mobilbank. Dette designforslag kalder vi for Sms-baseret To-faktor Signon (STS), og vi vil i resten af specialet referere til denne betegnelse, når vi omtaler vores specifikke signon-model. STS forsøger at udnytte de muligheder, mobiltelefonen giver, og vil blive uddybet i afsnit 3.
En relevant overvejelse, man bør gøre sig, inden man begynder at bruge ressourcer på at udvikle en netbank til mobiltelefonen, er, hvorvidt der overhovedet er et behov for mobile bankløsninger? Ifølge en undersøgelse, foretaget af konsulenthuset Celent (2007), vil 35 procent af alle husstande, der bruger almindelig netbank via en pc, benytte sig af mobile netbankløsninger i 2010, hvor tallet i 2007 var på blot 1 procent. Og i en undersøgelse blandt danske netbankkunder foretaget i august 2007 blev det konkluderet, at 22 procent ville benytte en mobil netbank, hvis de fik muligheden (BEC 2007b: 7). Undersøgelsen viser desuden, at jo yngre brugeren er, des mere åben er personen over for at bruge mobile netbanker.
I Danmark er det begrænset, hvad der på nuværende tidspunkt eksisterer af browserbaserede mobilbanker. Vi har undersøgt udbuddet fra de forskellige danske banker og er kommet frem til, at det i Danmark pt. kun er Danske Bank, der tilbyder kunderne at benytte en mobil netbank. BEC, hvis systemer benyttes af 71 danske banker og sparekasser, har tidligere har tilbudt en løsning via WAP, men denne blev nedlagt 15. januar 2006, fordi der var et meget begrænset antal brugere. BEC’s WAP-løsning havde dog meget begrænsede funktioner, og det var eksempelvis ikke muligt at overføre penge til eksterne konti. Danske Banks aktuelle løsning er browserbaseret og baserer sig på brugen af et såkaldt ActivCard (se afsnit 4.2.2), der ligner en lommeregner, og det er kun lidt større end et kreditkort. Ved signon i Danske Mobilbank indtaster brugeren ud over sit cpr-nummer en engangskode (OTP) fra et ActivCard, og derfor skal man altså besidde det fysiske ActivCard, der ligeledes kræver en pinkode for at blive aktiveret, for at kunne logge på. Danske Bank har et alternativ, der er baseret på printede engangskoder, som kunden selv kan printe fra den pc-baserede netbank. Her kræves kun adgang til disse engangskoder og brugerens cpr-nummer for at logge på, mens der ikke kræves et fast password, som det er tilfældet for at kunne læse en engangskode produceret af ActivCard’et. En signon-model, som af flere danske it-medier er blevet kritiseret for, at den ikke er sikker nok (Simonsen 2008 & Pedersen 2008).
En variant af ovenstående er det netop annoncerede DanID, der er en afløser for den tidligere officielle danske digitale signatur. DanID, der bliver leveret af PBS, er ikke taget i brug endnu, men ser ud til at blive en løsning med engangskoder på et stykke papir på størrelse med et kreditkort (PBS 2008). Denne løsning kan gøre det nemmere for bankerne at tilbyde browserbaserede mobilbanker, fordi de ikke selv skal investere ressourcer til at udvikle en sikker signon-model. Den vil dog næppe være det springende punkt, da for eksempel Jyske Bank længe har kørt med en netbankløsning baseret på samme principper uden også at lancere en mobilbank efter samme model. Da vi ser muligheden for, at DanID bliver defacto-standarden for signon på netbanker (se også afsnit 9.1) er vi meget nysgerrige over for, om denne type signon giver større brugervenlighed, og derfor vil vi i dette speciale diskutere denne løsningsmodel i forhold til STS.
Netbanker via mobiltelefonen er altså ikke specielt udbredt i Danmark i øjeblikket, men det er dog muligt for bankkunder at tilgå deres bankinformationer via mobiltelefonen. Løsninger til at bruge banken via sms er således mere udbredte: De fleste banker tilbyder at sende kunderne bankoplysninger via sms, for eksempel saldo, lige som det ofte er muligt at overføre penge mellem egne konti. Betalinger af regninger og andre mere avancerede opgaver kan kunderne dog ikke bruge sms-løsningerne til. Bankløsninger via sms er ikke blevet den store succes, hvilket vi umiddelbart antager skyldes, at de dels ikke har været brugervenlige at anvende, og dels at bankkunderne ikke har kunnet lave alle de bankforretninger, de gerne ville.
Ideen til dette speciale udsprang meget direkte af, at vi selv godt kunne tænke os mange af de samme muligheder, som netbankerne tilbyder, men via mobiltelefonen i stedet – som et supplement til vores eksisterende netbanker. Vi ville finde det praktisk at kunne lave små bankforretninger, når vi var ude forskellige steder og ikke lige havde adgang til en computer. Man kunne tænke sig et eksempel, hvor vi lige havde lånt nogle penge af en ven til eksempelvis frokost, og her kunne det være rart at være i stand til at overføre penge til vennens konto med det samme – i stedet for at skulle huske det når man kom hjem.
Vi ser mange grunde til, at netbank via mobiltelefonen ikke er blevet udbredt i Danmark, selv om de er det flere steder i udlandet, for eksempel Korea (Ihlwan 2004). Det kan både være brugerne, der ikke har været klar, bankerne, der ikke har villet prioritere feltet eller simpelthen, at teknikken ikke har været moden endnu, som nævnt ovenfor.
I forbindelse med ovenstående overvejelser har vi derfor udviklet STS: En konkret ide til, hvordan man til en browserbaseret mobilbank kan lave et autentificeringssystem, der både er sikkert nok og brugervenligt nok, så folk får lyst til at anvende mobilbankløsningen. Vi vil i dette speciale udforske STS nærmere, og vi vil udvikle en prototype baseret på dette designforslag. Denne prototype vil vi teste blandt en række brugere for at blive i stand til at tage stilling til de teorier om brugervenlighed, som danner baggrund for prototypens konkrete design. Ovenstående overvejelser leder os frem til følgende problemformulering:
1.1 Problemformulering
Hvordan er sikkerheden og brugervenligheden
i en signon-model til mobilbank, der bruger Smsbaseret To-faktor Signon (STS),
og er denne løsning mere brugervenlig end en traditionel signon-model baseret
på engangskoder? Hvordan skal en mobilbank designes for at være så brugervenlig
som mulig?
Det vil sige, at vi først og fremmest gerne vil undersøge sikkerheden og brugervenligheden i vores konkrete designforslag, kaldet STS, og derefter vil vi sammenligne brugervenligheden i STS med en mere traditionell signon–model baseret på engangskoder.
For at kunne lave disse tests vil vi være nødt til at udvikle to forskellige prototyper, der gør brug af henholdvis STS og engangskoder til signon, således at vi kan sammenligne de to signon-modeller. Samtidig vil vi også gerne diskutere og afprøve, hvordan selve funktionerne i en browserbaseret mobilbank skal designes, så brugerne både kan finde ud af at anvende dem og synes om det.
1.2 Læsevejledning
Dette speciale er inddelt i en række kapitler, der har til formål at gennemgå alle de aspekter inden for sikkerhed og usability, der har betydning for browserbaserede mobilbanker. I det følgende vil vi kort opsummere indholdet af disse kapitler for at give et overblik over specialets teoretiske og praktiske indhold. For at sikre korrekt forståelse her og i resten af dette speciale er der dog to begreber, det vil være relevant først at definere og adskille fra hinanden:
Netbank vs. mobilbank: Når vi benytter begrebet netbank, henviser vi altid til de almindelige, pc-baserede netbanker, som brugerne interagerer med ved hjælp af en browser på en PC. Mobilbank er derimod det begreb, vi har valgt at bruge, når vi taler om netbank via mobiltelefonen, det vil sige en browserbaseret mobilbank. Vi henviser således ikke til at kunne lave sine bankforretninger på mobilen via installerede applikationer eller sms, når begrebet mobilbank bruges, medmindre det specifikt er nævnt.
En komplet liste over særlige begreber brugt i dette speciale kan ses i bilag 1. Med ovenstående begreber på plads kan vi gå videre til at give et overblik over teori og praksis i dette speciale:
Afsnit 2: Metode
Den metodiske tilgang til dette speciale er opdelt i tre hovedområder: 1) En indsamling af teori omkring vores emneområde, 2) konstruktion af en fungerende prototype, og 3) brugertests af den konstruerede prototype. I afsnit 2 beskriver vi metoden i detaljer og forklarer, hvordan denne leder os frem til en konklusion på vores problemformulering.
Afsnit 3: Designforslag til autentificering
i en mobilbank
Vi gennemgår her i detaljer konceptet bag det designforslag til autentificering i en mobilbank, kaldet STS, der danner grund for dette speciale. Resten af specialet forholder sig til dette specifikke designforslag og er derfor opbygget med dette for øje.
Afsnit 4: Sikkerhed
I dette afsnit forholder vi os til sikkerhed i forbindelse med netbanker og mobilbanker. Vi diskuterer først sikkerhed på et mere generelt plan, og derefter vil vi komme yderligere ind på sikkerhed specifikt i forhold til mobilbanker. Vi gennemgår generelle sikkerhedsprincipper og modeller for sikker autentificering, herunder enkelt-faktor autentificering og to-faktor autentificering. Derefter gennemgår vi sikkerhedstrusler mod netbanker og mobilbanker, herunder sårbarheder i GSM-netværket. Endeligt vurderer vi, hvilke mulige sikkerhedstrusler STS-modellen er sårbar over for.
Afsnit 5: Usability
Dette afsnit handler om usability i forhold til webapplikationer og i særdeleshed mobile webapplikationer. Vi definerer begrebet usability og gennemgår forskellige regler for webinterfacedesign, målrettet mobile enheder.
Endeligt diskuterer vi, hvem målgruppen for en mobilbank kunne være.
Afsnit 6: Usable Security
Dette afsnit samler de to områder sikkerhed og usability og diskuterer, hvordan man opnår såkaldt usable security. Vi konstaterer, at der er en forskel på teoretisk sikkerhed og sikkerhed i praksis, som i stor grad kan relateres til, om der er opnået usable security. Endeligt diskuterer vi, hvordan vi forsøger at opnå usable security i mobilbank-prototypen.
Afsnit 7: Prototype
Dette afsnit beskriver opbygningen af en mobilbank-prototype baseret på det designforslag, der præsenteres i afsnit 3. Vi starter med at analysere, hvilke funktioner vi bør medtage i prototypen baseret på bankernes og brugernes ønsker. Det gør vi blandt andet ved at gennemføre en undersøgelse blandt potentielle brugere for at få et fingerpeg om, hvorvidt den tænkte målgruppe er interesseret i en mobilbank, og i givet fald hvilke funktioner der ønskes.
Vi afslutter kapitlet med at præsentere prototypens brugergrænseflade samt prototypens tekniske struktur.
Afsnit 8: Brugertest
Det sidste skridt, inden vi kan besvare problemformuleringen, er afvikling af en brugertest. Dette afsnit omhandler således brugertest af den konstruerede prototype, der blev beskrevet i afsnit 7. Vi starter med at gennemgå relevant teori om brugertests, hvorefter vi præsenterer resultaterne af brugertesten af den udviklede prototype.
Afsnit 9: STS-modellen og BEC’s fremtidige
satsninger
Vi forholder vores designforslag til BEC og diskuterer, hvilke forhold BEC bør være opmærksom på, hvis virksomheden beslutter at afsætte ressourcer til udviklingen af en mobilbank. Vi vurderer blandt andet, at designforslaget præsenteret i dette speciale vil være forholdsvist nemt at integrere i BEC’s eksisterende systemer, men samtidig er der nogle forhold, man skal være opmærksom på; ét af dem er, at der er en ny officiel dansk digital signatur på vej, som PBS står bag.
Afsnit
10: Konklusion
Her runder vi specialet af og opsamler vores delkonklusioner for at besvare vores problemformulering.
2 Metode
Vores tilgang til dette speciale vil være fordelt på tre områder: 1) En indsamling af teori omkring vores emneområde, 2) konstruktion af en fungerende prototype, og 3) brugertests af den konstruerede prototype.
Indsamling af teori omkring vores emneområde er nødvendigt for at gøre os i stand til at foretage de overvejelser, der skal til, for at vi kan konstruere en fungerende prototype, der implementerer principper fra både sikkerhed og brugervenlighed for dermed at finde den gyldne mellemvej; den, vi kalder for ’usable security’. Sikkerhedsovervejelserne vil især komme til at omhandle signon – det vil sige at logge på mobilbanken – idet der er nogle udfordringer i at implementere to-faktor autentificering, der må betegnes som den minimale grad af sikkerhed i såvel en almindelig netbank som en mobilbank.
Den endelige prototype benyttes som udgangspunktet for en række brugertests, der har til formål at bidrage med konklusioner, vi kan bruge til at evaluere brugervenligheden i prototypen. Vi er nødt til at konstruere prototypen til vores tests, da der ikke umiddelbart findes noget lignende, som vi kan evaluere med i stedet (her tænker vi specifikt på signon-modellen). Evalueringen baseres både på konklusionerne fra vores samlede teoriapparat samt de foretagne brugertests.
Vores indledende teoriafsnit samler en række teorier og konklusioner om usability, herunder traditionel web-usability og mobil web-usability, samt om sikkerhed, herunder særligt i forhold til netbanker. Disse to områder danner grundpillerne i vores speciales teoretiske fundament. Teorien skal både give os retningslinjer for konstruktionen af vores designforslag og for vores afprøvning af prototypen i form af brugertests.
Som det uddybes i afsnit 3 baserer vi signon-modellen i mobilbankprototypen på en kombination af sms og telefonernes mobile webbrowser. Det betyder i praksis, at selve mobilbanken er webbaseret, men at signon tilføjes en sms-funktion af hensyn til sikkerheden i løsningen.
Vi har valgt at basere vores udvikling på ASP.NET, der er en del af Microsofts .NET-platform. ASP.NET har som princip at adskille HTML-koden fra den underliggende kode, der i vores tilfælde er skrevet i C#. Ved at bruge Microsofts udviklingsmiljø Visual Studio giver ASP.NET desuden mulighed for at skabe meget funktionelle websteder meget hurtigt, hvorfor det er ideelt til vores formål, hvor det ikke er selve koden, der er i fokus, men derimod den endelige applikation.
I praksis vil test
af de første prototyper blive udført af os, mens selve brugertesten først vil
finde sted, når implementeringen af prototypen er nået så langt, at alle de
planlagte funktioner er implementeret. Brugertesten har primært til formål at
evaluere brugervenligheden i prototypen, både signon og funktioner, mens de
løbende tests, vi selv laver, primært har til formål at finde fejl i koden.
Vi vil følge en Extreme Programming (XP) inspireret udviklingsform, der gør os
i stand til at reflektere kritisk over vores design, mens det er i gang,
hvilket vil gøre os i stand til hurtigt at reagere på nye problemstillinger,
der måtte opstå, inden vi udfører de reelle brugertests. Vi mener, at når vi
implementerer en fungerende prototype, vil vi kunne få et langt større indblik
i de reelle udfordringer, brugerne oplever, fremfor hvis vi blot udførte tests
med mockups eller lignende horisontale prototyper uden fuldt implementerede
funktioner (se afsnit 7 for en uddybning af de forskellige tilgange til
prototyper). Dette fordi vi vil kunne teste brugernes interaktion med
mobilbanken frem for blot at spørge dem, om de kan lide et statisk
designforslag. Vi vurderer, at især signon-delen i STS er noget nær umulig at
teste brugervenligheden af med statiske mockups, da vi tester funktionalitet,
som brugerne ikke har stiftet bekendtskab med tidligere og derfor vil have
svært ved at forestille sig.
Endeligt vil vi, ud over at implementere en prototype, der gør brug af sms til autentificeringen, implementere en prototype, der gør brug af engangskoder, også kaldet OTP (se afsnit 4.1.1). Denne prototype skal simulere autentificeringsmodeller, der gør brug af OTP-tokens (såsom Danske Banks ActivCard) og engangskoder trykt på papir (som Jyske Bank praktiserer i sin netbank). Denne ekstra prototype vil gøre det muligt at reflektere yderligere over konsekvenserne af vores designforslag, idet OTP-prototypen vil kunne testes i brugertesten på lige fod med STS-prototypen. Det vil kunne give værdifulde informationer om, hvad brugerne opfatter som den nemmeste måde at logge på en mobilbank.
Ud fra resultaterne af brugertesten vil vi diskutere, om de elementer og funktioner i prototypen, som vi har identificeret i og udvalgt på baggrund af vores teori, har vist sig som kvalificerede valg, og om vores sammenhængende designforslag, i form af prototypen, skitserer en mulig tilgang til design af en mobilbank.
Denne fremgangsmåde skal kvalificere vores designforslag, således at det både får et velfunderet teoretisk og praktisk grundlag.
2.1 Samarbejde med BEC
I forbindelse med vores speciale har vi etableret et samarbejde med BEC i Roskilde. BEC er en forening af 71 pengeinstitutter og har primært specialiseret sig i udvikling og drift af brancheløsninger til den finansielle sektor. Vi anvender samarbejdet med BEC til at få konkretiseret vores designforslag, ved at de kan fungere som en reel ’aftager’ som vi kan bruge til at træffe designbeslutninger ud fra. Samtidig gør vi brug af de erfaringer og overvejelser omkring mobile bankløsninger, som BEC er i besiddelse af.
Størstedelen af Danmarks lokale banker, sparekasser og andelskasser benytter BEC’s systemer, herunder netbank og sms-bank. Og da en af dette speciales forfattere, Christina Rudkjøbing, er ansat i BEC, var det derfor meget nærliggende at spørge BEC, om virksomheden var interesserede i at fungere som sparringspartner i forbindelse med dette speciale.
Gennem samtaler foretaget med BEC har vi fundet frem til, at den signon-sikkerhedsmodel, som vi skitserer i dette speciale, vil kunne indarbejdes i BEC’s eksisterende systemer på en forholdsvis enkel måde; BEC har i forvejen en sms-service, hvor man kunne integrere sms-signon til en mobilbank med denne. Her er brugeren allerede oprettet med sit mobilnummer, og man kunne blot tilføje et ekstra keyword til sms-service, som – i stedet for at sende eksempelvis en saldooversigt via sms – sendte et engangslink, der giver adgang til mobilbanken.
BEC medvirker gennem sin rolle som samarbejdspartner i dette speciale til at give os indblik i, hvilke former for funktionalitet bankerne ser som det væsentligste i virksomhedens nuværende netbank, samt hvilke funktioner BEC ville se som essentielle i en mobil udgave af netbanken (se afsnit 7.1.1).
Vi vil analysere, hvad der vil være mest hensigtsmæssigt i forhold til BEC og virksomhedens eksisterende netbanksmodel, hvis der skal udvikles en mobilbank, hvor der både skal fokuseres på sikkerhed og brugervenlighed. Analysen skal også tage stilling til designet af funktionerne i mobilbanken. Baseret på ovennævnte analyse vil vi derfor udvikle et forslag til en brugergrænseflade, som vi kan udføre brugertests på, samtidig med at STS- og OTP-signon testes.
3 Designforslag til autentificering i en mobilbank
Dette speciale tager udgangspunkt i en specifik ide til, hvordan man kan udnytte mobiltelefonens muligheder bedst i forbindelse med udvikling af en mobilbank, der både skal være sikker og brugervenlig.
Vi har i litteraturen fundet et eksempel på, hvordan mobiltelefonen kan udnyttes til at sikre to-faktor autentificering (se afsnit 4.2.3) ved signon på en pc-baseret netbank (Nagel 2007), men vi har vurderet, at dette ikke har kunnet eksporteres direkte til en mobilbank. Og ingen steder har vi fundet eksempler på mobilbanker, der gør brug af to-faktor autentificering kun ved at udnytte mobiltelefonens muligheder – det vil sige uden ekstra elementer som for eksempel en OTP-token (se afsnit 4.1.1) eller et OTP-genererende program på telefonen.
Vi har derfor selv udviklet et forslag til, hvordan man kan udnytte mobiltelefonen som det element, der sikrer to-faktor autentificering i signon til en mobilbank ved at udnytte mobiltelefonens mulighed for at sende og modtage sms. Dette designforslag kalder vi, som tidligere nævnt, for Sms-baseret To-faktor Signon (STS).
Designforslaget koncentrerer sig om autentificering af brugeren; det vil sige sikring af brugerens identitet i forbindelse med signon og godkendelse af transaktioner. Brug af to-faktor autentificering sikrer dette ved at bruge en form for engangskoder, også kaldet OTP-koder, der sendes via sms til brugeren. Så udnytter man telefondelen, der er en naturlig del ved en mobilbank, og dermed slipper brugeren for at skulle bære rundt på en separat OTP-token eller et papir med engangskoder. Dette vil gøre det nemmere for brugerne at logge på mobilbanken, når de ønsker det, da de ikke vil skulle huske deres OTP-token eller kodekort – i stedet kan de blot bruge deres mobiltelefon. Risikoen for, at de mister kodegeneratoren bliver også mindre, da de ikke skal bære rundt på en ekstra fysisk ting, de kan miste.
Ideen er, at brugerens mobilnummer er kendt af banken, samtidigt med at det ikke praktisk er muligt at få en telefon til at modtage beskeder for andre end dens eget nummer, medmindre det originale simkort er blevet kopieret. GSM-standarden er dog konstrueret til at forhindre, at mere end ét simkort med samme identifikationsinformation kan være på nettet samtidigt. Dermed gør man det svært for en angriber med fysisk adgang til kortet at klone det, da kortet kun kan bruges, når den rigtige bruger ikke anvender det (se også afsnit 4.4).
I STS starter brugeren signon-processen med at sende en sms indeholdende sit brugernummer til bankens sms-gateway (fra et mobilnummer, der i bankens systemer er koblet til det indtastede brugernummer). Derefter vil banken sende en sms indeholdende et link med en engangskode retur til det godkendte nummer. Indholdet i sms’en kunne lyde som følgende:
Du kan logge på Mobilbanken ved at klikke på
dette link: https://mobilbanken.dk/Login.aspx?ses=5d5d1f14c8704e935a87ad78fc535bea
Dette link med engangskoden udgør den unikke kode, som en OTP-token (for eksempel Danske Banks ActivCard) bruges til i andre signon-modeller. Når brugeren følger dette link i sin telefons indbyggede webbrowser, vil han/hun skulle logge ind med sit almindelige brugernavn og adgangskode. Den unikke kode i linket vil være bundet til dette brugernavn, således at det kun er det brugernavn, der sendte sms-beskeden, der kan logge ind. Og signon skal ske inden for et tidsinterval, hvor engangslinket er gyldigt, for eksempel 15 minutter. Signon-forløbet i STS er illustreret i figur 1 på næste side. Dermed er der to dele, eller faktorer, i sikkerheden; engangskoden/-linket, der kun kan bestilles fra og modtages af det godkendte mobilnummer, samt det almindelige brugernavn og password.
Når brugeren skal godkende de transaktioner, han/hun har oprettet, foregår det på næsten samme måde: Når en transaktion er oprettet vil brugeren blive bedt om at godkende den eller udskyde godkendelsen til senere. Når brugeren vælger at godkende sine transaktioner, sender banken en sms indeholdende et godkendelseslink til det registrerede mobilnummer. Denne sms beder brugeren om at logge ind for at godkende sine transaktioner, og når brugeren følger linket, skal han/hun autentificere sig med password igen. Når brugeren er logget ind igen, får han/hun vist en liste over sine ubekræftede transaktioner, som så enten kan godkendes eller afvises.
3.1 To-faktor sikkerhed i designforslaget
Det, der gør STS til en to-faktor-løsning, er selve mobiltelefonen (ellere rettere simkortet), der kombinerer en ”noget du har”-enhed sammen med ”noget du ved” (password). Det kræver adgang til mobiltelefonen at kunne modtage de sms-beskeder, som der kræves for at logge ind på mobilbanken. Har man ikke adgang til telefonen for at modtage sms-beskeden, og/eller kan man ikke passwordet til mobilbanken, kan man ikke logge ind. Selv om man skulle besidde telefonen, skal man stadig også være i besiddelse af password. Man skal altså besidde begge faktorer for at kunne fortage et succesfuldt signon. Mobiltelefonen erstatter i STS-modellen derfor en traditionel OTP-token, såsom et printet kodekort eller et ActivCard.
3.2 STS i forhold til eksisterende to-faktor løsninger
Der er en række forskellige former for to-faktor autentificering i brug hos eksisterende danske netbanker (se afsnit 4.2.2 for uddybning). Den mest udbredte tilgang er brug af en signaturfil, der er placeret på kundens computer. Sammenlignet med denne har STS en lang række fordele. Brugervenlighedsmæssigt er der den fordel, at brugeren ikke skal installere noget på computeren eller telefonen, og derfor er der heller ikke software, der skal vedligeholdes. Sikkerhedsmæssigt er der også nogle fordele: En af truslerne mod løsninger med signaturfiler er, at en uautoriseret person i mange tilfælde kan kopiere den via internettet, hvilket i praksis ikke er en trussel med et simkort (se afsnit 4.4).
En anden udbredt løsning til at logge på netbanker er, som tidligere nævnt, engangskoder via kodekort eller OTP-tokens. Her er fordelene ved STS, at den er mere brugervenlig, idet brugeren ikke skal huske at medbringe en ekstra ting, men kan nøjes med sin mobiltelefon, hvilket tillige er billigere for banken, der ikke skal bruge ressourcer på at administrere OTP-tokens. Ulempen er, at hvis telefonen bliver inficeret med malware, vil angriberen kontrollere både kodegeneratoren samt den enhed, der foretager transaktionerne. Det vil kunne gøre det en smule nemmere at misbruge mobilbanken, end hvis kodegeneratoren var en separat enhed. Dette er dog ikke et sikkerhedsmæssigt problem, der kan forårsage, at brugere og banker ikke vil bruge STS-modellen, da alle kendte netbanksløsninger er sårbare, hvis en angriber først har fået kontrol med den enhed, som transaktionerne udføres på. Det skal også sammenlignes med, at Danske Bank tillige har en løsning til deres mobilbank, som nævnt i problemfeltet, hvor en angriber kan nøjes med at stjæle de printede engangskoder og brugerens cpr-nummer, som ofte begge vil være at finde i brugerens pengepung. Hvis Danske Bank mener, dette er et acceptabelt sikkerhedsniveau, bør STS også kunne accepteres i banksektoren, da det giver sikkerhed på et langt højere niveau.
Vi ser STS som et (for banken) billigere alternativ til to-faktor autentifikation end OTP-tokens, og som et simplere alternativ til nøglefiler uden dog at ofre sikkerheden for slutbrugeren eller banken.
4 Sikkerhed
I de foregående afsnit har vi præsenteret vores designforslag, STS, der bruger sms til at gøre signon på en mobilbank sikkert gennem to-faktor autentificering. I de følgende afsnit vil vi diskutere sikkerhed på et overordnet plan, og derefter vil vi komme yderligere ind på sikkerhed relateret til mobilbanker. Akkurat som sikkerhed er en central del i en browserbaseret netbank, bør det også være det i en browserbaseret mobilbank.
4.1 Sikkerhedsprincipper
Der er syv sikkerhedsprincipper, der generelt opfattes som grundlaget for en god sikkerhedsløsning; autentificering, autorisation, integritet, tilgængelighed, fortrolighed, revidering/evaluering og uafviselighed (Ramachandran 2002: 52). Heraf er særligt fire principper vigtige i sammenhæng med dette speciale, og vi vil derfor gennemgå disse i det nedenstående:
Autentificering:
Dette er processen, hvor det bestemmes, om en påstået identitet er gyldig. Det
vil sige, at man sikrer sig, at det er den rigtige person, der får adgang til
systemet. Netop autentificering er af særlig høj vigtighed for webbaserede
bankløsninger, herunder både eksisterende netbanker og vores bud på en
mobilbank. Hvis ikke man kan sikre, at det er den rigtige person, der bruger en
netbank eller mobilbank, bliver systemet stort set ubrugeligt. Vi vil diskutere
autentificering yderligere i afsnit 4.2.
Integritet: Med integritet menes der, at det skal forhindres, at uautoriserede personer kan modificere eller destruere data, eller at der sker utilsigtede uheld, der modificerer data.
Integritet i data-kommunikation kan for eksempel sikres ved at benytte SSL (Secure Sockets Layer), der gør brug af stærk kryptografi for at sikre autentificering, integritet og fortrolighed (Ramachandran 2002: 183).
Fortrolighed: Data skal beskyttes mod at blive vist for uautoriserede brugere eller processer. Dette er af særlig vigtighed for netbanker og mobilbanker, der har med både personfølsomme og meget private data at gøre. I en mobilbank, såvel som i en traditionel netbank, kan denne fortrolighed i stor grad søges sikret gennem brugen af SSL, som nævnt ovenfor. I den udviklede prototype vil vi dog ikke implementere SSL, idet det kan give problemer i forhold til test af brugervenligheden i prototypen, da vi ikke er i besiddelse af et certifikat, der er forhåndsgodkendt af browseren (læs mere om dette i afsnit 7.3.5).
Uafviselighed: Det skal forebygges, at en deltager i en kommunikation eller transaktion kan benægte at have deltaget, når kommunikationen/ transaktionen er gennemført. For eksempel skal en bankkunde ikke umiddelbart kunne benægte at have gennemført en overførsel til en anden konto gennem netbank. Dette vil kunne gøre netbanken ubrugelig, hvis man ikke med rimelig sikkerhed kan vide, om bankkunden virkelig ikke selv har foretaget overførslen, og dermed dekvalificeres netbanken. Det samme gælder naturligvis en mobilbank. Dette vil vi i specialet dog ikke beskæftige os yderligere med ud over den grad af uafviselighed, der naturligt følger med en sikker autentificering.
4.1.1 One-time-password (OTP)
Mange af de sårbarheder, et almindeligt, fast password har (se afsnit 4.2.1), kan undgås, hvis man i stedet kunne bruge et konstant skiftende, tilfældigt eller pseudo-tilfældigt password. Dette koncept kaldes for one-time-passwords (OTP), eller på dansk engangskoder. Formålet med disse er at gøre det mere besværligt at få uautoriseret adgang til en applikation eller ressource, som for eksempel en netbank. Der findes forskellige typer af OTP-generatorer, og disse vil blive præsenteret nærmere i afsnit 4.2.2.
Princippet, der anvendes i for eksempel OTP-tokens, er, at man har en matematisk algoritme, der bliver forsynet med et tilfældigt input, der kan være en hemmelig kode, tidspunktet eller noget helt tredje. Inputtet gør algoritmen i stand til at udregne en pseudo-tilfældig enganskode. Når man har algoritmen og det anvendte input, kan serveren ved at lave samme udregning som klienten verificere, at det er den rigtige engangskode, der bliver oplyst. Det er muligt at have mere end et input for at øge tilfældigheden; for eksempel både en kode, brugeren skal indtaste, og det aktuelle tidspunkt, det sker på.
Dette giver en pseudo-tilfældig engangskode, som kan verificeres begge veje, hvilket i teorien gør brugen af OTP-koder meget sikkert. Sikkerhedsproblemerne kan ligge i kvaliteten af den algoritme, der udregner koden. Hvis der er fejl i denne, kan en angriber måske regne nøglen ud, eller hvis OTP-tokenen ikke har CPU-kraft nok, så kan designerne blive tvunget til at anvende en svag algoritme. Hvis man som Jyske Bank i stedet sender kunderne en papirliste med engangskoder, vil man kunne bruge mere tid på udregningerne og derved benytte en stærkere algoritme, idet udregningerne ikke er begrænsede af en svag processor på en OTP-token.
Netbanker, der er beskyttet med OTP-koder, er dog ikke fuldstændigt beskyttet mod angreb. Således er der eksempler fra både USA og Sverige, hvor OTP-baserede netbanker har været udsat for phishing-angreb, der tilsidesatte den sikkerhed, OTP-koderne gav (Krebs 2006 & The Register 2005).
4.2 Autentificering i netbanker
Når en bruger skal logge på en applikation, uanset om den er web- eller desktop-baseret, så er der forskellige faktorer, man kan gøre brug af for at sikre signon. Der er tre overordnede typer af autentificerings-faktorer:
- Det, brugeren ved (for eksempel brugernummer og password)
- Det, brugeren har (noget fysisk, som brugeren er i besiddelse af – det kan for eksempel være en OTP-token eller en mobiltelefon)
- Det, brugeren er (biometri)
Afhængig af antallet af faktorer taler man om enkelt-faktor eller to-faktor autentificering[1]. I de følgende afsnit vil vi uddybe, hvilke typer af enkelt-faktor og to-faktor autentificering, der typisk benyttes på internetbaserede tjenester, herunder netbanker. Overvejelserne over sikkerheden i de forskellige typer af signon er også aktuelle for mobilbanker.
4.2.1 Enkelt-faktor autentificering
Den første af de ovennævnte autentificeringskategorier (det, brugeren ved) er typisk det, der bruges ved enkelt-faktor autentificering – det vil sige brugen af kun et brugernavn og et password. En teknologi, som de fleste bruger, når de logger på webmail, Windows, LinkedIn, onlinebutikker og lignende. De autentificerer alle brugeren ud fra det, han/hun ved. Denne form er blevet mere usikker, i takt med at metoderne til at afsløre svage passwords bliver bedre (Ramachandran 2002: 58). Applikationer kan forsøge at øge sikkerheden ved denne type autentificering ved at forælde passwords, kræve en minimum password-styrke[2] eller spærre brugeren ved for mange forkerte signon-forsøg. Sådanne forholdsregler kan dog også give en risiko for, at brugerne omgår sikkerheden ved for eksempel at nedskrive passwords, så den praktisk oplevede sikkerhed er mindre end den teoretiske sikkerhed (se også afsnit 6.2).
Men enkelt-faktor autentificering er langt fra sikker nok til at blive benyttet til netbanker. I en rapport fra 2004 skriver den amerikanske indskydergarantifond FDIC således, at finansielle institutioner bør opgradere eksisterende enkelt-faktor autentificeringssystemer (Tubin 2005: 9). Det skal dog nævnes, at danske banker ikke – som deres amerikanske kolleger – har nøjedes med enkelt-faktor autentificering. Danske netbanker har, siden de blev etableret, krævet en eller anden form for to-faktor autentificering. Finansrådet har således udarbejdet et kodeks[3], der stiller krav til sikkerheden i selvbetjeningssystemer, der medfører økonomiske forpligtelser for kunden, herunder netbanker.
Her kræves der blandt andet, at signon-metoden skal anvende to uafhængige elementer bestående af noget, kunden ved, og noget kunden har – altså klassisk to-faktor autentificering.
Fordelen ved enkelt-faktor autentificering er, at det er nemt at bruge og administrere. Til gengæld har den også den ulempe, at brugere let kan lade sig narre til at røbe kombinationer af brugernavn og password, f.eks. gennem phishingangreb, eller brugeren kan få oplysningerne afluret fra sin pc, uden at vide det, hvis han/hun har fået installeret spyware på sin computer.
I forhold til mobilbanker er det præcis de samme faktorer, der gør sig gældende: Enkelt-faktor autentificering er nem at anvende for brugeren, men sikkerheden er simpelthen ikke god nok i forhold til, hvad danske banker og Finansrådet kræver.
4.2.2 To-faktor autentificering
Hvis man tilføjer en ekstra faktor til autentificeringen – noget, du har eller er – forøges sikkerheden altså ganske betragteligt i forhold til enkelt-faktor autentificering. Sikkerheden øges, fordi man nu skal have fat i begge faktorer for at kunne logge ind i brugerens netbank.
Man benytter typisk forskellige former for hardware-tokens eller printede lister over engangskoder som den ekstra faktor. Hvis brugeren mister sin hardware-token, kan den ikke bruges til noget uden brugernavn og password. Hvis brugeren bliver franarret sit brugernavn og password, så kan svindleren intet gøre, uden også at besidde enten brugerens hardware-token eller en gyldig kode genereret af sidstnævnte. Problemet med to-faktor autentificering er, at hardware-tokens koster penge for bankerne, lige som det kræver ressourcer at administrere dem (eksempelvis ved at sende tokens til kunderne). Desuden er nogle banker bange for, at deres kunder vil være afvisende over for at skulle bruge en fysisk ting, som de skal slæbe med sig rundt, lige som kunder hurtigt kan drukne i tokens fra forskellige banker (Tubin 2005: 10):
“Financial institutions have traditionally viewed the choice between advanced authentication approaches as selecting the "least bad" option. While stronger authentication does improve security, it has the potential to be costly, intrusive, burdensome, and imperfect. Online security and authentication are essentially exercises in risk management. A completely fail-safe solution would likely be cost prohibitive and resisted by consumers.” (Tubin 2005: 9)
Resultaterne fra vores brugertest af den udviklede prototype
(se afsnit 8.3) viser da også, at det at skulle bære rundt på en OTP-token
eller en liste med engangskoder ikke er et populært alternativ blandt brugerne.
Samme konklusion er analyse- og rådgivningsselskabet TowerGroup kommet frem til. I figur 2 ses således en evaluering af
forskellige autentificeringsmuligheder, som er lavet af TowerGroup. Det vurderes, hvor bekvemt, billigt og sikkert de
forskellige løsninger er. Jo mere af cirklen, der er mørk, jo bedre er
løsningen på det pågældende område:
Figur 2: En evaluering af forskellige autentificeringsmuligheder (uddrag fra Tubin 2005: 11)
I det følgende vi vil gennemgå de forskellige typer af autentificeringsmuligheder, der kan medvirke til at give to-faktor sikkerhed:
Password-tokens
Den mest udbredte form af denne løsning er et lille stykke hardware, som viser en seks-cifret OTP-kode, uden at brugeren først skal indtaste en personlig kode, som for eksempel denne eToken fra Aladdin:
En billigere og ikke-elektronisk løsning er at printe en række engangskoder ud på et kort/papir, som så sendes til kunderne. Når engangskoderne på papiret er opbrugt, får kunderne tilsendt en ny samling af engangskoder.
I Danmark benytter Jyske Bank sig af netop denne løsning med printede engangskoder, der erstatter den elektroniske password-token, og bankens brugere er tilsyneladende meget trygge ved netop denne løsning. Det fremgår således af en analyse fortaget af Analyse Danmark i 2007, at Jyske Banks kunder har en markant større tiltro til sikkerheden i netbanken i forhold til kunder i andre danske banker. I Jyske Bank er 90,9 procent således enige eller helt enige i, at deres netbank er meget sikker – mod et gennemsnit på blot 71,8 procent (BEC 2007b: 4).
Smartcards og
smarttokens
Et smartcard ligner typisk et kreditkort i størrelse og form, mens en smarttoken minder mere om en USB-stick. Begge typer har dertil en chip, som kan indeholde information og udføre enkle beregninger. Informationen på enhederne er beskyttet af en pinkode, og for at kunne tilgå disse informationer, er man derfor nødt til at have en form for læser, der kan kommunikere med enheden. Smarttokens kan for eksempel læses af USB-porten på en computer, mens et smartcard kræver en kortlæser. Et eksempel på en smarttoken, der ikke har indbygget hverken display eller tastatur er denne USB smarttoken fra Raak Technologies:
Et simkort er et eksempel på et smartcard, hvor telefonen udgør læseren. Der er dog efterhånden kommet smartcards på banen, som inkluderer tastatur og display, så en separat kortlæser kan undgås. Et eksempel på sådan et smartcard er Danske Banks ActivCard, der har indbygget tastatur og display:
Danske Banks ActivCard bruges ved, at kunden, der ønsker adgang til sin netbank, indtaster sin personlige kode og derefter taster en kode (en ’nøgle’), som vises i netbanken. Dermed får brugeren på ActivCard’et vist en pseudo-tilfældig OTP-kode, der blandt andet er genereret på baggrund af den personlige kode og nøglen fra netbanken. Denne OTP-kode indtaster brugeren så på sin netbank og banken kan validere, at brugeren har adgang til det rigtige ActivCard.
Løsninger med smartcards og smarttokens vil nemt kunne anvendes til mobilbanksløsninger, som Danske Bank da også allerede gør i deres mobilbank. Sikkerheden er her lige så god, som når man anvender ActivCard til at logge på den traditionelle netbank.
Ulempen er, at brugeren altid skal bære rundt på endnu en dims, selv om han/hun allerede har en elektronisk enhed ved hånden, når de forsøger at anvende mobilbanken – nemlig mobiltelefonen. STS udnytter mobiltelefonens tilstedeværelse, så brugeren undgår at skulle slæbe rundt på andre ting end denne for at kunne logge på mobilbanken.
Biometri
Biometri-autentificering er tjek af fysiske kendetegn, som for eksempel fingeraftryk og iris-scan. Denne teknologi er dyr at implementere og vedligeholde. Og fysiske kendetegn kan kopieres eller stjæles, men hvis dette sker, kan man ikke bare ændre på brugerens fysiske kendetegn. Brugen af biometri til online autentificering er et stykke vej væk endnu, mener George Tubin (2005: 13). Biometri i forhold til mobile brugere vil desuden være svært at håndtere. Som vi ser det, er den eneste reelle form for biometri, som kan verificeres i forbindelse med en mobilbank uden ekstra udstyr, stemmegenkendelse: Brugeren kunne da foretage et opkald for at godkende sig. Stemmegenkendelse kan dog være svær at gennemføre i praksis, da stemmekvaliteten ikke altid er i top i en mobiltelefonsamtale.
Signaturfiler
Den mest udbredte autentificeringsmetode i danske netbanker, der ikke fremgår af oversigten i figur 2, er signaturfiler på computeren. Således tilbyder blandt andet BEC (71 pengeinstitutter), SDC (79 pengeinstitutter), Bankdata (15 pengeinstitutter), Nordea og Danske Bank denne mulighed til deres kunder. Det vil i praksis sige, at alle danske banker – på nær Jyske Bank – tilbyder denne løsning til deres kunder enten som eneste eller en af flere mulige signon-løsninger.
En signaturfils-løsning giver også to-faktor sikkerhed gennem ”noget man har”, dog uden helt samme sikkerhed som med en fysisk token, da en signaturfil kan kopieres af en uautoriseret person med tilstrækkelig kontrol over computeren. Det er ikke umiddelbart muligt at eksportere en signon-model med signaturfiler til mobiltelefoner, da de fleste mobilbrowsere ikke understøtter teknologier, der kan læse og verificere en signatur fra filsystemet. Hverken Java, ActiveX eller lignende er understøttet i gængse mobilbrowsere i dag. Samtidig har mobilbrowserne af sikkerhedsgrunde meget begrænset adgang til filsystemet, hvilket vil besværliggøre, eller helt umuliggøre, at man for eksempel prøver at uploade en fil fra telefonen til en webserver eller omvendt. Derfor har vi heller ikke beskæftiget os yderligere med design af en signaturfils-baseret mobilbank i dette speciale.
4.2.3 Mobilen som hardware-token
Som vi har set det i de foregående afsnit, så er brugen af OTP-tokens en måde at implementere to-faktor sikkerhed i netbanker, som nemt kan overføres til en mobilbankløsning. Men hvis mobilbanken skal være uafhængig af ekstra hardware, der kan generere disse engangskoder, så er det nødvendigt at udvikle en model, hvor mobiltelefonen kan udnyttes som hardwaretoken i stedet. I det følgende afsnit vil vi derfor gennemgå de muligheder, der er for at benytte mobiltelefonen som OTP-token i forbindelse med signon i traditionelle netbanker, og hvilke af disse løsninger der vil kunne overføres til en mobilbankløsning.
SMS med OTP-kode
Man kan bruge mobiltelefonen som den ekstra sikkerhed ved signon til netbank. Det kan ske ved, at banken, når brugeren forsøger at logge på, sender en sms til brugerens registrerede mobilnummer. Sms'en indeholder en tilfældig kode, som brugeren skal indtaste. Det giver en højere sikkerhed, end hvis brugeren kun logger på med brugernavn og almindeligt password (Tubin 2005: 13).
Samtidig er det billigere og nemmere for banken i forhold til en løsning med hardwaretokens.
De fleste banker i verden har implementeret to-faktor sikkerhed for deres virksomhedskunder, men på forbrugersiden (den almindelige privatkunde) har især banker i USA og Storbritannien, ifølge Bill Nagel (2007: 2) afstået fra det, af flere grunde:
- For dyrt for bankerne. F.eks koster OTP-tokens, der ikke kræver en pinkode, og OTP-genererende ’regnemaskiner’ (smartcards) mellem 5 og 40 dollars, afhængig af funktionalitet, mens de mere simple smartcards, der blot ligner et almindeligt plastickort og kræver en kortlæser, typisk ligger i et prisleje mellem 2 og 10 dollars.
- For kompliceret at udrulle og vedligeholde. Det kræver en stor indsats at købe, distribuere og erstatte OTP-tokens.
-
For
upraktisk/besværligt for kunder. To-faktor autentificering kræver, at
kunderne skal være i besiddelse af andet end ’det, de ved’ (passwords,
brugernumre, svar på tjek-spørgsmål). Særligt kunder, der er i besiddelse af
flere brugerkonti/logins, er ikke begejstret for to-faktor autentificering, da
de hurtigt kan ende med en hel stak hardware, som for eksempel OTP-tokens.
Ved i stedet at bruge mobiltelefonen som det ekstra led i to-faktor autentificering, bliver det både billigere for banken og mere bekvemt for brugerne at benytte mobilbank, fordi brugeren slipper for besværet med at skulle slæbe rundt på et ekstra stykke hardware. Samtidig er mobiltelefonen en tovejs-kanal, hvor både bruger og bank kan initiere kommunikationen. Det kan man altså udnytte, når der skal logges sikkert på en netbank, som nedenstående figur illustrerer:
Figur 3: To-faktor autentificering på netbank ved hjælp af
sms (Nagel 2007: 4)
Løsningen kræver blot, at brugeren har en mobiltelefon, hvilket langt de fleste har i dag. I 2007 havde 95 procent af alle danske familier mindst én mobiltelefon, ifølge Danmarks Statistik.
Ulempen ved at benytte sms-beskeder til at autentificere brugeren med, er, at teleselskaberne ikke garanterer, at en sms bliver leveret straks. I områder med dårlig mobildækning kan det være et problem, da løsningen er sårbar over for netværksproblemer og manglende dækning. Nogle gange er sms’er flere minutter om at komme frem, mens sms i nogle tilfælde slet ikke bliver leveret (Nagel 2007: 4).
Løsningen tager kun i begrænset omfang højde for man-in-the-middle-attacks. Hvis en bruger besøger en webside, der udgiver sig for at være bankens, kan brugeren således forsyne en uautoriseret person med engangskoden.
Det ovenstående skitserede løsningsforslag er nært beslægtet med det designforslag, der præsenteres i dette speciale, da STS-modellen også anvender sms i forbindelse med signon. STS er dog tilpasset en rent mobil løsning, da den ovenfor skitserede løsning er besværlig at anvende, hvis man kun har mobiltelefonen ved hånden og ikke en almindelig pc. Hvis denne løsning skulle anvendes i en mobilbank, så skulle man, når man fik sms-beskeden, huske engangskoden eller nedskrive den på et stykke papir og derefter starte browseren og gå ind på bankens webside for at indtaste koden.
Installeret program, der danner OTP-koder
Det næste skridt, der kan løse problemer med netværksdækning og manglende levering, er, at omdanne mobiltelefonen til en slags ’soft’ OTP-token ved at installere software, der selv genererer en engangskode. Det kan for eksempel være en Java-applikation, der installeres, eller det kan være en applikation, der er indeholdt direkte på simkortet. (Nagel 2007: 5). På denne måde bliver mobiltelefonen altså omdannet til en slags password-token (se afsnit 4.2.3).
Det er dog ikke en løsning, der er særlig brugervenlig, idet brugeren skal være i stand til at installere software på sin mobiltelefon. Det er muligt for banken at sende softwareopdateringer til kundens telefon, men dette giver helt andre sikkerhedsproblemer: Hvis brugeren er vant til bare at sige ’ja tak’ til automatiske opdateringer til sin mobilbank-software, så er der en forøget risiko for, at der kan blive installeret malware på mobiltelefonen, hvilket kan kompromittere sikkerheden.
Opkald med password
En anden løsning er, at banken – i stedet for at lave en computergenereret sms – laver et computergenereret opkald, der ved hjælp af talesyntese siger den kode højt, som brugeren skal taste for at autentificere sig selv. Denne, og den overstående løsning med et program, der danner engangskoder, ser vi dog ikke som gennemførlig i en mobilbank: På mange telefoner vil brugeren ikke kunne taste koden i browseren, imens han/hun taler i telefon. Så vil brugeren skulle huske koden eller skrive den ned på papir, afslutte opkaldet og åbne browseren for at indtaste koden. Det er efter vores mening en for besværlig løsning, der vil kunne skræmme brugerne væk.
4.3 Sikkerhedstrusler mod netbanker
En netbank er et attraktivt mål for kriminelle og er eksponeret for en lang række sikkerhedstrusler. Truslerne omfatter både direkte angreb mod netbankssoftware og brugernes sløsede omgang med passwords – for eksempel ved at skrive passwordet ned – som ofte er konsekvensen af for restriktive password-regler, der gør at passwords ikke er nemme at huske (Sasse & Flechais 2005: 19).
En browserbaseret mobilbank vil være udsat for mange af de samme trusler som en netbank, hvorfor det er relevant med en gennemgang af disse trusler. I det følgende afsnit vil vi derfor gennemgå de potentielle trusler, netbanker kan være udsat for.
4.3.1 Softwarebaserede trusler
Det simpleste softwarebaserede angreb er, hvis den computer, som anvendes til at logge på netbanken, er inficeret med et keyloggerprogram, der kan opsnappe brugernavn og password[4]. Dermed kan tredjepart få adgang til informationen og kan anvende denne til selv at logge ind i netbanken og for eksempel foretage transaktioner eller overvåge kontoaktiviteten. Denne type angreb bliver dog i stor grad uskadeliggjort, hvis der benyttes to-faktor autentificering, hvor det ikke er nok at opsnappe password.
To-faktor autentificering, der gør brug af nøglefiler frem for engangskoder, er dog ikke en sikring imod ovennævnte type angreb, da en angriber ud over et keyloggerprogram kan installere fjernstyringssoftware. Det er software, der gør angriberen i stand til at køre programmer på en computer over internettet, som om personen fysisk sad ved den. Eksempler på fjernstyringssoftware kan være Virtual Network Computing (VNC) eller den remote desktop-funktion, der er indbygget i Windows[5]. Dermed kan angriberen overtage kontrollen med brugerens computer og foretage transaktioner i netbanken med denne, fordi brugerens signon-oplysninger er opsnappet via keyloggeren, og fordi nøglefilen er tilgængelig, da angriberen fjernstyrer brugerens egen pc (Mannan & van Oorschot 2007: 6).
Angreb som de nævnte er afhængige af, at en uautoriseret person er i stand til at installere software på brugerens computer. Dette kan ske, hvis en person får direkte fysisk adgang til computeren (for eksempel ved delte computere), eller hvis brugeren bliver lokket til at installere softwaren. Sidstnævnte kan for eksempel ske gennem inficerede dokumenter eller programmer, der udgiver sig for at være et legitimt program, men i virkeligheden er lavet til at udbrede virus, spyware eller keyloggers. Computeren kan også inficeres, hvis den benytter software med kendte sikkerhedshuller, der gør det muligt at installere anden software uden brugerens medvirken og vidende. Et eksempel er Microsoft Internet Explorer, der har haft en lang række fejl, der har gjort det muligt for ondsindede hjemmesider at installere programmer på computeren, uden at brugeren selv skulle gøre noget eller umiddelbart kunne se, at det skete (US-CERT 2004).
Programmerne kan også komme fra e-mails, der udgiver sig for at være (mere eller mindre) nyttige ting fra venner, som brugeren har tillid til. Men i virkeligheden er afsendernavnet forfalsket, og e-mailen er designet til at overbevise brugeren om, at det er sikkert at køre programmet (Tubin 2005: 4). Disse ondsindede programmer kan også bruges til meget mere end at opsnappe brugernavne og passwords. Der er set eksempler på, at de har omdirigeret brugerne til en anden hjemmeside end den, de ville besøge: Det vil sige, at de bliver overført til angriberens hjemmeside i stedet for bankens, selv om de indtaster den korrekte webadresse i browseren. Dermed har angriberen foretaget et man-in-the-middle angreb, og angriberen vil nu kunne modificere brugerens transaktioner eller lægge ekstra transaktioner ind som en slags ”ekstra bagage” oven i de transaktioner, brugeren selv foretager (Mannan & van Oorschot 2007: 6).
Et af de simpleste angreb, der tidligere har været udbredt mod mange typer af netværkstrafik, er simpelthen at aflytte trafikken, der går over netværket. Aflytning af trafikken er dog ikke det store problem længere i netbanker, da så godt som alle anvender end-to-end kryptering med SSL, hvilket sikrer autentificering, fortrolighed og integritet som nævnt i afsnit 4.1.
Dette skaber så en række andre trusler mod datasikkerheden: Et centralt punkt i SSL er nemlig, at der udveksles certifikater mellem serveren og klienten, så de kan godkende hinandens identitet. Her kan brugere snydes til at acceptere et andet certifikat end bankens, og dermed indtaster brugeren sit password på en hjemmeside, der benytter sikker kommunikation og ser ud til at tilhøre banken, men i virkeligheden tilhører hjemmesiden ikke banken (Chandra 2002: 10). Brugeren kan snydes på flere måder. Enten kan man prøve at få dem til at acceptere et usigneret certifikat, eller en angriber kan prøve at få udstedt et certifikat i en andens navn (for eksempel bankens). Der har været mindst et eksempel, hvor nogen var i stand til at få udstedt et certifikat i Microsofts navn, så det er bevist, at det kan lade sig gøre (VeriSign 2001). I det sidste tilfælde vil siden se ud som om, at den passer til banken (certifikatet ser legitimt ud), og browseren vil ikke advare brugeren om, at hjemmesiden ikke passer med certifikatet.
4.3.2 Brugerbaserede trusler
Ud over de trusler, der installerer software på brugerens computer, er der også en række muligheder for, at en angriber kan snyde brugeren til at give angriberen adgang til netbanken. Den mest basale er, at brugerne skriver deres signon-oplysninger på et stykke papir, der sidder på skærmen og nemt kan ses af andre (”den gule lap”). I forbindelse med passwords er der også den risiko, at brugeren anvender samme password på alle hjemmesider. Det betyder, at en uautoriseret person kan trænge ind i en mindre sikker hjemmeside og stjæle passwords herfra, som så kan anvendes til at logge ind på netbanken, hvis denne kun benytter enkelt-faktor sikkerhed (Mannan & van Oorschot 2007: 7).
Et andet problem er, at brugerne ikke nødvendigvis bruger tid og energi på at tjekke, om de nu virkeligt er inde på den rigtige hjemmeside. Der har været et tilfælde med en newzealandsk bank, hvor bankens certifikat var udløbet og fik lov til at være det i 12 timer. Her var det kun 1 ud af 300 brugere, der fravalgte at logge på netbanken. Dette på trods af at deres browser advarede dem direkte om, at der var problemer med netbankens certifikat (Mannan & van Oorschot 2007: 10).
En anden meget udbredt metode, der kræver overblik fra brugerne, hvis de vil undgå at falde i fælden, er at masseudsende e-mails, der ser ud som om, at de er sendt fra banken – såkaldt phishing. I e-mailen bliver kunderne bedt om at bekræfte deres bankoplysninger, hvis de vil forsætte med at bruge netbanken. Linket i mailen vil dog ikke føre til bankens side, men i stedet føre til en adresse, der ligner, men som er under angriberens kontrol. Her vil brugeren så blive bedt om at logge ind (og dermed får angriberen signon-oplysningerne) og eventuelt herefter oplyse navn, alder og lignende, så angriberen får den fulde information om brugerens identitet. Signon-informationen kan angriberen bruge til at logge ind på brugerens bankkonti (Tubin 2005: 4). Ifølge Georg Tubin (2005: 8) er der sket en tidsmæssig udvikling, hvor angrebene er blevet mere og mere avancerede – som illustreret i figur 4.
Figur 4: Den tidsmæssige udvikling i
angreb på netbanker (Tubin 2005: 8)
Her er hypotesen, at angrebene er blevet mere avancerede og ikke kun kan klares ved at kræve gode passwords og uddannelse af brugerne. Illustrationen viser også, at det er et konstant våbenkapløb mellem bankerne og angriberne: Når bankerne finder ud af at modvirke én type angreb, bliver der straks udviklet nye og mere avancerede måder at snyde på. Derfor vil det være en konstant kamp for bankerne at udvikle sikkerhedsløsninger. De skal ikke kun tage hensyn til de angreb, der ses i dag, men også dem, der kommer i morgen. Figuren skal dog ikke læses som om, at truslerne afløser hinanden. De ældre bliver ofte kombineret med nyere – for eksempel kan phishing-mails bruges til at installere malware.
4.4 GSM-sikkerhedsmodel
Da STS-modellen gør brug af sms, og dermed GSM-netværket, til signon, er det nødvendigt med en forståelse for, om dette kan give alvorlige sikkerhedsproblemer. I det følgende afsnit vil vi derfor gennemgå sikkerhedsmodellen på GSM-netværket samt de potentielle sikkerhedsrisici, der kan være forbundet med vores designforslag.
GSM-standarden blev introduceret i 1991 og er et såkaldt anden-generations netværk (2G). Efterfølgende er der udviklet 2.5G-standarder, der bygger på GSM (for eksempel GPRS og EDGE) samt 3G-standarder, der har nye, hurtigere teknikker og bedre kryptering (for eksempel UMTS, der dog bygger på GSM’s infrastruktur). Udviklingen i Tyskland, som må formodes at være sammenligneligt med Danmark[6], er illustreret i nedenstående figur:
Figur 5: Generationerne inden for
telekommunikationsstandarder (Tiwari & Buse 2007: 49)
GSM-sikkerhedsmodellen er designet til at opnå to mål; dels at sikre, at det kun er den rigtige bruger, der får adgang til netværket (autentificering), og dels at sikre kundens samtaler imod at blive opsnappet (fortrolighed).
Autentificeringen sker ved hjælp af simkortet, der er unikt og indeholder information, der bruges til at godkende sig over for netværket (se nedenstående for detaljer). Hvis brugeren fysisk besidder simkortet og pinkoden til at aktivere simkortet, beviser det i teorien, at han/hun må få adgang til mobilnetværket. Umiddelbart er der tre hovedformål med dette; at teleselskabet kan sende regningen til den rigtige bruger, at denne ikke umiddelbart kan nægte at have foretaget opkaldene, og at andre personer med rimelig sikkerhed kan forvente at få fat i den rigtige person, når de ringer til et givent telefonnummer (Tiwari & Buse 2007: 36). Både autentificering og fortrolighed forsøges opnået gennem kryptering og kryptografiske principper:
På simkortet bliver der gemt en række sikkerhedsrelaterede informationer, som for eksempel en autentificeringsalgoritme, kaldet A3, og en hemmelig autentificeringsnøgle, kaldet KI.
Når en mobiltelefon logger på GSM-nettet, sker der følgende, som illustreret i figur 6:
Først skal den mobile enhed (simkortet) godkendes, hvilket sker ved hjælp af en challenge-response mekanisme – her sender operatørens netværk et tilfældigt 128-bit tal (RAND) til den mobile enhed, hvor det tilfældige tal, sammen med autentificeringsnøglen KI, sendes gennem algoritmen A3. Sidstnævnte er ikke en bestemt algoritme, men derimod en betegnelse for den algoritme, operatøren har valgt at implementere (Quirke 2004: 6). Når simkortet har beregnet en værdi ud fra RAND og KI sendes resultatet retur til netværket i form af en respons, kaldet SRES. Her sammenlignes resultatet med den værdi, som netværket selv har beregnet på baggrund af den samme A3-algoritme og den hemmelige autentificeringsnøgle KI, der er kendt af både simkortet og netværket. Hvis netværket har modtaget en korrekt SRES retur, vil det tillade den mobile enhed adgang til netværket. I denne forbindelse vil der blive lavet en ny nøgle, Kc, som både telefonen og netværket kender. Kc bruges til den efterfølgende kryptering af datatrafikken mellem netværket og den mobile enhed. Princippet for autentificering i GSM er illustreret i nedenstående figur, hvor det gråtonede felt repræsenterer simkortet:
Figur 6: Autentificering af simkort
på GSM-netværket (Sans Institute 2001: 4)
KI og A3 er hemmelige og kun tilgængelige hos operatøren samt på simkortet. De vil aldrig blive kendt af den enhed (mobiltelefonen), simkortet er indsat i (Quirke 2004: 3).
Sikringen af det enkelte simkort er baseret på, at brugeren af simkortet kan vælge en pinkode, som skal anvendes til at læse simkortet fra telefonen, og som brugeren derfor vil blive spurgt om, når telefonen tændes. Dette vil gøre det umuligt at anvende et stjålent simkort, hvis pinkoden ikke kendes: Uden den rigtige pinkode kan man altså ikke få adgang til kortets data, og hvis koden indtastes forkert for mange gange spærres kortet og kan kun aktiveres igen ved hjælp af en PUK-kode, som mobiloperatøren er i besiddelse af (Quirke 2004: 4). Dette er samme princip som for brug af ActivCard og andre OTP-tokens, der normalt bruges til almindelige netbanker. Dog skal det medtages, at de fleste personer har deres mobiltelefon tændt det meste af tiden, samt at pinkode kan fravælges helt, hvorved denne sikring bliver noget svagere. Til gengæld kan mobiloperatøren nemt spærre simkortet, hvis det bliver meldt stjålet eller mistet.
GSM er derudover konstrueret til at forhindre, at mere end et simkort – med samme identifikationsinformation – kan være på nettet samtidigt. Dermed gør man det svært for en angriber med fysisk adgang til kortet at klone det, da kortet kun kan bruges, når den rigtige bruger ikke anvender det. Og hvis det rigtige kort spærres af mobiloperatøren, kan klonen heller ikke længere benyttes.
Kommunikation på GSM-nettet er, som ovenfor nævnt, krypteret for at forhindre, at uautoriserede aflytter trafikken (Sans Institute 2001: 3ff). Men krypteringen dækker dog kun dataoverførsler mellem den mobile enhed (Mobile Station, se figur 7) og basestationen (Base Station Subsystem, se figur 7), hvorimod al trafik i og mellem operatørnet foregår uden nogen form for kryptering, lige som fastnet-kommunikation. De sms’er, der sendes mellem bankkunde og mobilbank i STS-modellen, er således kun krypterede i den trådløse trafik, det vil sige fra mobil enhed til basestation:
Figur 7: GSM’s arkitektur (Sans
Institute 2001: 2)
Den manglende end-to-end kryptering i sms afsendelser kan give nogle potentielle sikkerhedstrusler i forhold til STS-modellen foreslået i dette speciale, da en del af sikkerheden er baseret på, at sms’en indeholdende engangskoden ikke kan læses af uautoriserede personer, når den sendes via GSM. Disse potentielle problemer vil vi gennemgå i afsnit 4.6.
Endelig udgør det en stor sikkerhedskritisk svaghed i GSM-netværket, at det kun er den mobile enhed, der skal autentificere sig, mens netværket ikke behøver at gøre dette (Quirke 2004: 13). Denne svaghed vil gøre det muligt at gennemføre et man-in-the-middle-attack ved at opsætte en falsk basestation, der udgiver sig for at være en legal mobiloperatør, og dermed kan der opnås uautoriseret adgang til at opsnappe eller ændre de data – for eksempel sms – der sendes fra den mobile enhed (se afsnit 4.6).
4.5 Sikkerhedstrusler mod mobiltelefoner
Vi har i de foregående afsnit set, hvilke sikkerhedstrusler der kan være over for pc-baserede netbanker og for trafik på GSM-netværket. I det følgende vil vi først kort gennemgå de generelle sikkerhedstrusler, mobiltelefoner er sårbare overfor, og derefter vil vi gennemgå de konkrete trusler, en mobilbank baseret på STS-modellen vil være udsat for.
Den første virus til mobiltelefoner blev fundet i 2003 (kaldet Cabir) og var meget simpel. Hvis virussen blev installeret, søgte den efter andre mobiler via bluetooth og prøvede at sende sig selv til de telefoner, den lokaliserede (Hypponen 2006: 70). Her skulle brugeren af telefonen, der modtog Cabir via bluetooth, selv sige ja til at modtage filoverførslen – men programmet blev ved med at sende, så med mindre brugeren slukkede telefonen/bluetooth eller gik uden for rækkevidde, ville det ikke være muligt at bruge telefonen, før filen var modtaget, idet telefonen konstant ville spørge, om brugeren ville acceptere bluetooth-overførslen. Hurtigt efter Cabir blev offentligt tilgængeligt, kom der modificerede versioner og helt nye udgaver, der var væsentligt mere skadelige. I 2006 vurderede Hypponen (2006: 72), at der var mere end 300 aktive vira til mobiltelefoner.
Allerede nu er de fleste store smartphone-fabrikanter i gang med at forbedre sikkerheden på deres telefoner. For eksempel kræver nye Nokia-telefoner som standard, at programmerne bliver godkendt (certificeret) af Nokia, inden de kan installeres, hvis de skal have adgang til eventuelle farlige funktioner. Denne sikkerhed kan brugerne dog slå fra i telefonen, hvis de ønsker det (Hypponen 2006: 77).
De fleste kendte ondsindede programmer til mobiltelefoner har fungeret på én af to måder; enten har de forsøgt at skabe penge til bagmændene ved at lave opkald/sms til overtakserede numre (for eksempel RedBrowser[7]), eller også har de overvåget brugernes handlinger og sendt informationen til den person, der installerede det (for eksempel Flexispy[8]). I nedenstående figur ses et udvalg af ondsindede programmer til mobiltelefoner fra 2006:
Figur 8: Ondsindede programmer til
mobiltelefoner (Hypponen 2006: 77)
Set i forhold til mobilbanker er programmer såsom Flexispy en stor trussel. Her kan telefonen blive overtaget (fjernstyret) af en anden person, uden at brugeren bliver opmærksom på det. Som det er nu, fokuserer Flexispy mest på at overvåge aktiviteten på telefonen (indhold i og modtager af sms-beskeder og samtaler samt telefonens geografiske placering). Dette kan man dog nemt forestille sig udvidet til andre typer af funktionalitet, der kan true en mobilbankløsning, lige som fjernstyringssoftware på en pc kan gøre det. Programmer som Flexispy kræver dog, som det er nu, fysisk adgang til mobiltelefonen for at kunne installeres.
Det er svært at finde tal på, hvor udbredt malware til mobiltelefoner er. Det bedste tal, vi har fundet frem til, er fra statistikken over inficerede mms-beskeder hos en (unavngivet) ledende russisk mobiloperatør (Coursen 2007: 9). Her var 264.474 beskeder ud af de 43.204.473 beskeder sendt i 2006 inficeret med en eller anden form for malware. Det vil sige, at cirka 0,6 procent af alle sendte mms-beskeder var inficeret.
Antallet af ondsindede programmer til mobiltelefoner er langsomt stigende, men en ny ide, der kan give angriberne væsentlige finansielle muligheder, vil kunne få antallet til at stige voldsomt, som man også har set på pc’er (Coursen 2007: 10). Det kunne for eksempel være, at mobilbanker bliver mere udbredt. Samtidig gør konsolideringen på mobilmarkedet – med færre og mere avancerede styresystemer – det nemmere at lave ondsindede programmer, der kan ramme en stor del af brugerne, og dermed bliver det også mere interessant at lave dem (Coursen 2007: 10).
4.6 Mulige trusler mod STS-modellen
Som tidligere nævnt er en mobiltelefon mindre udsat for angreb end traditionelle computere, men dette kan ændre sig i takt med, at mobilen blandt andet begynder at blive brugt til bankforretninger. I det følgende afsnit vil vi gennemgå de specifikke sikkerhedstrusler, som STS-modellen kunne blive udsat for, samt hvilke konsekvenser disse trusler vil kunne få.
Fjernstyringssoftware
STS vil, som netbanker, have meget få muligheder for at forsvare sig imod et angreb, hvor der er installeret ondsindet software på telefonen. Som tidligere nævnt er der set eksempler på, at angribere har installeret software på brugerens computer, og det har gjort angriberne i stand til usynligt (for brugeren) at modificere brugerens transaktioner i realtime. Det eneste forsvar, vi kan se i STS mod denne type angreb, er, at det er sværere at installere fjernstyringssoftware på en mobiltelefon end på en normal hjemmecomputer. Vi ser dog ikke fjernstyringssoftware som en uacceptabel risiko ved STS-modellen, da det er en risiko, der ligeledes eksisterer ved almindelige netbanker – en risiko, som bankerne har valgt at acceptere for at kunne tilbyde kunderne en netbank. Men risikoen for mobilbanken er dog en smule mindre, og derfor må vi antage, at bankerne vil acceptere denne.
Adgang til operatørens
net så sms-beskeder kan opsnappes
Da sms-beskeder sendes ukrypteret i og mellem operatørnet kan en ansat eller andre personer med adgang til operatørens net potentielt set opsnappe sms–beskederne, når de bliver sendt fra brugeren til bankens sms-gateway og fra bankens sms-gateway til brugeren. Dette er dog en risiko, vi vurderer som acceptabel, idet sms-beskederne kun indeholder brugernummeret og engangskoden (i form af et engangslink). En angriber vil således stadig skulle have (eller gætte) brugerens password for at kunne logge ind i mobilbanken, og dette skal gøres inden for de 15 minutter, engangslinket er gyldigt. Dette svarer risikomæssigt til, at en netbankbruger med et Jyske Bank-lignende system (engangskoder på papir) taber sit kodekort og brugernavn. I vores designforslag bevares sikkerheden gennem to-faktor-delen af signon-modellen, idet passwordet aldrig vil blive sendt via sms som en del af modellen – selv om det selvfølgelig aldrig kan forhindres, at brugeren finder på at sende sit password i en sms i en anden sammenhæng.
Det store problem ved personer med adgang til operatørens net er, hvis angriberen har så stor adgang, at han/hun kan modificere den sms, brugeren modtager, så engangslinket peger på en anden webside end den rigtige mobilbank. Her vil angriberen så kunne opsnappe både brugernavn, engangskode og password. Dette vil sætte angriberen i stand til at tilgå den almindelige mobilbank med fuld adgang via det rigtige engangslink, hvis det sker inden for de 15 minutter, engangslinket er gyldigt. Dette angreb kan vores nuværende designforslag ikke beskytte imod. Det er dog et relativt komplekst angreb at iværksætte, og der findes mobilbanksløsninger i drift i Danmark med væsentligt lavere sikkerhedsniveau (se eksemplet med Danske Mobilbank i afsnit 3.2).
En anden variation af dette angreb kunne være, at angriberen for hver opsnappet sms forsøgte et enkelt eller to signon-forsøg, hvor angriberen forsøgte at gætte folks koder. Da de fleste systemer vil udelukke en bruger efter et vist antal fejlslagne logins, ville angriberen blive nødt til at nøjes med et begrænset antal login-forsøg per sms. Dette kunne, hvis banken ikke udelukker netværk, der forsøgte at logge på mange forskellige konti, medføre, at angriberen fik fuld adgang til brugerens mobilbank. Angriberen ville dog også skulle stoppe de sms-beskeder, der blev sendt om godkendelse af transaktioner for at forhindre, at brugeren får mistanke til, at noget er galt. Vi ser ikke dette angreb som et særligt stort problem, da det vil være meget vanskeligt at gennemføre, og der er andre angreb, der nemmere vil kunne give adgang til netbanker og/eller mobilbanker.
Phishing via sms
Et alternativt angreb er, at en angriber spammer tilfældige
mobilbrugere med en sms, der har et link, der til forveksling ligner et rigtigt
link til mobilbanken. Sms’en kunne bede brugerne foretage et signon, hvor de
røber deres personlige oplysninger; for eksempel kunne sms-beskeden bede dem om
at bekræfte deres oplysninger, hvilket er en hyppigt brugt besked i phishing
e-mails. Dette vil SSL-certifikater ikke kunne beskytte imod, da angriberen blot
kan få udstedt et SSL-certifikat til sin næsten rigtige URL-adresse, og
samtidig er der også mange brugere, der ikke tjekker, om SSL-certifikatet er
gyldigt (se eksemplet om den newzealandske bank i afsnit 4.6). I denne
forbindelse vil vi nok godt kunne antage, at mange brugere heller ikke vil være
opmærksomme på, om den URL, de modtager i en sms, er helt korrekt. Dog kan man
håbe, de undrer sig over at få sms-beskeder, de ikke har bedt om. I forbindelse
med denne type angreb vil designforslaget i dette speciale være mere
modstandsdygtigt end en mere traditionel signon-metode med engangskoder: Hvis
brugeren forsøger at logge ind på den falske side, vil engangskoden (i form af
linket) stadig mangle, så angriberen ikke vil få nok information til at overtage
brugerens konti. Hvis brugeren prøver at generere en ny kode, vil der blive
tilsendt et korrekt link, som de kan følge, og dermed kommer brugerne ikke ind
på phishing-siden.
Hvis brugeren havde anvendt en signon-model, der benytter sig af en almindelig
engangskode, ville han/hun kunne komme til at oplyse denne engangskode til
phishing–siden, når han/hun forsøger at logge ind. Dette ville dog ikke
være et kritisk problem, da der ved brugen af OTP-koder som regel kræves en ny
engangskode ved transaktioner.
Et phishing-angreb vil være langt mere alvorligt ved en netbanksløsning, der benytter signaturfiler, da phishing-websiden vil kunne læse brugerens signaturfil. Og hvis brugeren samtidig giver sit brugernavn og password, vil man i yderste tilfælde kunne risikere, at angriberen får fuld adgang til netbanken. Vi vurderer på baggrund af ovenstående, at STS-modellen modstår phishing-angreb bedre end løsninger med signaturfiler og mindst lige så godt som løsninger med engangskoder.
Opsætning af falsk
basestation
Som tidligere nævnt har GSM den svaghed, at netværket ikke behøver at autentificere sig over for den mobile enhed. Hvis en uautoriseret person opsætter en falsk basestation, der udgiver sig for at være mobiloperatøren, kan et man-in-the-middle-attack gennemføres. Angriberen kan dirigere opkald og data videre til det rigtige netværk, men opsnappe eller ændre udvalgt data som for eksempel sms-beskeder. Hvis brugeren samtidig, når han vil benytte mobilbanken, dirigeres til et falsk website, der imiterer mobilbankens, kan angriberen yderligere komme i besiddelse af brugerens faste password og dermed opnå adgang til brugerens mobilbank. Det er dog et ret omstændeligt angreb, der kræver, at mange faktorer er opfyldt, for at dette kan gennemføres.
Dette angreb kan desuden, hvis operatøren anvender en usikker A3-algoritme, som for eksempel den originale COMP128, føre til, at angriberen kan klone simkortet. Dette kan lade sig gøre, fordi en angriber vil kunne sende tilstrækkeligt mange beskeder, hvor simkortet bliver bedt om at godkende sig over for netværket – og dermed genererer simkortet en stor mængde KI, så angriberen kan samle nok data til at bryde algoritmen (Quirke 2004: 15). De danske teleoperatører er dog, så vidt vi kan finde ud, af gået væk fra at bruge den oprindelige COMP128-algoritme (Krøyer 2001). Og i de nyere former for netværk, som for eksempel UMTS (3G) er problemet, som tidligere nævnt, løst, da netværket her også skal godkende sig over for simkortet. Dermed bliver det svært at opsætte en falsk basestation.
Kloning af simkort
Set i forhold til STS-modellen er det godkendelsen af terminalen baseret på simkortet, der er relevant for sikkerheden: Da en del af sikkerheden i designforslaget er baseret på, at andre end den korrekte modtager ikke kan modtage en sms med et givent nummer, er det vigtigt for sikkerheden, at det, som ovenfor nævnt, ikke er muligt at klone et simkort og dermed modtage sms, der er beregnet til dets telefonnummer. Dette afværges af GSM-netværket ved, at to ens simkort ikke kan fungere på samme tid, og dermed kan en svindler ikke benytte et klonet simkort, så længe det oprindelige simkort er i brug. Endelig kan brugeren til enhver tid bede om at få spærret sit simkort og få tilsendt et nyt, således at klonen ikke længere virker. Samtidig kræver det, som tidligere nævnt, fysisk adgang til simkortet for at klone det eller opsætning af en falsk basestation med efterfølgende brydning af A3.
Glemt mobiltelefon
Hvis brugeren har tabt sin telefon eller på anden måde glemt den et offentligt sted, vil en angriber kunne sende og modtage godkendelses-sms’er fra den. Her mangler angriberen dog stadig passwordet, medmindre brugeren har gemt passwordet på telefonen enten i form af en note eller hvis browseren kan gemme passwordet. De færreste standard mobilbrowsere i dag er i stand til dette, men der findes dog modeller på markedet, hvor vi ved, at det kan lade sig gøre – for eksempel kan den kommercielle mobilbrowser Opera Mobile gøre netop dette, mens den gratis version, Opera Mini, ikke giver denne mulighed.
Hvis mobiltelefonens browser er i stand til at huske passwords, og brugeren har sat den til at huske passwordet til sin mobilbank, så er der ikke længere tale om reel to-faktor sikkerhed, idet man nu kun behøver at være i besiddelse af mobiltelefonen for at kunne logge på. Designerne bag en egentlig produktionsklar udgave af en mobilbank bør derfor undersøge, om dette er et problem, man kan programmere sig ud af, så browseren ikke tillades at gemme passwordet til mobilbanken.
Hvis en mobiltelefon bliver stjålet, og hvis dens browser er i stand til at husek passwordet til mobilbanken, så kan dette angreb alligevel nemt stoppes ved, at brugeren melder telefonen stjålet, således at mobilnummeret (eller rettere simkortet) ophører med at fungere, på samme vis som brugeren kan spærre adgangen til en traditionel netbanken hos sin bank. Hvis angriberen ikke kan modtage sms-beskeder med et link til godkendelse, er det ikke muligt at anvende brugernavnet og passwordet, hvorfor dette angreb hurtigt og nemt kan modvirkes.
Vi har nu gennemgået sikkerhed set i forhold til både netbanker, mobilbanker generelt samt vores designforslag, STS. Vi vil i de følgende afsnit gennemgå relevant usability-teori i forhold til STS for til sidst at koble sikkerhed og usability sammen og diskutere, hvad der kan skabe usable security.
5 Usability
Det centrale punkt i vores designforslag er, om brugerne kan
finde ud af at anvende det. Kan de ikke det, hjælper det ikke, at vi har en
nytænkende og sikker signon-model.
For at kunne designe vores mobilbankprototype bedst muligt, herunder både
signon og funktioner, har vi lavet et litteraturstudie af teorierne omkring
usability; i dette kapitel fremlægger vi de teorier, vi har udvalgt, og som er
relevante for vores designforslag. Disse teorier lægger grunden for det
implementerede design. Først har vi en generel introduktion til begrebet
usability, og derefter går vi videre til Ben Shneidermans klassiske otte
’gyldne regler’ for usability. Vi har udvalgt Ben Shneidermans teorier, da de
er veletablerede og bredt accepterede, samtidig med at de i stor grad afspejler
vores egne forestillinger om usability. Derudover giver de os også nogle klare
pejlemærker, som vi kan opbygge designet i prototypen efter.
Som det sidste har vi samlet en række teorier og undersøgelser af, hvordan man opnår god usability på mobile enheder, både fra Shneiderman og andre kilder. Udgangspunktet er en tidlig undersøgelse af WAP-usability udarbejdet af Jakob Nielsen og Marc Ramsay (2000). Vi finder især WAP-undersøgelsen relevant, da det er en af de tidligste større undersøgelser af denne karakter. Undersøgelsen danner grund for en del af Jakob Nielsens senere råd til mobilt webdesign samt drager paralleller til ”normalt” webdesign, og vi vurderer, at undersøgelsen stadig er relevant. Da Nielsen og Ramsay drager paralleller til traditionel webusability sætter den tidlige WAP-undersøgelse os bedre i stand til at relatere vores allerede gennemgåede usability-teori til mobiltelefonen, samtidig med at den giver os et empirisk fundament at holde teorierne op imod.
Før vi går videre, er det dog nødvendigt med en definition af begrebet usability, hvilket vi vil gennemgå i det følgende afsnit.
5.1 Definition af usability
Brugervenlighedsekspert Rolf Molich benytter det danske ord brugervenlighed som dækkende over det engelske ord usability. Samtidig definerer han brugervenlighed som dækkende over to begreber, nemlig nytteværdi og nemhed (Molich 2003: 41). Det vil sige, at systemet skal løse brugerens opgaver (nytteværdi), og det skal være nemt at arbejde med (nemhed).
En anden dansk usabilityekspert, Jakob Nielsen, er derimod ikke glad for begrebet brugervenlighed (eng: user friendliness) og hælder i stedet til begrebet usability; han argumenterer for, at brugere ikke har behov for, at systemet er ’venligt’ mod dem, men at det i stedet ikke skal stå i vejen for brugerens arbejde og intentioner (Nielsen 1993: 23). Som Rolf Molich erkender han dog også, at begrebet dækker over flere ting og således ikke er en en-dimensionel egenskab.
Men hvad er så et brugervenligt system? Traditionelt er usability blevet associeret med attributterne learnability, efficiency, memorability, errors og satisfaction (Nielsen 1993: 26):
- Learnability betyder, at systemet skal være nemt at lære, så brugeren hurtigt kan komme i gang med at anvende systemet.
- Efficiency betyder, at systemet – når brugeren har lært at bruge det – skal muliggøre en høj grad af produktivitet. Det vil sige, at brugeren skal kunne opnå det, det er meningen med systemet.
- Memorability betyder, at systemet skal være nemt at huske, så brugeren kan genkende det, næste gang han/hun skal bruge det, selv hvis der er gået noget tid siden sidste brug.
- Errors betyder, at systemet skal have en lav fejlrate, således at brugere laver så få fejl som muligt. De fejl, der laves, skal systemet kunne komme sig fra, for eksempel ved hjælp af ’fortryd’-operationer. Og endeligt må katastrofale fejl, uden mulighed for at kunne fortryde, ikke opstå.
- Statisfaction betyder, at det skal være tilfredsstillende at bruge systemet; det vil sige at brugere subjektivt set skal kunne lide at bruge systemet. Dette er især vigtigt ved applikationer, der ikke benyttes i arbejdssammenhæng, som for eksempel spil.
Rolf Molich lægger sig tæt op ad ovenstående generelle definition af usability. Han definerer et brugervenligt websted som ét, der er let at lære, let at huske, effektivt at bruge, forståeligt og tilfredsstillende at bruge. På ofte anvendte websteder er effektiviteten dog vigtigst, mens indlæringstid (let at lære) og genindlæringstid (let at huske) er vigtigst på sjældent anvendte websteder (Molich 2003: 23). Webstedet skal dog have et vist kvalitetsniveau, før det overhovedet giver mening at tale om brugervenlighed: Systemet skal således først være pålideligt, sikkert og tilgængeligt (Molich 2003: 21ff).
I dette speciale vil vi benytte begge begreber – usability og brugervenlighed – i samme betydning, nemlig ’nemhed’ og ’nytteværdi’ (brugbarhed), med mindre andet er nævnt.
Usability er dog ikke det eneste, der har betydning for, om et system bliver en succes. Også den sociale acceptabilitet har betydning: Er systemet godt nok til at opfylde alle de krav og behov, som brugere og andre potentielle interessenter har? Systemets samlede acceptabilitet er en kombination af denne sociale acceptabilitet og dertil en praktisk acceptabilitet, som for eksempel usability hører ind under. Andre ting, der hører ind under praktisk acceptabilitet er for eksempel omkostninger, kompatibilitet med andre systemer og brugbarhed (eng: usefulness), som usability hører ind under (Nielsen 1993: 25). Modellen er illustreret i figur 9:
Figur 9: Elementer, der medvirker til
systemers acceptabilitet (Nielsen 1993: 25)
Som det kan ses af modellen, dækker brugbarhed både over begreberne usability og utility, hvor utility dækker over, om funktionaliteten i systemet kan gøre det, der er behov for, mens usability dækker over de fem tidligere nævnte attributter, der alle har betydning for, hvor godt brugeren kan bruge denne funktionalitet.
5.2 Gyldne regler for interfacedesign
En klassiker inden for usability er bogen Designing the User Interface (2005) af Ben Shneiderman, professor ved University of Maryland. Han fokuserer blandt andet på otte principper, eller ’gyldne regler’, som kan anvendes på de fleste interaktive systemer, herunder også mobile applikationer (Shneiderman 2005: 74). I det følgende vil vi forholde disse principper til designet af en mobilbank, men vi vil ikke være i stand til at implementere alle anbefalinger i den udviklede prototype, da vi har begrænsede ressourcer til rådighed. En endelig, produktionsklar udgave af mobilbanken bør dog tage højde for så mange af de nævnte usability-principper som muligt.
1. Strive for
consistency
Der skal tilstræbes konsistens i designet: Handlingssekvenser i ensartede situationer og/eller med samme formål skal ligne hinanden. Der skal benyttes den samme terminologi i prompter, menuer og hjælpetekster, og endeligt skal farver, former og skrifttyper udstråle en ensartethed gennem hele designet.
I vores speciale betyder det to ting; først og fremmest skal farver, former og skrifttyper være ensartede og konsistente gennem hele vores prototype, og sidst, men ikke mindst, skal mobilbanken minde om den eksisterende netbank, både når det gælder terminologi og handlingssekvenser. Ved at designe mobilbanken på denne måde vil brugere opleve, at mobilbanken minder om noget, de allerede kender og er trygge ved.
Den konsekvente punktform, vi i prototypen har valgt at anvende i alle de opgaver, brugerne kan udføre (se afsnit 7.2 og 8.3), giver også konsistens, i og med at brugerne vil vænne sig til, hvordan opgaverne er opbygget, og brugerne kan dertil genbruge den viden, de opnår.
2. Cater to universal
usability
Dette princip handler om at tage hensyn til, at forskellige brugere har forskellige behov. Er brugeren uerfaren, så giv mulighed for masser af hjælp. Er der tale om ekspertbrugere, så lav genveje, eksempelvis i form af specielle taster, kommandoer og lignende. Lige præcis i forhold til en webapplikation, der skal afvikles på en mobiltelefon, giver sidstnævnte ikke særligt god mening, da brugerens interaktion med applikationen så vidt muligt skal foregå gennem klik med ”musen” i den mobile browser. Dermed vil en mobilapplikation altid have et lavere niveau af usability, og indtastninger på det ofte noget begrænsede tastatur bør så vidt muligt undgås.
I mobilbanken kan princippet om universel usability i stedet
afspejles gennem enkelhed; der skal være mulighed for at få hjælpetekster frem,
hvis brugeren vil have det, og ellers skal designet holdes enkelt.
Skærmstørrelsen sætter en naturlig begrænsning for, hvor meget hjælp, der kan
være i billedet. Derfor handler det om at finde den gyldne mellemvej; det skal
altså være muligt at få hjælp, men det skal ikke fylde for meget, og denne
egenskab skal forsøges nået gennem et design, der er så enkelt og/eller
velkendt, at det kræver minimal forklaring.
3. Offer informative
feedback
Hver gang brugeren foretager en handling, skal systemet give en passende, informativ feedback. For hyppige og mindre handlinger, kan feedbacken være begrænset, mens sjældne og/eller komplicerede handlinger kræver en mere dybdegående feedback. I en mobilbank vil handlinger som tjek af saldi og posteringer kræve forholdsvist begrænset feedback, hvis nogen overhovedet, mens handlinger såsom betaling af regninger kræver mere vejledning og feedback.
4. Design dialogs to
yield closure
Brugerens handlingssekvenser skal organiseres i grupper med en begyndelse, midte og afslutning.
Ved at give brugeren informativ feedback, når en gruppe af handlingssekvenser afsluttes, opnår man at give brugeren en tilfredsstillende følelse af at have fuldført noget, og dermed bliver brugeren parat til at foretage den næste række af handlingssekvenser.
Dette, lidt abstrakte, princip kan i en mobilbank for eksempel være, når brugeren vælger at betale en regning og udfylder oplysningerne til betalingen (begyndelse), godkender betalingen (midte) og får vist et godkendelsesbillede, når overførslen er fuldført (afslutning).
5. Prevent errors
Systemet skal designes, så det så vidt muligt forebygges, at brugeren kan lave alvorlige fejl; der skal eksempelvis ikke tillades bogstaver i numeriske inputfelter, og menupunkter, som ikke er hensigtsmæssige i konteksten skal tones ud, så de ikke er klikbare. Og hvis der alligevel sker fejl, skal der tilbydes en enkel fejlhåndtering gennem konstruktiv feedback og præcise instruktioner, lige som brugeren ikke skal blive bedt om at indtaste korrekte oplysninger igen, hvis de for eksempel har indtastet et enkelt felt forkert i en formular.
6. Permit easy
reversal of actions
Brugeren skal have mulighed for at kunne fortryde sine handlinger. Lige præcis i et banksystem er der dog nogle forhold, der gør sig gældende, som betyder, at visse operationer ikke kan omgøres. Det er for eksempel allerede sådan i den almindelige netbank, at en betaling, der oprettes til overførsel samme dag, ikke kan fortrydes, når overførslen først er godkendt, idet transaktionen bliver påført kundens konto med det samme. Hvis kunden alligevel ønsker at fortryde, skal vedkommende have fat i banken, der kan gøre dette. Dog kommer brugeren igennem en bekræftelse af handlingen, således at man kan fortryde transaktionen, hvis man har lavet en tastefejl.
7. Support internal
locus of control
Dette princip handler om at tilstræbe, at systemet designes på en måde, så brugerne oplever, at de altid selv styrer situationen. Der skal ikke være nogle overraskende interfacehandlinger, og alle handlinger skal være startet af brugeren selv frem for systemet.
En undtagelse fra dette princip i et banksystem som mobilbanken er, at brugeren automatisk skal smides af systemet, hvis der ikke er nogen aktivitet inden for et vist antal minutter (for eksempel 15). Dette sker af sikkerhedsmæssige hensyn, så andre ikke kan overtage banksessionen, hvis brugeren efterlader computeren eller telefon uden at logge af net- eller mobilbanken.
8. Reduce short-term
memory load
Menneskers hukommelse er, i modsætning til computere, ikke
skabt til at kunne huske en masse detaljer. Ifølge Shneiderman (2005: 75) er
tommelfingerreglen, at menneskers korttidshukommelse kan rumme fem til ni
’bidder’ af information. Belastningen
på brugerens korttidshukommelse skal derfor begrænses, og det kræver, at ”displays be kept simple, multiple-page
displays be consolidated, window-motion frequency be reduced, and sufficient
training time be allotted for codes, mnemonics, and sequences of actions” (Shneiderman
2005: 75).
Det betyder i forhold til vores speciale og designet af en mobilbankprototype, som tidligere nævnt, at der skal være stort fokus på enkelheden i designet.
5.3 Mobile usability
En af de største usability-udfordringer i forbindelse med mobiltelefoner er skærmstørrelsen. Den lille opløsning kræver, at man tager højde for det tidligt i designet, da nedskalering af eksisterende webapplikationer sjældent fungerer særligt godt. Det betyder dog ikke, at man skal redesigne alle dele af en eksisterende webapplikation. De bedste resultater opnås, hvis applikationen anvender elementer, som brugerne allerede kender og forstår at bruge.
Ifølge Ben Shneiderman (2005: 393) bliver mobile enheder typisk brugt til rutineopgaver, som for eksempel at foretage et telefonopkald, tjekke en kalenderaftale, finde et sted (for eksempel nærmeste bilværksted på De Gule Sider) eller få en rutebeskrivelse. Derfor er det også nødvendigt at optimere designet til disse gentagne opgaver, mens mindre vigtige funktioner skal gemmes eller helt undlades. Den mest anvendte løsning på skærmstørrelsesproblemet har været at dele indholdet op på flere forskellige sider og bruge lineær skridtvis navigering (Nokia 2004). Man skal dog også være opmærksom på, at en del normale webelementer er forvirrende eller dårligt fungerende i mobile browsere; for eksempel vil popup-vinduer altid fylde hele skærmen og virke forvirrende, og dropdrown-menuer er næsten umulige at navigere med i en mobilbrowser (Nokia 2004).
Der er dog sket meget på mobilområdet i de senere år: Mange mobiltelefoner vil efterhånden være i stand til at vise samme type indhold som en almindelig browser – herunder også dropdown-menuer. Det er dog svært at vide med sikkerhed, og hvis man ønsker at bruge disse ’avancerede’ elementer i en mobilbank, bør man gennemteste på alle de mobiltelefoner, der sælges i dag, og ellers bør det undgås.
5.3.1 Tidlige usability-problemer ved WAP-applikationer
Jakob Nielsen og Marc Ramsay lavede i 2000 en større undersøgelse af WAP-sider og brugervenlighed (Nielsen & Ramsay 2000). I denne undersøgelse finder de, at mange af de brugervenlighedsproblemer, der var med internettet i starten, bliver gentaget i WAP. Derfor mener vi, at undersøgelsen stadig er aktuel, selv om det mobile internet har bevæget sig videre siden da.
Hovedproblemet, som Nielsen og Ramsay identificerede i WAP, var, at det tog for lang tid for brugerne at finde den information, de skulle bruge (over ét minut bare for at se avisoverskrifter). Et problem, de også observerede på internettet i starten. Problemet skyldes en række faktorer: Hjemmesiderne var bygget op, så det var svært logisk at regne ud, hvor informationen lå. Der var for eksempel for meget information på hver side, hvilket betød, at brugeren skulle scrolle igennem meget lange lister og ikke kunne overskue, hvad der var på den del af siden, de ikke kunne se på deres små skærme. Samtidig var datatransmissionerne langsomme, så der var en del ventetid imellem hver handling.
Disse elementer ser vi stadig optræde på det mobile internet. Det er vigtigt for os at opbygge vores mobilbank-prototype logisk og intuitivt, så brugerne nemt kan finde den ønskede funktionalitet. Samtidig skal der ikke være for meget information på hver side, så funktionerne nemt kan overskues, hvilket sammen med en konservativ brug af grafik vil resultere i sider, der hurtigt kommer frem.
Nielsen og Ramsay finder det også vigtigt, at man ikke bare genbruger designideer fra almindelige hjemmesider, da de ikke er optimale til et nyt medie, som mobiltelefoner er. Det viste sig heller ikke fornuftigt at genbruge layout-ideer fra printmedier på almindelige hjemmesider, da internettet i sin tid kom frem (Nielsen & Ramsay 2000: 4).
På almindelige hjemmesider sker det ofte, at de ikke er så fokuserede på de mål, brugerne prøver at opnå. Dette er ikke optimalt, men kan overleves, da brugerne både har en stor skærm og gode input-muligheder, men på en mobiltelefon er dette en katastrofe. Nielsen og Ramsay skriver direkte ”Be right or be dead” (Nielsen & Ramsay 2000: 4). Det er derfor centralt, at man, inden webapplikationen bliver designet, sætter sig ned og gør sig klart, hvad brugerne vil forsøge at bruge siden til, så man kan optimere den til disse formål. Det er også centralt at anvende standardterminologi, som brugeren allerede er fortrolig med, så man ikke spilder plads på at forklare en ny terminologi. Dette er både centralt i forhold til navigation og det faktum, at brugere ikke gider læse ret lange tekster på en lille skærm (Nielsen & Ramsay 2000: 4). Optimalt set må vigtige navigationsværktøjer ikke være placeret under det, brugeren ser, når siden kommer frem, for ellers risikerer man, at de bliver overset.
Indholdsmæssigt er det centralt, at tjenesterne er målorienterede. Brugerne gider ikke surfe rundt efter generel information. For eksempel viste det sig, at brugerne ikke gad købe flybilletter over mobilen, mens en tjeneste som ”mit fly er aflyst, find en ny reservation” var meget populære (Nielsen & Ramsay 2000: 6).
Disse erfaringer har vi haft i baghovedet fra starten, og vi har således forsøgt at forholde os til disse i opbygningen af mobilbankprototypen og i udvælgelsen af funktioner til denne.
5.3.2 Usability-guidelines til websites på mobile enheder
Den engelske virksomhed Webcredible, der er specialiseret i at designe og teste systemers brugervenlighed, har udarbejdet en liste over de forhold, man skal være særligt opmærksomme på, når man designer websites til mobile enheder (Webcredible 2007). Listen er udarbejdet på baggrund af en undersøgelse foretaget blandt mobiltelefonbrugere, som blev bedt om at foretage typiske opgaver på populære websites. Også Nokia har udarbejdet usability-guidelines til design af websites til mobile enheder, og telefongigantens anbefalinger er specifikt rettet mod browserbaserede mobilbanker (Nokia 2004). I det følgende vil vi gennemgå disse guidelines, som vi i designet af prototypen i stor stil har holdt os til:
1. Mød brugernes behov
hurtigt
Forudsig brugernes behov og opfyld dem hurtigst muligt. I en mobilbank kan det for eksempel være, at brugeren som det første ser sin saldo, når vedkommende logger ind, frem for først at skulle vælge en funktion i menuen. Alternativt kan man give brugeren mulighed for selv at sammensætte, hvilke informationer, der vises på forsiden.
Også Nokia erkender vigtigheden af at designe applikationen til slutbrugerens mål; man skal overveje, hvilke situationer brugeren vil stå i når, han/hun anvender applikationen – er det i toget, på sofaen eller imens de går? Interfacet skal altså optimeres til dette, blandt andet ved at gøre de mest anvendte funktioner nemmest at tilgå.
2. Gentag ikke
navigationen på hver side
Brugervenlige websider, der er designet til at blive brugt på en pc, har typisk en menu/navigation på hver enkelt side. Men fordi skærmpladsen er så begrænset på mobile enheder, kan navigationen skubbe indholdet ud af billedet, så brugeren bliver nødt til at scrolle ned for at komme til indholdet på siden.
Nokia anbefaler, at man bruger en navigationsmodel, der er nem at lære og huske, for eksempel ved at interfacet er konsistent og ikke går for ”dybt”.
Webcredible anbefaler, at man kun viser en menu på startsiden, mens alle andre sider kun skal indeholde links tilbage til startsiden samt sidste vigtige punkt i brugerens interaktion med websiden. Disse links skal vises både i toppen og bunden af den aktuelle side, så de aldrig er for langt væk for brugeren. BBC Mobile har eksempelvis gjort det ved at have klikbare ’brødkrummer’[9] i toppen af siden og en liste med links i bunden af siden:
Figur 10a:
BBC Mobile Figur 10b: BBC Mobile
3. Adskil markerede
menuer og links klart fra resten af indholdet
Mobiltelefonbrugere har som regel dårlig kontrol over, hvad der bliver markeret med cursoren i mobilbrowseren; når brugeren benytter telefonens joystick eller ’retningsknap’, så bliver den både brugt til at scrolle siden og markere links, knapper og formularfelter. Derfor er det vigtigt, at brugeren tydeligt kan se, hvad der er i fokus. Det kan for eksempel ske gennem en klar forskel i font- eller baggrundsfarve, når noget markeres.
4. Gør brugerinput så
simpelt som muligt
Tastaturet på en mobiltelefon og de fleste mobile enheder er ikke egnet til at skrive længere tekster på. Design derfor siden sådan, at mest muligt input kan vælges frem for at skulle skrives som tekst.
I mobilbanken er der nogle funktioner, hvor det ikke helt kan undgås, at brugeren skal indtaste lange tekster og/eller numre – eksempelvis, hvis brugeren overfører penge til en andens konto. Generne kan dog forsøges mindsket ved at tilbyde brugeren at gemme tidligere indtastede oplysninger, så de hurtigt kan vælges igen, hvis brugeren får behov for det.
5. Vis kun nødvendig
information
De fleste mobile enheder har kun begrænset skærmstørrelse. For eksempel har de fleste Nokia-telefoner i dag en opløsning på omkring 240*320 pixels, mens en almindelig computerskærm typisk har en opløsning på 1024*786 eller derover. Man skal derfor undgå horisontal scrolling og for meget tekst.
Dertil kommer, at mange mobilbrugere betaler for mængden af data, de downloader til telefonen, hvorfor mængden af information, særligt billeder og video, skal begrænses.
6. Placer basale
browser-funktioner på siden
Mobile browsere har ikke altid knapper såsom tilbage og frem indbygget i browseren. Placer derfor altid en tilbage-funktion på alle andre sider end startsiden, som for eksempel it-avisen Computerworld har gjort på deres mobilsite:
Figur
11a: Computerworld Figur
11b: Computerworld
Mobil
Mobil
7. Design mobilvenligt
sidelayout
Dette designprincip er primært gældende for websider, der er målrettet pc-baserede webbrowsere; hvis ikke man her har et design, der også ser fornuftigt ud i en mobilbrowser, så kan man overveje at lave en version af siden, der er målrettet mobile enheder.
I forhold til vores speciale siger dette dog sig selv, da vi kun designer et website til mobile enheder. Man kan dog udmærket vælge at bruge mobilbanken på en traditionel pc i stedet, hvis man skriver linket fra signon-sms’en ind i adresselinjen i eksempelvis Internet Explorer. Det er altså teknisk muligt at benytte mobilbanken på en pc i stedet for en mobiltelefon – men et bedre alternativ ville formentligt være den traditionelle netbank, der har flere muligheder og udnytter pc’ens større skærm.
Nokia fremhæver desuden vigtigheden af at bruge interface-elementer, som egner sig til mobile browsere. Hvis man overholder webstandarderne er der størst sandsynlighed for at applikationen virker ens i flest muligt mobilbrowsere. Frames, popup-vinduer og dropdrown-menuer understøttes dårligt i mobilbrowsere og kan forvirre brugerne.
5.3.3 Generelt design til mobile enheder
Det er begrænset, hvad der findes af litteratur omhandlende generelt design til mobile enheder, men en undtagelse er Designing the Mobile User Experience (Ballard 2007), hvor der præsenteres en række gode råd omkring design af applikationer og hjemmesider til mobile enheder. Som Nielsen & Ramsay (2000: 4) og Webcredible (2007) også nævner, ser Ballard det som centralt, at applikationer (og hjemmesider), der skal bruges på mobile enheder, bliver designet direkte til de mobile enheder. Hvis man blot laver lidt om i en eksisterende applikation, der er designet til en computer, bliver det ikke en succes. Der er for store forskelle imellem, hvordan brugeren kan interagere med enhederne, samt hvad brugerne ønsker at anvende dem til. Brugerne er, når de anvender mobile enheder, som regel fokuserede på at nå et specifikt mål (spil og lignende er anderledes), og de er ikke interesserede i generel søgning efter information. Derfor er det vigtigt, at ens applikation er målrettet (Ballard 2007: 6).
Ballards syn på design til mobile platforme er, at det vigtigste for brugervenligheden er, at brugerne er tæt på de funktioner, de ønsker at anvende. Med tæt mener hun den mængde af bevægelse, en bruger skal lave for at komme hen til funktionen (for eksempel antal tryk på knapper). Derfor er det centralt, at brugergrænsefladen er opbygget, så de vigtigste funktioner er tættest muligt på brugeren. Dette betegner hun som Fitt’s lov (Ballard 2007: 69). Vi har søgt at følge denne ved kun at putte de mest nødvendige funktioner ind på hver side, således at der ikke er langt imellem dem.
I forhold til sikkerheden har Ballard (2007: 79) følgende afvejninger i forhold til usability:
1. Indtastning af passwords behøves ikke at blive maskeret med *. Det er sjældent, at brugeren lader andre se skærmen nok til, at det er nødvendigt.
2. Cookies og sessioner skal have lang levetid, da brugeren altid har enheden på sig og hurtigt opdager, at den er mistet, og derfor er det ikke en stor risiko.
I forhold til punkt 1 mener vi, at det kan være acceptabelt for lavrisiko-applikationer, men for en mobilbank, hvor folk kan lave eksterne transaktioner, er det ikke acceptabelt. Punkt 2 er mere acceptabelt, men da vi ikke har kontrol med mobilnettet, er det vigtigt, at vi ikke sætter for korte timeouts, hvilket vi har taget højde for i designet ved at give sessioner en levetid på 15 minutter.
Da enhederne bruges mobilt, er der stor risiko for, at brugeren bevæger sig ind i områder med dårlig eller ingen dækning. Her er det vigtigt, at applikationen kan håndtere dette uden at miste data eller kræve, at brugeren logger ind igen og skal manøvrere tilbage til der, hvor han/hun var tidligere (Ballard 2007: 81).
Der er mange måder at lave gode velfungerende websider til mobile enheder ifølge Ballard (2007: 83ff):
- Man kan lave siden til en bestemt telefonbrowser.
- Siden kan designes ud fra laveste fællesnævner og dermed få flest mulige browsere med, hvilket kan sænke funktionaliteten.
- Automatisk oversættelse; serveren opdager, hvilken browser brugeren benytter, og præsenterer et design, der er skræddersyet til den.
- Klassebaseret; man opdeler de enheder, man kan forvente, at brugerne anvender, i forskellige klasser og designer en side til hver klasse. Klasserne kan for eksempel være almindelige telefoner, smartphones og PDA’er med touchscreen.
Vi har i mobilbank-prototypen primært forsøgt at designe efter mindste fællesnævner, så mobilbank-prototypen kan vises i flest mulige mobile browsere. Dette skyldes især den meget begrænsede WAP-browser i selv nyere Nokia-telefoner (se afsnit 7.3.4).
Ballard anbefaler en række patterns for, hvordan man bør lave den visuelle opbygning af brugergrænsefladen (Ballard 2007: 101ff). Her anvender vi en række af dem, der passer godt til vores formål; det drejer sig blandt andet om det liste-baserede design, hvor siderne er opbygget som en lang liste. Dette anbefales til enheder, hvor skærmen er højere, end den er bred, og hvor brugeren primært navigerer ved hjælpe af knapper, hvilket vi forventer, at hovedparten af vores brugere vil anvende, da det er sådan, de fleste telefoner er konstrueret. Antallet af resultater fra dataopslag skal helst kunne være på en side, uden at brugeren skal scrolle (Ballard 2007: 106). Dette opnår vores prototype på den horisontale led, når man anvender den på telefoner med en standardopløsning på 320*240 pixels. Det kan dog være nødvendigt, afhængig af telefonmodel, at ændre i måden, telefonens browser viser websiden på eller at sætte skriftstørrelsen i browseren et punkt ned for at opnå dette.
Brødkrummer er en god og ofte anvendt hjælp til navigation, men på sider til enheder, der kræver, at brugeren benytter knapper til at navigere igennem en side, bør brødkrummer kun befinde sig i bunden, da de ellers giver for mange tastetryk, mener Ballard (2007: 110).
Gennemgangen af ovenstående litteratur har givet os en teoretisk baggrund til at arbejde ud fra i vores design af prototypen, og derfor vil vi i det følgende afsnit beskæftige os med at definere målgruppen.
5.4 Målgruppe
I de foregående afsnit har vi gennemgået nogle generelle guidelines til at sikre brugervenlighed på mobile webapplikationer. Et andet, og meget vigtigt, punkt i designet af en brugervenlig mobilbank er at lave nogle overvejelser over, hvem målgruppen er. Dette vil vi beskæftige os med i det følgende afsnit.
Målgruppen skal defineres for at sikre, at webstedet har de funktioner, målgruppen ønsker. Det sikrer webstedets nytteværdi, som er en vigtig del af brugervenligheden (Molich 2003: 41). Derudover skal brugeropgavernes fastlægges; det vil sige, at man skal finde ud af, hvilke funktioner brugerne ønsker sig. Endeligt bør man etablere et godt samarbejde med typiske brugere, der kan hjælpe med hurtigt at afklare tvivlsspørgsmål. Dette vil vi gøre i form af de brugertests, som vi gennemfører (se afsnit 8).
5.4.1 Mobilbankens målgruppe
Brugerne af en mobilbank-løsning udviklet til BEC vil højst sandsynligt være kunder, der benytter enten netbank eller sms-service[10] i forvejen. Den traditionelle netbank benyttes af alle typer af brugere, både it-eksperter og -novicer samt bankkyndige og -ukyndige. Det vil derfor være svært at definere en præcis målgruppe for netbanken, og det samme gælder sms-service.
Ikke desto mindre vil målgruppen for mobilbanken sandsynligvis være mere begrænset, da det stadig ikke er normen for alle befolkningsgrupper at tilgå internettet via mobiltelefonen, selvom det bliver mere udbredt. Man kan argumentere for, at det især er teknologi-interesserede og/eller yngre personer, der ville være interesserede i denne mulighed.
En målgruppebeskrivelse for vores mobilbank kunne altså være:
Målgruppe 1: Den yngre
kunde
Brugerne anvender mobilbanken jævnligt for lige at tjekke saldoen og for at se, at weekendens festudgifter ikke er gået for hårdt ud over bankkontoen.
De overfører indimellem penge til vennernes konti, fordi de har lånt penge af dem en dag, de ikke lige havde kontanter med, eller fordi de har afholdt et arrangement, hvor arrangøren lagde ud for udgifterne.
Målgruppen er ikke synderligt bekendt med banktekniske begreber, men de forstår ord som overføre, indsætte, betale, saldo og rente, mens mere komplekse banktermer såsom kreditor og portefølgeberegning ikke forstås.
Brugerne er vant til at bruge den almindelige netbank flere gange om ugen, og de ser mobilbanken som en praktisk tilføjelse til netbanken.
Målgruppe 2: Den
teknologi-interesserede, lidt ældre kunde
Brugerne anvender mobilbanken jævnligt for lige at tjekke saldoen og for at se, at deres regninger er blevet betalt som ventet. De tjekker deres Betalingsservice-oversigt og afviser eller ændrer eventuelt en kommende betaling.
Indimellem overfører de også penge til andre personers konti.
Målgruppen er ikke synderligt bekendt med banktekniske begreber, men de forstår ord som overføre, indsætte, betale, saldo og rente, mens mere komplekse banktermer såsom kreditor og portefølgeberegning ikke forstås.
Brugerne er vant til at bruge den almindelige netbank flere gange om måneden, og de ser mobilbanken som en praktisk tilføjelse til netbanken.
Når målgruppen er fastlagt, bør det klarlægges, hvilke funktioner, målgruppen ønsker sig i mobilbanken. Vi har valgt at fokusere på målgruppe 1, den yngre kunde, i resten af dette speciale, da det er en gruppe, vi både kan identificere os med samt få forholdsvist nem adgang til at lave undersøgelser blandt. For at klarlægge, hvilke funktioner målgruppe 1 ønsker sig, har vi gennemført en spørgeskemaundersøgelse på RUC. Resultatet af denne vil blive gennemgået i afsnit 7.1.2.
6 Usable security
I de foregående kapitler har vi gennemgået både sikkerhed og usability, som ofte opnår at stå som modsætninger over for hinanden. I det følgende afsnit vil vi derfor diskutere, hvordan man kombinerer disse to faktorer, så man opnår, hvad man kan kalde for ’usable security’ samt hvordan dette lidt svævende begreb kan overføres til en mobilbank.
6.1 Definition af usable security
Behovet for at tænke usability med i systemers sikkerhed blev første gang påvist i 1975, da Jerome Saltzer og Michael Schroeder slog fast, at der var et behov for en psykologisk accept, hvis sikrede systemer virkelig også skulle være sikre (Sasse & Flechais 2005: 20). Det betyder kort fortalt, at for at sikre psykologisk accept skal en sikkerhedsmekanisme tilføje så lidt som muligt til sværhedsgraden af en bestemt opgave, som en person ønsker at udføre. Brugeren skal altså ikke være tvunget til at foretage sig mere, end det, der var nødvendigt, hvis sikkerhedsmekanismen ikke var påført (Bishop 2005: 2). Og hvis brugerens mentale bilede af sine sikkerhedsbehov matcher de sikkerhedsmekanismer, han/hun skal bruge, så er det mere sandsynligt, at fejl vil blive minimeret:
”If he must translate his image of his protection needs into a radically different specification language, he will make error.” (Saltzer & Schroeder, iflg. Bishop 2005: 2)
Traditionelt har man forsøgt at højne den psykologiske accept blandt brugerne ved at forsøge at gøre sikkerheden nemmere at bruge gennem en forbedring af brugergrænsefladen (Sasse & Flechais 2005: 20). Det er da også rigtigt, at en dårligt designet brugergrænseflade kan ødelægge et ellers udmærket fungerende system, hvorimod en veldesignet brugergrænseflade ikke kan redde et system, som ikke tilbyder den krævede funktionalitet (Sasse & Flechais 2005: 21). Systemet kan altså være brugervenligt uden nødvendigvis at være brugbart. Et sikkert system skal derfor både være brugbart og brugervenligt, før man kan snakke om usable security:
En vigtig pointe er altså, at hvis sikkerheden gør, at den ønskede funktion er så svær eller besværlig at gennemføre, at brugeren fravælger funktionen, så er systemet ikke brugbart på grund af manglende brugervenlighed.
En af de mest kendte artikler om begrebet usable security er ”Why Johnny Can’t Encrypt” af Whitten og Tygar (2005). Her laver forfatterne en usability-undersøgelse af PGP 5.0, et krypteringsprogram, der blandt andet kan kryptere e-mails. Artiklen handler om, hvordan det sikre kan forenes med det brugbare, og forfatternes hypotese er, at de gængse principper for brugervenlighed ikke nødvendigvis gør det muligt at lave et sikkerhedskritisk produkt, som brugerne kan finde ud af at anvende uden at sætte sikkerheden over styr.
Dette skyldes en række faktorer: 1) Brugerne bliver ikke gjort opmærksomme på, hvilke sikkerhedsforanstaltninger de skal tage, 2) hvordan de gør dette, 3) designet skal laves sådan, at brugerne ikke kan lave ”farlige” fejl, og 4) brugerne skal være komfortable med at anvende interfacet. De første tre punkter vil ofte blive glemt i traditionelt design (Whitten & Tygar 2005: 672). Desuden er der i den normale designtradition, som ovenfor nævnt, en konflikt mellem ”nemt at bruge” og ”sikkert”.
Balfanz et al (2004: 6) er ligeledes nået frem til, at it-sikkerhedsprodukter oftest fejler på grund af manglende brugervenlighed: Enten forstår brugerne ikke de sikkerhedsmæssige implikationer af deres handlinger, eller også slår de sikkerhedsfunktionerne fra for at opnå deres mål.
Der er flere måder at omgå dette. Smetters og Grinter (2002: 84) mener, at løsningen ikke er at lave programmet og så senere påføre sikkerheden; sikkerhed skal derimod være et designkrav fra starten og tænkes ind i hele processen. Sikkerhed er ikke noget, der kan kobles på senere. Samtidig må sikkerheden ikke designes først og bagefter gøres brugervenlig (Balfanz et al 2004: 4ff). Inden for sikkerhedsprodukter er det næsten blevet kutyme at ignorere brugernes ønsker og i stedet kun fokusere på, hvordan man laver sikre løsninger (Balfanz et al 2004: 4ff). Dette vil give lige så store problemer, som hvis man designede programmerne uden sikkerhedsmekanismer. Derfor skal både usability og sikkerhed tænkes med fra starten. Hvis brugeren bliver forhindret i at opnå sine mål af en sikkerhedsfeature, vil brugeren forsøge at slå sikkerheden fra.
Det, mener vi, betyder, at brugeren i praksis ikke skal kunne fravælge sikkerheden i systemet. Det kan man for eksempel opnå gennem brugen af OTP-tokens, der genererer koder, der kun kan bruges en enkelt gang. Disse koder kan brugeren ikke skrive ned nogen steder, og dermed får man mindst et punkt mindre, hvor brugeren bevidst kan fravælge sikkerheden. Et alternativ er printede engangskoder, der, selv om de er printede, stadig giver mere sikkerhed end blot et traditionelt, fast password. For begge løsninger gælder det dog, at brugeren kan opbevare sit faste password sammen med OTP-token eller engangskoder, hvorfor løsningerne ikke 100 procent kan afværge, at brugeren fravælger sikkerheden. Det samme gælder vores løsning med engangslinks sendt vis sms. Et andet eksempel på, at brugeren ikke skal kunne fravælge sikkerheden, er brug af SSL uden at tilbyde usikrede sider også.
Men selv om man altså teoretisk set skal stræbe mod at udvikle systemer, hvor brugeren ikke – bevidst eller ubevidst – kan fravælge sikkerheden, så kan man diskutere, om det i praksis er muligt i alle sammenhænge.
6.2 Teoretisk sikkerhed versus sikkerhed i praksis
Gennem mange år har computerbrugere lært, at sikkerhed
hænger uløseligt sammen med komplekse systemer, der er svære at bruge. En konklusion, der ikke nødvendigvis
er sand:
“… the more complex a system is, the more
secure it should be – yet the less secure it is likely to be, because of
the complexity designed to add security” (Bishop 2005: 1).
Fokus på brugervenligheden kan altså være med til at sikre, at systemerne også bliver sikre at bruge i praksis. Man kan dog aldrig sikre sig 100 procent mod personer, der af den ene eller anden grund bevidst omgår sikkerheden; for eksempel en person, der for at huske koden til sit MasterCard skriver pinkoden ned på kortet. En praksis, der ifølge Sasse & Flechais (2005: 17) er meget almindelig blandt bankkunder. På samme måde skriver mange brugere deres password ned.
Teoretisk sikre systemer stiller nemlig ofte store krav til brugerne, blandt andet når det gælder passwords. Det kan for eksempel være, at brugerens password skal have en vis længde, kompleksitet (specialtegn, store/små bogstaver m.m.), samt at passwordet skal ændres med et fast interval. Sådanne regler kan som nævnt tvinge folk til at nedskrive deres ellers hemmelige password eller dele det med andre, og derved kompromitteres sikkerheden i systemet. Derfor kan et teoretisk mere usikkert system, der for eksempel benytter mindre strenge passwordregler, i praksis vise sig at være mere sikkert (Adams & Sasse 1999: 41 og Payne & Edwards 2008: 14).
Man kan dog også argumentere for, at krav til stærke passwords er nødvendige, da brugere ellers har en tendens til at vælge passwords, der er nemme for en uautoriseret person at gætte.
It-sikkerhedseksperten Bruce Schneier skrev i 2006 en artikel om et MySpace phishing-angreb. Her var det lykkedes angribere at indsamle mere end 100.000 brugernavne og password; heraf fik Bruce Schneier gennem en kollega adgang til 34.000 reelle brugernavne og passwords, som han derpå analyserede: Han fandt, at gennemsnitslængden på et password var otte karakterer, men at hele 17 procent havde et password på seks karakterer eller derunder. 28 procent af de fundne passwords bestod blot af små bogstaver plus en enkelt tal – heraf var en tredjedel tallet 1. Det mest brugte password var password1, som blev brugt af 0.22 procent (ca. 75 brugere), mens ordet password indgik i næsten en procent (ca. 340) af brugernes password (Schneier 2006 & Grimes 2006).
6.3 Opnåelse af usable security
Der er mange metoder til at opnå usable security. I en undersøgelse af danske netbankers sikkerhed og brugervenlighed (Hertzum et al 2004: 7) nævnes tre tilgange, der kan medvirke til, at man kan opnå usable security:
- Instruktion dækker over, at brugerne på den ene eller anden måde bliver instrueret i at anvende programmet: Det kan være alt fra hjælpetekst i selve programmet til kurser eller anden undervisning. Problemet er her, at instruktioner ikke kan dække alle de potentielle situationer, brugerne kan komme ud for, og instruktionerne kan gøre brugerne endnu mere uforberedte på de situationer, der ikke er dækket. Som eksempel kan nævnes forløbet med at installere netbankers signaturfiler. Her var netbanken ikke i stand til at give brugerne en ordentlig hjælpeinstruktion, da brugere kan anvende forskellige browsere eller versioner af disse, hvor de dialogbokse, brugeren bliver præsenteret for, ser vidt forskellige ud (Hertzum et al 2004: 5ff).
Der er dog også en risiko ved, at brugeren får meget detaljerede instruktioner. Balfanz et al (2004: 3) gennemførte et forsøg, der viste, at selv folk med ph.d.-grader i datalogi, der blev udsat for detaljerede instruktioner, oplevede, at deres tekniske overblik blev reduceret i en sådan grad, at de ikke var i stand til at tænke over, hvad de lavede. I stedet fulgte de bare guiden blindt, hvilket medførte, at de ikke var i stand til at udføre basal fejlsøgning, når noget gik galt. Hvis dette er rigtigt, vil det være et stort problem for en sikkerhedskritisk applikation. Derfor kan der være gode grunde til ikke at lave instruktioner, som brugerne skal følge alt for nøje. For detaljerede instruktioner kan altså komme i konflikt med brugerens forståelse af systemet.
- Automatisering går ud på at minimere antallet af opgaver, brugeren skal udføre. Det kan for eksempel være, at man laver en ”husk password”-funktionalitet, eller at man samler udførte funktioner i en ”kuvert”, således at de kun skal godkendes en gang. Det vil sige, at antallet af de opgaver, brugeren skal udføre, bliver minimeret og i så stor mulig grad udført af systemet. Det er dog den af de tre muligheder, der er sværest at gennemføre, uden at det går ud over sikkerheden.
- Den sidste tilgang til at opnå usable security er forståelse, hvor man forsøger at få brugeren til at forstå systemet og de nødvendige sikkerhedsopgaver, der ligger bagved, så brugeren bliver i stand til at træffe fornuftige valg, der er begrundet i en viden om systemet. Problemet ved denne fremgangsmåde er, at brugerne ofte ikke er interesseret i at lære om sikkerhed, samt at sikkerhedskritiske systemer, såsom en mobilbank, ikke egner sig til, at brugeren lærer sig selv om systemet ved ’trial-and-error’, det vil sige at prøve sig frem og lære gennem sine fejl.
Balfanz et al (2004: 6) nævner endnu et vigtigt middel til at opnå usable security, nemlig brugertests. De mener, at man ikke kan afgøre teoretisk, om et system har opnået usable security. Det kan kun afgøres ved at teste systemet med rigtige brugere. Dette passer godt til vores tilgang til vurdering af STS-modellen, hvor vi laver prototypen for netop at kunne lave slutbrugertests og dermed opnå materiale til at konkludere på vores problemstilling.
6.4
Usable
security i mobilbank-prototypen
Smetters & Grinter (2002: 84) mener, som ovenfor nævnt, at sikkerhed skal være et designkrav fra starten og tænkes ind i hele processen. Vi er enige i synspunktet. Brugeren skal altså i praksis ikke kunne fravælge sikkerheden i systemet: Sikkerheden skal både tænkes med fra starten af udviklingsprocessen, og sikkerheden skal integreres så dybt i applikationen, at det ikke er muligt at gennemføre opgaverne på en usikker måde. Derfor har vi også arbejdet på, at vores forslag til en mobilbankløsning lever op til disse principper. Som Hertzum et al (2004: 2) er inde på, er det nemmere at integrere sikkerhed i en applikation som vores mobilbankprototype, da det ikke giver mening at give brugeren mulighed for at udføre usikre opgaver, som det eksempelvis er tilfældet i et e-mail program, hvor brugeren kan have gode grunde til både at ville kunne sende krypterede og ukrypterede e-mails. Problemet er også, at brugerne ikke er interesseret i sikkerheden direkte. De vil udføre en opgave (og gerne sikkert), men de er ikke motiverede til at udføre ekstra opgaver for at få sikkerheden eller læse store manualer. Sikkerhed er også et meget abstrakt emne, som mange brugere ikke er i stand til at forstå, og derfor er det især vigtigt med god feedback til brugerne, så de bliver forhindret i at lave farlige fejl. Men denne feedback kan være svær at generere, da ofte kun brugeren ved, hvad de selv forsøger at opnå. Samtidigt er et sikkerhedssystem kun lige så stærkt som det svageste led, og hvis en hemmelighed først er sluppet ud, kan det være umuligt at trække den tilbage igen (Whitten & Tygar 2005: 673). Vi ser disse pointer som meget relevante for dette speciale på trods af, at vi ikke mener, alle punkterne er lige relevante for vores forslag til en mobilbankløsning. Vi er dog, som tidligere nævnt, helt enige i punktet om, at sikkerheden skal være så dybt integreret i applikationen, at brugeren ikke skal foretage sig ekstra ting ud over de nødvendige for at opnå sine egentlige funktionelle mål – i dette tilfælde kan det for eksempel være at overføre penge eller på anden måde administrere sine konti.
Som vi ser det, er de farligste fejlmuligheder, brugeren har i en mobilbank baseret på STS-modellen, ikke sikkerhedsrelaterede, men funktionelle, nemlig at de kommer til at overføre penge til den forkerte modtager. I denne forbindelse er det vigtigt med god feedback til brugeren. Dette er også betinget af, at en mobilbank, ligesom sikkerhedssoftware, ikke giver den store mulighed for ’trial and error’-anvendelse, hvor brugerne lærer af sine egne fejl. Hvis brugerne først laver fejl, så kan det have store konsekvenser for indholdet på deres konti. I denne forbindelse har vi i dette speciale dog en fordel frem for de mere generelle applikationer, som nævnes i Whitten og Tygars artikel, idet vores løsningsforslag har en meget begrænset funktionalitet. Derfor kan vi i langt højere grad forudse, hvad brugeren forsøger at opnå. Da sikkerheden er central i en mobilbank, har vi i designet af prototypen i størst mulig udstrækning arbejdet på at gøre det umuligt for brugeren at lave noget sikkerhedsmæssigt farligt (ud over den tidligere nævnte fare for at overføre et beløb til en forkert konto). Vi mener, at vi har reduceret den sikkerhedsmæssige kompleksitet i vores prototype, således at brugeren ikke burde kræve store mængder af instruktion for at anvende den (sikkert). Vi kan ikke være sikre på, hvordan brugerens mobilinterface ser ud og kan derfor ikke tilbundsgående forklare, hvordan de sender signon–sms’en. Her kan vi i stedet udnytte, at brugeren af en mobiltelefon allerede ved, hvordan man sender og læser sms-beskeder. Da vores prototype er baseret udelukkende på HTML og ikke for eksempel en Java-applet, kan vi sikre os, at brugeren ikke bliver stillet spørgsmål, de ikke kan svare på, imens de bruger applikationen. Set i forhold til eksemplet i Hertzum et al (2004: 6), hvor en bruger, der vil installere netbankens signaturfil, bliver stillet en lang række sikkerhedsspørgsmål, som banken ikke kan forudse, så kræver vores prototype ikke nogen installation, og vi kan forudse alle de spørgsmål, mobilbanken vil stille – med meget få undtagelser. Undtagelserne kan for eksempel være, hvis mobiltelefonen mister internetforbindelsen. I så fald ved vi ikke præcist, hvad mobiltelefonens browser vil sige.
Set i forhold til anbefalingerne i undersøgelsen af danske netbankers sikkerhed (Hertzum et al. 2004) har vi i mobilbanken opnået en stor grad af automatisering, idet alle sikkerhedsopgaver er automatiseret i sådan en grad, at brugeren ikke skal foretage noget ud over det, som han/hun bliver ledt igennem. Vi ser ikke umiddelbart mulighed for, at opgaverne kan automatiseres yderligere uden at gå på kompromis med sikkerheden. Vores problem er det samme som det, der eksisterer for de banker i undersøgelsen, der ikke bruger signaturfiler: Hvis man automatiserer yderligere, skal man anvende metoder såsom passwordhuskere, eller man skal reducere antallet af gange, brugeren skal indtaste passwordet (Hertzum et al. 2004: 7). Dette ville dog svække sikkerheden i mobilbanken.
7 Prototype
I de foregående kapitler har vi gennemgået en række teorier omkring sikkerhed og usability. I det følgende kapitel vil vi gennemgå den mobilbank-prototype, som vi har udviklet på baggrund af teoriapparatet.
Prototyper kan opbygges både horisontalt og vertikalt: Horisontale prototyper indeholder alle funktioner, men de er ikke implementeret i dybden. Det vil sige, at man har hele brugergrænsefladen i systemet, mens den faktiske funktionalitet endnu ikke er implementeret. En vertikal prototype, derimod, implementerer funktionaliteten i dybden, om end kun for et begrænset område af prototypen (Nielsen 1993: 93ff):
(Figur 12: De to forskellige dimensioner inden for prototyper, modelleret
efter Nielsen 1993: 95)
Formålet med disse begrænsninger i implementeringen er, at prototypen kan produceres hurtigere, og dermed kan konklusioner på baggrund af usability-tests af prototypen uddrages hurtigere. Der er flere måde at begrænse prototypen på. En horisontal prototype kan eksempelvis gøre brug af papir-mockups, der illustrerer brugergrænsefladen uden at implementere den. En anden metode er at acceptere simplere algoritmer og/eller mindre pålidelig og dårlig kode, der kan give fejl og nedbrud i systemet. Dette må testlederen så kompensere for i testene (Nielsen 1993: 95ff).
I vores prototype har vi således bestemt nogle begrænsninger, som kan accepteres i prototypen, men ikke i en endelig, produktionsklar udgave af mobilbanken. Det gælder koden og den bagvedliggende database (se afsnit 7.3), der begge ville kunne optimeres, og det samme gælder de implementerede funktioner: Vi har således bestræbt os på at lave en vertikal prototype, der giver mulighed for at teste så mange funktioner som muligt i praksis i brugertesten (se afsnit 8), men nogle funktioner vil ikke være implementeret fuldt ud. For eksempel er det i prototypen ikke alle ændringer, der skal godkendes, men kun oprettelse af nye betalinger og ændring af eksisterende betalinger (se også afsnit 7.3.5).
I de følgende afsnit vil vi først gennemgå, hvilke funktioner der ud fra målgruppen (den yngre kunde) og aftageren (BEC’s banker) vil være relevante at medtage i prototypen. Dernæst vil vi gennemgå prototypens visuelle opbygning, det vil sige brugergrænsefladen, og endeligt vil vi – om end ganske kort – forklare prototypens tekniske struktur.
7.1 Funktioner i mobilbanken
Den begrænsede skærmstørrelse på mobiltelefoner og PDA’er gør det nødvendigt at tænke mere indgående over, hvilke funktioner der er de vigtigste at have med i en mobilbank: Hvis mobilbanken bliver for kompleks, kan man risikere, at brugerne ikke vil benytte den, og hvis der er få for funktioner, risikerer man det samme. Hvis BEC skal afsætte ressourcer (tid og penge) til at udvikle en mobilbank, er det ønskværdigt med en afklaring af, hvilke funktioner det vil være hensigtsmæssigt at have med. Dette vil vi i de følgende afsnit analysere; dels ud fra en afklaring af bankernes ønsker, dels ud fra en afklaring af kundernes ønsker.
7.1.1 Bankernes ønsker
BEC har tidligere haft en WAP-løsning, der dog havde meget begrænset funktionalitet. Det blev besluttet i 2005, at WAP-løsningen skulle nedlægges pr. 15. januar 2006. Årsagen var, at der næsten ingen brugere var – mellem 1 og 14 om dagen. Samtidig var løsningen teknisk forældet, idet løsningen var udviklet til WAP 1.1 browsere og ikke virkede i nyere versioner (1.2.1 og 2.0). Derfor var det umuligt for nyere telefoner at benytte løsningen. Og da der kan antages at være en sammenhæng imellem dem, der vil bruge en WAP-løsning, og dem, der køber de nyeste telefoner, var det særligt problematisk. Selv om disse tekniske hindringer kunne være en forklarende årsag til, at der kun var få kunder, som benyttede WAP-løsningen, vurderede BEC’s kunder (bankerne), at omkostningerne ved en teknisk opgradering og det fremtidige vedligehold ikke ville blive modsvaret af en væsentlig øget anvendelse af produktet.
BEC havde ellers præsenteret en løsning til opgradering af WAP-løsningen, men bankerne ønskede ikke at betale for det, da de ikke mente, at de kunne øge antallet af brugere nok til, at det var forretningsmæssigt forsvarligt. En projektleder hos BEC gav i et interview foretaget i forbindelse med dette speciale udtryk for, at løsningen simpelt hen var for tidligt ude. Folk var ikke klar til løsningen, den kunne for lidt og teknologien var ikke moden.
Det mener han dog, at teknologien er nu: Telefonerne har fået skærme, der kan præsentere data pænt, og brugerne har taget det mobile internet til sig. For eksempel har den gratis mobilbrowser Opera Mini over 40 millioner brugere, ifølge deres hjemmeside. Som projektlederen hos BEC ser det, ville det være meget attraktivt for BEC at lancere en mobilbank inden for en overskuelig periode – særligt fordi netbankbrugerne gerne vil anvende deres mobiltelefoner til at gå i banken: I en undersøgelse blandt danske netbankkunder foretaget i august 2007 af Analyse Danmark blev det således konkluderet, at 22 procent af netbankkunderne ville bruge mobiltelefonen til deres netbanktransaktioner, hvis de fik muligheden (BEC 2007b: 7).
BEC foretog i 2007 en forundersøgelse af, hvilke funktioner der skulle være i en mobilbank med henblik på udvikling af en sådan (BEC 2007a). Forundersøgelsen definerede blandt andet en liste over den basale funktionalitet, som BEC’s banker kræver i en mobilbank:
- Oversigt over konti og posteringer
- Kommende betalinger, herunder BS (Betalingsservice)
- Overførsler til interne og eksterne konti
- Betaling af indbetalingskort
- Spærring af dankort
- Kurser på egne, udvalgte værdipapirer
- Kontaktoplysninger på kundens bankrådgiver
BEC specificerer specifikt i forundersøgelsen, at ”Det er vigtigt, at en mobil Webbank giver kunderne mulighed for at lave eksterne overførsler og betale indbetalingskort” (BEC 2007a).
Udviklingen af en mobilbank blev dog lagt på hylden i første omgang, blandt andet fordi BEC ikke havde styr på sikkerhedsmodellen. Samtidig ville BEC afvente, hvad der skulle ske med sikkerhedsmodellen i den almindelige netbank, som der pt. arbejdes på (se også afsnit 9.1). Hvis muligt bør den nye sikkerhedsmodel for netbanken også kunne benyttes på mobile enheder, vurderer BEC.
Bankernes ønsker er dog ikke hele billedet, og derfor vil vi i næste afsnit diskutere, hvad brugerne har af ønsker til en mobilbank.
7.1.2 Brugernes ønsker
Der er tidligere lavet undersøgelser af, hvilke funktioner brugerne kunne ønske sig i en mobilbank. For eksempel har Analyse Danmark hvert år siden 2003 i samarbejde med Finansrådet foretaget en stor undersøgelse, hvor de spørger danske netbankkunder om deres bankvaner. I 2007 blev undersøgelsen foretaget i perioden 8-20. august, og 8655 personer svarede på spørgsmålene.
22 procent af netbankkunderne angav, som tidligere nævnt, at de ville bruge mobiltelefonen til deres bankforretninger, hvis de kunne udføre det samme som i den almindelige netbank. Cirka halvdelen af disse personer angav yderligere, at de i så fald ville bruge mobilbanken til mere end 25 procent af deres netbankforretninger (BEC 2007b: 7). Undersøgelsen viser desuden, at jo yngre brugeren er, des mere åben er personen over for at bruge en mobilbank. BEC konkluderer, at der er et klart potentiale i at udvikle netbank-applikationer til mobile enheder (BEC 2007b: 8).
Men hvilke funktioner ønsker de adspurgte brugere så i mobilbanken? Det fremgår ikke af Netbankanalysen 2007, hvorfor der er behov for at foretage en sådan undersøgelse. Som tidligere nævnt gør den begrænsede skærmstørrelse på mobiltelefoner og PDA’er det nødvendigt at tænke mere indgående over, hvilke funktioner der er de vigtigste at have med i en mobilbank, idet man kan risikere, at brugerne ikke vil benytte den, hvis der er få for funktioner, eller hvis den bliver for kompleks. I det følgende afsnit vil vi derfor gennemgå resultaterne af en brugerundersøgelse foretaget på RUC.
7.1.3 Brugerundersøgelse
For at få en indikation af, hvilke funktioner brugere kunne tænke sig i en mobilbank, har vi valgt at gennemføre en spørgeskemaundersøgelse blandt undervisere og studerende på RUC. Samtidig vil vi afdække, om en af de tænkte målgrupper, den yngre kunde, overhovedet har interesse i at benytte netbank på mobiltelefonen. Som Netbankanalysen 2007 viste, angiver 22 procent af netbankkunderne, at de ville bruge en mobilbank, hvis de fik muligheden for det. Hvis det er korrekt antaget, at målgruppen for en mobilbank blandt andet er den yngre kunde (se afsnit 5.4.1), så vil en brugerundersøgelse på RUC indikere en større andel potentielle mobilbankbrugere end de 22 procent, som det konkluderes i Netbankanalysen 2007.
Undersøgelsens struktur og gennemførsel
Vores spørgeskema er en begrænset stikprøve, som vi gennemfører for at afdække vores målgruppes holdning til mobilbankløsninger. Vi udfører som tidligere nævnt stikprøven blandt undervisere og studerende på RUC, selvom vi godt er klar over, at de ikke udgør et repræsentativt udsnit af vores målgruppe, men primært dækker den del af målgruppe 1 (de unge), som læser på en videregående uddannelse. Dette, mener vi ikke, er et stort problem, da de alligevel udgør en stor del af målgruppen samt repræsenterer et stort udsnit af faglige baggrunde, og de er tilfældigt udvalgt blandt denne gruppe. Samtidig er spørgeskemaet blot en del af vores materiale, idet resultaterne skal sammenholdes med BEC’s forundersøgelser og krav til funktioner i mobilbanken.
Det rundsendte spørgeskema (se bilag 5) starter med nogle få spørgsmål, der skal klarlægge respondenternes demografiske data, såsom alder, køn og beskæftigelse. Dertil kommer spørgsmål, der giver en viden om, hvorvidt respondenterne bruger en traditionel netbank, om de har en mobiltelefon og hvorvidt de ønsker at bruge netbank på mobiltelefonen. De respondenter, der svarer ’ja’ eller ’ved ikke’ til, om de kunne tænke sig at bruge netbank på mobiltelefonen, blev derudover bedt om at svare på, hvilke funktioner de kunne tænke sig at have adgang til i en mobilbank. Vi har så vidt muligt forsøgt at lave klare præ-kodede spørgsmål uden nogen form for skjulte hensigter, som det anbefales af Boolsen (2004: 25ff).
Undersøgelsen blev gennemført blandt RUC-studerende og -ansatte i perioden mellem d. 27. maj og 5. juni 2008. Undersøgelsen blev foretaget ved, at der på mail-listerne [email protected] samt [email protected] blev sendt en mail ud, hvor vi bad folk om at svare på ovennævnte spørgeskema, som de kunne få frem ved at klikke på et link.
Da RUC-studerende kan beholde deres e-mailadresse, når de stopper på universitetet, er der også en mulighed for, at folk, som ikke længere studerer, besvarer spørgeskemaet.
Et andet forbehold er, at i og med, at undersøgelsen foretages online, vil der være en forholdsvist stor procentdel, der bruger nettet meget. Dette vurderer vi imidlertid ikke som et problem, da målgruppen netop omfatter brugere, der i forvejen bruger netbank og dermed nettet. Resultaterne burde altså stadig kunne give os et fingerpeg om, hvorvidt målgruppen virkelig er interesseret i at benytte mobilbank.
Konklusioner fra undersøgelsen
116 personer valgte at klikke ind på undersøgelsen i de 10 dage, spørgeskemaet var åbent. Heraf gennemførte de 115 personer undersøgelsen helt. De to mail-lister har tilsammen 1205 modtagere, der potentielt set kunne have svaret på spørgeskemaet. Kun 116 af disse valgte, som ovenfor nævnt, at klikke ind på spørgeskemaet. Det giver en svarprocent på lidt under 10 procent. Vi kan dog af gode grunde ikke vide, hvor mange af de tilmeldte, der rent faktisk læser post på de e-mailkonti, der er tilmeldt postlisterne. 10 procent er ifølge Merete Boolsen (2004: 70) for lidt til, at man kan generalisere og kalde undersøgelsen fuldt ud repræsentativ for målgruppen, men det er heller ikke formålet med vores undersøgelse. Vi mener, at undersøgelsens resultater alligevel er brugbare, da vi med undersøgelsen fik godt fat i de unge. 93,9 procent af besvarelserne blev således afgivet af personer under 35 år, som det ses i nedenstående figur:
Figur 13: Respondenternes aldersfordeling
Besvarelserne er nogenlunde ligeligt fordelt mellem mænd (56 procent) og kvinder (44 procent). Langt størstedelen af respondenterne, nemlig 95,7 procent, benytter almindelig netbank i forvejen, mens samme antal benytter internettet hver dag. Alle respondenter har en mobiltelefon, og heraf kan 66,4 procent gå på internettet, mens 6 procent svarer ’ved ikke’ til spørgsmålet om, hvorvidt mobiltelefonen kan gå på internettet. Et af de mere interessante tal er, hvor mange af respondenterne, der er interesserede i at benytte netbank på mobiltelefonen. Fra Netbankanalysen 2007 ved vi, at den samlede andel af befolkningen, der er interesseret i dette, er på 22 procent. Vi bør dog kunne forvente en højere andel, såfremt vi med vores spørgeskema har fået fat i målgruppen. Det viser sig da også at være tilfældet: Som det kan ses i figur 13, siger 43,1 procent, at de ville være interesserede i at bruge netbank på mobiltelefonen, hvis netbanken var tilpasset den lille skærm, mens 17,2 procent svarer ’ved ikke’. Kun 39,7 procent svarer direkte nej til spørgsmålet, og det er således en ret stor andel af first movers, der her er tale om. Så vi kan konkludere at der er en stor interesse for en mobilbank blandt unge mellem 15 og 35 år. Der skal dog tages det forbehold, at de respondenter, der valgte at klikke ind på spørgeskemaet, var klar over, at undersøgelsen omhandlede netbank på mobiltelefonen. Der kan derfor argumenteres for, at antallet er respondenter, der er positivt interesserede i en mobilbank, kan være kunstigt højt. Vi mener dog stadig, at konklusionerne fra undersøgelsen er valide, idet det primære formål med undersøgelsen var at få klarlagt, hvilke funktioner potentielle mobilbank-brugere kunne tænke sig at få adgang til, og ikke hvor stort behovet for en mobilbank er.
Figur 14: Interesse i mobilbank
Men hvilke funktioner har respondenterne så ønske om? Som det kan ses af nedenstående tabel (figur 15), så er det især fem funktioner, der falder i øjnene som meget ønskede af de potentielle brugere, nemlig tjekke saldo på egne konti, tjekke posteringer på egne konti, overføre penge mellem egne konti, overføre til eksterne konti og spærring af dankort, som mere end tre fjerdedele af respondenterne er ’interesseret’ eller ’meget interesseret’ i.
Dertil kommer en række funktioner såsom betale girokort, se kommende betalinger samt afvise/ændre kommende betalinger, der alle er ønskede i et vist omfang; således er mellem 40 og 59 procent af respondenterne ’interesseret’ eller ’meget interesseret’ i disse funktioner.
Endelig kan vi kategorisere de resterende funktioner som nogle, respondenterne kun i begrænset omfang er interesserede i, nemlig handle aktier og ansøge om lån, som mellem 70 og 82 procent af respondenterne slet ikke er interesserede i at benytte. Vi tolker svarene som, at respondenterne ser mobilbanken fra samme synspunkt som os selv, nemlig noget, der skal gøre de små bankforretninger nemmere for dem hurtigt at foretage på farten. De mere komplicerede funktioner, såsom betaling af girokort (de er besværlige at indtaste), ansøge om lån og handle aktier, får en lavere vurdering. Det skal dog nævnes, at ”handle aktier”-punktet også kan blive påvirket af, at respondenterne i vores undersøgelse er unge, og derfor er det ikke sikkert, at de beskæftiger sig med aktiehandel.
|
Hvor interesseret er du i følgende funktioner, hvis du skulle bruge
netbank på mobilen? (Fed skrift markerer
største procentdel for hver funktion) |
|||||
|
|
Slet ikke |
Lidt interesseret |
Interesseret |
Meget interesseret |
Ved ikke |
|
Tjekke saldo på dine konti |
1,4% |
4,3% |
27,5% |
66,7% |
0,0% |
|
Tjekke posteringer på dine konti |
1,5% |
16,2% |
38,2% |
41,2% |
2,9% |
|
Overføre penge mellem egne konti |
4,3% |
21,7% |
27,5% |
46,4% |
0,0% |
|
Overføre penge til eksterne konti (Fx. til en ven) |
4,3% |
13,0% |
34,8% |
47,8% |
0,0% |
|
Betale girokort |
9,0% |
35,8% |
25,4% |
29,9% |
0,0% |
|
Se kommende betalinger |
9,1% |
31,8% |
37,9% |
21,2% |
0,0% |
|
Afvise/ændre kommende betalinger |
10,4% |
47,8% |
26,9% |
13,4% |
1,5% |
|
Handle aktier |
70,6% |
19,1% |
5,9% |
1,5% |
2,9% |
|
Spærre dit dankort |
3,0% |
4,5% |
20,9% |
70,1% |
1,5% |
|
Ansøge om lån |
82,4% |
11,8% |
1,5% |
1,5% |
2,9% |
Figur 15: Ønsker til funktioner i en mobilbank
Ud over disse valgmuligheder gav vi også respondenterne mulighed for selv at komme med forslag til funktionalitet. Her var der kun 8 personer, der skrev noget, og af dem var der kun få, der kom med egentlige forslag til funktionalitet. Her var forslagene, at man skulle kunne skrive e-mails til sin bankrådgiver/banken og bestille udenlandsk valuta. Vi ser muligheden for at skrive e-mails til banken som spændende funktionalitet, som man kunne undersøge i senere udgaver af mobilbanken. Men vi ser ingen af de givne forslag som så essentielle, at de kommer med i vores prototype. Dels fordi det kun er få respondenter, der har ytret ønske om det, og dels fordi det ville tilføje en hel del kompleksitet til vores prototype.
I forhold til bankernes ønsker så er der en høj grad af overensstemmelse mellem disse og respondenternes ønsker. Der er kun to ting, bankerne ønskede, som brugerne ikke viste større interesse i, nemlig betaling af girokort og muligheden for at se kurser på aktier. Det første ser vi som for besværligt i forhold til telefonernes input muligheder, og det er dermed ikke en funktion, der passer til en mobilbank, hvilket brugerne tilsyneladende er enige med os i. Med hensyn til kurser på aktier kan det i stor grad være et spørgsmål om forskellige målgrupper. Dog var der ikke umiddelbart nogen sammenhæng mellem alder og interesse i at handle aktier. 67 procent af respondenterne over 36 år sagde, at de slet ikke var interesseret (dog skal det nævnes, at de kun udgjorde syv besvarelser).
Validiteten af vores undersøgelse, mener vi, er høj set i forhold til vores formål, hvor resultaterne blot skal bruges som indikationer af, hvilken funktionalitet der ønskes. Set i forhold til Merete Boolsens krav (2004: 29) mener vi, at vores spørgeskema opfylder kravene til gyldighed og præcision, da vi har forsøgt at bruge meget præcise spørgsmål, der klart spørger til det, vi ønsker at afdække, og vi anvender kun relevante begreber, som vi forventer, at respondenterne forstår. Vi ser også spørgsmålene og svarmulighederne som objektive, og derved giver de ikke den store mulighed for alternative konklusioner.
Det eneste problem, vi ser i undersøgelsen, er, at vi har svært ved at udtale os om, hvorvidt resultaterne er klart repræsentative, da vi kun har sendt spørgeskemaet ud til en mindre del af vores målgruppe, og derfor kan der være afvigelser i den bredere del af målgruppen.
Alt i alt mener vi dog, at undersøgelsen er gyldig i forhold til de mål, vi forsøger at opnå: Undersøgelsen skal give os ekstra materiale til vores overvejelser omkring, hvilken funktionalitet der er nødvendig i mobilbanken, men den skal ikke være et videnskabeligt oplæg i sig selv.
7.1.4 Funktioner i prototypen
Vi har i det foregående gennemgået bankernes og brugernes ønsker til en mobilbank og set, at der eksisterer en vis enighed blandt de to grupper om, hvilke funktioner mobilbanken bør indeholde. Funktionerne kan overordnet inddeles i tre kategorier, alt efter hvor vigtige de er at have med, ifølge vores vurdering baseret på ovenstående gennemgang: 1) essentielle funktioner, 2) ønskede funktioner og 3) mindre ønskede funktioner, som det kan ses i nedenstående tabel:
|
Essentielle funktioner |
Ønskede funktioner |
Mindre ønskede funktioner |
|
tjekke saldo på egne konti tjekke posteringer på egne konti overføre beløb mellem egne konti overføre beløb til eksterne konti spærre dankort |
betale girokort se kommende betalinger afvise/ændre kommende betalinger |
handle aktier ansøge om lån |
I en udrulning af en mobilbank til rigtige brugere kunne man overveje at implementere funktionerne trinvist, således at kun de funktioner, der er vurderet som essentielle, vil være at finde i den første udgave af mobilbanken, mens de næste funktioner implementeres efterfølgende, i takt med at mobilbanken bliver taget i brug, og banken samt brugerne får erfaringer med den.
I forhold til vores prototype, der har til formål at afprøve, hvordan mobilbanken skal opbygges for at være brugervenlig, vil det være irrelevant at implementere alle ovenstående funktioner, idet principperne for brugervenligheden burde være den samme på alle funktionerne – og derfor vil vi implementere de funktioner, der er vurderet som essentielle i det foregående, dvs. tjekke saldo på egne konti, tjekke posteringer på egne konti, overføre beløb mellem egne konti, overføre beløb til eksterne konti og spærre dankort. I denne forbindelse er overførsler til eksterne konti den mest problematiske, det er her, kriminelle kan misbruge mobilbanken. Derfor kræver denne funktionalitet ekstra overvejelser, som vi behandler i næste afsnit.
Ud over de funktioner, vi har vurderet som essentielle, har vi valgt også at implementere de ønskede funktioner, på nær betaling af girokort, det vil sige funktionerne se kommende betalinger og afvise/ændre kommende betalinger. Vi implementerer ikke funktionen betale girokort, da vi vurderer, at det er for kompleks en opgave at medtage i en første prototype, fordi der vil være mange indtastninger og forskellige valgmuligheder, som det vil tage lang tid at implementere på en hensigtsmæssig og realistisk måde. Blandt andet findes der flere forskellige korttyper, som alle skal kunne betales. I en produktionsklar udgave af mobilbanken bør denne implementeres, da den er en del af de ønskede funktioner.
7.1.5 Overvejelser i forbindelse med eksterne overførsler i mobilbanken
Den mest sikkerhedskritiske del af vores designforslag til en mobilbank, hvis vi ser bort fra signon, er overførsler til eksterne konti. Der er ingen, der har lyst til at se at hele deres pensionsopsparing overført til en konto i Rusland, så derfor er det en central overvejelse.
Traditionelt er man i danske netbanker blevet bedt om at autentificere sig igen, når man skal overføre penge eller betale girokort. Denne fremgangsmåde præsenterer en række udfordringer for brugervenligheden i vores designforslag. På de fleste telefoner vil en gentagelse af to-faktor signon kræve, at brugeren går ud af browseren for at læse sine sms’er, hvilket vil bryde sessionen med mobilbanken.
Hvorvidt dette kan være et problem, kommer an på brugsmønsteret. Hvis brugerne primært anvender mobilbanken til enkelte transaktioner, hvilket vi umiddelbart antager, vil det ikke udgøre et problem, da brugeren, når han/hun har lavet sin transaktion, er færdig. Det vil derfor ikke bryde alt for meget med flowet at skulle tjekke sine sms-beskeder igen. Hvis brugerne vil anvende mobilbanken som erstatning for den almindelige netbank – og dermed foretage flere transaktioner per signon – ser vi følgende muligheder for at håndtere dette:
1: Kun to-faktor autentificering ved signon. Når eksterne overførsler skal godkendes, bliver det kun godkendt med enkelt-faktor autentificering, nemlig ved at brugeren genindtaster sit password ved hver transaktion. Denne løsning ser vi ikke som acceptabel rent sikkerhedsmæssigt.
2: To-faktor godkendelse ved hjælp af ’bundling’, det vil sige samling af transaktioner, der så kan godkendes på én gang. Brugeren indtaster her alle sine transaktioner, og når han/hun er færdig, bliver der sendt endnu en sms fra systemet, hvor brugeren så skal logge ind igen og godkende en liste over de transaktioner, som lige er oprettet. Hver transaktion kan eventuelt også godkendes med brugerens password i første omgang, hvor brugeren indtaster det for at forøge sikkerheden.
Disse løsninger kan
eventuelt kombineres. Hvis transaktionen er en betaling eller overførsel til en
konto, der er overført penge til før (evt under et vist beløb), kan det være
nok at godkende transaktionen med password, men hvis det er til en ny konto,
skal overførslen godkendes ved hjælp af overstående bundlings-metode.
Det kunne også implementeres ved, at små transaktioner (for eksempel under 250
eller 500 kroner) kun skulle godkendes med password, men at større beløb skal
godkendes via sms.
Vi har i prototypen valgt at implementere en løsning, hvor man kan samle transaktioner sammen og godkende dem samlet, når man er færdig med at bruge mobilbanken. Vil man kun oprette eller ændre en enkelt transaktion, kan denne godkendes med det samme. Løsninger, der gør brug af ovenstående modeller, hvor mindre beløb eller faste beløbsmodtagere ikke kræver to-faktor autentificering, kræver solide risici- og forretningsmæssige overvejelser af banken. Vi har valgt ikke at implementere dette i vores prototype af denne årsag, men holdt os til to-faktor godkendelse, der kræver fornyet signon.
I det næste afsnit vil vi gå videre med at beskrive selve den udviklede prototype.
7.2 Prototypens brugergrænseflade
I dette afsnit vil vi gennemgå det visuelle og funktionelle design, eller brugergrænsefladen, i vores mobilbankprototype for at forklare, hvorfor vi er kommet frem til netop dette design[11].
Vi har forsøgt at designe prototypens brugergrænseflade, så den holder sig tæt op ad de regler og guidelines, vi har præsenteret i afsnit 5 og 6.
En evaluering af, om disse usability-regler holder i praksis, vil blive gennemgået i afsnit 9.3, hvor vi præsenterer resultaterne af prototypens brugertest.
7.2.1
Signon
Som det blev forklaret i afsnit 3, skal brugeren i vores designforslag logge på ved først at sende en sms indeholdende sit brugernummer til bankens sms-gateway.
Når brugeren har sendt denne sms-besked vil han/hun modtage et svar, som vist i figur 16a, og når linket bliver fulgt, får brugeren vist det signon-billede frem, som ses i figur 16b. Som et alternativ til STS-prototypen har vi også udviklet en OTP-prototype, der benytter engangskoder til signon. Her skal brugeren ikke først sende en sms, men han/hun kan i stedet nøjes med at gå direkte til mobilbankens signon-side i mobilbrowseren, hvor der ud over brugernummer og underskriftskode også skal indtastes en engangskode fra et udleveret stykke papir (ikke illustreret).
7.2.2 Menu
Det
første, brugeren ser, når han/hun er logget ind i mobilbanken, er menuen (se figur
17). Den er opbygget ud fra Fitt’s lov (se afsnit 5.3.3), hvor princippet er at
placere de vigtigste funktioner så tæt på brugeren som muligt. På den første
side, brugeren møder efter signon, bliver en oversigt over brugerens
forskellige konti og deres aktuelle saldo således vist, idet vores
brugerundersøgelser (se afsnit 7.4.1) har vist, at dette er den mest
interessante oplysning for brugerne.
Derefter følger resten af funktionerne som links, prioriteret i den rækkefølge, som ifølge vores undersøgelser er dem, brugerne oftest vil anvende og er mest interesserede i. Den eneste undtagelse er funktionen til spærring og aktivering af kort. Den er en af de mest interessante for brugerne, men vores vurdering er, at det ikke er en funktion, brugerne vil benytte ofte, hvorfor den er placeret langt nede i listen.
7.2.3
Oprettelse af betaling
Når
brugeren vælger punktet ”Opret ny
betaling” i menuen, vil brugeren først blive præsenteret for en kort liste over
de konti, han/hun har råderet over (se figur 18). Derefter skal brugeren vælge,
om han/hun vil overføre penge til et nyt kontonummer, mellem sine egne konti
eller til en tidligere gemt standardbetaling (ikke illustreret). Hvis brugeren
vælger at overføre til en tidligere gemt standardbetaling, vil han/hun blive
præsenteret for det skærmbillede, der er vist i figur 19. Efter at have valgt
en standardbetaling, vil brugeren blive præsenteret for skærmbilledet i figur 20a
og figur 20b, hvor man kan angive datoen og beløbet. I dette tilfælde har
brugeren anvendt at udføre en standardbetaling, som er blevet kaldt
”Efterskolen i Tommerup”. Alle typer af overførsler oprettes i et skærmbillede,
der minder om det i figur 20a og 20b.
For
at gennemføre overførslen skal brugeren udfylde de felter, der ønskes. Kun
feltet beløb er obligatorisk, og
resten af felterne er valgfrie. Hvis datofeltet ikke udfyldes, vil overførslen
blive udført i dag, og man behøver ikke indtaste en tekst. Dette gør, at
brugeren kan nøjes med at indtaste så lidt information som muligt, så der
kommer mindst muligt besvær med at anvende mobiltelefonens begrænsede
input-muligheder.
Ud for feltet Dato er der givet et eksempel på, hvordan brugeren kan skrive datoen, så vi minimerer mulighederne for forkert input – ud over det givne eksempel vil vores prototype kunne acceptere datoinput, der benytter en skråstreg i stedet for en bindestreg, for eksempel dd/mm/åååå. Hvis brugeren skriver en dato, der allerede er passeret eller i et format, der ikke kan forstås af systemet, vil mobilbanken gøre opmærksom på problemet og nægte at gennemføre transaktionen, indtil datoen er skrevet korrekt.
Ud over at gennemføre transaktionen kan man vælge knappen ”Fortryd”, der annullerer oprettelsen af betalingen og sender brugeren til hovedmenuen, eller man kan vælge et af de tidligere punkter i brødkrummesporet nederst på siden. I dette tilfælde hvilken konto man vil overføre fra, og hvilken slags overførsel det skal være. Brødkrummerne er der, så brugeren hele tiden kan orientere sig i forhold til, hvor de er i systemet, som anbefalet af både Jakob Nielsen og Webcredible (se afsnit 5.3). Vi har dog valgt kun at placere brødkrummesporet i bunden af siden for at overholde Fitt´s lov (se afsnit 5.3.3), idet brødkrummesporet ellers ville kunne resultere i alt for mange tastetryk for brugeren, inden han/hun kom ned til de for brugeren interessante funktioner.
Vælger brugeren at trykke på ”OK”, vil han/hun, hvis transaktionen kan gennemføres, blive videresendt til en side, hvor man kan vælge imellem at forsætte med at bruge mobilbank (og dermed gå til menuen) eller godkende sine transaktioner (ikke illustreret).
7.2.4 Godkendelse af betalinger
Hvis
brugeren vælger at logge ud og godkende, bliver han/hun logget ud, og hvis der
er nogen transaktioner at godkende, bliver brugeren oplyst om dette, og
systemet sender en sms, der minder om sms-beskeden sendt i forbindelse med
signon (se figur 21a). I godkendelses-sms’en er der et engangslink til en godkendelsesside.
Når brugeren følger dette link, vil han/hun komme frem til en signon-side hvor
underskriftskoden skal indtastes igen. Når brugeren har logget på, får han/hun
vist siden, der kan ses i figur 21b, hvor de transaktioner, der kan godkendes,
bliver vist. Disse kan brugeren så vælge enten at godkende eller afvise.
Man kan dog ikke afvise eller godkende enkelte transaktioner, når man først er nået til godkendelsessiden; man skal afvise eller godkende alle transaktionerne på listen. Vil man slette eller ændre i enkelte transaktioner, skal det ske i selve mobilbanken, og altså ikke på godkendelsessiden.
Hvis man vil se transaktionerne, inden man logger ud, kan brugeren vælge menupunktet ”Se transaktioner, der skal bekræftes”. Dermed får brugeren en side frem, hvor, hvor man kan se de transaktioner, der afventer bekræftelse, og man kan læse transaktionsdetaljerne (se figur 22a).
I
OTP-prototypen fungerer godkendelsesprocessen lidt anderledes end i
STS-prototypen: Når brugeren vælger at godkende sine transaktioner, vil
brugeren komme direkte til godkendelsessiden uden at blive logget af først. For
at godkende sine transaktioner skal brugeren skrive en engangskode i bunden af
godkendelsessiden, som det kan ses i figur 22b, og derefter trykke på ”Godkend”-knappen.
Her vil engangskoden så blive valideret, inden transaktionerne bliver godkendt.
7.2.5 Posteringer og kommende betalinger
Hvis
brugeren vil se, hvilke transaktioner der har været, skal han/hun vælge det
første punkt i hovedmenuen, kaldet ”Posteringer”. Her kommer man hen til et
skærmbillede, hvor brugeren skal vælge, hvilken konto han/hun vil se
posteringerne på (se figur 23a). Derefter kommer man til det skærmbillede, der
er illustreret i figur 23b, hvor brugerne kan se de transaktioner, der er gennemført
på den valgte konto. Her har vi placeret de nyeste transaktioner øverst, da vi
vurderer, de er mest interessante (jævnfør Fitt’s lov). Knappen ”Ældre poster”
giver adgang til de ældre poster, der er, og der vises fem posteringer ad
gangen, ligesom på den viste figur. Tallet fem har vist sig at være et godt
kompromis mellem, hvor meget information der kan vises på en mobilskærm og det at
give nok information til, at det er muligt at få et overblik. ”Ældre poster”-knappen dukker kun op,
når der rent faktisk er ældre poster at vise. Når man er i gang med at se ældre
posteringer, kommer der også en ”Nyere poster”-knap frem. Klikker man på
beløbet (der er et link), får man detaljerne om transaktionen frem; det er for
eksempel information om, hvem beløbet er overført til og fra samt en eventuel
tekst.
Oversigten over kommende posteringer (se figur 24b), der vælges i hovedmenuen, fungerer på præcist samme måde som oversigten over gennemførte posteringer, med den ene undtagelse, at der i detaljevisningen for den enkelte kommende post (som vælges ved at klikke på linket i den ønskede kommende betaling) er mulighed for at ændre eller afvise betalingen, samt at man, som det kan ses i figur 24a, kan vælge at se kommende posteringer på alle konti.
I oversigten over kommende betalinger kan man også se transaktioner, der endnu ikke er godkendt. De vil så være markeret med en stjerne (*), således at brugeren nemt kan identificere dem.
7.2.6 Betalingsservice
Betalingsservice
fungerer ud fra en meget lignende model som ved funktionerne ”Posteringer” og
”Kommende betalinger”. Når brugeren vælger punktet ”Betalingsservice” i
hovedmenuen, kommer han/hun ind på en side (se figur 25), hvor denne måneds
betalinger via Betalingsservice kan ses, og brugeren har muligheden for at se detaljer
og eventuelt afvise dem ved at klikke på posteringsteksten. Ved at klikke på
knappen ”Se BS-aftaler” får brugeren vist en oversigt over alle BS-aftaler (se figur
26), og brugeren har mulighed for at afmelde hver enkelt BS-aftale. De konkrete
betalinger for den aktuelle måned kan også ses i kommende betalinger, hvis de
ikke er trukket endnu, og når de er udført, kan man se dem i oversigten over
tidligere poster.
7.2.7 
Spærring og aktivering af kort
En af de funktioner, brugerne allerhelst så i en mobilbank, er muligheden for at spærre sit dankort. Funktionen er, som tidligere nævnt, placeret som en af de sidste valgmuligheder i hovedmenuen. Når brugeren klikker på linket ”Spærring og aktivering af kort”, får han/hun et skærmbillede frem som det, der ses i figur 27. I prototypen skal der pt. ikke autentificeres igen, når status på eksempelvis et dankort skal ændres. Af sikkerhedshensyn bør alle ændringer dog kræve fornyet autentificering, så en produktionsudgave af mobilbanken er bedre beskyttet (se også afsnit 7.3.5).
7.3 Prototypens tekniske struktur
I det følgende kapitel vil vi ganske kort gennemgå den tekniske struktur i mobilbank-prototypen; herunder hvilket programmeringssprog vi har valgt og hvorfor, hvordan databasen er opbygget, og hvilke særlige forholdsregler vi har været nødt til at tage som følge af problemer opdaget under udviklingsprocessen.
7.3.1 Programmeringssprog
Da formålet med at udvikle en mobilbank-prototype primært var at kunne foretage brugertests, der kan give værdifulde oplysninger om brugernes syn på sms-sikkerhedsmodellen og brugervenligheden i mobilbankens design, så vurderede vi hurtigt, at det valgte programmeringssprog skulle understøtte vores fokus på funktionerne frem for den underliggende kode.
Det var en af hovedgrundene til, at vi valgte at bruge Microsofts .Net-platform i form af ASP.NET og C#. Med Visual Studio, et integreret udviklingsmiljø specielt udviklet til at understøtte blandt andet .Net-udvikling, gav det os mulighed for at fokusere på hurtig udvikling af funktionerne i prototypen frem for den basale kode, idet Visual Studio integrerer en række præ-definerede kontroller, som gør det hurtigt og nemt at udvikle eksempelvis en webapplikation som mobilbank-prototypen.
C# er et objektorienteret sprog, hvilket naturligt har givet vores applikation et objektorienteret design. Vores applikation er opdelt i en række .aspx og .aspx.cs-filer hvor HTML-koden primært ligger i .aspx-filen og kalder funktionerne, der er skrevet i C# i .cs-filen. Derudover har vi en fil (shared-code.cs) med en klasse, der indeholder de funktioner, der skal deles imellem flere sider, således at vi undgår for meget gentagen kode. Men ellers er hver side implementeret som sin egen klasse.
7.3.2 Design og udførsel
Med udgangspunkt i .NET-platformen som det valgte udviklingsmiljø var det naturligt også at vælge Microsoft SQL Server til at understøtte den dynamiske funktionalitet i prototypen. Vi valgte udgaven SQL Server Express, da begrænsningerne i forhold i den almindelige udgave primært er, at den kun kan bruge en gigabyte RAM, og at databaser ikke må fylde mere end 4GB, hvilket er mere end rigeligt til vores forholdsvist simple prototype.
Databasestrukturen i prototypen kan ses i nedenstående database-diagram:
Figur 28: Databasestruktur i prototypen
Med databasestrukturen på plads kunne vi begynde det egentlige design. Vi udviklede to prototyper – en STS-prototype og en OTP-prototype – der i store træk var ens: Den eneste deciderede forskel ligger i signon-modellen og godkendelse af transaktioner, hvorfor kun de sider, der havde direkte relation hertil, er forskellige i de to prototyper (koden er vedlagt på CD-ROM som bilag 8).
Rent kronologisk udviklede vi først STS-prototypen, og dernæst udviklede vi selve funktionerne i mobilbanken og koblede dem sammen med sms-signon. Til sidst udviklede vi OTP-prototypen og koblede den på funktionerne. Altså er vores design opbygget af tre dele; de to signon-løsninger og selve bankfunktionerne. De er designet, så de kun er løst koblede, og der skal ikke laves nogen ændringer i koden for at skifte signon-model: Man skal blot udskifte de filer, der indeholder signon og godkendelse af transaktioner. STS-signon er implementeret i Login.aspx, og OTP-signon ligger i Default.aspx. Derudover er der klasserne til godkendelse af transaktioner, der eksisterer i to udgaver; en til hver signon-type. STS-signon benytter klasserne send-godkendelses-sms og godkend. OTP-prototypen anvender kun klassen godkend, da den blot kan viderestille brugeren direkte til godkendelsen, hvor den skal have en OTP-kode igen, når en transaktion skal godkendes. I STS, derimod, er brugeren for at følge linket i sms-beskeden nødt til at gå væk fra browseren på sin telefon.
I forhold til STS-signon er der to tabeller i databasen, der har betydning, nemlig users og session. Når brugeren sender en sms med sit brugernummer til mobilbanken, bliver der – hvis brugernummeret er registreret med det pågældende telefonnummer i tabellen users – oprettet en hash-værdi i tabellen sessions tilknyttet det aktuelle brugernummer. Denne hash-værdi er en del af det signon-link, brugeren modtager på sms, og har et tidsstempel, der er med til at sikre, at hash-værdien kan sættes til kun at være gyldig i eksempelvis 15 minutter. Når brugeren følger linket og derpå skriver sit password (brugernummer findes frem ved hjælp af hash-værdien), bliver brugeren autentificeret, hvis passwordet er korrekt.
I forhold til OTP-signon er der også to tabeller, der har betydning, nemlig users og otp. Når brugeren vil logge på, tjekkes tre oplysninger; brugernummer, password og engangskode, og hvis alle disse er korrekte, bliver brugeren autentificeret. I STS-prototypen har vi anvendt en standardkontrol fra Visual Studio til at foretage godkendelsen, kun lettere modificeret til at anvende hash-værdien. OTP-koden benytter en kontrol, vi selv har lavet.
Ud over den indledende session, som vores prototype bruger til STS-signon, så anvender prototypen den indbyggede sessions-funktionalitet i ASP.NET til at holde styr på, om brugeren er logget ind.
De resterende tabeller i databasen, som vi ikke har nævnt, er oprettet for at gemme data, der medvirker til at simulere de funktioner, vi har valgt at have med i mobilbank-prototypen. Vi har ikke beskæftiget os med optimering af databasen, da fokus i specialet – som tidligere nævnt – ligger på brugervenligheden og ikke den underliggende kode. Dertil kommer, at vi kun foretager tests med en enkelt bruger ad gangen. Vi har derfor vurderet, at det ikke har kunnet svare sig ressourcemæssigt at bruge kræfter på at optimere databasen, når blot de ønskede funktioner i prototypen var tilgængelige og virkede. Det samme forbehold gælder i øvrigt for den underliggende C#-kode i applikationen, der givetvis ville kunne optimeres en hel del, hvis man havde det for øje.
STS-signon er en central del af vores prototype, og derfor vil vi behandle implementeringen af denne separat i det næste afsnit.
7.3.3 Afsending og behandling af sms
I STS-prototypen skal serveren kunne sende og modtage sms beskeder. Rent teknisk foregår det ved, at vi anvender en kommerciel sms-gateway hos virksomheden Compaya. Når den modtager en sms med vores nøgleord (bank), kalder den en URL på vores server med brugerens telefonnummer og indholdet i beskeden som parametre. Den URL, som gatewayen kalder, vil den forsøge at læse som et XML-dokument, der giver den svaret på sms-beskeden. I vores tilfælde laver vi et databaseopslag, og hvis det er en godkendt bruger, vil URL’en returnere et XML-dokument, der indeholder vores signon-URL med en gyldig hash-værdi. Dette indhold (den tekst, der står i <MSG></MSG> tagget i nedenstående eksempel) vil gatewayen så sende tilbage til brugeren i en sms.
Eksempel på XML indeholdende signon-sms til brugeren:
<?xml version="1.0" encoding="utf-8"?><ROOT><MSG>Du kan logge på Mobilbanken ved at klikke på dette link: http://chester.ruc.dk/Login.aspx?ses=08B634BC108AB734C06C15067DD95DAF&usr=61601234567</MSG>
<BC>0000</BC>
</ROOT>
Når vi vil sende en sms til at godkende transaktioner foregår det på samme måde. Vi kalder en URL på Compayas sms-gateway med sms’ens indhold og modtagerens telefonnummer som parametre, og så får vi en bekræftelse i XML-format.
7.3.4 Særlige forholdsregler i udviklingen
Efter udviklingen af den første prototype, der gør brug af sms til signon, løb vi ind i nogle problemer; når man klikker på et link i en sms, så vil man på de fleste Nokia-telefoner med Symbian S60-styresystemet (blandt andet N- og E-serien) opleve, at det ikke er den indbyggede webbrowser, URL’en åbnes i, men derimod den indbyggede WAP-browser[12]. Forskellen ligger i, at WAP-browseren ikke er lige så avanceret som webbrowseren, selv om den dog godt kan vise HTML. Da vi eksempelvis forsøgte at åbne URL’en http://chester.ruc.dk/Login.aspx?ses=5d5d1f14c8704e935a87ad78fc535bea ved at klikke på linket i sms’en, så fik vi dog blot en fejl, der sagde, at handlingen ikke kunne udføres. Efter lang tids fejlsøgning viste det sig, at den indbyggede WAP-browser kun kan vise sider, hvor den outputtede html-kode fra serveren starter med tagget <html>.
Der må således ikke være et linjeskift eller mellemrum, og html-tagget må ikke indeholde yderligere information, som for eksempel: <html xmlns="http://www.w3.org/1999/xhtml">.
WAP-browseren kunne heller ikke acceptere denne outputtede html-kode, der ellers er krævet af XHTML-standarden:
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Derfor kan vores XHTML–kode heller ikke valideres, da vi har truffet en beslutning om, at det er vigtigere, at vores kode virker i så mange mobilbrowsere som muligt, fremfor at den opfylder XHTML -standarden fuldt ud.
Følgende tre eksempler fra kildekoden i aspx-filerne virkede derfor ikke, da de outputtede HTML-kode, der ikke fulgte ovenstående regel:
<%@ Page
Language="C#" AutoEventWireup="true"
CodeFile="Default3.aspx.cs" Inherits="Default3" %>
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml">
<%@ Page
Language="C#" AutoEventWireup="true"
CodeFile="Default3.aspx.cs" Inherits="Default3" %>
<html
xmlns="http://www.w3.org/1999/xhtml">
<%@ Page
Language="C#" AutoEventWireup="true"
CodeFile="Default3.aspx.cs" Inherits="Default3" %>
<html>
I stedet skulle kildekoden i aspx-filerne se således ud, for at prototypen kommer til at virke i WAP-browseren på Nokia-telefoner med styresystemet S60.
<%@ Page
Language="C#" AutoEventWireup="true"
CodeFile="Default3.aspx.cs" Inherits="Default3"
%><html>
Indtil Nokia stopper med at anvende denne browser som standard, når der klikkes på et link i en sms, vil man skulle tage denne forholdsregel.
7.3.5 Sikkerhedsforbehold i prototypen
Der er flere sikkerhedsmæssige aspekter, som vi er opmærksomme på, at der skal tages højde for i en egentlig produktionsudgave af en mobilbank, men som ikke er implementeret i prototypen:
- Prototypen benytter ikke SSL til at sikre kommunikationen mellem brugeren og mobilbanken. Grunden til dette er, at vi ikke er i besiddelse af et certifikat, der på forhånd er godkendt i browseren, da disse kan koste temmelig mange penge. Vi kunne have signeret vores eget certifikat, men vi ville så løbe ind i nogle problemer i forhold til brugertesten, idet et certifikat, der ikke er kendt af browseren, skal godkendes manuelt af brugeren. Dette kan forstyrre det egentlige formål med brugertesten, nemlig test af brugervenligheden, fordi det kan forvirre brugeren. I en rigtig, fungerende mobilbank er SSL-kryptering dog essentielt for sikkerheden, og man må formode, at bankerne vil investere i et nyt certifikat specifikt til mobilbanken, akkurat som de har gjort til netbanken.
- I prototypen er der ikke taget højde for, at browsere – også i mobiltelefoner – gemmer (cacher) siderne for hurtigt at kunne vise dem igen. En produktionsklar mobilbank skal naturligvis konstrueres på en måde, så dette problem overkommes, for eksempel ved at ’fortælle’ browseren, at den ikke skal cache siden.
- De fleste pc-baserede browsere er i stand til at huske indtastede passwords på websider, så brugeren slipper for at indtaste dem igen. Det er rart for brugeren, men mindre rart for sikkerheden. I en netbank beregnet på at blive brugt på en pc kan man programmere sig ud af dette sikkerhedsproblem ved for eksempel at lade signon ske gennem en Java-applet. Dette er dog ikke en mulighed på mobiltelefoner (endnu), hvorfor dette ikke er en løsning. Den udviklede mobilbank-prototype tager derfor heller ikke højde for dette sikkerheds-aspekt. Det skal dog også nævnes, at langt de fleste mobiltelefoners indbyggede browsere ikke er i stand til at huske passwords (se afsnit 4.6), så på nuværende tidspunkt er problemet stadig meget teoretisk.
- Vi har ikke brugt tid på at sikre os, at brugeren ikke kan misbruge prototypen ved for eksempel at snige SQL ind i inputfelter. Dette har vi valgt da, applikationen kun er en prototype, der vil blive anvendt af brugere, vi har tillid til, under vores opsyn i en brugertest.
- Den sms-gateway, der benyttes i prototypen, er en kommerciel gateway, drevet af virksomheden Compaya. Til brug for en produktionsklar mobilbank bør banken nok overveje at implementere sin egen sms-gateway eller tage andre forholdsregler, så følsomme signon-oplysninger ikke kommer i hænderne på tredjepart.
- Slutteligt skal det nævnes, at det ikke er alle ændringer, som brugeren kan foretage sig, der skal godkendes igen ved hjælp af to-faktor autentificering. Det er kun godkendelse af nyoprettede eller ændrede transaktioner, der kræver fornyet autentificering af brugeren, mens funktioner såsom spærring/aktivering af dankort, afvisning af BS-aftale og sletning af en overførsel ikke kræver godkendelse i prototypen. Dette er ikke implementeret af ressourcemæssige hensyn, men ville naturligvis skulle være en del af en fungerende produktionsudgave af mobilbanken.
8
Brugertest
I det foregående afsnit har vi gennemgået prototypens brugergrænseflade og tekniske struktur. I dette kapitel vil vi først præsentere relevant teori om gennemførsel af brugertests, og derefter vil vi gennemgå udførelsen og resultaterne af de konkrete brugertests af den udviklede prototype.
Brugertests er essentielle for, at man kan lave et godt og brugervenligt design. Dette skyldes, at de giver præcis information om, hvordan brugerne oplever designet, samt hvilke problemer de får (Nielsen 1993: 165).
Det er centralt, at brugertests er både pålidelige og gyldige. Pålidelighed, eller reliability, er spørgsmålet om, hvorvidt andre kan gentage testene og få lignende resultater (Nielsen 1993: 165). Man må dog forvente udsving, da ingen brugere er ens, og der kan således være store forskelle mellem testbrugere, hvorfor det kan være svært at påvise, at data er pålidelige. Det betyder dog ikke, ifølge Jakob Nielsen (1993: 166), at man ikke skal bruge data fra brugertesten, selv om der kan være udsving: “For usability engineering purposes, one often needs to make decisions on the basis of fairly unreliable data, and one should certainly do so since some data is better than no data” (Nielsen 1993: 166). I forhold til vores planlagte brugertest betyder det, at vi sandsynligvis kommer til at opleve modstridende meldinger fra nogle af brugerne, men dette betyder ikke, at vi ikke kan konkludere på de resultater, der trods alt er fremkommet.
Gyldighed, eller validitet, handler derimod mere om, hvorvidt testen måler noget, der er relevant for produktets anvendelse blandt slutbrugere (Nielsen 1993: 169). Altså om man tester det ”rigtige”, med de rigtige brugere og under de rigtige omstændigheder. For at konstruere valide tests er det derfor centralt, at de opgaver, man stiller brugerne, er de samme opgaver, som brugerne ville ønske at udføre med slutproduktet. Det er også centralt, at man har udvalgt de rigtige brugergrupper (så datalogistuderende ikke tester software til landmænd), og at testen foregår under virkelighedsnære omstændigheder. For eksempel skal tidspresset passe med det, slutbrugerne opererer under (Nielsen 1993: 169). Det er dog acceptabelt at have brugere, der ikke udgør den endelige målgruppe, men er tæt på. For eksempel kan man bruge handelshøjskolestuderende til at teste et produkt, der er lavet til ledere, da det er sandsynligt, at en stor del af de studerende vil ende som ledere (Nielsen 1993: 169). Hvis man anvender testbrugere, der er for langt væk fra slutbrugerne, ender man med at udvikle et produkt, hvor alt ser flot ud på overfladen, men i praksis viser det sig at være ubrugeligt for målgruppen (Preece 2002: 280).
I forhold til vores speciale er dette også et centralt punkt; vi forventer at foretage brugertests blandt unge under 35 år, som er den primære målgruppe for mobilbanken, og dette skulle gerne give os relevante data til videre bearbejdning. I denne forbindelse er der den udfordring, at en del af vores testbrugere er personer, vi kender, og her kan vi risikere, at de udtrykker sig mere positivt om mobilbank-prototypen, fordi de gerne vil gøre os glade. Dette har vi forsøgt at tage højde for ved ikke at gå efter, om de kan lide mobilbanken, men i stedet stille dem konkrete opgaver, som de har skullet forsøge at gennemføre. Da et af de vigtige målepunkter er, hvor godt de har kunnet gennemføre dem, vil det ikke have betydning, om de prøver at gøre os glade, da dette ikke har indflydelse på, i hvor stor grad de kan gennemføre opgaverne. Derudover gør vi dem opmærksomme på, at det hjælper os med at lave et bedre program, hvis de finder fejl, hvilket gør dette til noget positivt.
Om brugertesten bliver en succes, afhænger ifølge Jakob Nielsen (1993: 170) mest af, om man har lavet en klar testplan og tydeligt defineret, hvad målet (eller målene) er. I forbindelse med dette definerer han en række punkter (se nedenstående), hvor man skal overveje, hvad det vigtigste er i forhold til det konkrete projekt. Vores konkrete overvejelser omkring disse punkter kan læses i afsnit 8.2:
- Hvad er målet med testen? Hvad vil du/I opnå?
- Hvor skal testen afholdes?
- Hvor lang tid skal hver testsession tage?
- Hvor stor en del af systemet skal være klar, før man kan teste?
- Hvem skal være testbrugerne, og hvordan får man fat i dem?
- Hvor mange testbrugere er der brug for?
- Hvilke opgaver skal testbrugerne forsøge?
- Hvilke kriterier skal anvendes for at bedømme, om brugeren har udført testen korrekt?
- I hvilken grad skal brugerne uddannes, og må de blive hjulpet undervejs?
- Hvordan skal data om forsøgene opsamles?
- Hvad er kriteriet for, om interfacet er en succes?
Når man skal måle på resultaterne af en test, er den mest anvendte faktor tid; det vil sige den tid, brugerne er om at nå et specifikt mål. Men også antallet af opgaver, en bruger skal igennem for at nå målet, bruges som målefaktor, lige som antallet af fejl (Nielsen 1993: 192). I vores planlagte brugertest finder vi ikke, at tid er den mest relevante målefaktor, da anvendelsen af en mobilbank oftest ikke vil være under tidspres, og det er heller ikke en produktivitets-applikation. Derfor finder vi det mest relevant at kigge på, om brugerne uden problemer kan finde ud af at navigere i designet, og hvor mange fejl de laver.
Vi vil altså undersøge, om brugerne kan udføre opgaverne og ikke giver udtryk for høj frustration undervejs. Dette vil vi gøre ved at benytte en testmetode kaldet tænke-højt. Denne vil vi beskrive i det følgende afsnit.
8.1 Testmetode
Den testmetode, vi har valgt at anvende til brugertest af mobilbank-prototypen er en såkaldt tænke-højt-test. Denne type test er, ifølge Jakob Nielsen (1993: 195), den mest værdifulde test i forhold til andre testmetoder, da det er den test, der selv med en lille gruppe testpersoner giver mest data fra brugerne – både om hvordan testen forløber, og om hvilke tanker der ligger til grund for brugerens handlinger. I brugertesten af mobilbank prototypen benytter vi et begrænset antal testpersoner, nemlig fem, og derfor har vi behov for en testmetode, der giver os størst muligt udbytte af en test med så få personer. Derfor har vi valgt tænke-højt-tests.
Den største ulempe ved denne testmetode er, at det er svært at måle performance, altså den tid, det tager for brugerne at udføre en specifik handling med systemet. Dette skyldes en række forskellige faktorer: Den primære er, at brugerne har svært ved at vende sig til at ”tænke højt”, og at det derfor – sammen med interaktionen med test-personalet – sløver udførelsen af opgaverne. I forbindelse med dette er det vigtigt at forklare tænke-højt-princippet for brugerne, da de kan have svært ved at fange ideen. Det er også vigtigt at udføre en eller flere pilottests, således at man har gennemprøvet testen og fundet faldgrupperne. Samtidigt er det vigtigt at genteste designet, når man har håndteret de usabilityproblemer, der blev afsløret i den første test: Det kan være, at brugerne nu kan se nye problemer, der var skjult før, eller måske har de løsninger, man har lavet, skabt nye problemer (Preece 2002: 341).
I dette speciales designforslag ligger vores primære interesse ikke i, at mobilbanken har en høj produktivitet, men derimod at den skal være nem at finde ud af. Dette skyldes, at vi ikke ser en mobilbank som et produkt, brugerne skal anvende i lang tid af gangen, men som et produkt, hvor de skal udføre små opgaver en gang imellem. Her er det derfor meget vigtigt, at en mobilbank er intuitiv, da brugerne ikke kan forventes at skulle bruge lang tid på at sætte sig ind i funktionaliteten og designet eller opnå stor rutine i brug af denne.
En anden styrke ved tænke-højt-testen er, at man kan samle meget kvalitativt data fra et lille antal brugere. Disse faktorer gør, at vores designforslag er en naturlig kandidat til en tænke-højt-test, både fordi vi ønsker en lille testgruppe, og fordi vi blandt andet ønsker at teste, om applikationen er intuitiv.
Når man udfører en tænke-højt-test, skal man huske hele tiden at spørge brugerne, hvad de tænker, så man sikrer sig konstante data. Spørgsmål skal udformes, så de ikke ændrer brugernes opførsel; man kan for eksempel stille spørgsmål som, ”hvad forventede du ville ske, da du trykkede på den knap?”, men man skal ikke stille spørgsmål til dele af systemet eller skærmen, som brugeren ikke selv har fået øje på, lige som man heller ikke skal dirigere brugerens tanker ved at stille spørgsmål som ”hvad tror du vil ske, hvis du trykker på den knap?”. Samtidig skal man passe på med ikke at lægge for meget vægt på, hvad brugerne siger, idet de har en tendens til at efterrationalisere deres handlinger. Man skal notere deres problemer og tankerne bag disse, men ikke deres forslag til, hvordan man løser dem (Nielsen 1993: 197). Det er også vigtigt, at spørgsmål fra brugerne om, hvordan tingene fungerer, ikke bliver besvaret. For at få den bedst mulige information ud af brugerne, skal processen være drevet af brugernes egne opfattelser.
Man skal dog også være opmærksom på, at selve tænke-højt-øvelsen kan påvirke den måde, brugerne anvender systemet, og dermed gøre hele testsituationen anderledes end den virkelige situation. Jakob Nielsen (1993: 192) henviser til en undersøgelse, hvor det viste sig, at deltagerne i en tænke-højt-test kun lavede 20 procent af de fejl, som stille brugere lavede.
Det har også betydning, hvor ofte det er meningen, at slutproduktet skal anvendes. I mobilbank-scenariet vil brugerne, som med alle systemer, opnå indsigt i mobilbanken, når de bruger den. Men vi forventer, at en mobilbank er noget, de anvender i små portioner en gang imellem; det vil formentligt ikke være en løsning, de bruger mange gange og i lang tid hver dag. Derfor vil det i brugertesten passe bedst med kun en mindre mængde vejledning i brugen af mobilbank-prototypen. Dette afspejler, at vi ikke forventer, at brugerne hurtigt opnår en stor mængde af rutine, hvis de brugte en fungerende, virkelig mobilbank.
8.1.1 Opsamling af resultater
Man har sjældent brug for at se helt specifikt, hvad der skete under en tænke-højt-test, hvorfor det ofte ikke kan betale sig at videooptage forsøgene. I stedet kan man skrive de vigtigste punkter fra testen ned, imens den foregår. Det gør det også nemmere at undgå at fokusere på ligegyldige detaljer. Jakob Nielsen (1993: 203) foreslår, at man registrerer resultaterne ved at nedskrive de vigtigste punkter, som brugerne har problemer med, samt brugernes udsagn.
En anden mulighed er, at man sammenskriver resultaterne fra hver enkelt brugertest til en lille historie, umiddelbart efter at testen er foretaget (Preece 2002: 380). Dette vil gøre det nemmere at forklare resultaterne for andre og sammenligne data fra forskellige brugere. Man bør især koncentrere sig om at finde mønstre og nøglehandlinger i de forskellige historier, da det kan hjælpe med at forklare, hvad der driver brugernes handlinger. Dette vil identificere de største problemer, brugerne har, og gøre det nemt at sammenligne data med senere undersøgelser, så man kan se, om problemerne er afhjulpet. Vi har valgt denne tilgang, og har dermed opsamlet resultaterne fra brugertesten af mobilbank-prototypen i en forsøgslog i form af nogle små historier (se bilag 5).
8.2 Brugertest af mobilbank-prototypen
Dette speciale har to overordnede formål med at gennemføre brugertests af mobilbank-prototypen: 1) vi vil finde og rette de mest kritiske uhensigtsmæssigheder i designet – det vil sige evaluering af usability i browserbaseret mobile banking – og 2) vi vil foretage en evaluering af, hvordan brugerne opfatter STS i forhold til en OTP-prototype, der gør brug af engangskoder. Sidstnævnte har til formål at simulere løsninger baseret på OTP-tokens eller printede engangskoder, som for eksempel den nye danske digitale signatur DanID, udviklet af PBS, som skal erstatte den nuværende Digital Signatur fra TDC (læs også afsnit 9.1).
Vi har gjort os en række overvejelser ud fra de af Jakob Nielsen nævnte punkter (se starten af kapitel 8) omkring planlægning af brugertest i forhold til brugertesten af vores prototype og er kommet frem til følgende:
- Vi vil afgøre, om interfacet er intuitivt og kan anvendes med så få fejl som muligt. Med det mener vi, at brugerne kan anvende mobilbanken uden særligt meget undervisning, forudsat at de har netbank i forvejen, og at de ikke begår store fejl. Derudover skal brugerne også gerne være glade for interfacet. Vi vil altså gerne undersøge, om vores designforslag har et godt interface rent usabilitymæssigt.
- Det er mindre vigtigt i testen af mobilbanken, hvor testen afholdes, men det er dog vigtigt, at testlokalet er uforstyrret, så der ikke forekommer forstyrrelse af resultaterne. Testen afholdes derfor enten på RUC i et lukket lokale eller i brugerens hjem. Vi foretrækker at afholde testene med én bruger ad gangen, således at vi ikke bliver distraheret og misser væsentlige pointer.
- Hver testsession er beregnet til at tage cirka halvanden time, så der både er tid til for-interview, opgaver og efter-interview.
- Som minimum skal signon (både med sms og engangskoder) være klart, før testen kan påbegyndes. Men hvis vi også skal teste brugervenligheden i opbygningen af mobilbankens funktioner, så skal alle de essentielle funktioner, der nævnes i afsnit 7.1.4 være klar.
- Vi forventer at foretage brugertests blandt unge under 35 år, som er den primære målgruppe for mobilbanken. I praksis betyder det, at vi udvælger personerne blandt vores egen omgangskreds, da de vil være nemme at rekruttere til forsøgene. Det, at vi udvælger personer, vi kender, kan dog have en betydning for resultaterne af brugertesten, fordi det kan være en risiko, at venner forsøger at ’please’ os ved at komme med de meninger, de tror, vi gerne vil have fra dem. Dette har vi dog forsøgt at tage højde for som tidligere nævnt.
Vi udvælger deltagere, der benytter forskellige netbanker. Som minimum skal én bruger benytte en netbank, der er baseret på BEC’s systemer, da prototypen er målrettet disse (blandt andet gennem valg af terminologi). Ved at udvælge deltagere, der er vant til at bruge forskellige netbanker kan vi analysere, hvor stor betydning det har for en mobilbank, om den ligner den almindelige netbank.
- Testbrugerne skal teste de to forskellige signon-modeller (STS og engangskoder) samt teste den almindelige funktionalitet (se bilag 3, spørgeguide, for flere detaljer). Vi skal altså teste brugervenligheden i den centrale tekniske sikkerhed (signon og godkendelse af transaktioner) i både STS- og OTP-prototypen samt brugervenligheden i de funktioner, vi tidligere har identificeret som værende centrale for vores mobilbank-prototype (se afsnit 7.1.4).
- Om brugerne har udført testen korrekt vil blive vurderet ud fra, om de kan gennemføre alle opgaver uden problemer, hvilket vil være det optimale for en brugervenlig mobilbank.
- Brugerne får en generel introduktion til mobilbanken med fokus på signon, men ellers må de ikke hjælpes undervejs ud, over generel hjælp til brug af mobiltelefonen. Derudover vil de få udleveret en kort skriftlig vejledning til mobilbanken (se bilag 4) Hvis de sidder helt fast kan vi også guide dem, men det vil ikke være optimalt og skal noteres i forsøgsloggen.
- Om interfacet er en succes vurderes ud fra, om brugerne er i stand til at gennemføre de stillede opgaver uden problemer.
Vi vil, som tidligere nævnt, gennemføre brugertests i to omgange, der hver især forholder sig til de to ovenstående formål; evaluering af usability i browserbaseret mobile banking og evaluering af, hvordan brugerne opfatter STS-modellen i forhold til en prototype, der gør brug af engangskoder til signon.
Første runde af brugertesten foregår med to personer – dog én ad gangen – hvor formålet er at finde fejl og kritiske uhensigtsmæssigheder i designet af mobilbanken, så vi kan optimere brugervenligheden ved eventuelt at rette i prototypen, inden næste runde af brugertests igangsættes.
Anden runde af brugertesten vil ligeledes blive gennemført som en tænke-højt-test blandt 2-3 personer. Her er formålet ikke så meget at finde fejl og kritiske uhensigtsmæssigheder, men mere at evaluere, om det fremkomne mobilbank-design er et fornuftigt bud. Samtidig skal signon-sikkerhedsmodellen evalueres i forhold til de andre mulige signon-løsninger. Testpersonerne i anden runde skal ikke være de samme personer som i første runde.
I testen vil vi så vidt muligt forsøge at lade brugeren selv anvende mobilbanken uden spørgsmål eller svar fra os: Vi vil kun spørge til brugerens tanker og ikke stille ledende spørgsmål, med mindre han/hun går i stå med anvendelsen af programmet eller ikke får tænkt højt. Dog har vi ved enkelte af vores testpunkter nogle uddybende spørgsmål til brugeren: Det er punkter, hvor vi er i tvivl om, hvad den bedste løsning er, og derfor vil vi gerne vil høre brugerens syn på netop dette (se spørgeguide i bilag 3). Disse spørgsmål vil vi dog først stille, når brugeren har gennemført det punkt, han/hun er i gang med, så vi undgår, at det bliver et ledende spørgsmål.
Vi planlægger at lade brugerne anvende deres egne
mobiltelefoner: Dette vil flytte fokus i usabilitytesten fra anvendelsen af
mobiltelefoner til vores designforslag, da brugerne vil være bekendte med den
almindelige anvendelse af deres egen mobiltelefon. Vi antager, at hvis de
ellers passer i vores målgruppe, så vil de allerede bruge deres mobiltelefon
til at gå på nettet med, og dermed vil de være bekendte med, hvordan
internettet fungerer på mobiltelefonen: Dermed bliver testen af vores
applikation så vidt muligt ikke forstyrret af, at de skal regne ud, hvordan
telefonen virker. Ulempen er, at mobilbrowsere ikke er ens. Derfor kan der være
kosmetiske forskelle på, hvordan mobilbanken ser ud, og hvordan man tilgår
funktionerne. Dette, mener vi, udgør dog ikke et problem, selv om vi
selvfølgeligt skal tage højde for det i vores resultater. Når folk anvender
deres egne telefoner, afspejler det desuden virkeligheden, hvor folk vil
anvende mobilbanken med vidt forskellige mobiltelefoner og browsere, hvilket vi
i høj grad har forsøgt at tage højde for i udviklingen af vores designforslag
ved at gøre den bagvedliggende kode og designet så simpelt som muligt.
I testrunde 1 vil testpersonerne en ad gangen blive bedt om at udføre en række funktioner i den udviklede prototype, hvorefter der vil blive foretaget et kort efter-interview.
Testrunde 2 vil finde sted, efter at der er blevet rettet i prototypen som en konsekvens af resultaterne fra første testrunde, og der vil være en ny gruppe testpersoner. Selve brugertesten og opgaverne i denne vil være magen til første testrunde.
8.2.1 Begrænsninger ved brugertesten
Som vi har været inde på tidligere, er der en række begrænsninger ved vores test. Først og fremmest har vi kun et lille antal testbrugere. Vores resultater ville blive mere velunderbyggede med flere brugere, men vi antager, at fordelen ikke ville opveje den mængde ekstra tid, som det ville tage. Det underbygges især af, at en af tænke-højt-testens fordele er, at den giver gode resultater ved få brugere, samt at vi har en relativt simpel applikation at teste. Det er også en ulempe for kvaliteten af testresultaterne, at vi kun anvender personer med en mellemlang eller højere uddannelse til vores test og ikke et bredere udsnit af målgruppen (se afsnit 8.3 for en præsentation af testpersonerne). Dog forventer vi, at vores målgruppe er præcis nok til, at vi kan drage nogle generelle hovedkonklusioner.
Vores forsøg kommer til at foregå under virkelige omstændigheder, idet brugerne anvender deres egne mobiltelefoner, hvilket kan give anledning til problemer: Som i en virkelig situation er vi afhængige af, at der ikke er forsinkelser i telenettet (sms), og at dataforbindelserne (GPRS/3G/WiFi) virker. Disse faktorer kan spille ind på den oplevede brugervenlighed i vores prototype og er uden for vores kontrol. De giver dog formentligt mere virkelighedsnære resultater, da vores test kommer til at foregå under samme forhold og begrænsninger, som et slutprodukt vil blive brugt under.
8.2.2 Alternative testmetoder
Ud over tænke-højt-test, som vi har valgt at anvende, er der en lang række af forskellige testmetoder til test af både usability specifikt og software generelt. I det følgende afsnit vil vi reflektere over de alternativer, vi kunne havde valgt at teste med.
Performancetest
Ifølge Jakob Nielsen (1993: 191) er en meget udbredt testmetode performancetesting, hvor man prøver at måle, hvor effektive brugerne er ved anvendelse af brugerfladen.
Det, man oftest måler, er, hvor lang tid brugerne er om at gennemføre en given opgave, eller hvor mange opgaver de kan udføre i et givent tidsrum. Men der er også en lang række variationer.
En variant er, at man tæller det antal ”skridt”, som brugeren skal igennem for at løse opgaverne, også kaldet walkthrough. Skridt kan for eksempel være antal indtastninger eller antallet af skærmbilleder.
Risikoen er, at man i et fokus på tid ender med at måle og optimere ting, der egentligt ikke er så relevante for den samlede anvendelse af applikationen (Nielsen 1993: 192).
Performancetest har sin berettigelse i, at det er vigtigt at sikre, at brugerne kan gennemføre de opgaver, de har, inden for en rimelig tid, men som tidligere nævnt finder vi ikke tid som det springende punkt i testen af mobilbank-prototypen.
Performancetest vil oftest blive anvendt som en kvantitativ metode.
Coaching
Denne testmetode adskiller sig en del fra de gængse måder at foretage usabilitytests på (Nielsen 1993: 199). Ideen er, at brugeren har en coach, som de er velkomne til at stille alle de spørgsmål, de ønsker, under testen, hvilket er det omvendte af de normale procedurer, hvor der helst skal være så lidt interaktion mellem testbrugeren og dem, der afvikler testen. Dette giver et indblik i, hvad brugeren har af problemer under testen, og hvordan man kan afhjælpe dem. Metoden er dog mere egnet til at udforske, hvilken type og mængde af dokumentation der er nødvendig til en given applikation end at finde ud af, hvordan en bruger uden coach opfatter applikationen. Fordelene er, at situationen virker mere naturlig for testbrugerne end tænke-højt-metoden, og den gør det nemt for ukyndige brugere at teste relativt komplicerede applikationer (hvilket en mobilbank helst ikke skal være et eksempel på). Coaching er lige som tænke-højt-tests god til situationer, hvor man tester med få brugere, og metoden anvendes som regel kvalitativt.
Observationstest
Observationstest afviger fra tænke-højt-testen ved, at der ingen interaktion er mellem brugeren og forsøgsafvikleren (Nielsen 1993: 207). Det, brugeren foretager sig, bliver blot nedskrevet eller optaget på video, og brugeren skal helst ikke gives specifikke opgaver, men bare forsøge at bruge systemet til det, de ønsker. Her sikrer man sig, at der ikke sker nogen påvirkninger af brugeren, imens forsøget foregår, og så kan man stille eventuelle spørgsmål, efter testen er forløbet. Vi vurderer, at vi får mere information ud af brugerne ved at udføre testen med tænke-højt-metoden end ved at anvende observationer. Der, hvor vi kunne få mere ud af observationstesten, var ved at observere, om brugeren prøvede at anvende mobilbanken på måder, vi ikke har overvejet. Dette vægter vi dog ikke højt, da vores mobilbank-prototype har en ret afgrænset funktionalitet.
Ud over de ovenstående nævnte testmetoder er der en lang række andre metoder til gennemførelse af brugertests, lige fra fokusgrupper til spørgeskemaer. Disse har vi dog fravalgt, da vi vurderer, at de kræver for mange ressourcer i forhold til den information, de vil give os. Spørgeskemaerne ser vi som mest velegnede til at forbedre en eksisterende applikation, hvor man så kan sende spørgeskemaer til eksisterende brugere og spørge dem om deres holdninger. Jakob Nielsen (1993: 209) vurderer, at man kun får begrænset information ud af undersøgelser, hvor brugeren ikke direkte interagerer med applikationen, hvilket vi er helt enige i, og det har også dannet baggrund for vores valg af metode.
Softwaretests
Brugertests er ikke den eneste måde at teste den funktionelle kvalitet af software. Der findes forskellige former for softwaretests, der kan finde funktionelle og implementeringsrelaterede fejl i koden. Da vores applikation kun er en prototype, der skal bruges til at lave brugertests af STS-modellen og den generelle brugergrænseflade, har vi dog ikke testet implementeringen i dybden. Vi har udført en generel black-box test, der har til formål at teste alle funktionerne i en applikation ved at bruge applikationen og give den både forkerte og rigtige inddata (Sommerville 2001: 443). Vi har således testet mobilbank-prototypen på denne måde for at se, om programmet gav de rigtige resultater, og at forkerte input ikke ødelagde prototypen. Her har vi så med det samme rettet de fejl, vi fandt.
Formålet med denne test var, at brugerne i vores brugertest havde muligheden for at gennemføre de opgaver, vi stillede dem, uden at systemet fejlede, og samtidig at systemet skulle give de korrekte outputs, således at brugertesten kunne koncentrere sig om usabilitydelen af mobilbanken.
Her fandt vi blandt andet frem til en fejl – eller uhensigtsmæssighed – i nogle Nokia-telefoners WAP-browser, der gjorde det nødvendigt at tage nogle forholdsregler i kildekoden, som nævnt i afsnit 7.3.4. Men ud over dette problem vil vi ikke bruge yderligere plads i dette speciale på at dokumentere de fundne fejl, da det er sekundært i forhold til målet med at udvikle prototypen. Vi har valgt ikke at udføre yderligere softwaretests, som for eksempel stresstests.
8.3 Resultater og konklusioner fra brugertest af prototypen
I det følgende afsnit vil vi gennemgå de resultater og konklusioner, vi er kommet frem til på baggrund af de to runder af brugertesten.
Først vil vi dog kort beskrive testdeltagerne fra testrunde 1 og 2: Hvilke forudsætninger har de i forhold til at bruge netbank og mobilbank, hvor gamle er de, og hvad er deres uddannelsesmæssige baggrund:
Kresten (testrunde 1)
Kresten er 28 år og studerer datalogi og filosofi på Roskilde Universitetscenter. Han arbejder på Center for WebBaseret Læring (CWBL) på Københavns Universitet, hvilket – ifølge Kresten selv – langt fra er så teknisk, som det kan lyde.
Han har brugt netbank i omkring seks år og bruger netbanken, som er Jyske Bank, 5-6 gange månedligt. Han benytter primært netbanken til at tjekke saldo, betale girokort samt til overførsel af penge, primært mellem egne konti eller til hans kærestes konto.
Krestens forventninger til en mobil udgave af netbanken er, at den skal kunne bruges til de samme ting, som han normalt bruger sin netbank til. Hans mobiltelefon er en Sony Ericsson K610i, der er en model med et par år på bagen, og han benytter normalt nettet på sin mobiltelefon til at læse nyheder via sin udbyders portal. Tidligere brugte han også e-mail på mobiletelefonen, men det har han skippet, da det var for besværligt på hans telefon.
Anders (testrunde 1)
Anders er 29 år og studerer datalogi og offentlig administration på Roskilde Universitetscenter. Han arbejder som studievejleder. Anders har brugt netbank de sidste 5-6 år og anvender i gennemsnit netbanken, som er Lån & Spar Bank, en gang om ugen.
Han anvender primært mulighederne for at se saldi og posteringer. Derudover overfører han penge til både egne og andres konti, og endeligt bruger han netbanken til at til- og afmelde Betalingsservice-aftaler. Derudover bruger han også sin netbank som adgangspunkt til at logge på e-Boks.
Hans mobiltelefon er en Nokia E65, der er en nyere model med styresystemet Symbian S60.
Kristine (testrunde 2)
Kristine er 28 år og uddannet cand.pæd. i pædagogisk psykologi, men er pt. på barsel. Hun har brugt netbank i 2-3 år og bruger netbanken, som er Nordea, 2-4 gange ugentligt. Hun benytter primært netbanken til at betale regninger og overføre penge samt tjekke saldo, posteringer og kommende betalinger. Kristines forventninger til en mobil udgave af netbanken er, at hun skal kunne få et overblik over posteringer på sine konti. Hun forventer dog et dårligere overblik end på sin almindelige netbank, og hun vil formentligt kun bruge en mobilbank i nødstilfælde. Hendes mobiltelefon er en Nokia 5310, der er en musikmobil med styresystemet Symbian S40, og hun er ikke vant til at gå på nettet på sin mobil.
Niels (testrunde 2)
Niels er 28 år og studerer forvaltning på RUC. Han er i øjeblikket i gang med at skrive speciale. Han har brugt netbank siden 2003 og bruger netbanken, som er Danske Bank, 2-3 gange ugentligt. Han benytter primært netbanken til at betale regninger og overføre penge samt tjekke saldo, posteringer og kommende betalinger. Der udover anvender han også bankens muligheder for at lave budgetter. Niels’ forventninger til en mobil udgave af netbanken er, at han skal kunne tjekke saldi og poster, især hvis han for eksempel er i udlandet. Hvis den var fornuftigt opbygget, kunne han godt forestille sig at anvende den regelmæssigt. Hans mobiltelefon er en Nokia N73 med styresystemet symbian S60. Han er ikke særligt glad for browseren, så han anvender ikke så ofte mobiltelefonen til at gå på nettet.
Karina (testrunde 2)
Karina er 26 år og arbejder som industrilaborant, men er pt. på barsel. Hun har brugt netbank i 7-8 år og bruger netbanken, som er Roskilde Bank, cirka en gang om ugen. Hun benytter primært netbanken til at tjekke saldo samt betale girokort og overføre penge. Karinas forventninger til en mobil udgave af netbanken er, at hun skal kunne tjekke saldo og se posteringer, men hun tror ikke umiddelbart, hun ville overføre penge via mobiltelefonen. Hendes mobiltelefon er en Nokia 3500c, der benytter styresystemet S40.
8.3.1 Første testrunde
Første testrunde, der blev gennemført med Anders og Kresten, afslørede en række punkter, hvor mobilbankens brugervenlighed kunne forbedres gennem ganske små ændringer. Den testede prototype i første testrunde er forløberen til den endelige prototype, som blev præsenteret i afsnit 7.2. I anden testrunde bliver den endelige prototype testet.
Vi vil i det følgende afsnit gennemgå hovedkonklusionerne fra første testrunde, mens en komplet gennemgang af resultaterne kan ses i bilag 5.
En ting, som begge testpersoner gav udtryk for, var, at det skal forsøges undgået, at der er for meget tastearbejde, når banken skal bruges på en mobiltelefon, både i signon-processen og i selve brugen af mobilbankens funktioner.
I sammenligningen af STS-prototypen og OTP-prototypen mente Kresten, at det er en anelse nemmere at logge ind via engangskoder end via STS, især da han alligevel slæber rundt på et kodekort til sin nuværende netbank (Jyske Bank). Han synes, det er fint med et alternativ til STS-modellen, hvis sms-gatewayen er nede, men ellers foretrækker han faktisk STS, fordi denne metode kun kræver, at han har sin mobiltelefon på sig. Også Anders mente, at det var en smule nemmere at logge på i OTP-prototypen, men han foretrak alligevel STS, da han ville synes, det var irriterende at skulle bære rundt på et kodekort eller en OTP-token. I forhold til godkendelse af transaktioner i STS-prototypen, så mente Anders, at det var en smule bøvlet at godkende, fordi man var nødt til at forlade browseren for at åbne den modtagne sms. Kresten fik ikke gennemprøvet denne funktion, da sms-leverancen svigtede på dette tidspunkt i testen.
’Brødkrummerne’ i toppen og bunden af websiderne lagde hverken Kresten eller Anders rigtigt mærke til, da begge primært brugte browserens tilbageknap. Kresten lagde heller ikke mærke til logud-knapperne på bunden af siderne, med undtagelse af forsiden, og Anders så dem slet ikke.
De fandt begge mobilbank-prototypen logisk opbygget, og på en positiv måde mindede den om en almindelig netbank. Men Anders fandt det dog irriterende, at man skulle vælge konto som det første, når man ville se kommende betalinger, fordi man ikke nødvendigvis altid ved, hvilken konto en betaling gennemføres fra.
Et andet forvirrende punkt var navnet på menuen ”Opret ny betaling”. For Anders er en betaling en slags regning og ikke en overførsel. Denne forvirring kan eventuelt forklares med, at Anders er kunde i Lån & Spar Bank og ikke i et BEC-pengeinstitut. I den nuværende BEC-netbanks standardmenu hedder dette punkt ”Ny betaling”, og man må derfor forvente, at kunder, der er vant til BEC’s terminologi, vil forstå punktet bedre. På nær dette punkt fandt Anders oprettelse af en ny overførsel for logisk opbygget; dog mente han ikke, at feltet ”Navn på ny standardbetaling” var så vigtigt, at det skulle stå øverst på siden. Til gengæld mente begge testpersoner, at det ville være rart at have navnet på kontoen, man var ved at overføre fra, stående øverst på siden frem for blot kontonummeret.
Anders mener, at sider, hvor det er nødvendigt at scrolle horisontalt, er irriterende. Han vil meget hellere scrolle vertikalt, hvis scrolling ikke kan undgås helt.
I posteringsoversigten kunne både Kresten og Anders godt undvære den løbende saldooversigt ud for hver enkelt postering for at spare plads og dermed minimere behovet for horisontal scrolling – det vigtigste er at kunne se den aktuelle, gældende saldo, mener begge. Anders ville hellere have haft teksten i posteringsoversigten end den løbende saldo.
Generelt har begge ellers nemt ved at finde rundt i mobilbanken. Et sted, der forvirrer Kresten, er dog der, hvor han skal vælge, om han vil bekræfte en netop oprettet betaling med det samme eller fortsætte med at anvende mobilbanken. De to valgmuligheder hedder henholdsvis ”Bekræft via sms” og ”Gå til hovedmenu”. Her blev han i tvivl om, hvorvidt den betaling, han netop har lavet, er blevet registreret.
Da Anders skulle godkende betalingerne i sms-prototypen, syntes han, det var underligt, at valget hed ”Log ud og godkend” men da han så, at metoden benyttede sms som i signon, syntes han alligevel, det var naturligt. Det var dog lidt besværligt at skulle lukke browseren og læse den nye sms, mente han, og det virkede også underligt på ham, at man ikke kunne ændre betalingerne, når man klikkede på linket i sms’en.
I forhold til om en mobilbank kan fungere som erstatning for netbanken, så mente Kresten, at han godt kunne forestille sig – hvis han havde en smartere mobiltelefon – at bruge mobilbank frem for netbank, da det er ret trivielle ting, han bruger sin netbank til. Anders, derimod, ville aldrig nøjes med kun at bruge mobilbanken; i stedet skulle mobilbank være et supplement til den almindelige netbank, især på grund af, at skærm og tastatur på en mobiltelefon er for begrænsede til, at telefonen kan erstatte en computer.
På baggrund af resultaterne fra første testrunde er vi kommet frem til en række konklusioner, som vi i det nedenstående vil relatere til den gennemgåede usability-teori fra afsnit 5:
Input
- Indtastning skal så vidt muligt forsøges minimeret, når det foregår på en mobiltelefon. STS-prototypen havde den fordel over OTP-prototypen, at man kan gemme sms-beskeden, der indeholder brugernummeret, og dermed skal man reelt kun indtaste password for at kunne logge på mobilbanken igen, fordi man kan gensende de tidligere afsendte sms.
Denne konklusion stemmer overens med både Webcredibles og Nokias anbefalinger om, at brugerinput skal gøres så simpelt som muligt, da der er dårlige input-muligheder på mobile enheder (se afsnit 5.3.2).
Mængden af
information og navigation
- Feltet ”Navn på standardbetaling” i oprettelsen af en ny betaling er ikke så vigtigt, at det skal stå øverst ved oprettelse af ny betaling. Ved at flytte informationen længere ned på siden imødekommer man Webcredibles og Nokias råd om, at man dels skal møde brugernes behov hurtigt og dels kun skal vise den nødvendige information. Brugertesten viste også, at testpersonerne savnede, at navnet på den konto, man er ved at overføre fra, står øverst på siden i stedet for blot kontonummeret.
- Det skal forsøges undgået, at der skal scrolles horisontalt for at se hele siden. Denne egenskab kan opnås, hvis man designer mobilvenligt sidelayout, som det anbefales af Webcredible i råd nummer 7 (se afsnit 5.3.2). Horisontal scrolling gør det svært for brugeren at opdage information, der gemmer sig uden for skærmenarealet, fordi horisontal scrolling ikke er en naturlig handling for brugeren. Horisontal scrolling kan eksempelvis undgås ved ikke at bruge brede tabeller i designet.
- Løbende saldo ud for hver enkelt postering i posteringsoversigten var for begge testpersoner en ligegyldig oplysning, der sagtens ville kunne undværes, og dermed vil pladsen kunne bruges på for eksempel posteringsteksten, hvilket kan forbedre overblikket. Denne konklusion stemmer lige som de to ovennævnte punkter fint overens med designrådet om, at man kun skal vise den nødvendige information på grund af den begrænsede skærmstørrelse.
- Processen
med at godkende betalinger via sms er noget bøvlet og skal, så vidt det er
muligt, forsøges forenklet. Som både Webcredible og Nokia anbefaler (se afsnit 5.3.2), så skal
brugernes behov mødes hurtigt, hvilket ikke sker i processen med at godkende
betalinger i STS-prototypen, grundet den noget omstændelige proces, der kræver,
at brugeren forlader browseren og åbner en sms.
Information og
feedback
- I bekræftelsesbilledet efter oprettelse af en ny betaling bør de to knapper have et mere sigende navn end ”Bekræft” og ”Gå til hovedmenu”, idet sidstnævnte kan så tvivl om, hvorvidt betalingen annulleres eller gennemføres.
- Hvis det kan gøres på en sikkerhedsmæssig forsvarlig måde, så kunne man overveje, om brugeren skal have mulighed for at ændre i betalinger på ”Godkend”-siden – det vil sige den side, brugeren kommer ind på, når betalinger skal godkendes/bekræftes. Hvis dette gøres, vil mobilbank-prototypen bedre følge det råd, Ben Shneiderman giver i sin gyldne regel nummer 6 (se afsnit 5.2), nemlig at det skal være nemt at fortryde sine handlinger – her ved at kunne ændre i transaktionen.
- Endeligt kan vi konkludere, at det har stor betydning i forhold til terminologien, eller sproget, i mobilbanken, hvilken netbank brugeren er vant til. Når man designer en mobilbank er det således vigtigt at tage hensyn til, hvilke termer brugerne er vant til at se og dermed forstår. Denne konklusion stemmer overens med de anbefalinger, Jakob Nielsen og Marc Ramsay, kommer med efter deres større undersøgelse om WAP-usability (se afsnit 5.3.1). De mener, at det er vigtigt at bruge standardterminologi, så man ikke spilder pladsen på at skulle forklare ny terminologi. Dermed kan man også imødekomme Webcredibles råd om, at man kun skal vise nødvendig information, når man designer mobile webapplikationer.
På baggrund af ovenstående konklusioner har vi besluttet, at følgende elementer i den prototype, der blev testet i første runde, skal ændres, inden den anden testrunde gennemføres:
- Den løbende saldo ud for hver enkelt postering fjernes fra posteringsoversigten for at få plads til posteringsteksterne i stedet.
- Feltet ”Navn på standardbetaling” kan flyttes længere ned på den side, hvor der oprettes en ny betaling.
- Forløbet med at godkende transaktioner bør søges forenklet. I OTP-prototypen kan det ske ved, at der ikke logges ud, men blot skrives en ny engangskode for at godkende. I STS-prototypen er det straks mere vanskeligt at se, hvordan forløbet kan forenkles, idet man er nødt til at forlade browseren for at åbne sms’en med linket til at godkende betalinger. Ændringen i OTP-prototypen vil også forbedre den logiske sammenhæng i applikationen, som Ben Shneiderman anbefaler i sin gyldne regel nummer et (se afsnit 5.2). Samtidigt vil det gøre, at brugerne ikke bliver udsat for nogle overraskende interfacehandlinger.
- Ikke-godkendte betalinger bør fremgå af oversigten over kommende betalinger, men med tydelig markering af, at transaktionerne ikke er godkendte endnu. Dette vil også forbedre den logiske sammenhæng i applikationen, da alle transaktioner så vil blive behandlet ens.
- Det bekræftelsesbillede, der fremkommer efter oprettelsen af en ny betaling, skal ændres, så de to knapper hedder henholdsvis ”Bekræft nu” og ”Bekræft senere”, hvilket er mere sigende navne for brugerne.
8.3.2 Anden testrunde
Vi vil i det følgende afsnit gennemgå hovedkonklusionerne fra den anden testrunde, der er baseret på den endelige prototype, der blev præsenteret i afsnit 7. Den endelige prototype indeholder de forbedringer, vi valgte at gennemføre efter første testrunde. En komplet gennemgang af resultaterne fra anden testrunde kan ses i bilag 5.
I testrunde 2 havde vores brugere nogle andre telefoner end i første testrunde, nemlig en Nokia N73 med Symbian S60-styresystemet (Niels) og to med Nokias eget S40 styresystem (Nokia 5310, Kristine og Nokia 3500c, Karina). Det gav et uventet teknisk problem, da det viste sig at Kristines og Karinas mobiltelefoner ikke kunne logge ind på vores prototype, idet S40-browseren ikke kunne vise vores .aspx-sider, men i stedet fremkom med fejlen ”Ukendt filformat”. Da de to testdeltagere havde lånt en telefon af os (Nokia E65), kunne de gennemføre testene som tiltænkt. Da begge er vant til Nokia-telefoner i forvejen, var de i stand til at gennemføre testen med kun en smule vejledning fra vores side for at kunne betjene mobiltelefonen.
Ellers var der generel enighed blandt testpersonerne. Alle tre syntes, forsiden var logisk opbygget, og at det var godt med saldi øverst på siden, da det oftest er den information, de vil se. De gav også udtryk for, at det, der gjorde mobilbanken nem at finde rundt i, var den punktform, den var bygget op i: Alle funktioner var opbygget trinvist, så man, når man valgte et punkt, blev guidet frem til de rigtige valg. Det gjorde, at hver side kun havde de få punkter eller den feedback, som var relevant for den aktuelle funktion.
Alle tre kunne intuitivt foretage STS-signon uden at få brug for forklaringer eller hjælp, og de syntes, det fungerede godt. Der var dog to mindre problemer; i Kristines første forsøg på at logge ind, kom hun til at skrive det brugernummer, der var givet som eksempel i brugervejledningen (se bilag 4) i stedet for hendes rigtige brugernummer. Efter at være blevet korrigeret til at benytte det rigtige brugernummer, loggede hun fint ind. Karina havde også, i første forsøg med at logge på mobilbanken via sms, et lille problem, idet hun glemte at skrive keywordet ”bank” i starten af sms-beskeden, men da hun fik en fejlbesked retur fra sms-gateway’en om, at den ikke kendte keyword’et, fandt hun hurtigt ud at, at hun havde glemt dette. Efter hun havde skrevet sms’en rigtigt, gik der dog omkring 10 min, før sms’en indeholdende engangslinket dukkede op.
Alle tre testpersoner udtalte, at de bedst kunne lide at logge på STS-prototypen. Kristine og Niels syntes, det var den mest naturlige fremgangsmåde på en mobiltelefon, idet de hurtigere kan skrive en sms end åbne mobilbrowseren. OTP-prototypen virkede acceptabel for testpersonerne forstået på den måde, at de fandt fremgangsmåden let. På trods af, at de fleste syntes godt om at logge på med engangskoder, så syntes de alle alligevel, at det ville være besværligt at skulle være tvunget til at bære rundt på et kodekort for at kunne logge på en mobilbank. I forbindelse med godkendelse af transaktioner i OTP-prototypen lavede de alle den fejl, at de ville genbruge den samme engangskode, som de brugte i forbindelse med signon, også selv om de havde streget den ud på papiret. Flere af dem gav udtryk for, at de troede, engangskoden hørte til sessionen.
Ingen af testpersonerne gav, som i testrunde 1, udtryk for, at der var for meget at indtaste i forbindelse med det lange brugernavn – hverken i STS- eller OTP-prototypen. Men de gav alligevel alle udtryk for, at de generelt set helst ville undgå at taste for meget på mobiltelefonens begrænsede tastatur.
Det, som især Niels bedst kunne lide, var, at alt var enkelt, overskueligt og gik rigtigt hurtigt uden brug af tung grafik.
Da Karina ville se posteringer på en anden end den valgte konto, benyttede hun som en af de få af vores testbrugere ’brødkrummerne’ i bunden af siden i stedet for at gå ud til hovedmenuen igen. Hun sagde dog, at hun normalt bare ville bruge browserens tilbage-knap, men den kunne hun ikke lige finde på den lånte telefon. Niels brugte også brødkrummerne, ikke fordi han kunne lide at bruge dem, han ville hellere bruge browserens tilbage-knap, men hans erfaring var, at webapplikationer tit holdt op med at virke, når man brugte denne.
I forhold til input, så overså eller misforstod alle deltagerne et eller andet, da de skulle indtaste data i dato-feltet under oprettelse eller ændring af en overførsel. I første omgang var der ingen af vores testpersoner, der lagde mærke til, at man kunne efterlade datofeltet tomt, hvis transaktionen skulle gennemføres samme dag. Kristine og Karina lagde dog mærke til informationen efter første gang, de havde indtastet en dato, og de brugte muligheden i deres senere transaktioner. Niels opdagede derimod slet ikke muligheden for ikke at indtaste noget i dato-feltet. Karina var i første omgang ikke i stand til at udfylde datofeltet i korrekt format uden hjælp; hun udfyldte den først uden bindestreger, fordi det var hun vant til fra netbanken, og da det ikke virkede, prøvede hun med mellemrum i stedet for bindestreger. Hun forstod ikke, ved at kigge på eksemplet på siden (dd-mm-åååå), at hun skulle skrive datoen på præcis denne måde, også med bindestreger. Først da hun fik hjælp, fik hun skrevet datoen korrekt.
Alle syntes, at STS-modellen var god, fordi de følte, at man blev guidet bedre igennem processen med at logge ind eller godkende betalinger – også selv om man skulle ud af browseren i forbindelse med godkendelse af transaktioner.
Hvad gælder terminologien, så havde Kristine nogle gange svært ved at regne funktionerne ud, da hun ikke genkendte termerne, mens Karina – der som testens eneste person var vant til at bruge en BEC-baseret netbank – havde nemmere ved at forstå terminologien, fordi hun allerede kendte den. Det er dog en ting, brugerne hurtigt lærer, viste testen også. For eksempel havde Niels ingen problemer med at finde rundt i mobilbanken, selv om han ikke kendte termerne. Han syntes, man kunne regne ud, hvad termerne betød, ud fra hvor de var placeret i mobilbankens struktur.
På baggrund af resultaterne fra anden testrunde er vi kommet frem til en række konklusioner, som vi i det nedenstående vil relatere til den gennemgåede usability-teori fra afsnit 5:
Input
- De indtastninger, som brugerne skal foretage, skal mindskes i størst mulig grad. Alle testdeltagerne gav udtryk for, at det ikke var rart at taste meget på mobiltastaturet, og derfor er det vigtigt, at de kan gemme betalinger og i øvrigt kan foretage valg fra lister, eller at teksten er præudfyldt – i stedet for at de selv skal lave indtastningerne med mobiltelefonen. Dette er helt i overensstemmelse med resultaterne fra testrunde 1 samt Webcredibles råd om, at brugerinput skal gøres simpelt (se afsnit 5.3.2).
- Datoen var det vanskeligste for brugeren at indtaste korrekt, og det var faktisk den eneste funktion, hvor alle testbrugerne misforstod eller overså et eller andet. Som ovenstående også konkluderer, så skal brugerinput gøres så simpelt som muligt. Vanskelighederne ved at indtaste korrekte data i dato-feltet i den udviklede prototype illustrerer vigtigheden af netop denne usability-guideline.
Mængden af
information og navigation
- Det er centralt, at mobilbanken er hurtig til at blive indlæst, og at den reagerer hurtigt på brugernes handlinger: En af testbrugerne udtalte, at det var positivt, at der ikke var grafik, der fyldte på skærmen og nedsatte hastigheden. Dette er helt i overensstemmelse med resultaterne fra første testrunde, og denne tilgang til designet af mobilbank-prototypen følger rådet fra Webcredible om, at der kun skal vises nødvendig information på siden (se afsnit 5.3.2). Grafik er således ikke en nødvendighed i en mobilbank, men det kan naturligvis vise sig at være det i en anden type applikation.
- Den trinvise opbygning guidede brugerne igennem funktionerne på en måde, så de kunne undgå at lave fejl. Denne opbygning følger de anbefalinger, som Ben Shneiderman giver i det fjerde af sine såkaldt gyldne regler (se afsnit 5.2). Her pointerer han også, at handlingssekvenser, der guider brugerne intuitivt gennem en række handlinger, giver dem en opfattelse af at få fuldført noget.
- Det er vigtigt at anbringe de vigtigste funktioner først; blandt andet var alle brugerne glade for, at saldoen stod øverst på første side, så de ikke skulle klikke mere rundt end højst nødvendigt. Her kan vi igen konkludere, at både Webcredibles og Nokias råd om, at man skal møde brugernes behov (se afsnit 5.3.2) faldt i god jord hos vores testpersoner.
- Selv om den usability-litteratur, vi har gennemgået, anbefaler brødkrummer i navigationen, så man kan gå trinvist tilbage gennem side-hierarkiet, var det ikke noget, vores testbrugere kunne lide at bruge. De ville langt hellere anvende tilbageknappen i browseren. Dette kan dog skyldes, at vores prototype ikke havde nogle rigtigt dybe veje; den længste vej til at nå en funktion er således fire ’skridt’ (funktionen ”Opret ny betaling”), og der var kun én indgang til siderne, nemlig hovedmenuen, som på næsten alle sider er tilgængelig via et link i toppen af siden.
Information og feedback
- Vi kan konkludere, at det er vigtigt at give feedback på alt, hvad brugeren foretager sig. I testrunde to var alle brugere således glade for, når mobilbank-prototypen fortalte dem, hvad de var i gang med. God feedback er også en af Ben Shneidermans såkaldt gyldne regler for interfacedesign (se afsnit 5.2). I den testede prototype er dette af ressourcemæssige hensyn ikke implementeret fuldt ud i alle funktioner, men det gør ikke vigtigheden heraf mindre.
- Det er vigtigt at tydeliggøre, at engangskoderne kun skal bruges en gang; flere af brugerne ville anvende den kode, de brugte til signon, til at bekræfte transaktionerne, hvilket ikke kan lade sig gøre.
- Det er en fordel, at terminologien, der bliver anvendt i mobilbanken, er de samme som i brugerens netbank. Dette stemmer både overens med resultaterne fra testrunde et og med de konklusioner, Jakob Nielsen og Marc Ramsay havde i deres WAP-undersøgelse (se afsnit 5.3.1).
- Forsinkede sms’er, som det var tilfældet i Karinas test, kan have stor betydning for STS, da brugeren kan nå at blive meget utålmodig, mens han/hun venter på at modtage engangslinket via sms.
- Alle mobilbrowsere er forskellige. Selv om en telefon har en browser, der kan vise HTML-sider, er det ikke det samme som, at den kan vise alle websider.
Baseret på overstående konklusioner fra både testrunde et og to ville vi gå videre med følgende punkter, såfremt vores prototype skulle udvikles til en produktionsklar mobilbank:
- Indtastningen af datoen for transaktioner skal gøres nemmere for brugeren. Det ser vi to muligheder for: Enten kan man præ-udfylde dato-feltet med dagsdato (fx 01-09-2008). Dette gør, at brugeren tydeligt kan se formatet, og hvis der skal indtastes en anden dato, kan brugeren nøjes med at indtaste de tal, der skal ændres. En anden mulighed er, at brugeren kan trykke på en knap og få en ny side frem indeholdende en lille kalender, hvor brugeren kan vælge den dato, transaktionen skal gennemføres.
- Vi ville skræddersy terminologien, så den stemmer overens med den netbank, brugerne normalt anvender. Dette vil minimere brugerens forvirring over, hvad termerne dækker over.
- Mobilbanken skal testes på og tilpasses alle de udbredte telefonmodeller, således at et så stort udsnit af brugerne som muligt kan anvende den. I denne forbindelse bør man være sparsom med ”avanceret” indhold såsom JavaScript og brug af tabeller. De fleste mobilbrowsere kan vise tabeller, men det ser ikke altid pænt og overskueligt ud. For eksempel så vi i begge runder af brugertestene, at tabellerne tvang brugerne til at scrolle vertikalt, eller at telefonerne delte tabellerne op på uhensigtsmæssige måder. De fleste telefoner kan dog godt vise tabellerne på en fornuftig måde, men det kræver ofte, at brugeren aktivt redigerer mobilbrowserens indstillinger, så teksten bliver mindre og/eller skærmlayoutet ændres. Ikke alle brugere er klar over disse muligheder, så man bør tilstræbe, at mobilbankens design ser fornuftigt ud med browserens standardopsætning. Flerkolonnetabeller bør om muligt helt undgås.
9 Mobilbank-prototypen og BEC’s fremtidige satsninger
BEC havde, som tidligere nævnt, indtil 15. januar 2006 en mobilbank, i form af en WAP-løsning. Denne blev dog nedlagt på baggrund af, at næsten ingen brugere anvendte løsningen. Statistikken viste således, at kun mellem 1 og 14 kunder om dagen benyttede WAP-løsningen, og samtidigt var den teknisk forældet. Løsningen var nemlig skrevet til WAP 1.1-browsere og virkede ikke i nyere (1.2 og 2.0), hvilket gjorde, at nyere telefoner ikke kunne benytte WAP-løsningen. Og da der kan antages at være en sammenhæng imellem dem, der ville bruge WAP, og dem, der køber de nyeste telefoner, var det ekstra slemt.
BEC præsenterede over for sine banker, i forbindelse med lukningen af den gamle WAP-løsning, en løsning til opgradering, men bankerne ønskede dog ikke at betale for det, da de mente, at de kunne øge antallet af brugere nok til, at det var forretningsmæssigt forsvarligt. En projektleder fra BEC gav i et interview foretaget i forbindelse med dette speciale udtryk for, at løsningen simpelt hen var for tidligt ude: Den kunne for lidt, og teknologien var ikke moden, hvilket han dog mener, at den er nu. BEC foretog i foråret 2007 en forundersøgelse af, hvilke funktioner der skulle være i en mobilbank, hvis en sådan skulle udvikles. Ideen blev dog lagt på hylden, blandt andet fordi BEC endnu ikke havde klarhed over, hvad der ville ske med sikkerhedsmodellen i den almindelige netbank og i resten af banksektoren, og virksomheden ville derfor afvente, hvad der her skulle ske.
På trods af beslutningen om at nedlægge WAP-løsningen i 2006 kan vi, på baggrund af interne notater og flere samtaler med BEC-ansatte, konkludere, at interessen for at udvikle en ny mobilbank i BEC stadig er til stede, om end en mobilbank ikke er lige om hjørnet.
I det følgende har vi derfor, på baggrund af konklusioner fra dette speciale, opstillet nogle anbefalinger, som BEC bør være opmærksom på, hvis virksomheden skal investere tid og ressourcer i en ny mobilbank-løsning:
- Benyt terminologi og fremgangsmåder, der minder om dem i den traditionelle netbank.
- Sørg for at teste mobilbanken i alle kendte mobilbrowsere, da der kan være meget stor forskel, selv hvis siderne validerer efter XHTML-standarden.
- Undgå ’avancerede’ HTML-elementer, såsom dropdown-menuer og flerkolonnetabeller. Ikke alle mobilbrowsere kan vise det, mens nogle kræver, at brugeren ændrer i browserens opsætning for at få det til at virke.
- Undgå grafik, der kan give tunge og dyre sider at hente på en mobiltelefon.
- Undgå at tvinge brugeren til at bære rundt på ekstra hardware eller et papir med engangskoder (se nedenstående). Tilbyd eventuelt engangskoder/OTP-tokens som et alternativ, hvis GSM-netværket svigter.
- Forsøg at følge de usability-retningslinjer, som er målrettet mobile webapplikationer (se afsnit 5)
Designforslaget præsenteret i dette speciale vil være forholdsvist nemt at integrere i BEC’s eksisterende systemer. En BEC-ansat interviewet i forbindelse med dette speciale, så for eksempel gode muligheder for, at man kunne integrere sms-signon til en mobilbank med BEC’s eksisterende sms-service. Her er brugeren allerede oprettet med sit mobilnummer, og man kunne blot tilføje et ekstra keyword til sms-service, som – i stedet for at sende eksempelvis en saldooversigt via sms – sendte et engangslink, der giver adgang til mobilbanken.
9.1 Ny officiel Digital Signatur
Mens dette speciale har været undervejs, er der kommet
detaljer frem i offentligheden om en ny Digital Signatur – DanID –
som PBS, og dermed de danske pengeinstitutter, står bag. DanID gør brug af
engangskoder for at sikre to-faktor sikkerhed, og engangkoderne vil være at
finde på et lille kort, som brugere får tilsendt fra DanID. PBS udtaler i en
pressemeddelelse, at det kan forventes, at danske netbanker vil overgå til at
benytte DanID som signon-metode: ”Når man
klikker ind på sin netbank, skal man inden længe bruge sit DanID” (PBS
2008).
Hvis det bliver tilfældet, også hos BEC, vil det være nærliggende at implementere denne signon-model også i mobilbanken. Men, som resultaterne af vores brugertests viser, så er brugerne ikke glade for at være nødt til at skulle bære rundt på et kodekort eller en OTP-token for at kunne logge i mobilbanken, selv om de syntes, det var en meget brugervenlig løsning. BEC bør derfor, hvis den fremtidige signon-model for netbanken involverer DanID, overveje at implementere begge signon-modeller, både DanID og STS, i en mobilbank-løsning. Dermed får brugerne frihed til selv at vælge, om de har lyst til at slæbe rundt på deres digitale signatur for at benytte mobilbanken, og mobilbanken er samtidig mindre sårbar over for forstyrrelser i GSM-netværket, fordi der er en alternativ signon-model, der gør brug af engangskoder, nemlig DanID.
Driftsstabiliteten på BEC’s sms-gateway har der ofte været problemer med, og der opstår tit situationer, hvor man i flere timer ikke kan sende sms til en bestemt operatør. Dette er, ifølge en BEC-ansat interviewet i forbindelse med dette speciale, ikke en driftssikkerhed, BEC kan stå inde for på et primært produkt som den traditionelle netbank. Men til en mobilbank, som kan ses som et tillægsprodukt til netbanken eller sms-service, vil det formentlig bedre kunne accepteres.
Endeligt skal det nævnes, at PBS – ifølge BEC – arbejder på at indføre et sim-toolkit, der skal installeres af teleudbyderne på simkortet og dermed give nem adgang til signaturfiler, der kan benyttes til betaling via mobiltelefoner. Dette er dog stadig på forsøgsstadiet, men kan måske i fremtiden blive et alternativ til mobilbank-signon med sms eller engangskoder.
10 Konklusion
Vi har i dette speciale gennemgået en række teorier inden for sikkerhed og usability samt udviklet en prototype med baggrund i disse teorier. Derefter har vi testet prototypen blandt brugere, alt sammen for at kunne besvare problemformuleringen:
Hvordan er sikkerheden og brugervenligheden
i en signon-model til mobilbank, der bruger Smsbaseret To-faktor Signon (STS),
og er denne løsning mere brugervenlig end en traditionel signon-model baseret
på engangskoder? Hvordan skal en mobilbank designes for at være så brugervenlig
som mulig?
Som nævnt i indledningen ville vi først og fremmest gerne undersøge sikkerheden og brugervenligheden i vores konkrete designforslag, kaldet STS, og derefter ville vi sammenligne brugervenligheden i STS med en mere traditionel signon–model baseret på engangskoder. Samtidig ville vi også gerne diskutere, hvordan selve funktionerne i en mobilbank skal designes, så de fremstår brugervenlige.
Baggrunden for at udvikle og diskutere STS-modellen var blandt andet, at mobilbanker i dag ikke er udbredt i Danmark – kun Danske Bank tilbyder således pt. denne løsning til sine kunder. Vi kunne derfor godt tænke os at diskutere, om man kunne satse på STS-modellen, hvis mobilbanker skulle udbredes til flere danske banker.
Vi argumenterer i specialet for, at enkelt-faktor autentificering ganske enkelt ikke er sikkert nok til at beskytte følsomme tjenester som netbanker. I Danmark stiller Finansrådet da også krav til, at netbanker som minimum benytter to-faktor autentificering. STS-modellen følger denne anbefaling, idet der skal bruges både et fast password og en engangskode for at logge på mobilbank ved hjælp af STS. Mobiltelefonen benyttes som erstatning for en OTP-token eller papirbaserede engangskoder. Det kan give en mulig svaghed, der underminerer to-faktor sikkerheden, fordi mobiltelefonen benyttes til både at modtage den genererede engangskode og til at gå på nettet med. Der kan dog argumenteres for, at svagheden ikke udgør en uacceptabel risiko, da der principielt benyttes to forskellige kanaler, nemlig sms og internettet. Hvis sms’en, og dermed engangskoden, opsnappes, kræves der stadig et fast password for at kunne logge på mobilbanken og omvendt. Den største trussel er her, hvis mobiltelefonens browser er i stand til at huske passwordet til mobilbanken. Kun få mobilbrowsere i dag tilbyder dette, men i takt med, at det bliver mere almindeligt, stilles potentielle mobilbank-udviklere over for en udfordring om at skulle udvikle en løsning, der forhindrer mobilbrowseren i at gemme brugerens password. Hvis dette problem overkommes, er der dog stadig sikkerhedsrisici ved STS-modellen: Da sms’en sendes via GSM-netværket, hvor der ikke er kryptering af data i og mellem operatørernes interne netværk, er der en risiko for, at uautoriserede personer med direkte adgang til operatørens netværk vil være i stand til at aflytte engangskoden. Et angreb, der udnytter denne svaghed vil dog ikke være katastrofalt for sikkerheden i STS-modellen, idet brugeren stadig skal godkende sig med et password på mobilbankens hjemmeside, hvilket illustrerer sikkerhedsfordelene ved to-faktor autentificering. Hvis en angriber derimod opsætter en falsk GSM-basestation, der imiterer en legal operatør over for brugeren, kan også denne sikkerhed sættes ud af kraft, omend det er et meget omstændeligt angreb. Andre potentielle trusler mod en mobilbank baseret på STS er fjernstyringssoftware, phishing via sms, samt hvis brugeren mister sin mobiltelefon. Vi vurderer dog, at ingen af disse potentielle trusler udgør en større sikkerhedsrisiko end dem, man ser til pc-baserede netbanker.
Vi har også set, at STS præsenterer en mulighed for at logge på en mobilbank, uden at brugeren har brug for at medbringe ekstra hardware (ud over den mobiltelefon de alligevel bærer rundt på) eller printede engangskoder. Vores brugertests viste, at det var noget, brugerne satte stor pris på. Det viser, at brugervenlighed ikke kun handler om ’nemhed’, men også om ’brugbarhed’. En mobilbank gør ikke stor nytte, hvis brugeren har glemt sin OTP-token og dermed ikke er i stand til at logge på sin mobilbank på farten.
Hvad angår nemhed, var signon med henholdsvis STS og OTP-koder nogenlunde lige nemme at benytte for brugerne i vores test, mens re-autentificering i forbindelse med godkendelse af betalinger kunne virke forvirrende med STS, fordi det krævede, at man forlod browseren. De fleste brugere foretrak dog denne svækkelse af nemhed til fordel for brugbarhed ved ikke at være afhængig af en OTP-token. Det kan dog diskuteres, om denne holdning skyldes, at testbrugerne ikke er vant til at bruge engangskoder til at logge på netbank: Kun én af testbrugerne var således vant til dette, gennem Jyske Bank, og han var samtidig den eneste testbruger, der ikke ville have noget imod at medbringe engangskoder for at kunne logge på en mobilbank.
Det bringer os videre til det faktum, at der er en ny, officiel dansk digital signatur på vej, kaldet DanID, som PBS står bag. DanID bygger på samme principper som Jyske Banks signon-model, nemlig brug af engangskoder. Meget tyder på, at DanID vil få en dominerende rolle i danske netbanker, idet PBS allerede udvikler løsninger til pengeinstitutternes fælles infrastruktur. Dette vil sandsynligvis gøre det nemt for bankerne at implementere DanID enten som afløsning for deres eksisterende signon-model eller som et supplement. Og hvis brugerne vænnes til altid at have deres DanID med sig, kan det hurtigt blive en populær metode til også at logge på mobilbank.
Vores gennemgang af usability-teori samt resultater fra de gennemførte brugertests har vist os, at en af de største usability-udfordringer i forbindelse med at designe webapplikationer til mobiltelefoner er skærmstørrelsen. Den lille opløsning kræver, at man tager højde for det tidligt i designet, da nedskalering af eksisterende webapplikationer sjældent fungerer særligt godt.
Derfor er det også vigtigt at anbringe de væsentligste funktioner først; blandt andet var alle brugerne i de gennemførte brugertests glade for, at saldoen stod øverst på første skærmbillede efter signon i prototypen, da det ofte er den information, de søger.
Det er også en stor usability-udfordring. at mobile browsere viser websider meget forskelligt: Selv om en telefon har en browser, der kan vise HTML-sider, er det ikke ensbetydende med, at den kan vise en mobilbank, som designerne har tænkt sig, og nogle gange er telefonen slet ikke er i stand til at vise siden, som vores brugertest viste. Det er derfor vigtigt i udviklingen af en mobilbank, at den testes på og tilpasses alle de mest udbredte telefonmodeller, således at et så stort udsnit af brugerne som muligt kan anvende den. I denne forbindelse bør man være sparsom med ”avanceret” indhold såsom JavaScript og brug af tabeller, idet det ikke altid ser pænt og overskueligt ud, selv om mobilbrowseren godt kan vise elementerne. De fleste mobilbrowsere kan godt vise eksempelvis tabeller på en fornuftig måde, men det kræver ofte, at brugeren aktivt redigerer mobilbrowserens indstillinger, så teksten bliver mindre og/eller skærmlayoutet ændres. Ikke alle brugere er klar over disse muligheder, så man bør tilstræbe, at mobilbankens design ser fornuftigt ud med mobilbrowserens standardopsætning.
Udover mobilbrowsernes forskellighed er brugerens begrænsede input-muligheder også en central udfordring nævnt i usability-teorien (Webcredible 2007). Dette bekræftede vores test af mobilbank-prototypen også, idet alle testdeltagerne gav udtryk for, at det ikke var rart at taste meget på mobiltastaturet. Derfor er det vigtigt, at de kan foretage valg fra lister, eller at teksten er præudfyldt.
STS-modellen har her den fordel, at man kan gemme sms-beskeden, der indeholder brugernummeret, og dermed skal man reelt kun indtaste password for at kunne logge på mobilbanken igen, fordi man kan gensende de tidligere afsendte sms, der ligger gemt i telefonen.
Vi har også set, at det er centralt at anvende standardterminologi, som brugeren allerede er fortrolig med i sin netbank. Dermed spilder man ikke plads på at forklare en ny terminologi, hvilket er centralt både i forhold til navigation og det faktum, at brugere, ifølge Nielsen og Ramsay (2000), ikke gider læse ret lange tekster på en lille skærm.
På baggrund af de gennemførte brugertest kan vi også konkludere, at brugervenlighed i en mobilbank kan fremmes meget ved at anvende en trinvis opbygning af funktionerne: Ved at give få valgmuligheder i hvert skærmbillede – i form af links – og samtidig hele tiden fortælle brugeren, hvad han/hun er i gang med, minimeres risikoen for, at brugeren laver fejl, samtidig med at det minimeres, hvor meget brugeren selv skal indtaste. Denne tilgang følger desuden Ben Shneidermans gyldne regel om, at brugerens handlingssekvenser skal organiseres, så de har en begyndelse, midte og afslutning (Shneiderman 2005: 74).
Trinvis opbygning og præ-udfyldte felter eller links er således de nøgleelementer, vi har identificeret som medvirkende til at sikre oplevet brugervenlighed i en mobilbank.
Vi kan altså konkludere, at det er muligt at skabe en mobilbank med både høj brugervenlighed og høj sikkerhed, men især brugervenligheden kræver grundig planlægning og udførsel af et design, der er specifikt tiltænkt mobile enheder, samt grundig test af applikationen på alle mobile enheder, der anvendes af målgruppen og ønskes understøttet, da næsten alle telefoner viser mobile sider lidt forskelligt. STS-modellen er mest brugervenlig for de brugere, der kun anvender mobilbanken lejlighedsvist, da de så slipper for at bære rundt på eksempelvis printede papirkoder eller et ActivCard. For de brugere, der vil anvende mobilbanken ofte, kan engangskoder være en mere brugervenlig løsning, da det giver et mere uforstyrret flow.
Om STS-modellen kan blive den tilgang, der gør, at danske banker begynder at satse på at udbrede mobilbanker til deres kunder, afhænger af, om bankerne vurderer sikkerhed, brugervenlighed eller økonomi højest. STS-modellen sikrer brugervenlighed ved blandt andet at gøre brugerne uafhængige af ekstra hardware, i form af OTP-tokens, og samtidig er det en billigere løsning for bankerne, der kan slippe for at skulle udsende tokens eller engangskoder til kunderne. Til gengæld er der nogle større udfordringer i at gøre STS-modellen sikker end ved OTP-tokens, og der er nogle forbehold, vi er nødt til at tage: Inden en bank eventuelt beslutter at satse på udviklingen af en mobilbank baseret på STS, bør sikkerheden undersøges nøjere. Vi har argumenteret for, at sikkerheden i STS-modellen er på niveau med eksisterende netbank- og mobilbankløsninger, men der kan hurtigt opstå nye forhold, der kræver genovervejelse af sikkerheden i modellen. Et eksempel er problemet med, om mobilbrowseren kan gemme brugerens password. I de fleste telefoner i dag er det ikke en mulighed, men i takt med, at der begynder at komme mobilbrowsere på markedet, der giver brugeren denne mulighed, udfordres sikkerheden og gør det at ’miste sin mobiltelefon’ til en af de største sikkerhedsrisici ved modellen, og derfor burde en videre undersøgelse af modellen beskæftige sig med teknikker, der kan bruges til at forsvare sig mod dette sikkerhedshul.
11 Litteraturliste
Adams, A.
& Sasse, M. A. (1999)
The Users are
not the Enemy
Communications of the ACM, årgang 42, nr. 12, side 40-46
Balfanz, D.,
Durfee, G., Grinter, R. E., & Smetters, D. K. (2004)
In Search of
Usable Security: Five Lessons from the Field.
IEEE Security and Privacy,
årgang 2, nr. 5
side 19-24
Ballard, B.
(2007)
Designing the Mobile User Experience
John Wiley & Sons.
BEC (2007a)
Beslutningsnotat om webbank mobil
Internt
dokument fra BEC – ikke vedlagt
som bilag i den offentlige version af specialet
BEC (2007b)
Netbankanalysen 2007 –
kommentering af udvalgte resultater og statements
Internt
dokument fra BEC – vedlagt som bilag 7
Bishop, M.
(2005)
Psychological
Acceptability Revisited
I: Cranor, L. F. & Garfinkel, S.
(Eds.), Security and Usability -
Designing Secure Systems That People Can Use
O’Reilly
Boolsen, M.W. (2004)
Fra spørgeskema til statistisk analyse
C.A. Reitzels
Forlag
Chandra, P., Messier, M. & Viega,
J. (2002)
Network
Security with OpenSSL
O’Reilly
Claessens, J.,
Dem, V., De Cock, D., Preneel, B. & Vandewalle, J. (2002)
On the
Security of Today’s Online Electronic Banking Systems
Computers & Security, årgang 21, nr. 3, side
253-265
Coursen, S.
(2007)
The future of
Malware
Network Security, årgang 2007, nr. 8, side 7-11
Grimes, R. A.
(2006, 17. november)
MySpace
password exploit: Crunching the numbers (and letters)
InfoWorld.
Lokaliseret den 14. juli 2008 på http://www.infoworld.com/article/06/11/17/47OPsecadvise_1.html
Hertzum, M., Juul, N. C., Jørgensen, N. H., & Nørgaard, M. (2004)
Usable Security and E-Banking: Ease
of Use vis-à-vis Security
I: OZCHI
2004 Conference Proceedings. Wollongong, Australia: University of
Wollongong.
Hypponen, M. (2006)
Malware goes mobile
Scientific
American, november 2006
Ihlwan, M. (2004, 27. september)
Korea: Mobile Banking Takes Off
BusinessWeek. Lokaliseret den 20. juli
2008 på http://www.businessweek.com/magazine/content/04_39/b3901068.htm
Krebs, B. (2006, 19. juli)
Citibank Phish Spoofs 2-Factor
Authentication
Washington Post. Lokaliseret den 14.
juli 2008 på http://blog.washingtonpost.com/securityfix/2006/07/citibank_phish_spoofs_2factor_1.html
Krøyer, K. (2001, 21. maj)
Spion-udstyr kan købes på nettet
Ingeniøren. Lokaliseret den 22. juli
2008 på http://ing.dk/artikel/38863
Mannan, M. & van Oorschot, P.C
(2007)
Using a Personal Device to Strengthen
Password Authentication from an Untrusted Computer
I: Financial Cryptography and Data Security, 11th International Conference, FC 2007
Molich, Rolf (2003)
Brugervenligt webdesign, 2. udgave
Ingeniøren|bøger
Nagel, B. (2007)
Mobile
Authentication Marries Security With Convenience
Forrester Research
Nielsen, J. (1993)
Usability Engineering
Academic Press
Inc.
Nielsen, J. & Ramsay, M. (2000)
WAP Usability–Déjà Vu: 1994 All
Over Again
Nielsen Norman Group
Nokia (2004, 11. november)
Usability Is A
Must In Browser-Based Mobile Banking
Version 1.0.
Lokaliseret den 21. marts 2008 på http://www.forum.nokia.com/main/html_readers/usability_is_a_must_in_browser_based_mobile_banking.html
Payne, B. D.
& Edwards, W. K. (2008)
A Brief
Introduction to Usable Security
IEEE Internet
Computing, årgang 12, nr. 3, side 13-21
PBS (2008, 25. juni)
DanID bag næste generation af digital
signatur
Lokaliseret
den 31. juli 2008 på http://pbs.dk/dk/nyheder/nyhed_080625
Pedersen, Rune (2008, 19. juni)
Password-fri adgang til Danske netbank
via mobilen
Computerworld.
Lokaliseret den 10. august 2008 på http://www.computerworld.dk/art/46458
Preece, J.,
Rogers, Y. & Sharp, H. (2002)
Interaction
Design: Beyond Human-Computer Interaction
John Wiley & Sons
Quirke, J.
(2004, maj)
Security in
the GSM system
AusMobile. Lokaliseret den 8. august 2008 på http://www.csd.uoc.gr/~hy457/_Past-Courses/0607F/papers/Security_in_the_GSM_system.pdf
Ramachandran,
J. (2002)
Designing
Security Architecture Solutions
John Wiley & Sons, Inc.
Sans Institute
(2001)
The GSM standard (An overview of its
security)
Lokaliseret den 8. juli 2008 på http://www.sans.org/reading_room/whitepapers/telephone/317.php
Sasse, M. A. & Flechais, I.
(2005)
Usable Security
I: Cranor, L. F. & Garfinkel, S.
(Eds.), Security and Usability -
Designing Secure Systems That People Can Use
O’Reilly
Schneier, B.
(2006, 14. december)
MySpace
Passwords Aren't So Dumb
Wired.
Lokaliseret den 14. juli 2008 på http://www.wired.com/politics/security/commentary/securitymatters/2006/12/72300
Shneiderman, B. & Plaisant, C.
(2005)
Designing the
User Interface: Strategies for Effective Human-Computer Interaction,
4. udgave
Addison-Wesley
Simonsen, T.
R. (2008, 20. juni)
Danske Bank erkender svag sikkerhed i
mobil-bank
Version2.
Lokaliseret den 10. august 2008 på http://www.version2.dk/artikel/7685
Smetters, D. K. and Grinter, R. E.
(2002)
Moving from the design of usable
security technologies to the design of useful secure applications.
I: Proceedings
of the 2002 Workshop on New Security Paradigms (Virginia Beach, Virginia,
September 23 - 26, 2002). NSPW '02. ACM, New York, side 82-89
Sommerville, I. (2001)
Software Engineering,
6. udgave
Pearson Education Limited
Tiwari, R. & Buse, S. (2007)
The Mobile Commerce Prospects: A
Strategic Analysis of Opportunities in the Banking Sector
Hamburg
University Press
The Register (2005, 12. oktober)
Phishing attack targets one-time
passwords
Lokaliseret den 10. august 2008 på http://www.theregister.co.uk/2005/10/12/outlaw_phishing
Tubin, G. (2005, april)
The Sky IS Falling: The Need for
Stronger Consumer Online Banking Authentication
TowerGroup. Lokaliseret den 1. marts
2008 på http://www-304.ibm.com/jct03004c/businesscenter/fileserve?contentid=82467
US-CERT (2004,
3. december)
Buffer
Overflow in Microsoft Internet Explorer
Lokaliseret
den 3. august 2008 på http://www.us-cert.gov/cas/techalerts/TA04-315A.html
VeriSign
(2001, januar)
Jan 2001 -
Advisory from VeriSign, Inc.
Lokaliseret
den 8. august 2008 på http://www.verisign.com/support/advisories/authenticodefraud.html
Webcredible
(2007, oktober)
7 usability
guidelines for websites on mobile devices
Lokaliseret
den 23. maj 2008 på http://www.webcredible.co.uk/user-friendly-resources/web-usability/mobile-guidelines.shtml
Whitten, A. & Tygar, J. D. (2005)
Why Johnny Can’t Encrypt – A
usability Evaluation of PGP 5.0
I: Cranor, L. F. & Garfinkel, S.
(Eds.), Security and Usability -
Designing Secure Systems That People Can Use
O’Reilly
12 Liste over bilag
Bilag 1: Begrebsliste
Liste over særlige begreber brugt i dette speciale.
Bilag 2: Spørgsmål og
resultater fra indledende spørgeskemaundersøgelse på RUC
I specialets startfase gennemførte vi en webbaseret spørgeskemaundersøgelse blandt studerende og ansatte på RUC. Spørgeskemaet havde til hensigt dels at afdække behovet for en mobilbank og dels at fastslå, hvilke funktioner de potentielle brugere ønskede.
Bilag 3: Spørgeguide
til brugertesten
Oversigt over brugertestens forløb og spørgsmål.
Bilag 4: Brugervejledning
til mobilbank
Dette dokument fik brugerne udleveret i forbindelse med brugertesten af den udviklede prototype.
Bilag 5: Komplette
resultater fra brugertesten
Testforløbene for hver enkelt testbruger er her skrevet ned som små ’historier’, der opsummerer resultater og konklusioner fra hver enkelt brugertest.
Bilag 6: BEC -
Beslutningsnotat om webbank mobil
OBS: Dokumentet er ikke tilgængeligt i den offentlige version af dette speciale.
Bilag 7: BEC -
Netbankanalysen 2007 – kommentering af udvalgte resultater og statements
Dokumentet er udleveret fra BEC og er en kommentering af udvalgte resultater fra Netbankanalysen 2007, udarbejdet af Analyse Danmark, som BEC modtog den 10. oktober 2007.
Bilag 8: CD-ROM
indeholdende kildekode til prototypen
Denne CD-ROM indeholder prototypens kildekode og SQL-dump af databasen med testdata.