Annonse
De fleste nettlesere tilbyr en funksjon hvor innloggingsinformasjon , altså brukernavn og passord, for ulike nettsteder, kan lagres i nettleseren og hentes fram igjen når brukeren på nytt vil logge seg inn på det samme nettstedet.
Programvareutvikleren Elliot Kember har nylig fått litt oppmerksomhet for et blogginnlegg han har skrevet om passordlageret i Google Chrome. Som relativt fast bruker av Apples Safari, har han ifølge ham selv begrenset erfaring med Chrome, noe som har ført til at han i blogginnlegget slår inn noen relativt åpne dører når han forteller at det i Chrome er svært enkelt få se innholdet i passordlageret i klartekst.
For det er svært enkelt. Alt man behøver å gjøre, er for eksempel å skrive chrome://settings/passwords i adressefeltet. Da får man en oversikt over alle de lagrede passordene. For å se selve passordet, må man i hvert enkelt tilfelle klikke på en knapp hvor det står «Show» eller noe tilsvarende, avhengig av språkdrakten til nettleseren.
I motsetning til de andre store nettleserne, har ikke brukeren mulighet til å lage et hovedpassord som må tastes inn før man får tilgang til passordene, enten i listen eller ved innloggingen på et nettsted. Unntaket er i Internet Explorer, hvor man ikke behøver å taste inn noe hovedpassord ved innloggingen, men bare når man vil se på passordene i passordlageret.
Kember har fått såpass mye oppmerksomhet for blogginnlegget at sikkerhetssjefen for Google Chrome, Justin Schuh, har kommentert det. Han gjør det i alle fall klart at dette er bevisst gjort fra Googles side, og at det ikke dreier seg om en feil, noe enkelte i pressen har prestert å skrive.
I kommentaren skriver Schuh at det eneste som virkelig hindrer tilgang til passordlageret, er operativsystemets brukerkonto. Derfor tar Chrome bruk den formen for kryptert lagring som hvert enkelt system tilbyr for en låst konto.
– Utover det har vi erfart at begrensninger innenfor operativsystemets brukerkontoer ikke er pålitelige, og de fleste dreier seg bare om spill for galleriet, skriver Schuh.
Schuh skriver videre at så lenge noen har fysisk tilgang til brukerkontoen, har de også tilgang til å se session-cookies, se brukerens nettleserhistorikk eller å installere ondsinnet programvare som fanger opp all nettleseraktivitet.
I tillegg tilbyr de fleste nettlesere et sett med integrerte utviklingsverktøy hvor man kan lokalt i nettlesern kan endre HTML-koden ligger innholdet i nettleseren er basert på. Dersom man først får nettleseren til å fylle ut passordfeltet, kan man ved hjelp av noen få kommandoer endre typeverdien til passordfeltet til noe annet enn «password». Da vises passordet i klartekst i de opprinnelige passordfeltet, i stedet for de vanlige stjernene (asterisk).
Gå inn på Facebook med for eksempel Internet Explorer 10. Trykk F12 og skriv “password” i søkefeltet som da kommer opp. Da finner du HTML-koden til passordfeltet på Facebook-siden. Endre verdien til input-parameteren type, så kan du lese hva som egentlig står i passordfeltet. Tilsvarende kan gjøres også i de fleste andre pc-nettlesere. På smartmobiler og nettbrett er nettleserne gjerne noe enklere og tilbyr derfor færre muligheter av denne typen. (Skjermbilde:Harald Brombach)
Dette avhenger riktignok av at eieren av kontoen har tastet inn det eventuelle hovedpassordet i nettleseren før maskinen ble forlatt i ulåst tilstand.
En annen teknikk er rett og slett å logge seg inn på websiden og deretter endre passordet. Mange nettsteder krever ikke at du skriver inn det opprinnelige passordet på nytt, og selv i slike tilfeller vil nettleseren i blant kunne være villig til å skrive det inn for deg.
– Poenget mitt er at straks skurken har tilgang til kontoen, er spillet over, fordi det er for mange vektorer som han kan bruke for å oppnå det han ønsker, skriver Schuh.
– Vi har blitt spurt mange ganger hvorfor vi ikke støtter et hovedpassord eller noe tilsvarende, selv om vi ikke tror at det fungerer. Vi har gjentatte ganger kommet til den samme konklusjonen, nemlig at vi ikke ønsker å gi brukere en falsk form for sikkerhet eller å oppfordre til risikabel atferd, skriver Schuh.
I en kommentar til Schuhs innlegg skriver brukeren kapawaz at fordi Chrome lagrer passordene med nøyaktig samme mekanismer og steder i OS X som det Safari gjør, reduserer Chrome sikkerheten til Safari ved at Chrome ikke krever noe hovedpassord for å få tilgang til disse passordene – som kan være lagret med Safari, selv om Safari krever dette.
Men som brukeren anologwintermut deretter svarer: dersom Chrome får tilgang til disse passordene i OS X uten å be om et passord, hva er som hindrer andre programmer å oppnå samme tilgang uten bruk av passord? I praksis er det OS X som ikke krever passord for å få tilgang til dette sentrale passordlageret.
Hovedpoenget til Schuh er at man alltid bør låse datamaskinen når man forlater den, slik at ikke andre kan få tilgang til kontoen mens man er vekk. På de aller fleste systemer kan man skru på en slik passordbeskyttet skjermlås ved hjelp en enkel snarvei.
En som likevel ikke er enig med Schuh, er Tim Berners-Lee, selve oppfinneren av weben. I twittermeldingen nedenfor uttrykker han skuffelse over det Schuh skriver.
Men uten noen nærmere utdypning, er det vanskelig å vite hvor Berners-Lee mener at Schuh tar feil.
I tillegg til verktøyene som er integrert i nettleserne, finnes det også egne passordverktøy med utvidet funksjonalitet, som fungerer på tvers både flere ulike nettlesere og datamaskiner. Eksempler på dette er Roboform og LastPass. Ved å bruke en av disse i stedet for nettleserens eget passordlager, omgår man i alle fall det eventuelle problemet med Chromes manglende støtte for hovedpassord.
No comments:
Post a Comment