Stikkordarkiv: Sikkerhet

Password Fail

Her er ditt passord

Nylig gikk jeg gjennom nærmere 150 nettsider og byttet passord på kontoene mine. Listen over netsidene har jeg i «safen». Som mange andre bruker jeg et eget verktøy for å holde rede på passordene. Jeg benytter LastPass, men det finnes mange tilsvarende med eller uten krav til nett. Det sikreste er selvsagt en lokal safe, slik at man unngår mye av problematikken forbundet med en online løsning, men det handler også om brukervennlighet og tilgang. Derfor har jeg sterke, unike passord på samtlige sider jeg benytter, og kanskje det sterkeste av dem alle er for «safen» selv.

De flest passord er basert på et system som jeg selv har kommet på. Ettersom det følger et system er det selvsagt mulig å finne et mønster, men med mindre et program er skrevet for nettopp dette anser jeg de som svært usannsynlig at noen tar seg bryet. Litt samme logikk som at innbruddstyver heller går inn i villaene noen hundre meter unne leiligheten min. Det er enklere.

Etterhvert som jeg gikk gjennom listen av nettsider oppdaget jeg at svært mange har dårlige rutiner rundt sikkerheten, enten de oppbevarte passordene uforsvarlig (kanskje i klartekst) eller hadde regler som begrenset hvor gode passordene kan være. Mange sendte en epost med bekreftelse på endret passord, hvor passordet var lagt ved i eposten i klartekst. Slik som også noen nettsider gjerne gjør ved registrering. Det er flere grunner til at dette er en dårlig idé:

  • Eposten blir lagret i flere systemer = passordet er lagret i flere systemer. I klartekst.
  • Brukeren trenger som oftest ikke bli påminnet sitt eget passord. Han/hun har tastet det inn selv, og ingen andre trenger vite om det.
  • Selv etter at eposten er slettet vil høyst sannsynlig flere kopier eksistere i andre systemer.
  • Sikkerheten kan være brutt allerede før brukeren har lest eposten.

For å nevne noen.

Det er ingen grunn til å sende passord i eposten.

Når brukeren velger sitt passord ved registrering har vedkommende sannsynligvis god kontroll over hva dette passordet er. Det er typisk tastet inn i to felt, hvor det også gjøres en sjekk om de er like. Hvordan passord håndteres etter dette er litt forskjellig, men ofte blir det håndtert på en dårlig måte.

Om passordet sendes tilbake til den nye brukeren på epost er sikkerheten allerede svekket. Det er utenfor kontroll, og man kan ikke lenger garantere at kun brukeren vet hva passordet er. Det vil ligge kopier av eposten med passordet i flere systemer, i tillegg til at det kan være snust opp på nettverket. Og avsender har ingen kontroll over hvem som har tilgang til mottakers epost.

Skulle brukeren glemme sitt passord bør det være en smal sak å ha en mekanisme for å sette et nytt passord. En vanlig måte å løse dette på er å enten sende brukeren et nytt og midlertidig passord (gjerne med tvang om nytt passord etter innlogging) eller ved å sende en lenke til inntasting av nytt passord (som selvsagt kun er gyldig en viss tid).

Passordet skal ikke lagres!

I løpet av de siste årene har det vært mange saker i media rundt kontoer på avveie. Felles for de fleste av disse har vært dårlig sikkerhet i systemene som har håndtert kontoinformasjon. En gjenganger har vært passord lagret i en database, som noen har fått tilgang til.

De som ikke kjenner til mulighetene lurer gjerne på hvordan man kan bekrefte et passord uten å lagre det. En løsning er å lagre en hash av passordet. En hash er veldig forenklet et resultat av en hashfunksjon med passord som input. Det skal ikke være enkelt å finne ut hva input var, helst umulig. Altså en enveis funksjon.

Tidligere anså man med hash problemet som løst. Et passord ble kjørt gjennom en funksjon som ga en hash som resultat. Denne hashen ble så lagret i en database, sammen med brukernavn og eventuelle andre data om brukeren. Ved innlogging tar man så passordet brukeren taster gjennom samme funksjon og sammenligner resultatet med det som er lagret for brukeren. Er de like vet man så at brukeren har tastet riktig. Og kun brukeren vet passordet. Eller?

