Foto.no er hacket: Over 90 000 passord kan være tatt

[XmasB]

Har ikke med tiden det tar å generere hashet, men hvor mye plass det tar i databasen. Og hadde du lest nøye så hadde du sett at det er det jeg skriver - jeg skriver intet om det å generer selve hashet. Å sette passordfeltet i databasen til f.eks varchar(64) og ikke til f.eks tinytext har betydelig ytelseseffekt på server.

Mulig jeg misforstår noe her her... Men du skal jo ikke gjøre noe mer med passordet etter at du har fått hashen. Det er hashen som skal lagres og ikke passordet. Og når hashen får samme lengde uansett påvirker ikke dette db. Eller?

Endret 26. oktober 2012 av XmasB

[AnaXyd]

Hvis det er noen hasher som er lengre enn varchar(64), så blir det jo annerledes. Men jeg vet ikke om dette er tilfelle, at noen algoritmer genererer lengre hasher enn f.eks MD5.

[007CD]

Han gjort en stor fy fy sak her, og det var å mekke noe selv.

Det er grunn til at rutiner for passord hashing ligger innebygget i PHP og andre oppsett av denne årsaken, slik at du ikke får en merksnodig hjemmesnekkret og usikker løsning.

[jpsalvesen]

@jpsalvesen:

 

Har ikke med tiden det tar å generere hashet, men hvor mye plass det tar i databasen. Og hadde du lest nøye så hadde du sett at det er det jeg skriver - jeg skriver intet om det å generer selve hashet. Å sette passordfeltet i databasen til f.eks varchar(64) og ikke til f.eks tinytext har betydelig ytelseseffekt på server.

 

 

Om det er lengdeforskjell i databasen på en langt passord eller et kort passord, så er det ikke hash'et. Alle hash-algoritmer gir en forutsigbar og konsistent lengde på hash'en.

 

Og jeg har aldri skrevet en webapp som lagret passord i cleartext. Ikke da jeg startet i 1998 engang.

 

En del av grunnlaget bak fokusen på passordhåndtering er nettopp innsikten at "vi kan ikke regne med å beskytte databasen vår". Da må vi sørge for at det som er lagret i databasen ikke kan brukes av svinepelsene. Derfor terper jeg på dette, for at du også skal lære deg det grunnleggende slik at du kan ble med på å gjøre nettet sikrere.

Endret 26. oktober 2012 av jpsalvesen

[Bolson]

Har ikke med tiden det tar å generere hashet, men hvor mye plass det tar i databasen. Og hadde du lest nøye så hadde du sett at det er det jeg skriver - jeg skriver intet om det å generer selve hashet. Å sette passordfeltet i databasen til f.eks varchar(64) og ikke til f.eks tinytext har betydelig ytelseseffekt på server.

Mulig jeg misforstår noe her her... Men du skal jo ikke gjøre noe mer med passordet etter at du har fått hashen. Det er hashen som skal lagres og ikke passordet. Og når hashen får samme lengde uansett påvirker ikke dette db. Eller?

 

Igjen les hva jeg skriver - det skjer mye mer enn lagring av et hash i en innloggingsløsning. Les også det jeg skriver om at de fleste systemer har en historie (lang historie når det gjelder arkitektur), og de er laget for å tilfredsstille ulike sikkerhetsnivåer (løsninger) - kanskje til og med single signon. Begrensingene knyttet til størrelse i databasen samt min- og makslengde er ofte logikk som henger igjen fra tider hvor man faktisk måtte fokusere på ytelse, sikkerhet ble tatt lettere osv. Da la man faktisk ofte inn 16 eller 32 tegn som maks begrensing.

 

Jeg skriver også at bruk av hash gjør den tradisjonelle begrensingen i forhold til databasen mer eller mindre irrelevant. Men historisk har den ikke vært det.

 

Som sagt gjør en innloggingløsing langt mer enn å generer et hash - uten at vi skal komme innpå det i detalj. Men under testing av en løsning for ca 3 år siden som har relativt avanserte rutiner for sjekking (blant annet mot ip) fikk vi ytelseseffekter av svært lange passord. Arrayene med data som skulle sjekkes (her låg også passordet som skulle hashes før sjekk mot hashet i databasen) spiste minne og CPU når vi testet med svært store mengder simultane innlogginger og lange passord.

 

