To nettenester for å la personar få tak i sine brukarnamn og sette passord. Dette løysast blant anna ved hjelp av tekstmeldingar, samt webservicen CIS. Tenesta skal vere generell nok til å kunne brukast av alle Cerebrum-instansar som ønsker det.
Tenesta består av to funksjonar:
- Ei nettside for å kunne hente ut ei liste over brukarnamna sine.
- Ei nettside for å kunne sette seg eit nytt passord for ein av brukarane sine. Dette fungerer også etter at brukaren er i autopassord-karantene, sidan vi autentiserer personar ved hjelp av eingangskoder sent til mobilen.
Tenesta hadde under utvikling arbeidsnamnet individuation, men har seinare blitt forenkla til gløymd-passord-tenesta.
Finn-ditt-brukarnamn-tenesta
Tenesta skal i hovudsak be personen om nok opplysingar til å identifisere personen, og returnere ei liste over brukarnamna som høyrer til personen. Sidan opplysingane tenesta returnerer er relativt sett harmlause ber vi ikkje om så mange opplysningar. Vi kan difor ikkje vite med sikkerhet at det er personen sjølv som har bedt om brukarnamna, så det er viktig at tenesta ikkje returnerer noko som helst annan informasjon enn ei liste over brukarnamna til personen og deira tilhøyrande status.
Tenesta skal fungere som følger.
Personen blir presentert med ein kort tekst som forklarer kva tenesta gjer, og eit skjema der ein kan fylle ut følgande informasjon:
- Fødselsnummer, Studentnummer eller Ansattnummer (eitt av felta må vere utfyld). Fødselsnummer bør settast som default, då dette er det folk flest ønsker å bruke.
- Captcha (påkrevd).
Brukaren fyller ut og sender skjemaet.
Om skjemaet er utfylt meir enn eit gitt antal gonger, vil brukaren få feilmeldinga:
"For mange forsøk. Du er blitt midlertidig sperret fra tenesten."
Merk at dette gjeld uansett om skjemaet vart riktig utfylt eller ikkje. Sperringa varer i eit definert antal minutt.
Om ingen er registrert på oppgitt id får brukaren feilmeldinga:
"Kunne ikke finne personen ut fra oppgitte data. Vennligst prøv igjen."
Om personen har reservert seg frå publisering på nett, registrert i FS eller SAP:
"Kunne ikke finne personen ut fra oppgitte data. Vennligst prøv igjen."
Merk at denne meldinga er identisk med om personen ikkje vert funne. Dette for å unngå at dei som er reserverte vil kunne bli lista ut. Det er difor viktig å opplyse på sida om at reserverte brukarar ikkje listast ut.
For UiO definerast alle utan aktive tilknyttingar som reserverte, dvs. alle som ikkje er registrert som aktiv i noko kjeldesystem vil ikkje kunne listast ut her.
Dersom alle opplyste id'ar gir treff på samme personen:
- Brukaren får ei liste over alle brukarane sine, sortert etter prioritet, primærbrukaren først. Brukarar utan tilknyttingar (affiliations) vert lista ut til sist, etter kva som vert returnert frå databasen.
- Kvart brukarnamn skal ha ein tilhøyrande status. Sjå Statusar.
- For kvart brukarnamn skal det vere ei lenke for å bytte passord for denne brukaren. Brukarar som er sperra eller på andre måtar ikkje kan få bytte passord har inga slik lenke. Dette avhenger av tilhøyrande status.
- Sida skal innehalde ei forklaring på kva ein kan gjere for å få tilgang til ein brukar, inkludert lenke til passordtenesta og informasjon om å kontakte lokal IT.
- Dersom personen ikkje har ein brukar vert det informert om dette og beskjed om å kontakte sin lokale IT-ansvarlege om dette er ein feil.
- Merk at ingen annan informasjon, td. namnet til personen, skal publiserast.
- Dersom noko av informasjonen vert mellomlagra må det vere mulig for personen å logge seg ut av tenesta.
Vi har vurdert om personen bør bli varsla på noko vis (til dømes via e-post) om at lista over brukarnamn er blitt henta ut. Vi har valgt å ikkje informere om dette, men vi ser at dette kan vere eit behov.
Statusar
Kvar brukar vil ha ein status som skal vere forståeleg for personen samtidig som den ikkje avslører for mykje informasjon. Statusane vi har definert:
- Ikkje aktiv - Not active: Brukarar som er avvikla, reserverte, er utan spread eller har aktive karantener som ikkje er autopassord eller auto_kunepost. Karantenetypane må kunne endrast i ein cereconf- variabel.
- Aktiv - Active: Alle aktive brukarar.
Det kan vurderast å seinare utvide tenesta med fleire statustypar, til dømes med passordkarantene for dei som har karantena autopassord.
Sett-nytt-passord-tenesta
Tenesta skal i hovudsak autentisere brukaren på ein annan måte enn ved bruk av passord, og dermed kunne la brukaren få sette eit nytt passord. Dette skal også fungere sjølv om brukaren er blitt sperra grunna eit for gamalt passord.
Valg av autentiseringsmetode
Før ein person autentiserer seg, må ein velge ein innloggingstype, etter kva brukargruppe ein er i. Brukaren vil kunne velge blant:
Mobiltelefon: Gjeld alle som har ei aktiv tilknytting til eit autoritativt kjeldesystem og som er registrert med eit mobilnummer.
MinID: Gjeld alle som har ei aktiv tilknytting til eit autoritativt kjeldesystem.
Merk at bruk av MinID ikkje vil kunne bli tatt i bruk i første versjon av tenesta.
Systemet må gjere det enkelt å kunne legge til og disable autentiseringsmetodar (og påsjå at autentiseringsmetoden faktisk ikkje kan brukast). Dersom berre ein metode er tilgjengeleg kan brukaren automatisk vidaresendast til denne.
Autentisering
Mobiltelefon
Personen må fylle ut eit skjema, der vi ber om:
Brukarnamn (påkrevd).
Dette kan vere ferdig utfyld om det er oppgitt i urlen, på formen "password.php?username=mrbob". Brukarnamnet må då strippast for all eventuell html-kode. For å unngå misbruk skal det ikkje sjekkast om brukarnamnet er gyldig. Brukarnamnet skal kunne endrast i skjemaet sjølv om det er ferdigutfyld.
Fødselsnummer, studentnummer eller ansattnummer (eitt felt må vere utfyld). Fødselsnummer bør settast som default.
Kan vere ferdig utfyld om ein har klikka på ei lenke frå finn-ditt-brukarnamn, men må då vere mulig å endre. Dette skal ikkje komme med i url-en, men kan til dømes vere lagra i sesjonen i ein kort periode. Det er viktig at det då berre er opplysingar som brukaren har oppgitt i brukarnamn-tenesta som leggast ved, og ikkje informasjon henta frå Cerebrum, då dette ville kunne opne opp for uthenting av fødselsnummer ved å td. oppgi eit studentnummer.
Mobilnummer (påkrevd).
Må opplyse om at nummeret på førehand må vere registrert i eit autoritativt kjeldesystem (td. SAP eller FS), evt. i Brukerinfo om det er opna for registrering der, td:
" Mobilnummeret må på forhånd være registrert i StudentWeb eller i SAP-portalen."
Vi må ta hensyn til at mobilnummer vert tasta inn i ulike format, i tillegg til at kjeldesystema har ulik grad av datavask. Krava til mobilnummer:
- Mellomrom vert automatisk fjerna både frå brukarinput og frå registrerte mobilnummer.
- Dersom vi ikkje tillet utanlandske mobilnummer sjekker vi at lengda på brukarinput er på 8 teikn før vi samanliknar nummera.
Vi kunne utført fleire sjekkar her, til dømes om nummeret starter med ein landskode (+47 eller 0047), men vi håper at kjeldesystema har god nok kontroll på dette til at brukarar vil taste inn riktig nummer.
Captcha (påkrevd).
Brukaren fyller ut og sender skjemaet.
Dersom skjemaet har blitt feil utfylt eit gitt antal forsøk vil brukaren bli sperra frå tenesta i ein gitt periode. Sjå Angrepssperring for meir informasjon om dette.
Dersom utfyllingsfelta ikkje er riktig utfyld får brukaren beskjed om kva informasjon som mangler. Tilbakemeldingar vert gitt i følgande rekkefølge:
Om brukarnamnet er feil:
"Kunne ikke finne din bruker utfra oppgitte opplysninger."
Om brukaren har prøvd tenesta for mange ganger:
"For mange forsøk. Du er midlertidig utestengt fra tjenesten."
Antal forsøk vert lagra per brukar, som er difor dette ikkje kan vere første meldinga.
Om oppgitte data (brukarnamn, fødselsnummer eller andre id-felt) ikkje gir ein eintydig person:
"Kunne ikke finne din bruker utfra oppgitte opplysninger."
- Vi kan ikkje informere for mykje om kva felt
som er feil, då dette opnar for enklare utfisking av informasjon.
Om brukarkontoen er sperra/avvikla el.l:
"Denne brukerkontoen er inaktiv. Vennligst ta kontakt med din lokale IT-avdeling."
Om brukaren er i ei gruppe som er reservert mot bruk av tenesta:
"Du er reservert fra å bruke denne tjenesten. Vennligst ta kontakt med din lokale IT-avdeling."
Om brukaren har sjølv reservert seg frå tenesta:
" Du har reservert deg mot bruk av denne tjenesten. Vennligst ta kontakt med din lokale IT-avdeling for å få nytt passord. Reservasjonen kan endres i Brukerinfo."
Om personen ikkje har aktive affiliations frå eit autoritativt kjeldesystem:
"Ikke all din informasjon er tilgjengelig. Vennligst ta kontakt med din personalavdeling eller studentkontor."
Merk at vi her har ein grace-periode: Ein nyleg inaktiv affiliation reknast som aktiv 7 dagar etter at den vart inaktiv, for å ta hensyn til feilregistreringar og at nyleg slutta brukarar skal få tilgang til å rydde opp i sitt heimeområde.
Om personen ikkje er registrert med eit mobilnummer:
"Ikke all din informasjon er tilgjengelig. Vennligst ta kontakt med din personalavdeling eller studentkontor."
Dette er samme feilmeldinga som for manglande aktiv affiliation. Dette fordi vi ønsker ikke å opplyse om at det er mobilnummeret som ikkje stemmer, men at "noko" manglar, som personalavdelinga eller studentkontoret kan rydde opp i.
Om oppgitt mobilnummer samsvarer med eit nummer frå FS som er nyleg endra:
"Ditt mobilnummer er nylig byttet i StudentWeb, og kan av sikkerhetsmessige årsaker ikke benyttes før etter noen dager. Vennlighst ta kontakt med din lokale IT-avdeling."
Personen varslast samtidig på e-post om at mobilnummeret nyleg er blitt bytta i StudentWeb og at det er forsøkt å bli tatt i bruk. Varselet sendast til primæradressa til alle brukarane til personen. Dette er for å hindre misbruk gjennom FS, då det er relativt enkelt å få tak i pinkoden til ein student.
Om oppgitt mobilnummer ikkje er blant nummera som er registrert på personen i eit av dei autoritative kjeldesystema:
"Noe av informasjonen er feil. Vennligst prøv igjen."
Merk at dette er samme meldinga som for om ein td. oppgir feil fødselsnummer eller brukarnamn.
Om personen er blitt identifisert vert det sendt eit eingangspassord på SMS til personen sitt mobilnummer, og brukaren sendast vidare til eit skjema for å validere eingangspassordet. Til- nummeret må loggast i changelog, så ein kan sjå dette i user history.
Brukaren fyller ut og sender skjemaet for eingangspassordet.
Ved feil inntasta eingangspassord vil brukaren få feilmeldinga:
"Feil engangspassord. Vennligst prøv igjen."
Etter eit gitt antal feila forsøk vil eingangspassordet bli gjort ugyldig, og brukaren får feilmeldinga:
"For mange forsøk, engangspassordet er blitt gjort ugyldig."
Ved korrekt inntasta eingangspassord vert brukaren sendt til skjemaet for å sette eit nytt passord.
MinID
Personen vert sendt til MinID si pålogging. Av sikkerhetsårsaker velger vi å tvinge personen til å logge på på nytt i MinID, og ikkje kunne gjenbruke ein allereie eksisterande pålogging. Ein vil med andre ord ikkje kunne gjenbruke ein allereie innlogga MinID-sesjon for passordtenesta.
Ved korrekt pålogging sender MinID ein tilbake til passordtenesta, som då forsøker å autentisere personen.
Dersom vi ikkje kan identifisere personen, til dømes fordi vi ikkje har registrert ein person med samme fødselsnummer, vert personen logga ut med meldinga:
"Du ser ut til å ikke vere registrert i våre systemer ved Universitetet i Oslo. Vennligst ta kontakt med din lokale IT-avdeling eller Houston (houston.uio.no) dersom dette er feil."
Dersom personen eksisterer i Cerebrum, men har ingen aktive tilknyttingar frå eit autoritativt kjeldesystem får personen tilbake feilmeldinga:
"Din person er ikke registrert som aktiv i Felles Studentsystem eller ansattdatabasen. Vennligst ta kontakt med din lokale IT-avdeling dersom dette er feil."
Dersom personen er registrert i våre system, men har ingen brukar, vert personen logga ut med meldinga:
"Du har ingen registrert bruker i UiO sine systemer. Vennligst ta kontakt med din lokale IT-avdeling dersom dette er feil."
Dette skal i praksis ikkje skje for studentar, då dei får oppretta brukaren sin automatisk. Det er likevel tilfeller der studentar ikkje har studentbrukar, til dømes dersom dei logger inn før dei har fått studierett.
TODO: anna som kan feile før vi godtek personen?
Dersom personen har fleire brukarar ved UiO må personen no velge kva brukar ein skal bytte passord på. Om berre ein brukar er registrert kan denne automatisk velgast. Passordsida må tydeleg vise kva brukar ein bytter passord på.
Dersom alt er ok vert brukaren sendt til passordskjemaet.
TODO: Det er usikkert korleis MinID fungerer, men om feila påloggingar sender personen tilbake til nettenesta må personen bli sendt til framsida att, så ein får muligheten til å velge ein annan innloggingsmetode.
Endring av passord
Etter godkjend autentisering får ein muligheten til å bytte passord på brukaren sin. Det må tydeleg opplysast kva brukar ein no bytter passord på.
Personen blir presentert med brukarnamnet til brukaren ein skal bytte passord på, og blir bedt om opplysingane:
- Nytt passord (påkrevd)
- Bekrefting av nytt passord (må vere likt passord-feltet)
I tillegg bør det opplysast om dei vanlegaste krava til passordet.
Det leggast inn AJAX for å få validert passordet medan brukaren tastar det inn, ved at tilbakemeldingar dukker opp under passordfeltet. Dette vil forhåpentlegvis gje ei bedre brukaroppleving.
Brukaren fyller ut og sender passord-skjemaet.
Brukaren skal, dersom passordet ikkje oppfyller passordkrava, få dei samme tilbakemeldingane som passordbyttet i bofh/Brukerinfo.
Dersom passordet er gyldig vil det bli satt som brukaren sitt nye passord i Cerebrum. Brukaren vil få tilbakemelding om dette og vil bli logga ut av tenesta, dvs. vi fjerner all mellomlagra informasjon om brukaren.
TODO: skal vi også logge ut personen frå MinID, eller skal brukaren velge dette eksplisitt?
Merk at brukaren aldri skal få sjå nye eller gamle passord i nettlesaren, dette skal kun settast av brukaren.
Gjennom heile prosessen skal det eksistere ein mulighet for å avbryte prosessen, så brukaren kan vere sikker på at han kan avbryte prosessen utan at han er delvis innlogga. Ved avbryting skal all mellomlagra informasjon slettast.
Vi har vurdert om personen burde blitt varsla om passordbytte, i tilfelle dette er gjort av andre enn personen sjølv. Vi har dessverre ingen trygg måte å informere brukaren om dette på, sidan personen som har bytta passordet uansett vil ha tilgang til mobilen til brukaren, og vil kunne slette både tekstmeldingar og også e-postar vha. det nyerværva passordet. Vi har difor ingen måte å få varsla brukaren på, sjølv om vi ser behovet for det.
PHP-klienten
Nettsida skal i hovudsak vere så dum som mogeleg og berre vere ein budbringar. Det meste av funksjonaliteten skal, så langt det er mogeleg, ligge på Cerebrum-sida. Koden bygger på Brukerinfo, så mykje er likt mellom tenestene.
Loggar frå php-applikasjonane er gjort tilgjengelege på w3utv- ws01.uio.no. Sjå Cerebrum sin driftsdokumentasjon (uio_drift.rst) for nøyaktig plassering.
Testing: Det er lagt til unit- og funksjonalitetstesting av spesielt felleskoden, og ligg under cerebrum/testsuite/phpunit/. Løysinga eg har gått for er PHPUnit, då dette var mest aktivt. Alternativa som vart vurdert var SimpleTest og phpt.
Testverktøyet er installert lokalt på w3utv-ws01.uio.no, dokumentasjon om det ligg i uiocerebrum/brukerinfo/testoppsett.rst.
For å unngå CSRF må det brukast token i html forms. Tokenet må fornyast for kvart steg mot eit høgare autentiseringsnivå, dvs. for kvart stadium i registreringa.
Det må brukast captcha for å unngå brute-force angrep mot tenesta, samt utfisking av person-informasjon. Vi bruker reCaptcha som WebID. Ei fil på 300 kodelinjer frå Google er kopiert inn i kodetreet vårt, og må oppdaterast etterkvart som Google oppdaterer sin.
Eit potensielt brute-force-hol som captcha ikkje kan sperre for, er om ein kommuniserer direkte med Cerebrum sin daemon i staden for å bruke nettsida. For å unngå dette må tilgangen til daemonen sperrast ned for alle andre enn php-klienten, sjå meir om dette under Beskyttelse.
Cerebrumsdaemon
Nettsida treng å kommunisere med Cerebrum. Av sikkerhetshensyn må all kommunikasjon gå gjennom nettsida, som betyr at det må settast opp ein eigen daemon for denne funksjonaliteten, som må sperrast ned frå andre adresser enn nettenaren sin(e). Til dette vil vi bruke nye Cerebrum Integration Service (CIS), som er ein soap-tenar for parallelle transaksjonar, tiltenkt eventbaserte oppdateringar mellom Cerebrum og andre tenester.
Testing av CIS gjerast med ein SOAP-tenar på cere-utv01.uio.no med kommandoane som trengs. I produksjon må porten til SOAP-tenaren på cerebrum-uio.uio.no vere nedsperra til å kun akseptere data frå nettenaren så ikkje ondsinna kode kan gå bakvegen, i tillegg til at begge partar må autentisere kvarandre.
Funksjonalitet
Kommandoar
Nettenesta treng følgande kommandoar:
get_usernames(String id_type, String id) @return: list(users): [{uname: String, status: String, can_change_password: bool), ...]Funksjon for å liste ut alle brukarnamna til ein person som vi kan identifisere ved hjelp av forskjellige id-typar:
- Fødselsnummer
- Studentnummer
- Ansattnummer
Lista må vere sortert etter prioritert, slik at primærbrukaren kjem først. Kvar brukar kjem med ein påfølgande status, som ein streng på vald språk, evt. som ein kode php-applikasjonen kan oversette sjølv, og info om brukaren kan benytte den nye passordtenesta.
Dersom ein person ikkje har nokon brukarkontoar sendast ei tom liste, evt. ein eigen exception. Dersom personen ikkje finnast sendast ein exception med ei forklaring som enten kan visast for brukaren, eller som er gjenkjenneleg for nettsida.
Det må sjekkast om brukaren er reservert frå denne tenesta, som må føre til ein exception med ei passande forklaring.
generate_token(String id_type, String id, String username, String phone_no, String browser_token) @return: boolean
Funksjon som skal, ved korrekt input, sende eit token (eingangspassord) til den oppgitte personen sitt mobilnummer, og midlertidig lagre dette i Cerebrumdatabasen for seinare validering. Funksjonen skal returnere True berre om all inputinformasjon er ok og ein SMS er blitt sendt. Merk at ved fleire genereringar er det berre det siste einganspassordet som skal vere gyldig.
Merk at phone_no ikkje skal godtakast blindt, men må vere registrert i minst eit av dei autoritative kjeldesystema, og personen må ha ei aktiv tilknytting til dette kjeldesystemet, slik at vi veit at nummeret er oppdatert.
Parameteret browser_token brukast for å kunne identifisere nettlesarar frå kvarandre, og med det hindre misbruk av token om dette vert lest av andre enn brukaren sjølv. Dette er eit tekstfelt og er ein tilfeldig streng som er generert på php-sida. Ein tom streng er også gyldig, dersom vi velger å slå av for denne sperra.
Det må sjekkast om brukaren er reservert frå denne tenesta, som må føre til ein exception med ei passande forklaring.
Eingangspassorda og browser_token må hashast før dei lagrast som traits i databasen, salta med brukarnamnet og browser_token. Færrast mogleg må få tilgang til bofh-kommandoar som kan liste ut desse traitsa.
check_token(String username, String token, String browser_token) @return: boolean @throws: too many attempts
Sjekker om eit eingangspassordet er gyldig for ein gitt brukar. Eingangspassordet har ei begrensa levetid så utdaterte eingangspassord må ignorerast.
Eit eingangspassord for ein gitt brukar skal berre kunne sjekkast eit gitt antal gonger (til dømes 10 gonger) før det må gjerast ugyldig i databasen.
TODO: burde denne kommandoen heller returnert eit auth_token, som kan brukast i set_password?
abort_token(String username) @return: boolean
Avbryter prosessen med eingangspassordet ved å gjere det ugyldig i Cerebrum.
validate_password(String password) @return: boolean
Sjekker om eit passord oppfyller alle krav til eit passord. Om passordet er godt nok returnerast True. Hvis ikkje skal den kaste ein exception med ei tekstleg forklaring, helst på eit vald språk. Forklaringane/feilmeldingane må samsvare med bofhd sine.
set_password(String username, String new_password, String auth_token) @return: boolean
Bytter passordet til ein gitt brukar dersom auth_token stemmer og passordet validerer. auth_token er eit token som er blitt generert av Cerebrum i løpet av ein av dei forskjellige autentiseringsmetodane. Dette er ønskeleg for å ha ein felles metode for passordbyttet, så det vert enklare å utvide med nye autentiseringsmetodar seinare. Dersom auth_token er feil, vert prosessen avbrutt og brukaren vert "logga ut".
Det er viktig at metoden dobbeltsjekker at brukaren faktisk kan få bytta passordet sitt og ikkje er til dømes sperra eller reservert.
TODO: Korleis få generert eit token ved bruk av MinID? Kva kommandoar treng vi for dette? Vi venter med dette til vi har meir dokumentasjon rundt korleis MinID fungerer.
Exceptions
Soap har berre støtte for SoapFault, av typane som støttast 'client', 'server', 'versionmismatch' og 'mustunderstand'. Alle exceptions sendt frå CIS vil komme som typen server fault.
Vi definerer difor at alle exceptions som brukaren skal kunne sjå, skal starte med strengen "CerebrumRPCException:" . Exceptions som ikkje starter på dette må php-klienten enten ta hensyn til eller loggføre som feil, og gje brukaren ei generell tilbakemelding om at "ein ukjend feil oppstod". Ingen slike feil skal vidareformidlast til sluttbrukaren.
Språk
Det er ønskeleg å kunne få data frå Cerebrum på forskjellige språk, etter kva brukaren ønsker. Løysinga vi har gått for er å ha ein eigen soap-kommando for å sette språket, set_language(lang_code). For at dette skal fungere må det opprettast ein sesjon mellom php-klienten og CIS. Denne settast opp med å sende ein cookie frå CIS, som php- klienten mellomlagrar og sender i retur for kvart soap-kall.
Twisted har innebygd støtte for sesjonar, men soapxml har ikkje dette, så løysinga vi har gått for er litt hackete, men fungerer goddt nok for vårt formål her og no.
Beskyttelse
Vi ønsker beskytte daemonen så det er berre PHP-klienten som får tilgang. Tiltak for dette:
- Berre IP-adressene til nettenaren må få tilgang til daemonen sin port. Dette må gjerast av drift når tenesta settast opp.
- CIS må autentisere php-klienten, til dømes ved å bruke sertifikat.
- PHP-klienten må autentisere CIS, til dømes ved å bruke sertifikat.
- All kommunikasjon må vere kryptert.
Autentisering
Vi må kunne autentisere PHP-klienten. I WebID vert dette gjort vha. pålogging med ein superbrukar med tilhøyrande passord som ligg i klartekst i ei fil på nettenaren.
CIS støtter bruk av x509-sertifikat gjennom HTTPS.
Validering av tenaren.
Tenaren (CIS) har ein privat nøkkel og eit (sjølvsignert) tenar-sertifikat. Sertifikatet kopierast over til klienten (PHP). Når klienten skal koble seg opp mot CIS vil den då kunne sjekke tenar-sertifikatet og verifisere at den snakker med riktig tenar.
Validering av klienten.
Klienten (PHP) har ein privat nøkkel og eit klient-sertifikat. Sertifikatet kopierast over til tenaren (CIS). Når tenaren får ei oppkobling vil den då kunne verifisere klienten ved å bruke sertifikatet. Tenaren vil med dette berre akseptere oppkoblingar gjort med klient-sertifikatet/sertifikata det har registrert.
Private nøklar kan passordbeskyttast, men sidan vi må lagre passordet i ei fil på samme området som nøkkelfila gir dette oss ingen ekstra sikkerhet. Det er likevel støtte for dette i koden, for andre instansar som lagrer passordet på andre måtar eller filområder.
Både klienten sin private nøkkel og eventuelt ei tilhøyrande passordfil vil ligge i ei mappe på nettenaren som driftast av www- drift. Mappa vil berre vere tilgjengeleg for gruppa cerebrum, httpd- brukaren og administratorar for tenarmaskina. Tenaren sin private nøkkel vil ligge på cerebrum si produksjonsmaskin. Klienten sin private nøkkel vil kunne ligge på Cerebrum-tenaren som backup.
Merk at vi bruker eigne sertifikat for dette, som har ingen samanheng med nettenaren sitt sertifikat for HTTPS.
Sikkerhetsutfordringar
Dette er ei teneste som aukar risikoen for at ondsinna personar kan ta over andre sine brukarkontoar, i tillegg til å samtidig sperre tilgangen til den eigentlege personen, sidan passordet er bytta. Ein må vere klar over sikkerhetsrisikoen denne tenesta medfører. I tillegg er det ein del ukjende faktorar, sidan dette er ei ny form for teneste ved UiO. Tryggleik bør vege tyngre enn brukarvennlighet.
Samme nettlesar
For å hindre at eit token kan snappast opp av andre har vi lagt inn sperre på at berre den aktive sesjonen vil kunne validere tokenet. Dette gjerast gjennom å legge ved eit browser_token i transaksjonen med Cerebrum, som vert generert i kvar sesjon. Dette vil gjere tenesta tryggare mot at andre kan snappe opp tekstmeldinga og bruke dette i sin eigen nettlesar.
Ulempa med denne funksjonen er at det kan bli vanskeleg for brukarar som er i land der tekstmeldingar bruker lenger tid på å nå fram enn sesjonen i passordtenesta varer. Det må difor vere mulig å kunne slå av denne sperra i konfigurasjonen. Ein kan vurdere om sperra kan midlertidig fjernast for enkeltbrukarar, men dette er ikkje støtta per idag.
Vi let denne sperra stå på, og vurderer å heller slå den av dersom det vert eit stort problem.
Angrepssperring
Vi treng tiltak mot at tenestene vert misbrukt, til dømes ved å sperre tilgangen etter eit antal forsøk. Stader med relevante input som kan misbrukast:
Inntasting av fnr/studnr/ansattnr for finn-mitt-brukarnamn, men beskytta av captcha. Her kan ein finne ut om eit fnr/studnr/ansattnr er gyldig og tilhøyrande brukarnamn, som kan gi ein indikasjon på namnet. Her kan ein fiske ut gyldige fødselsnummer om ein berre er tålmodig nok.
Eit tiltak for å gjere utfisking vanskelegare er å kreve fleire identifikatorar, til dømes at ein må både kunne fødselsnummer samt sitt ansattnummer eller studentnummer. Dette vil sjølvsagt ikkje hjelpe mot dei som allereie har tilgang på ansatt/studentnummer.
Eit anna tiltak er å begrense for antal forsøk per IP-adresse. Det er mulig å gjere dette i nettenaren (td. apache), men det er lagt til PHP-kode (IpBlock) som lagrer kvar IP-adresse sine forsøk i si eiga fil. Ein kan konfigurere antal forsøk kvar IP-adresse har, og over kor mange sekund ei eventuell sperring varer.
Inntasting av brukarnamn, fnr/studnr/ansattnr og mobilnr for sett- nytt-passord, men beskytta av captcha. Her kan ein finne ut om eit fnr/studnr/ansattnr er gyldig og høyrer til eit gitt brukarnamn og mobilnummer, i tillegg til å kunne få satt passord på brukaren om ein har tilgang til tekstmeldingar sendt til offeret.
Ein annan faktor her er at utsending av eingangspassord kostar pengar. Innkjøpsprisar finnast på http://www.telenor.no/bedrift/produkter/mobil/tjenester/sms-bedrift/priser.jsp, Merk at sms-drift også kan legge på litt for å dekke sine driftsutgifter.
For å løyse noko av dette sperrer vi kvar brukar midlertidig ute etter 10 forsøk. Ei utestenging varer i 60 minutt. Desse innstillingane kan endrast i cereconf, og det utførast ved hjelp av ein eigen brukar-trait. Merk at ingen andre tenester skal bli påverka av denne sperra.
Inntasting av eingangspassord. Har ein først fått tak i nok informasjon om ein person, kan ein mate på med token. Dette vil berre fungere eit gitt antal ganger før eingangspassordet vert gjort ugyldig.
Eit eingangspassord skal kunne sjekkast maksimalt 10 ganger.
Inntasting av nytt passord. Her er einaste sperra ei tidsbegrensing, men ein må først ha tasta inn gyldig token.
Varighet
For å unngå at nettsida kan misbrukast gjennom nettlesarar som brukast av fleire vil vi ha tidsbegrensingar på forskjellige situasjonar i tenestene:
- Venter på input av eingangstoken: 30 minutt
- Nedtellinga starter frå brukaren har fyld ut korrekt informasjon om brukarnamn, fnr, mobilnummer etc. og er blitt vidaresendt til sida for input av tokenet.
- Vi må ta hensyn til brukarar som befinner seg i land der tekstmeldingar kan bruke lang tid på å nå fram.
- Dersom vi skal sperre på at tokenet må validerast i samme sesjon, må vi sikre at nettenaren tek vare på sesjonsdata i lenger tid enn perioden for eingangstokenet. Dette må spesifiserast i konfigurasjonsoppsettet til tenesta.
- Dersom det er bedt om fleire token på rappen for samme brukar, er det berre siste tokenet som er gyldig, uavhengig av mobilnummer og nettlesar.
- Venter på input av nytt passord: 5 minutt
- Nedtellinga starter frå brukaren har tasta inn korrekt eingangstoken.
- Nedtellinga starter på nytt att dersom brukaren har prøvd å taste inn eit nytt passord. Dette fordi nye passord kan ta lang tid å få produsert.
Autopassord-karantener
Alle brukarar med karantena autopassord vil med denne tenesta få tilgang til å få reaktivert brukaren sin dersom dei har ei aktiv tilknytting frå eit kjeldesystem. Dette er ønskeleg, men ein bør vere klar over at dette kan opne opp for brukarar som eigentleg ikkje skulle hatt tilgang. Ein kan difor ikkje bruke autopassord-karantena som ein måte å sperre brukarar på lenger. Dette er vurdert til å vere ufarleg, då dette heller er manglande registreringar.
Reserverte brukarar (passordskifte)
Passordtenesta skaper større risiko for å kunne ta over brukarkontoar så vi bør ha mulighet for å kunne reservere enkelte grupper av brukarar og enkeltbrukarar frå å benytte tenesta. Dømer på grupper er superbrukarar og brukarar med mange og kritiske tilgangar i andre IT- system. Tenesta bør kunne reservere brukarar:
Ved å sperre for superbrukarane i Cerebrum.
Ved å sperre for medlem av gitte grupper. Vurderinga av kva grupper som skal leggast inn for UiO takast av sikkerhetssjef Espen Grøndahl.
Ved å la personar/brukarar få lov til å reservere seg i Brukerinfo. Dette må i første omgang gjerast gjennom traits, men i framtida er det ønskeleg å benytte seg av ein eigen tabell for reservasjonar.
Ein vil då kunne få reservert ein og ein av brukarane sine.
Det kan seinare vurderast om det er behov for at lokal-IT/Houston skal kunne midlertidig "avreserve" brukarar. Dette vil kunne gjere det enklare å dele ut passord i staden for å bruke faks, men det opner også opp for enklare misbruk av tenesta.
Reserverte brukarar (brukarlisting)
Alt som trengs for å få ei liste over brukarane til ein reservert person er eit ansattnummer, studentnummer eller eit fødselsnummer. Det som informerast om er brukarnamna, statusen til desse, og kva brukar som er den primære. Ingen namn eller personlege opplysingar skal informerast om, men brukarnamnet kan gi ein indikasjon på både fornamn og etternamn.
Personar kan reservere seg frå denne tenesta ved å reservere seg mot å bli publisert på nett i SAPUiO eller FS.
For UiO vil personar som ikkje har aktive tilknyttingar reknast som reserverte og vil difor ikkje kunne bli lista ut. Andre institusjonar kan ha andre krav til reservasjonar og må sjølv vurdere kven dei vil liste ut.
Bytte av mobilnummer
Mobilnummera kjem frå kjeldesystema SAPUiO og FS. Ansatte skal kunne registrere sitt mobilnummer via den nye HR-portalen, der autentisering foregår ved hjelp av vanleg brukarnamn og passord, medan studentar registrerer mobilnummeret sitt på StudentWeb eller Samordna Opptak.
StudentWeb gir grunn til bekymring, då innlogging på denne sida kan, i tillegg til innlogging gjennom Feide også gjerast vha. fødselsnummer og ein firesifra pinkode. Det er to muligheter for å få tak i denne pinkoden:
- Ved å kontakte Knutepunktet. Dei krever då fire opplysingar før dei
gir deg pinkoden:
- Fullt namn
- Fødselsnummer
- Heimstadsadressa, som registrert i FS
- Ein tilfeldig eksamen avlagt ved UiO
- Via StudentWeb. På innloggingssida kan ein taste inn sitt fødselsnummer og få tilsendt ein ny pinkode til både uio-registrert og privat e-postadresse.
Det er ingen skilnad på innlogging med pinkode eller brukarnamn og passord, ein kan bytte sitt mobilnummer i begge tilfella.
Vi ser på bruk av pinkode i StudentWeb som ein sikkerhetsrisiko. Håpet er at FS vil kunne bli oppdatert med ei sikrare rutine, men så lenge dette er på plass må vi legge inn nokre sperrer:
- For å unngå misbruk der nokon får tak i pinkoden til ein student og endrar mobilnummeret for så å bruke passordtenesta legg vi inn ein forsinkelse på bruken av mobilnummer frå FS. Mobilnummer frå FS som er blitt endra vil ikkje kunne takast i bruk av passordtenesta før tidlegast 7 dagar etterpå. Det er viktig at dette ikkje påvirker nye studentar.
- Dersom nokon har endra mobilnummeret og prøver å bruke passordtenesta, vil tenesta sei frå om at mobilnummeret er for ferskt. I tillegg vil personen bli varsla om forsøket på e-post. E-postvarselet skal sendast til alle brukarane til personen.
- Det har vore vurdert om Cerebrum burde varsla personar som har fått bytta mobilnummer på e-post når dette importerast frå FS, men dette er ikkje Cerebrum sin jobb. Det ønskelege hadde vore om FS kunne varsle personen om at mobilnummeret er endra, så ein vert klar over dette og kan følge opp saka.
- For å avgrense misbruket kan ein konfigurere webservicen til at personar som har tilknyttingar frå SAP ikkje skal få bruke mobilnummer dei har registrert i FS. Dette inkluderer også andre kjeldesystem.
Historikk i sms-utsendingar
For å kunne finne ut av om nokon har endra mobilnummeret til ein person tek vi vare på mobilnummera som eingangspassord er blitt sendt til i 31 dagar i changelog. Dette anser vi som lang nok tid til at dei fleste skal ha kunna ha oppdaga at passordet sitt har blitt bytta.
I bofh kan ein sjå desse mobilnummera gjennom kommandoane user history og entity history med brukaren som parameter. Det er greit å vere klar over kven som har tilgang til å sjå logga mobilnummer:
- Superbrukarar i bofh
- I hovudsak alle OpSet med operasjonen view_history:
- Houston har global tilgang - houston-forstelinje
- Cert har global tilgang - cert-vakter
- Postmaster har global tilgang - postmaster
- Unix-vakt har global tilgang - unix-vakter
- Pcadm har global tilgang - pcadm
- Progdist har global gruppe-tilgang - progdist Obs: merk at også global_group gir tilgang til alle brukarar.
- Lita2 har lokal tilgang avhengig av på kva disk heimeområdet er plassert. Dette er ulike lokal-IT-grupper.
- Termvakter, Studit og studit har tilgang til alle studentbrukarar, også dei utan heimeområde. Dette er ulike student-IT, termvakter og studiekonsulentar overalt på UiO.
Merk at brukaren sjølv har ikkje tilgang til denne informasjonen.
SMS
Vi vil ta i bruk SMS for å sende ut eingangstoken. Mobilnummer får vi frå kjeldesystema, dvs. FS og SAPUiO, og vi sender ikkje ut eingangstoken til andre nummer enn dei som er registrert der.
Tilgang til mobilnummer
I Cerebrum har vi følgande typar telefonnummer:
- contact_phone: Arbeidstelefonnummer.
- contact_mobile_phone: Offisielt mobilnummer.
- contact_phone_private: Privat heimetelefon.
- contact_private_mobile: Privat mobilnummer.
- contact_phone_cellular: Utdatert, skal ikkje brukast.
- contact_phone_cellular_private: Utdatert, skal ikkje brukast.
Typane aksepterte nummer kan i tenesta spesifiserast i konfigurasjonen for kvart enkelt system vi importerer frå.
FS
Vi har fått tilgang av Studieavdelinga til å bruke telefonnummer frå FS. Det er ikkje avgjort kva felt vi kan bruke og korleis desse skal brukast endå, men dette jobbast det med.
Det er bekrefta at vi ikkje treng godkjenning av kvar enkelt student, ettersom nummeret vert lagt inn og oppdatert av dei sjølv.
SAPUiO
TODO: Det er opp til OPA å avgjere kva vi får tilgang til av mobilnummer, deriblant private nummer.
I HR-portalen er det idag berre eitt felt for private nummer, og som ikkje har nokon inputkontroll.
Datavask
Studieavdelinga, ved mgrude, har gitt oss litt statistikk for deira bruk av SMS:
Den siste store utsendingen vi hadde, var i forbindelse med valg til studentparlamentet 2010:
- 23117 SMS ble forsøkt sendt ut
- 21427 av disse har status LEVERT (36 av disse er 'lange', dvs utenlandske telefonnr)
- 1690 ble ikke levert (130 av disse er 'lange', dvs utenlandske telefonnr)
Datakvaliteten er altså ikke 100% på topp og datakvaliteten på de utenlandske numrene er gjennomgående dårligere enn de norske.
Det er verdt å merke seg at denne sendingen gikk til alle semesterregistrerte studenter. De har alle hatt mulighet til å endre mobilnummeret sitt i studentweb.
Målgruppen dere er interessert i kan ha hatt lengre fravær. Det er imidlertid relativt enkelt å logge seg inn i søknadsweben og endre mobiltelefonnummeret der. (Man trenger bare fødselsnummer og litt enkel matematikk (søknadsweben sitt 'captcha'-substitutt) for å komme inn i søknadsweben.)
Sidan kjeldesystema er autoritative skal vi utføre minst mogeleg datavask for mobilnummer. Dette krever meir kontrol på både input og kjeldedata i passordtenesta. I HR-portalen kan ein i dag til dømes legge inn telefonnummeret "123abcde" utan å få feilmelding.
Vi vil i første omgang ikkje tillate utanlandske mobilnummer. Vi vil då berre tillate mobilnummer som enten er utan landskode, eller som har landskoden 0047.
Gateway
Det er to SMS-gatewayar i drift ved USIT i dag, vi har brukt https://sms-prod.uio.no, då den ikkje lagrar innhaldet i meldingane.
Merk at det jobbast med å få oss over på den andre gatewayen, då sms-drift ønsker å fase ut sms-prod.
Dokumentasjonen for tenesta finnast på https://www.uio.no/tjenester/it/applikasjoner/sms/drift-utvikling/ og kontaktpunktet er sms-drift@usit.uio.no.
Tekstmeldingar sendast vha. vanlege GET eller POST requests:
https://sms-prod.uio.no/sms?b=cerebrum&p=<passord>&s=USIT&t=<telefon>&m=<melding>
Alt dette vert i Cerebrum handtert av Cerebrum.Utils.SMSSender.
Parsing av svaret er ikkje nødvendigvis så enkelt, ettersom svaret er strengen "OK Message queued for delivery", som er plassert i ein ny <h1> tagg under overskrifta, og som kan endre seg i framtida. Slik det er løyst i dag, vil ein kunne komme i fare for å få falske positive svar frå SMSSender.
Kvar institusjon må få kvar sin brukar for utsending av tekstmeldingar. TODO: Vi treng informasjon frå sms-drift om korleis faktureringa foregår. Vi har eigne loggfiler for utsendingane, men om sms-drift har ein bedre oversikt er det ønskeleg å kunne bruke denne.
Meldingsinnhald
Av hensyn til tryggleiken må sms-en ikkje innehalde informasjon som kan identifisere personen eller brukaren. For å ikkje forvirre brukarane bør den likevel innehalde noko som kan identifisere kvar tokenet kjem frå, til dømes:
Ditt engangspassord er: <token> Universitetet i Oslo
og på engelsk:
Your one time password is: <token> University of Oslo
MinID
Sidan dei fleste studentar no bruker MinID for pålogging i Samordna Opptak er det ønskeleg for oss å også kunne tilby MinID for autentisering av personar i passordtenesta, i staden for bruk av mobiltelefon.
MinID bruker SAML i påloggingsprosessen, og SOAP for kommunikasjon mellom nettenesta og MinID sin tenar. Informasjonen ein får tilbake er bl.a. fødselsnummeret eller D-nummeret til den autentiserte personen, som vi kan benytte for å identifisere personen. Vi må ta hensyn til at ein person ikkje nødvendigvis eksisterer i våre system.
For å ta i bruk MinID må ein søke om tilgang som tenesteeigar hos DiFi (http://samarbeidsportalen.difi.no/), og fylle ut ein samarbeidsavtale.
Det er ønskeleg å benytte hyllevare for bruk av MinID i PHP. simpleSAMLPHP bør sjekkast ut om kan benyttast, ettersom vi har erfaring med denne frå før av.
Sikkerhetsnivå
Det er i dag to sikkerhetsnivå i MinID:
- Sikkerhetsnivå 3: Krever bruk av passord og pinkode.
- Sikkerhetsnivå 4: Krever bruk av smartkort. Skal brukast til ekstra sensitive tenester, til dømes helseopplysingar.
Ein kan berre velge minimums-nivå, som vil sei at personar som loggar inn vha. smartkort også får tilgang til nivå 3-tenester.
Sjølv om passordtenesta er kritisk for brukarar ved UiO, er smartkort lite utbredt endå. Nivå 3 er uansett på eit høgare nivå enn våre passord, då vi ikkje har pinkodar eller andre sjekkar, så nivå 3 virkar som det beste valget.
Design (webredaksjonen)
Vi ønsker å ta i bruk den nye nettprofilen til UiO i denne tenesta, i tillegg til at webgruppa ønsker å sjå over alle tenester, at dei er brukarvenlige nok. Webgruppa bør difor vere med frå starten av for å diskutere nettsida sin oppførsel for sluttbrukaren.
Etter å ha diskutert med Tomm vart vi einige om å først få ut tenesta med samme design som Brukerinfo har idag. Etterpå kan vi gå gjennom både Brukerinfo og denne tenesta i samarbeid med dei for å friske opp design og oppførsel.
Andre påverknader
Lenking frå Brukerinfo
Tenestene bør lenkast til frå innloggingssida til Brukerinfo, ved hjelp av standard "Gløymd ditt passord?"- og "Gløymd ditt brukarnamn?"-lenker. Dei ulike tenestene skal likevel også kunne lenkast til direkte.
Registrering av telefonnummer i Brukerinfo
For andre institusjonar enn UiO kan det vere ønskeleg å opne opp for å registrere sitt mobilnummer gjennom Brukerinfo for eventuell seinare bruk. Dette krever tilgang til ein ny kommando for å få lagt dette til på personen sin. Sikkerheten rundt dette må vurderast av kvar enkelt institusjon.
Reservering i Brukerinfo
Brukerinfo må utvidast med ei eiga side for å kunne reservere seg mot passord-tenesta. I første omgang gjerast dette gjennom ein trait, så brukarar må få tilgang til bofh-kommandoane trait_set og trait_info.
Reserveringar skal settast per brukar.
Det kan seinare vurderast om det skal vere mulig å reservere seg mot brukarnamn-utlisting også.
Dokumentasjon
Informasjon om nettenestene må ligge ute og linkast til frå tenestene. Tenestene bør vere godt forklart i dokumentasjonen, medan det i sjølve tenestene er lite, men presis tekst. Til dømes må ikkje brukaren kunne tru at ein i passord-tenesta kan oppgje kva som helst av mobilnummer, men berre eit som er registrert i våre kjeldesystem.
Testing
Utviklinga av grensenittet gjerast på https://w3utv-ws01.uio.no/cerebrum/individuation/www_docs/.
Author: jokim