Problemet med denne løsningen, som fortsatt brukes i stor grad, er at samme funksjon brukes i mange systemer og samme passord gir alltid samme resultat. Dermed kan man gjøre en del ting for å finne ut hva passordet egentlig er. Med brute-force kan man lage en såkalt rainbow-tabell, en tabell som inneholder hasher for de fleste kombinasjoner et passord kan bestå av. Dermed kan man slå opp en hash i denne tabellen for å finne riktig passord. Selv uten en slik tabell kan man med dagens hardware finne et passord lagret med en svak hashfunksjon relativt raskt.

Selvsagt har noen tenkt ut noen smarte løsninger for dette. En mer komplisert hashfunksjon kan benyttes sammen et såkalt salt. Et salt er kort og godt tilfeldig data. Saltet lagres sammen med hashen (beregnet av hashfunksjonen med passord og saltet som input), men uten passordet. Ved innlogging benyttes samme salt til å beregne en hash sammen det inntastede passord, for deretter å kontrollere om de to hashene er like. Ettersom saltet er tilfeldig for hver bruker blir det også utrolig mye vanskeligere å finne frem til riktig passord med brute-force. En rainbow-tabell må dermed bestå av samtlige kombinasjoner for både hash og salt, som i praksis vil kreve fantastisk mye tid.

De fleste gode rammeverk har innebygd funksjonalitet for dette, eller tilbyr det ved tredjeparts løsninger.

Svakeste ledd

Som nevnt trenger skal ikke systemene lagre passordet. Dermed er også de fleste regler som nettsider har lagt på passordene lite nyttige. De tjener ikke til annet enn å gjøre sikkerheten svakere. Eksempel er maks lengde på passord. Ettersom en hash typisk har en fast lengde, uavhengig av passord, ser jeg liten grunn til å legge slike restriksjoner på brukeren. Det samme gjelder også bruken av tegn i passord, enten det er krav for eller mot visse tegn. Noen nettsider krever alle tegn er enten gyldige bokstaver eller tegn, og har dermed effektivt begrenset antall mulige kombinasjoner betraktelig. Er det krav om visse tegn (f.eks et punktum) er heller ikke dette heldig, siden man da oppgir hvilke tegn som må være inkludert, en joker mindre å finne ut av for den med uærlige hensikter.

I tillegg er det slik at de fleste velger et passord de kan huske. I dag har gjerne de fleste brukere mange kontoer, passord og pinkoder de skal huske på. For å gjøre dette enklere velger de gjerne noe som er lett å huske. F.eks «Bamse1». Når passordet skal byttes? «Bamse2». Ved å ha strenge regler for hvordan passord skal bygges opp velger mange minste motstands vei, og finner på et passord som er veldig lett å huske, men også veldig lett å finne ut av. Spesielt kravet om at passord må endres med jevne mellomrom legger opp til denne praksisen.

Sikkerhet er et race mellom flere parter. Mens sikkerheten stadig blir bedre, oppdages det også hele tiden smartere metoder for å komme rundt sikkerheten. Som oftest er brukeren selv det svakeste leddet, men noen ganger klarer nettstedet selv å gjøre seg svakere. Når det er så lett å heve sikkerheten, og vi stadig ser kontoinformasjon på avveie, finnes det ingen unnskyldning for ikke ta grep for sine egne nettsider. Og kommer du over en nettside som åpenbart har dårlig sikkerhet kan det lønne seg å si ifra om dette. Ikke bare for din egen del, men også for andre.

Benytter du samme passord flere steder er du spesielt utsatt. Men det gjør du vel ikke?

Er passordene dine sikre?

I løpet av en vanlig dag benytter jeg mange passord og pinkoder for å verifisere meg mot ulike systemer. Jeg husker de aller fleste passord, men har funnet noen ulike metoder for å håndtere den uoversiktlige mengden av påloggingsinfo som er nødvendig gjennom både jobb og privat. For passord på jobb har jeg et passordbeskyttet regneark for de mindre kritiske passordene. Dette er delt med et par andre utviklere. Det største problemet er faktisk å huske passordet til regnearket, da dette ikke brukes i noen annen sammenheng.