Problemet ble løst med at vi gikk over til RSA-autentisering via nøkkelpar. Som også er sikrere totalt sett.

 

@jpsalvesen:

 

Har ikke med tiden det tar å generere hashet, men hvor mye plass det tar i databasen. Og hadde du lest nøye så hadde du sett at det er det jeg skriver - jeg skriver intet om det å generer selve hashet. Å sette passordfeltet i databasen til f.eks varchar(64) og ikke til f.eks tinytext har betydelig ytelseseffekt på server.

 

 

Om det er lengdeforskjell i databasen på en langt passord eller et kort passord, så er det ikke hash'et. Alle hash-algoritmer gir en forutsigbar og konsistent lengde på hash'en.

 

Og jeg har aldri skrevet en webapp som lagret passord i cleartext. Ikke da jeg startet i 1998 engang.

 

En del av grunnlaget bak fokusen på passordhåndtering er nettopp innsikten at "vi kan ikke regne med å beskytte databasen vår". Da må vi sørge for at det som er lagret i databasen ikke kan brukes av svinepelsene. Derfor terper jeg på dette, for at du også skal lære deg det grunnleggende slik at du kan ble med på å gjøre nettet sikrere.

 

Igjen virker det som du ikke leser alt jeg skriver. Jeg skriver faktisk rett ut at når man bruker hash er dette ikke en begrensing lengre (irrelevant), rett og slett fordi det har en konsistent lengde. Men det har ikke vært historien, og de fleste nettløsninger er i større eller mindre grad preget av historien. Det er ingen unnskyldning - men en realitet som påvirker dagens sikkerhet. Men jeg er ikke uenig at sikker håndtering av passord er svært viktig, men det er ikke hele bildet.

 

De fleste mer avanserte nettløsninger har også valg mellom ulike løsninger, rett og slett fordi mange av de skal kunne handle sammen med andre løsninger på en god måte (single signon). Dette har også påvirket måten løsningene er designet på - på godt og vondt.

 

Nå skyter du nok feil person når du snakker om "du". De løsningen jeg implementerer bruke PHPass med bCrypt eller ren Blowfish for hashing av passord i tillegg kjører de fleste med RSA-autentisering (dvs at man bruker nøkkelpar i stedet for passord i selve overføringen mellom nettleser og server) eller over SSL. Men enkelte ganger skal vi samhandle med systemer som bruker andre algoritmer og da må vi tilpasse oss til det som er mulig.

 

Ellers er jeg ikke helt ening med "utsagnet" - "vi kan ikke regne med å beskytte databasen vår". Jeg er fullt klar over at "shit happens" og at man må sikre passord etc. Men etter min mening skal man bestrebe seg på at dataene ikke skal kunne kompromiteres - det er for meg pri en. Å si at vi kan ikke beskytte dataene er for meg helt feil, vi skal gjøre det optimale for å beskytte dataene - noe annet er for meg defaitisme. Så legger vi gjerne på et eller to nivåer ekstra med sikkerhet. Men det skyldes kanskje at jeg er borte i implementeringer hvor det faktisk er annen informasjon enn brukernavn og passord som det er mer katastrofalt at kommer på avveie. Derfor er jeg også fokusert på overordna systemsikkerhet, hvor god passordhåndtering er bare et (og viktig) element. Hadde foto.no hatt en gjennomført sikkerhetskultur (systemsikkerhet) så hadde neppe dette skjedd i det hele tatt. I tillegg hadde dette garantert medført bedre passordhåndtering.

 

Jeg har dessverre sett løsninger som har hatt god passordsikkerhet med ellers var nesten som en sveitserost.

 

Han gjort en stor fy fy sak her, og det var å mekke noe selv.

Det er grunn til at rutiner for passord hashing ligger innebygget i PHP og andre oppsett av denne årsaken, slik at du ikke får en merksnodig hjemmesnekkret og usikker løsning.

 

