itfag
4
Mange slurver med passordsikkerhet
Innspill: 10 kommentarer · Kategori: data · Tagger: passord, sikkerhet
Av: Svend Andreas Horgen, høgskolelektor og faglærer i Webprogrammering i PHP
Blir du av og til oppgitt over at tilsynelatende profesjonelle nettsteder slurver med sikkereheten? Her er et godt eksempel på regelrett slurv, og en utfordring til deg om å si hvorfor dette er slurv.
Flytoget er for meg noe av det beste Norge har å by på innen kommunikasjon. Websidene deres er brukervennlige. Informasjonen er lett tilgjengelig, en kan betale superraskt fysisk og få kvittering tilsendt på e-post om en registrerer e-posten sin på websidene deres. En kan til og med se all historikk om sine kjøp, og alt er tilsynelatende toppers. Flytoget oser sikkerhet, trygghet og effektivitet for de reisende. Bortsett fra en ting, etter min mening en alvorlig brist som gjør at en kan spørre seg om sikkerheten er der i det hele tatt?
De har nemlig slurvet veldig når det gjelder “glemt passord”-funksjonaliteten. Dette gjelder ikke bare Flytogets websider. Altfor mange seriøse nettsteder har slurvet her. Eller evt. aldri tenkt over problematikken?
Scenario:
- Du vil logge inn og få oversikt over alle kjøpene dine
- Du har glemt passordet (mange gjør vel det). Passordet ditt er “1234dummy” men det har du glemt bort akkurat nå.
- Du trykker derfor “glemt passord”, skriver inn e-postadressen din og får denne e-posten umiddelbart:
Her er vi ved kjernen. Kommentarfeltet er åpent. Du som er interessert i teknologi, programmering og sikkerhet, bør umiddelbart kjenne at nakkehårene reiser seg. Så jeg spør: Hva er feil her, og hvordan kan det løses? Hvorfor er dette så alvorlig? Det er mange grunner og momenter å ta opp her, så start brainstormingen!
PS til Flytoget om de leser dette: Ha meg unnskyldt – dere er fantastiske på alt annet enn “glemt passord” og dette blogginnlegget er ikke ment brukt for å spre negativ reklame om dere. Dere kan jo vri dette til positiv reklame om dere vil 
Dette innlegget har 10 kommentarer. Gjerne bidra :-)
10 comments
Leave a Reply
<< TISIP-prisen
Bjørnar · 4. mars, 2011 klokken 08:09
Det er ikke usannsynlig at passordet er lagret som klartekst i databasen. Enten dette, eller en krypteringsform det er mulig å dekryptere med en nøkkel.
Et alternativ til dette burde være å lagre passordet som SHA-1-hash, og heller gi et tilfeldig generert passord ved å klikke på en midlertidig lenke.
Audun Sæther · 4. mars, 2011 klokken 10:49
Som du skriver, det er et problem hos veldig mange nettsider:
1. de lagrer passord i klartekst
2. de genererer ikke et nytt passord, men sender det gamle
En grunnleggende feil de burde gjøre noe med i går
Hans Nordhaug · 4. mars, 2011 klokken 13:25
Lagring av passord er jo et veldig viktig tema som har blitt behørig belyst i det siste – les om cracking/hackingen av brukerpassordene på Gawker eller rootkit.com. Som utvikler må du tenkte på hva som skjer hvis en angriper får tak i databasen din (med brukernavn/passord-informasjon) og koden din.
Lagring av passord i klartekst (eller kryptert med nøkkel/funksjon som ligger i koden) er selvfølgelig helt uansvarlig. Det som er mye mer interessant er at MD5 eller SHA1 er ubrukelig – også hvis passordene er saltet. MD5/SHA1 er rett og slett for effektive hash-funksjoner. Ved hjelp av en GPU kan du teste flere hundre millioner passord per sekund. (SHA1 er muligens litt tregere å regne ut og dermed litt sikrere enn MD5.)
Hvis programmeringsspråket ditt er PHP, er det phpass som er løsning – enkelt og greit.
Øivind · 10. mars, 2011 klokken 19:17
Selv den ellers hårreisende elendig gjennomførte t:kort-tjenesten ser ikke ut til å lagre passord i klartekst.
Author comment by Svend Andreas Horgen · 10. mars, 2011 klokken 23:17
Her peker du på noe jeg også har observert, Øivind. Det er rart med det: ofte ser en enten veldig flotte, usikre løsninger, eller veldig sikre, men totalt ubrukbare løsninger (for eksempel ESS/SAP som vi bruker for å fylle ut reiseregning i ved HiST). Mange nettbanker er trolig temmelig sikre, men de jeg har prøvd er ikke spesielt brukervennlige. Egentlig burde disse to ikke ha noe med hverandre å gjøre, men det har trolig med prioriteringer, tidsbruk og prosjektrammer å gjøre at det ofte blir en “konflikt” i praksis.
Jone · 15. mars, 2011 klokken 10:53
Som mange sier her; hash passordet før du lagrer det, bruk salt (selvfølgelig unikt for hvert passord), gå for en “trygg” algoritme som ikke regnes for å være knekt (f.eks md5 og sha1). Noe av det viktigste er likevel at det tar lang tid å produsere hashen av passordet. Gå for en algoritme som bruker lang tid, på den måten vil det bli mye mindre interessant å forsøke å knekke passordene.
Jon S E Jakobsen · 17. mars, 2011 klokken 14:20
Som påpeket ovenfor, med tjenester som f.eks. http://md5.rednoize.com/ er rene md5/sha-1 hash-tabeller enkle å ta selv for folk uten programmeringskunnskaper. Salt er essensielt. En metode jeg benytter er å låse kontoen ved x feilede innlogginger, og deretter generere et nytt passord med tilhørende link som blir sendt på mail. For ytterligere sikkerhet skulle jeg gjerne tatt i bruk SMS, men jeg sliter med å finne noen som tilbyr slike tjenester, så, om noen har noen tips til det tas de imot med takk
.
Jone · 17. mars, 2011 klokken 22:24
Det finnes mange muligheter til SMS, men det koster penger. Bruker selv SMS løsninger fra Teletopia og er godt fornøyd da de har en utvikleravdeling som er greie å ha med å gjøre hvis man trenger spesialløsninger. Må vel innrømme at jeg har nedprioritert utsending av passord på SMS fordi dette blir for dyrt i lengden, men at det er en mye bedre løsning enn e-post er det ikke tvil om.
Jon S E Jakobsen · 17. mars, 2011 klokken 22:44
Takker for svar. Har selv vært borti løsninger med USB-modem man kan putte telekort i, men det tar sin tid før de blir lønnsomme
Geir Arne Aasen · 22. mars, 2011 klokken 20:23
Da jeg var hackequak under Quak! 2005 og Quak! 2006 brukte vi Boostcom i Trondheim for SMS-sending og mottak. Husker ikke helt hvordan prisingen var hos dem, men det var i hvert fall et genialt enkelt interface for å sende og motta SMS. For mer informasjon: http://tinyurl.com/6fqfsxz