Privat bruker jeg, dessverre, ofte det samme passordet. Jeg har rundt regnet 10 ulike passord jeg benytter privat, de fleste følger det samme mønsteret – alle er kryptiske. Etter at noen misbrukte PayPal kontoen min har jeg endret passord for alle nettsider som kan tappe kredittkortet mitt for penger. Passordene er genererte strenger bestående av masse bokstaver, tall og tegn, som jeg ikke kjenner til. De ligger lagret i et eget program som krever enda et passord for å logge seg inn i. Trenger jeg tilgang til en av disse nettsidene må jeg gå gjennom dette programmet, eller få tilsendt et nytt passord. De aller fleste private passord ligger i dette programmet. Mister jeg nøkkelen inn i programmet, må jeg resette de fleste passord.

Jeg er opptatt av sikkerhet, men også opptatt av brukervennlighet. Ofte blir det et kompromiss for at vil ta i bruk en løsning. For noen systemer og nettsider er ikke sikkerheten like kritisk, og jeg velger å ta i bruk et standard passord. For andre steder velger jeg et autogenerert passord eller en variant av tidligere passord.

Når jeg da velger å ta i bruk smarte løsninger for å ta vare på sikkerheten blir jeg veldig skuffet når store og små leverandører ikke ser ut til å ta sikkerhet på alvor. Min sikkerhet. Et eksempel på dette er strømleverandøren min, Vitel (Tidligere strømleverandør. De har som kjent sluttet med strøm nå.). Som de fleste andre leverandører tilbyr de en mulighet for å få tilsendt innloggingsinformasjon dersom brukeren har glemt dette. Og som så mange andre gjør de den samme feilen og sender en epost med brukernavn og passord jeg registrerte meg med. Som om det ikke er nok finner jeg den samme informasjonen på hver eneste faktura.

Nå er det ikke slik at man kan gjøre spesielt stor skade ved å logge seg inn hos en strømleverandør, men passordet er nok for mange det samme som brukes mange andre steder. Sammen med epostadressen kan dette misbrukes i stor skala.

Så hvordan bør dette løses? Mange har skjønt det, og oppbevarer ikke passord i klartekst. Ei heller kan de hente ut passord når brukeren har glemt det. Man kan kun sjekke inntastet passord mot det som er registrert, ved å gjøre den samme kryptering på inntastet passord som ble gjort når passordet ble lagret første gang. Dersom brukeren har glemt passordet må nytt passord settes, enten ved at et passord genereres automatisk eller at brukeren setter nytt via en link som kan brukes en gang. Uansett bør brukeren kunne velge seg et nytt passord et sted i prosessen. De aller fleste gjør det på denne måten, men veldig mange slurver.

Jeg har for lengst send en epost med min mening til min strømleverandør og flere andre. Gjør det du også, så kanskje de endrer sin praksis!

Dette er eposten jeg sendte dem:

Jeg har en forespørsel angående deres praksis med å lagre og sende passord i klartekst over epost. I tillegg er også mitt passord skrevet i klartekst på alle fakturaer tilsendt meg. Hvorfor har dere behov for å lagre mitt personlige passord i klartekst? Jeg stiller meg skeptisk til at dere har tilgang på mitt personlige passord og er bekymret over muligheten for at noen av deres ansatte eller andre tredjeparter kan få tilgang på passordet med å lytte på nettverket, lese mine faktura eller andre metoder. Når dere sender mitt passord på epost, blir det overført over nettverket i klar-tekst og er lett leselig på ulike nettverks-rutere og lokasjoner. Det burde ikke være noen tekniske eller funksjonelle behov som gjør at dere må lagre mitt personlig passord i klartekst eller med en reversibel kryptering. Det bør være nok med en ikke-reversibel hash av passordet. Håper dere tar forespørselen til etterretning og forstår min bekymring for mitt privatvern.

Oppdatering! Jeg har fått svar på min henvendelse til Vitel:

Hei Vi har hatt oppe denne saken før med post og teletilsynet og vi har gjort endel endringer i vårt system som post og teltilsynet har funnet tilfredstillende godt nok. Jeg lister opp en del punkter under som viser hva som er gjort. – Ved å gå inn på «Mine sider» kan man velg bort at passord vises på faktura – Ingen ansatte i Vitel har tilgang til å se ditt passord – du kan selv velge passord på «Mine sider» Når det gjelder at passord blir sendt over nettverk via epost eller sms så er dette helt vanlig praksis og informasjonen som evt. kan leses kan skjelden være av interesse for en tredjepart. Vi har gått gjennom våre rutiner sammen med pt og dette skal være sikret tilstrekkelig godt nok. Håper dette var et beroligende svar. Med vennlig hilsen Kundesenter