Enig - jeg mener det er langt viktigere å fokusere på gode rammeverk/løsninger som har høy systemsikkerhet. Man vil da også få med seg gode sikkerhetsystemer rundt brukerhåndtering i de fleste tilfeller - og ofte langt mer enn bare hashing av passord (blacklist, domeneavgrensing osv). Bruk av mod_security og rett oppsatt Suhosin (ved bruk av PHP) er også noe som løfter generell sikkerhet og reduserer faren for data på avveier.

[potetskrell]

Da har jeg som mange andre fått beskjed om at passordet på ebay-kontoen min er tilbakestillt. Det er helt åpenbart at kombinasjonen av passord og epost er spredt til alle vinder.

[jpsalvesen]

Har ikke med tiden det tar å generere hashet, men hvor mye plass det tar i databasen. Og hadde du lest nøye så hadde du sett at det er det jeg skriver - jeg skriver intet om det å generer selve hashet. Å sette passordfeltet i databasen til f.eks varchar(64) og ikke til f.eks tinytext har betydelig ytelseseffekt på server.

Mulig jeg misforstår noe her her... Men du skal jo ikke gjøre noe mer med passordet etter at du har fått hashen. Det er hashen som skal lagres og ikke passordet. Og når hashen får samme lengde uansett påvirker ikke dette db. Eller?

 

Som sagt gjør en innloggingløsing langt mer enn å generer et hash - uten at vi skal komme innpå det i detalj. Men under testing av en løsning for ca 3 år siden som har relativt avanserte rutiner for sjekking (blant annet mot ip) fikk vi ytelseseffekter av svært lange passord. Arrayene med data som skulle sjekkes (her låg også passordet som skulle hashes før sjekk mot hashet i databasen) spiste minne og CPU når vi testet med svært store mengder simultane innlogginger og lange passord.

 

Wha-wha-what? Hvorfor ikke bare hashe før du putter det i arrayet, da? Dere avslørte jo en svakhet i implementasjonen som er enkel å gjøre en workaround på.

 

Problemet ble løst med at vi gikk over til RSA-autentisering via nøkkelpar. Som også er sikrere totalt sett.

 

Heldige side-effekter er bra greier!

 

@jpsalvesen:

 

Har ikke med tiden det tar å generere hashet, men hvor mye plass det tar i databasen. Og hadde du lest nøye så hadde du sett at det er det jeg skriver - jeg skriver intet om det å generer selve hashet. Å sette passordfeltet i databasen til f.eks varchar(64) og ikke til f.eks tinytext har betydelig ytelseseffekt på server.

 

 

Om det er lengdeforskjell i databasen på en langt passord eller et kort passord, så er det ikke hash'et. Alle hash-algoritmer gir en forutsigbar og konsistent lengde på hash'en.

 

Og jeg har aldri skrevet en webapp som lagret passord i cleartext. Ikke da jeg startet i 1998 engang.

En del av grunnlaget bak fokusen på passordhåndtering er nettopp innsikten at "vi kan ikke regne med å beskytte databasen vår". Da må vi sørge for at det som er lagret i databasen ikke kan brukes av svinepelsene. Derfor terper jeg på dette, for at du også skal lære deg det grunnleggende slik at du kan ble med på å gjøre nettet sikrere.

Igjen virker det som du ikke leser alt jeg skriver. Jeg skriver faktisk rett ut at når man bruker hash er dette ikke en begrensing lengre (irrelevant), rett og slett fordi det har en konsistent lengde. Men det har ikke vært historien, og de fleste nettløsninger er i større eller mindre grad preget av historien. Det er ingen unnskyldning - men en realitet som påvirker dagens sikkerhet. Men jeg er ikke uenig at sikker håndtering av passord er svært viktig, men det er ikke hele bildet.

 

Her er vi nok rykende uenige, og jeg synes at denne tankegangen er direkte farlig. Man gjør feil - jeg her også gjort mange, mange feil, men en del av ansvaret bak å utvikle programvare er å vedlikeholde den. Og når man vet bedre, så skal man for pokkeren og alt annet som er hellig omsette lærdommen i endringer til det bedre!

 

