itfag | Teknologi. Data. Læring. Deling.

mar/11

4

Mange slurver med passordsikkerhet

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 11 kommentarer. Gjerne bidra :-)

Skrevet av: Svend Andreas Horgen (totalt 133 blogginnlegg)

11 comments

  • Bjørnar · 4. mars, 2011, kl. 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, kl. 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, kl. 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, kl. 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, kl. 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, kl. 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, kl. 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, kl. 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, kl. 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, kl. 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

      • Sofiane · 27. juni, 2014, kl. 20:19

        Gode poenger!Jeg er selvff8lglig helt enig i at payobrdsstte ofte har en negativ innvirkning pe5 sikkerhetsnive5et. Det f8ker sannsynligheten for at de5rlige passord velges og at brukerene sliter med e5 huske passordet og me5 bruke et stf8ttesystem (PostIt-lapp-trikset). Og selv med krav til passord-kompleksitet vil brukeren da bare lage et passord som er godt nok, men med en teller el. (Vansk3ligPW#1, Vansk3ligPW#2 osv.). Som angriper trenger man da bare e5 knekke et passord og deretter lett ff8lge brukerens endringer.Jeg synes sog dere glemmer et viktig poeng. Noe som kanskje er enda viktigere i en passordpolicy enn selve kompleksiteten i passordet eller krav til payobrdsstte – er kravet til at man holder passordet personlig og ikke gjenbrukes. Her svikter nesten alle. Man gjenbruker samme passord pe5 tvers av forskjellige lf8sninger eller sikkerhetsregimer. Enda ve6rre er at man helt frivillig gir bort brukernavnet og passordet til en tjeneste til andre tjenesteleverandf8rer. Et eksempel pe5 dette er brukere som benytter tredjepartslf8sninger for e5 fe5 tilgang til sine «sky»-tjenester (eks. , eller brukere som opplyser om gyldige credentials til eks. Hotmail for e5 slurpe inn kontaktene sine til LinkedIn.Og dette er under vanlig bruk av standard tjenester. Vi som jobber med dette vet at brukere desverre ogse5 finner pe5 e5 dele ut passordet sitt til vilke5rlige fremmede som spf8r om det 😉 . Ne5r da samme passord benyttes til msn, facebook og annet – se5 er det fort gjort e5 miste kontrollen over egne data. Og hvis samme passordet benyttes pe5 bedriftens nettverk, se5 kan det ha litt negative innvirkninger der ogse5…..

<<

>>

Theme Design by devolux.nh2.me