 |
| men hvordan er sikkerheten? |
Bakgrunn
Denne historien startet med at en venn av meg tipset meg om at han hadde glemt sitt passord på NetShop, og gjennom "glemt passord" funksjonen der fikk han tilsendt brukernavn + passord i ubeskyttet e-post. Han fortalte meg også at store deler av nettsidene deres ikke benyttet SSL etter innlogging, slik at sesjonskapring og uautorisert innsyn i hans aktiviteter hos NetShop kan være enkelt å utføre.
På skriftlig henvendelse til NetShop fikk han til svar at hans passord lå lagret kryptert (ikke hashet), men at de hadde nevnt for systemleverandøren (Multicase) at de ønsket dette endret.
Verifisering
På bakgrunn av den informasjonen jeg fikk, samt min egen erfaring med FotoVideo (som beskrevet i tidligere bloggpost), så har jeg brukt en god del tid på å vurdere hvorvidt jeg burde skrive denne bloggposten eller ikke. Jeg ønsker virkelig ikke å gi "hackerne" noen oppskrifter eller tips om hvordan de kan ødelegge enda mer enn de allerede gjør på Internett. Det ser for meg ut som om lagringen av passord i reverserbar kryptert form går igjen på tvers av deres kunder, og at utsendelse av brukernavn + passord i ukryptert passord også er en "standard" funksjon. Sistnevnte kan visstnok endres i systemoppsettet.
Det at passordet blir sendt i ukryptert e-post er i seg selv en verifisering av at passordet enten lagres i klartekst (=ubeskyttet), eller at det lagres i en kryptert form. Dersom det lagres i en kryptert form, så er applikasjonene utstyrt med det nødvendige passordet for å kunne dekryptere passordet ved behov.
Jeg har ingen informasjon om hvorvidt passord faktisk blir lagret i kryptert form, ei heller om denne krypteringen på noen måte overholder anbefalte nøkkellengder og algoritmebruk pr dags dato. Det jeg vet er at testede nettbutikker basert på deres løsning ikke stiller de krav til brukernes passord som anses som minimum ift god praksis anbefalinger.
Anbefaling
Dersom du er kunde hos f.eks. FotoVideo eller Netshop, så vil jeg anbefale deg å kontakte selskapet og si at du forventer at de endrer sitt standard systemoppsett slik at de ikke sender ut brukernavn + passord i ubeskyttet e-post. Videre kan du også oppfordre dem til å gå over til hashing av lagrede passord, og at dette gjøres i tråd med god praksis anbefalinger. Hele prosessen rundt oppsett av nye brukere, endring av brukerinformasjon, lagring, verifisering og sending av passord med mer bør gjennomgås.
Til Multicase: Merkelig nok så finner jeg ikke ordet sikkerhet brukt på noen av deres websider. Ovenstående kan ses på som et tips om å implementere sikkerhet på en enda bedre måte, og deretter bruke også det som et salgsargument for deres løsning?
Hei Per,
ReplyDeleteVi ønsker i første omgang å si at vi syntes det er positivt at både våre kunder og deres brukere er opptatt av sikkerhet. Det er vi også!
Sikkerhet rundt lagring av passord:
Av historiske årsaker har vi to måter å lagre passord på. Den gamle måten lagres passord i databasen i klartekst. Dette er slettes ikke bra og derfor har vi endret på det. Den nye måten lagrer passord i databasen som en SHA-512 hash. Kundene våre kan selv velge metode, nye kunder får automatisk hash metoden og vi anbefaler gamle kunder til å gå over til hash metoden.
Ved bruk av hash metoden blir passord lagret i databasen som en 512bits hash. En slik metode er enveis, dvs at ingen kan finne passordet igjen ut i fra de data som blir lagret. Dette i motsetning til en krypteringsalgoritme der dette er mulig. Vi bruker ikke kryptering til dette, men det er nok mange som ikke vet forskjellen på hash og kryptering.
En konsekvens av dette er at man ikke vil kunne få tilbake passordet sitt, men at det må bli generert et nytt om man har glemt det gamle. Det nye passordet genereres av koden slik at det ikke er noen som har kjennskap til dette, andre en den som mottar det på f.eks. e-post. Når hash metoden er skrudd på vil man ikke i butikk kunne legge inn passord. Brukeren må selv bruke glemt passord funksjonen på webshopen for å få generert og få tilsendt passord (dette gjelder nyere versjoner av vår software).
Mange av våre kunder og deres brukere har nok syntes det har vært beleilig at man har kunnet få tilbake sitt gamle passord om man skulle glemme det, enten ved e-post eller ved å ringe opp support. Dette har nok mange ganger overveid sikkerhetsaspektet og ved overgang til ny metode syntes de å miste “en praktisk funksjonalitet”. Etter som tiden har gått og sikkerhet har blitt et større tema hos norske e-handels aktører har disse holdningene endret seg. Slik bevisstgjøring som du også driver med her, er med på å endre disse holdningene og samtidig gjøre det enklere for oss å få aksept for de nye, riktige og sikre metodene.
Du skriver også om ubeskyttet e-post. Så vidt oss bekjent finnes det ikke allment tilgjengelig enkle og gode krypteringssystemer for e-post. Man kan f.eks. bruke SMS, og/eller SMS og epost i kombinasjon. Vår utfordring er at dette også må være praktisk. Du har helt klart et poeng i at anonymisering av eposten og ikke å sende brukernavn sammen med passord vil heve sikkerheten. Dette skal vi ta med oss videre.
SSL:
Bruk av SSL (sikring av web sider) er først og fremst avhengig av at vår kunde har installert nødvendige SSL sertifikater. Vi anbefaler alle våre kunder å gjøre dette. Når dette er gjort skrur vi på bruken av SSL. Som standard bruker vi SSL på sider som har forbindelse med registrering, innlogging, kundesenter og kasse. Vi kan enkelt skru på SSL for alle sider eller de sider våre kunder skulle ønske. Grunnen til at vi ikke kjører SSL på alle sider er fordi det er blitt vurdert som unødvendig (da disse inneholder generelt tilgjengelig informasjon for alle) og kan få en uønsket ytelseskonsekvens. Det er mulig vi skal revurdere dette oppsettet, da utfordring med ytelse nok er mindre nå en tidligere.
Mvh,
Odd-Henrik Aasen
Avd. leder Web.
MultiCase Norge AS.
Heisann Odd-Henrik, og takk for et veldig godt svar! Slikt fortjener skryt!
ReplyDeleteOvergang fra klartekst lagring til SHA-512 er veldig bra. Avhengig av hvor langt dere er kommet i prosessen, så se gjerne følgende bloggpost fra Chris Lyon, inntil nylig sikkerhetssjef hos Mozilla: http://cslyon.net/2011/05/10/sha-512-w-per-user-salts-is-not-enough/
Du oppgir ikke noe om hvorvidt dere også salter inputen til SHA-512 hashingen, og jeg vil vel i praksis også anbefale å ikke opplyse hverken meg eller andre om det i offentlighet.
Ytelsestabellen for EGB (GPU Bruteforcer) gir en god ide om hvilke hastigheter man kan forvente ved passordknekking av ulike hashing algoritmer, selv om ikke SHA-512 står listet her.
Ved hashing av passord er selvfølgelig salting viktig. Enda mer viktig er å faktisk velge en algoritme som gir LAV ytelse, noe de aller fleste ikke er klar over. En flere år gammel bloggpost fra Thomas Ptacek gjennomgår dette og mere til på en svært god måte: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html
Galskapen i kunder som "klager" på frafall av muligheten for å få frem brukeres glemte passord trenger virkelig ingen ytterligere kommentar spør du meg.
Når det gjelder e-post så har du selvfølgelig helt rett. Implementering av STARTTLS støtte på deres (og kundenes) utgående mailserver vi bidra (se mer info her: http://www.dagensit.no/article1881581.ece). Imidlertid vil ikke dette gjøre mye fra eller til. Nytt passord kan sendes ut via SMS (bare send passordet!), eller du kan sende mail med en tidsbegrenset HTTPS link for å endre passordet. Mailen kan ellers inneholde minst mulig informasjon, siden mottakeren i de fleste tilfeller vil forstå hva det gjelder uansett.
Bruken av konstant SSL er fortsatt et diskusjonstema hos mange. I den grad deres kunder vil si at de har noe viktigere å beskytte enn Facebook og Twitter, så kan de jo gjøres oppmerksom på at nevnte tjenester kan benyttes med SSL fra A til Å. SSL ytelse er ikke et problem, det er en mersalgsmulighet for dere, samt en rekke ulike hosting leverandører. Salgsargumentet er selvfølgelig bedre sikkerhet og personvern for alle.
Igjen; takk for godt og utfyllende svar. Ønsker dere lykke til videre!
Ups: glemte linken til EGB: http://www.insidepro.com/eng/egb.shtml
ReplyDeleteHei igjen Per,
ReplyDeleteTakk for gode og konstruktive tilbakemeldinger. Her var også mye interessant lesestoff i dine referanser. Vi tar med oss alt dette i vårt videre sikkerhetsarbeid.
Mvh,
Odd-Henrik Aasen
Avd. leder Web.
MultiCase Norge AS.