Sikker passordshåndtering er en forutsetning for god sikkerhet.

 

De fleste mer avanserte nettløsninger har også valg mellom ulike løsninger, rett og slett fordi mange av de skal kunne handle sammen med andre løsninger på en god måte (single signon). Dette har også påvirket måten løsningene er designet på - på godt og vondt.

 

Nå skyter du nok feil person når du snakker om "du". De løsningen jeg implementerer bruke PHPass med bCrypt eller ren Blowfish for hashing av passord i tillegg kjører de fleste med RSA-autentisering (dvs at man bruker nøkkelpar i stedet for passord i selve overføringen mellom nettleser og server) eller over SSL. Men enkelte ganger skal vi samhandle med systemer som bruker andre algoritmer og da må vi tilpasse oss til det som er mulig.

 

Ellers er jeg ikke helt ening med "utsagnet" - "vi kan ikke regne med å beskytte databasen vår". Jeg er fullt klar over at "shit happens" og at man må sikre passord etc. Men etter min mening skal man bestrebe seg på at dataene ikke skal kunne kompromiteres - det er for meg pri en. Å si at vi kan ikke beskytte dataene er for meg helt feil, vi skal gjøre det optimale for å beskytte dataene - noe annet er for meg defaitisme. Så legger vi gjerne på et eller to nivåer ekstra med sikkerhet. Men det skyldes kanskje at jeg er borte i implementeringer hvor det faktisk er annen informasjon enn brukernavn og passord som det er mer katastrofalt at kommer på avveie. Derfor er jeg også fokusert på overordna systemsikkerhet, hvor god passordhåndtering er bare et (og viktig) element. Hadde foto.no hatt en gjennomført sikkerhetskultur (systemsikkerhet) så hadde neppe dette skjedd i det hele tatt. I tillegg hadde dette garantert medført bedre passordhåndtering.

 

Jeg har dessverre sett løsninger som har hatt god passordsikkerhet med ellers var nesten som en sveitserost.

 

Amen til det siste. Best practise må gjelde overalt.

 

Men til det sentrale:

 

Å publisere noe sikkert på web'en er svært, svært krevende - både konseptuelt og i forhold til å bruke tid på utvikling og penetrasjons-testing. Og jo mer avansert applikasjonen er, jo vanskeligere er det å gjøre dette sikkert. Man må

• Ha en sikker implementasjon av selve applikasjonen. Altså uten egen-introduserte hull. All input må valideres, escapes osv. Det må ikke gå an med CSRF, XSS, SQL injection etc. Ikke lagre data i cookies. Osv osv. Og når det dukker opp nye angrepsvektorer, så må disse lukkes ASAP.
  
• Ha god, sikker konfigurasjon på serverparken.
  
• Ha god kontroll på at ALLE libraries etc blir oppdatert fortløpende, både javascript-biblioteker, system-biblioteker og alt annet.
  

Og selv da er du ikke trygg, for plutselig kommer det noen med en zero day exploit.

 

Jeg følger best practise og standarder når jeg utvikler, men later ikke som om det jeg lager er 100% sikkert. Produktet blir sikrere over tid, men industrispionene og andre "hackere" blir dyktigere over tid. Det er et evig rotterace, og det vet du like godt som meg.

 

Å legge egen dyktighet til grunn for at man har en sikker applikasjon er overmot. Slutt med det. Det finnes hundretusener, kanskje millioner, med mennesker med mer IQ og kunnskap enn deg og meg. Det må vi ta inn over oss. Det er ikke defeatism, det er virkelighetsorientering.

[Gjest Slettet+6132]

Voldsom til debatt hver gang dette.

Mer eller mindre selverlærte eksperter i sikkerhet uttalser seg hver gang.

Kontrollspørsmål:

Hva er sikrest av ett ukryptert passord og ett kryptert passord gitt at man har passordet, "rainbow-tables" (anskaffet fra ditt favoritt-hacker-ru-site) og en bra GPU/CPU?

Nei., du får ikke premie for rett svar.

Hva er sikkerhet i første omgang?

Hva er problemet her?