De opererer med andre ord etter «godt nok»-taktikken. Jeg er ikke spesielt beroliget av en slik taktikk. Selvfølgelig har ansatte hos Vitel adgang til passord om de ønsker det, de sitter jo på dataene. Hvem som helst med tilstrekkelig adgang til riktige databaser kan hente ut denne informasjon. Utro tjenere finnes det mange av, og den beste måten å sikre seg mot disse er å ikke legge frem muligheter som dette. Nå er ikke jeg kunde hos Vitel lenger, da de ikke klarer levere strøm til meg uansett, men jeg endret fort passordet mitt når jeg fant ut av praksisen deres. Da er det greit med et kryptisk passord som jeg ikke kan selv engang. Eksempel på et slikt passord er (tilfeldig generert for meg nå): «cHQ^smX9G#sW».

Jeg jobber i et miljø hvor sikkerhet er utrolig viktig. Dårlige løsninger kan eksponere personsensitive og medisinske data. Skikkelig dårlige løsninger kan gi ledere en grunn til å pakke sammen på dagen, og utvikler følger nok med skulle det skje. Ofte må derfor det vurderes hvor godt disse dataene skal beskyttes. Vi kan velge å gjøre dette «godt nok» for å tilfredsstille lover og regler, eller vi kan sørge for å gjøre det så bra at vi sover godt om natten. Vi velger alltid sistnevnte, fordi det ikke koster så mye mer og fordi vi har et rykte å tenke på. Det finnes (dessverre) mange eksempler på brukernavn og passord på avveie, fordi løsningen har vært «god nok». Hva med å bare gjøre det bra med en gang? Så er også risikoen for feil fantastisk mye mindre!

XmasB.com er hacket

Uten at jeg kan forklare hvordan er det nå ingen tvil. Bloggen er blitt hacket, og er full av usynlige linker.

Hacket? Det begynte med at jeg hadde noen problemer med en plugin. Mens jeg gikk gjennom filene som tilhørte denne, ble jeg oppmerksom på en del filer som ikke hørte hjemme der. Det var rene html filer som kun inneholdt lenker til diverse sider jeg ville holdt meg langt unna, de aller fleste relatert til piller og diverse medikamenter så langt jeg kunne tolke. I tillegg har flere av php filene som tilhørte temaet fått flere tusen skjulte lenker og mystisk kode jeg ikke orket sette meg inn i. At egendefinert brukernavn og passord var definert var ikke et godt tegn. Jeg slettet alt jeg kom over, og var ikke så opptatt av å dokumentere imens.

Hva nå? Jeg slettet de filene jeg hadde kommet over og lette gjennom alle kataloger på serveren i tilfelle det var flere, og er nå ganske overbevist om at jeg har fått ryddet unna det meste. Jeg vil heller få ryddet opp i rotet fremfor å benytte meg av backup og miste oversikten jeg har nå. Jeg skal ikke skryte på meg å ha dagsaktuell backup nå heller. Den siste jeg har er ivhertfall en god uke gammel, og jeg er ikke helt sikker på når hackingen skjedde uansett. Det er muligens lettere å benytte anledningen til å rydde litt. Så det har jeg gjort. Og jeg rydder fremdeles. Det meste er på plass igjen, men det nye temaet krever en del tilpasninger som jeg får ta etterhvert.

Kan det skje igjen? For å sikre meg mot fremtidige angrep har jeg selvfølgelig byttet passord på brukeren min, ftp kontoen og mySQL kontoen. I tillegg har jeg lastet ned WordPress på nytt i tilfelle det er blitt tuklet med filene, og byttet tema fordi jeg har bekreftet at filene der er blitt tuklet med. Jeg føler meg i det hele tatt ganske trygg nå. Men kan det skje igjen? Helt klart, men det er en del ting man kan gjøre for å beskytte seg. Skrivetilgang er nok et stikkord for meg, der har jeg slurvet litt. Utifra hvilke steder filer har dukket opp kan det se ut som om dette var den største tabben.