Er det kryptert/ikke kryptert passord, eller at noen i sin visdom har laget passord i en database på en server aksessbar fra WAN?

Du får heller ikke premie for rett svar her heller.

Til slutt(ref "brute-force-live"):

Er det bra sikkerhet å ha en passordløsning hvor du får prøve x millarder ggr før din login blir avvist?

 

Konklusjon er:

Det er ingen sikkerhetsløsning som er sikker gitt at det finnes personer som kan rammeverket rundt sikkerhet (som utvikler/hacker), og som i tillegg på en eller annen måte har tilgang (fysisk) til maskiner hvor sensitiv info (passord/brukerid) ligger.

Endret 27. oktober 2012 av Slettet+6132

[jpsalvesen]

La oss ta bcrypt + et langt salt. Kan noen forklare meg hvordan det ikke er sikkert?

[Gjest Slettet+6132]

La oss ta bcrypt + et langt salt. Kan noen forklare meg hvordan det ikke er sikkert?

 

Det er ikke sikkerhtesalgorimtmer/<sett-inn-siste-advanded-hippe-"OpenCrypt"-API-her> som er problemet.

Har du fysisk tilgang til kode/servere/passord(krypterte) har du tilgang til login.

Det var vel det jeg prøvd å formidle.

 

Det er selvsagt en aldri så liten forskjell på å lagre ukrypterte passord kontra (godt nok) krypterte passord

[Horrorbyte]

En aldri så liten forskjell?

Poenget er jo først og fremst at passordene - som mange bruker andre steder - kommer i feil hender.

 

Slike tjenester burde vært lovpålagt å hashe alle passord med salt.

Endret 27. oktober 2012 av Horrorbyte

[XmasB]

Denne er kanskje verdt å se igjen?

http://www.youtube.com/watch?v=FYfMZx2hy_8

 

Eventuelt for første gang.

[AnaXyd]

La oss ta bcrypt + et langt salt. Kan noen forklare meg hvordan det ikke er sikkert?

 

Det er ikke sikkerhtesalgorimtmer/<sett-inn-siste-advanded-hippe-"OpenCrypt"-API-her> som er problemet.

Har du fysisk tilgang til kode/servere/passord(krypterte) har du tilgang til login.

Det var vel det jeg prøvd å formidle.

 

Det er selvsagt en aldri så liten forskjell på å lagre ukrypterte passord kontra (godt nok) krypterte passord

Du må jo decrypte passordet først, for å få tilgang til login? Om det er skikkelig saltet osv, er vel det en ganske langtrekkelig prosess? Om du ikke har tilgang til alt mulig da, da er det jo ikke noe problem å endre database og gjøre så og si alt man vil.

[Gjest Slettet+6132]

En aldri så liten forskjell?

Poenget er jo først og fremst at passordene - som mange bruker andre steder - kommer i feil hender.

 

Slike tjenester burde vært lovpålagt å hashe alle passord med salt.

 

Hehe.. jeg burde nok lagt til en liten ironivarsel...

Ser den.

[sjurtf]

Jeg har fått advarsel fra både ebay og facebook hvor jeg bruker samme epost adresse, om misstenkelig aktivitet.

 

Nå har jeg byttet passord overalt.

 

 

[Keyzer28]

Jeg har fått advarsel fra både ebay og facebook hvor jeg bruker samme epost adresse, om misstenkelig aktivitet.

 

Nå har jeg byttet passord overalt.

 

Jeg var dum nok til å bruke mitt gamle passord på foto.no da jeg opprettet den på nytt etter angrepet, og av en eller annen grunn får jeg ikke bytta til nytt passord når jeg forsøker (får beskjed om at mitt fungerende passord ikke fungerer). Bruker ikke dette passordet på noen viktige sider, men jeg lurer på om jeg får gå inn og bytte dette passordet der jeg bruker det.

 

Noe dritt.

 

Har ikke sjekket foto.no i dag, men hvis du ikke allerede har gjort det bør du si fra om problemet der. Dette er jo ganske alvorlig.

 

Edit: Ser at foto.no er fullstendig nede nå.

Endret 29. oktober 2012 av Keyzer28