Hvorfor meg? «Man tenker aldri at det kan skje en selv, før det faktisk skjer». Hørt det før kanskje? Det er heldigvis bare en blogg, men ja, det føles litt sånn. Jeg tror de fleste blogger blir forsøkt hacket eller misbrukt på andre måter ofte. Jeg har tidligere fulgt nøye med på logger og konkluderte den gang med at det var for mange angrep til å følge med på. Det var lettere å bare glemme dem, og håpe at man er godt nok beskyttet. Og etterhvert begynner man kanskje å slurve litt… En erfaring rikere, selv om jeg ikke kan sikkert si at jeg kunne avverget hackingen. Mest sannsynling.

Jeg tror også pluginen min kan gjøre meg til en aktuell kandidat. Jeg er lenket til fra mange lister over WordPress plugins. Et greit utgangspunkt for en som måtte ønske å hacke en WordPress blogg. Skulle jeg skrevet kode for å angripe en WordPress blogg ville jeg også kanskej begynt der…

Nytt tema? At jeg har lagt ned mange timer for å det forrige temaet til å oppføre seg som jeg ville må jeg bare glemme. Jeg har lenge hatt planer om å bytte, men likte ikke tanken på all jobben som er lagt ned i det forrige. Det meste er faktisk inkludert i det temaet jeg nå har valgt likevel, og masse annet som jeg ikke har tenkt på engang. I like it! (Ja, det er selvfølgelig mye som gjenstår enda…)

Konsekvenser? Mitt forrige innlegg, Søkemotorene vil ikke lenger ha meg har ganske sikkert sammenheng med hackingen. Min egen teori er at alle linkene og html filene ga meg en ganske å herlig straff hos min største leverandør av søketreff, Google. Med mange tusen skjulte linker kan jeg bare anta at dette har dyttet meg langt ned blant søkene som kunne ledet hit. Jeg er heldigvis mer opptatt av de leserne som kommer tilbake, og der stiller besøkende fra Google som oftest dårlig. Men kjedelig er det likevel. Forhåpentligvis har jeg fjernet alt som kunne fortsette å gjøre skade. Noe av koden kom tilbake bare timer etter at jeg fjernet den igår… Vi får håpe jeg slipper det nå.

Er du trygg? I løpet av (snart) tre år med denne bloggen har jeg aldri hatt noen liknende problemer. Sannsynligheten er sånn sett heldigvis liten. Jeg ville likevel tatt noen forhåndsregler, som å sørge for at man har siste versjon (uansett plattform), ikke mer enn nødvendig tilgang på filområder, ftp og database, og gode passord. Helst forskjellig for innlogging til blogg, ftp og database. For andre WordPress bloggere vil jeg anbefalte å ta en titt på dette innlegget. (Takk til Kristin for linken via Twitter.)

Sikkerhet til besvær

Jeg har nettopp brukt en liten slump tid på å finne frem noen bøker jeg hadde lyst på. Sender jeg avgårde bestillingen tidsnok rekker jeg kanskje å få de sendt avgårde allerede i dag. Jeg registrer meg på nettsiden Bokkilden.no, og legger bøkene jeg ønsker i handlekurven. Begynner nesten allerede å glede meg til å begrave meg i gode bøker. Så stopper begeistringen. Idet jeg skal betale får jeg spørsmål om sikkerhetskode nr 1 når jeg bruker Visa. Joda, den ligger hjemme. Jeg avbryter, å prøver å betale med Mastercard istedet. Samme maset om sikkerhetskode. Kjempeskuffet.

Nå har det seg slik at jg ikke ønsker å ta med meg sikkerhetskortet overalt, fordi det… vel, ikke virker som det sikre å gjøre. Tidligere trengte jeg kun dette kortet ved innlogging til bank. Og jeg følte at penge mine lå sikkert i banken fordi ingen hadde hverken pinkode eller sikkerhetskort. Og fikk dem tak i pinkode, var de like langt. Nå er det tydeligvis forventet at jeg enten kun betaler ting på nett fra hjemmepc’en, eller at jeg har med meg sikkerhetskortet overalt. Og snart sender vel banken ut en sånn duppeditt som generer koden der og da. Det er en fin liten klump å ha i lomma til enhver tid.

Hvor blir det av teknologien som lar meg identifisere kjøpet mitt med DNA, fingeravtrykk eller Irisgjenkjenning? Jeg savner den tiden hvor man kunne misbruke kort i nettbutikker, og få bestilt varer uten å ha med seg alt mulig tøys til enhver tid.