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

[AnaXyd]

SHA*-baserte passordlagringssystemer, uansett hvor saltede de er, er i praksis kun marginalt bedre enn å lagre passord i klartekst. Med dagens GPU-baserte passordcrackingløsninger bør man holde seg langt unna hashingalgoritmer som ikke er spesifikt lagd med tanke på passord, f.eks BCrypt. Les mer her: http://codahale.com/...ore-a-password/

Du skal ha en rimelig heftig GPU bruteforcer + heftig rainbowtable for å knekke et godt saltet passord på kort tid!

[potetskrell]

Hadde jeg visst at dette var konsekvensen av å bruke foto.no hadde jeg holdt meg LANGT unna.

 

Gir konsekvenser for mange som gjerne er mer enn at noen har fått tilgang til privat informasjon på foto.no

[JohndoeMAKT]

Du skal ha en rimelig heftig GPU bruteforcer + heftig rainbowtable for å knekke et godt saltet passord på kort tid!

Hvorfor blander du brute force og RT og hvorfor skal salt ha noe å si for brute force?

[TigerJack]

foto.no er nede i øyeblikket. Tipper det pågår hektisk aktivitet der nå.

 

Så vidt jeg har fått med meg, var hackeren en som ikke hadde vonde hensikter, og etter at foto.no gjentatte ganger har fått meldinger om elendig sikkerhet, valgte denne karen å hacke seg inn for å vise dem alvoret.

 

Forhåpentligvis stemmer dette, slik at passordene ikke kommer på avveie.

 

Edit: Foto.no var visst ikke nede likevel....

Endret 25. oktober 2012 av TigerJack

[AnaXyd]

Du skal ha en rimelig heftig GPU bruteforcer + heftig rainbowtable for å knekke et godt saltet passord på kort tid!

Hvorfor blander du brute force og RT og hvorfor skal salt ha noe å si for brute force?

Mulig jeg blandet litt der ja..

[jpsalvesen]

SHA*-baserte passordlagringssystemer, uansett hvor saltede de er, er i praksis kun marginalt bedre enn å lagre passord i klartekst. Med dagens GPU-baserte passordcrackingløsninger bør man holde seg langt unna hashingalgoritmer som ikke er spesifikt lagd med tanke på passord, f.eks BCrypt. Les mer her: http://codahale.com/...ore-a-password/

Du skal ha en rimelig heftig GPU bruteforcer + heftig rainbowtable for å knekke et godt saltet passord på kort tid!

Du skal ha en mange ganger heftigere løsning for å knekke en godt saltet bcrypt. Bare det å produsere et rainbow table tar enorme ressurser når det tar 1 sekund å beregne en hash. Husk at et rainbow table er en tabell med ferdigberegnede verdier for passord opp til en viss lengde, evt kombinert med salt av rimelig lengde. Du har altså en svær tabell som inneholder passord, hash. Hver eneste rad må beregnes.

 

Når du bruker en rainbow table, så har du en hash fra databasen du har hacka, og så slår du opp passordet som hører til hash'en. Om du ikke finner noen treff i rainbow table så har du ikke et rainbow table som passer.

 

Da må du gå over til brute force.

 

Og når du kjører brute force, så spiller igjen hvor lang tid det tar å beregne en hash en stor rolle. Om du kan beregne 100000 hash'er i sekundet, så går det mye raskere enn om du bare klarer 1 i sekundet.

 

bcrypt+et langt salt er greia.

[smort1]

Ja, ja, så er det registrert fortsatte problemer av samme slaget!

Ble oppfordret til å sette nytt passord igår kveld, og gjorde det! Nå melder de i kveld at samme elendigheten også var der idag, så nå er det påan igjen....

Tror jeg holder meg laaaaangt unna foto.no leeeenge! Iallefall mht. pålogging og endring av passord!

 

SKANDALE at de ikke greier å gjøre en skikkelig jobb! Amatørmessig er bare forbokstaven - !!!!! Tror det må en skikkelig kompetanseheving til der igården!!!

[AnaXyd]

SHA*-baserte passordlagringssystemer, uansett hvor saltede de er, er i praksis kun marginalt bedre enn å lagre passord i klartekst. Med dagens GPU-baserte passordcrackingløsninger bør man holde seg langt unna hashingalgoritmer som ikke er spesifikt lagd med tanke på passord, f.eks BCrypt. Les mer her: http://codahale.com/...ore-a-password/

Du skal ha en rimelig heftig GPU bruteforcer + heftig rainbowtable for å knekke et godt saltet passord på kort tid!

Du skal ha en mange ganger heftigere løsning for å knekke en godt saltet bcrypt. Bare det å produsere et rainbow table tar enorme ressurser når det tar 1 sekund å beregne en hash. Husk at et rainbow table er en tabell med ferdigberegnede verdier for passord opp til en viss lengde, evt kombinert med salt av rimelig lengde. Du har altså en svær tabell som inneholder passord, hash. Hver eneste rad må beregnes.

 

Når du bruker en rainbow table, så har du en hash fra databasen du har hacka, og så slår du opp passordet som hører til hash'en. Om du ikke finner noen treff i rainbow table så har du ikke et rainbow table som passer.

 

Da må du gå over til brute force.

 

Og når du kjører brute force, så spiller igjen hvor lang tid det tar å beregne en hash en stor rolle. Om du kan beregne 100000 hash'er i sekundet, så går det mye raskere enn om du bare klarer 1 i sekundet.

 

bcrypt+et langt salt er greia.

Absolutt, var en som klarte 2 mill hasher i sekundet på GPU på freak.no, det var rimelig heftig. Men fremdeles kan det jo ta veldig lang tid å finne en matchende hash.

[fcuk_IT]

Til dere som bruker samme passord overalt - Roboform er svaret.

 

Transportabel (i skyen) kryptert "passordbank" som attacher til de fleste kjente nettlesere. I praksis kan dere bruke så ullne passord som mulig - og ikke trenge huske dem med unntak av ett avanser masterpassord.

[potetskrell]

Av det jeg kan lese på foto.no sine forumsider og diskusjon om saken minner dette mer om en skandale enn noe annet. Det virker som det beste nå er å dra nettverkskabelen ut av serveren.

[AstroChicken]

Til dere som bruker samme passord overalt - Roboform er svaret.

 

Transportabel (i skyen) kryptert "passordbank" som attacher til de fleste kjente nettlesere. I praksis kan dere bruke så ullne passord som mulig - og ikke trenge huske dem med unntak av ett avanser masterpassord.

 

Var ikke leksen her å _IKKE_ lagre passord online?

 

Forøvrig kan du oppnå samme lettvintheten med å regne ut hash av passordet lokalt, saltet med navnet på nettstedet. eg.

 

echo "foto.noSaltErGodtPåBådeMatOgPassord" | sha256sum | sha256sum

gir: bbcfc83ee6241a419d816123a7b7fe4cd591e05c6784fab9ea9caab1ec41ae93 som passord for nettstedet.

 

Hvor mange ganger du ønsker å kjøre sha256sum kommer ann på hvor paranoid du er.Såklart, om du er redd for å bli keylogget master-passordet ditt, bør du regne ut hash'en på en separat offline enhet og taste inn for hånd.

Endret 25. oktober 2012 av Grizzmo

[Bolson]

Det er viktig å ta diskusjonen om hva som er sikre nok passord og det bør være slik at nettsteder har et minimum av sikkerhet knyttet til passord. Men hvorfor er det ingen som henger seg opp i det som virkelig er problemet her, nemlig en usikker nettløsning. Husk at selv med god sikkerhet for hashing + salt på passord vil en nettløsning med hull kunne kompromittere personlig informasjon som ikke bør kompromitteres. At passord ikke skal kommuniseres i klartekst noen steder er en selvsagthet.

 

Personlig vil jeg føle meg mer trygg på et nettsted jeg vet har gode generelle sikkerhetsrutiner, bruker en løsning med ingen kjente sikkerhetshull selv om de ikke har valgt den mest ekstreme løsningen for passordsikkerhet enn et nettsted med dårlige generelle sikkerhetsrutiner, historie for mange hull eller begrenset utviklermiljø selv om de har meget god passordløsning.

 

Foto.no er så vidt jeg vet en løsning i realiteten kodet av en utvikler og trolig med begrenset gjennomgang av kodebasen for å finne eventuelle sikkerhetshull. Personlig oppfatter jeg slike løsninger som direkte farlige, uansett hvor god en utvikler er vil han ikke klare å kode feilfritt. Min mening er derfor at man bør bruke løsninger som har en relativt stor installasjonsbase (særlig blant tyngre aktører med krav til sikkerhet), en god historie når det gjelder sikkerhetshull og et gjennomført system for å sjekke kodebasen samt løpende sikkerhetshåndtering.

 

Jeg mener også at nettsider der man logger seg inn og forventes å lagre profilinformasjon helt bør settes opp med SSL.

[fcuk_IT]

Til dere som bruker samme passord overalt - Roboform er svaret.

 

Transportabel (i skyen) kryptert "passordbank" som attacher til de fleste kjente nettlesere. I praksis kan dere bruke så ullne passord som mulig - og ikke trenge huske dem med unntak av ett avanser masterpassord.

 

Var ikke leksen her å _IKKE_ lagre passord online?

 

Forøvrig kan du oppnå samme lettvintheten med å regne ut hash av passordet lokalt, saltet med navnet på nettstedet. eg.

 

echo "foto.noSaltErGodtPåBådeMatOgPassord" | sha256sum | sha256sum

gir: bbcfc83ee6241a419d816123a7b7fe4cd591e05c6784fab9ea9caab1ec41ae93 som passord for nettstedet.

 

Hvor mange ganger du ønsker å kjøre sha256sum kommer ann på hvor paranoid du er.Såklart, om du er redd for å bli keylogget master-passordet ditt, bør du regne ut hash'en på en separat offline enhet og taste inn for hånd.

 

En del av poenget, med at noen stikker av med passordet til ett sted, er faren for at man har brukt det samme et annet sted.

 

Roboform er et verktøy som gjør det mulig å benytte i praksis så mange forskjellige passord man vil, uten at man må huske dem hele tiden. Det kritiske er at man sikrer disse godt, og med et godt/sterkt masterpassord.

 

Husk at ikke alle nettsteder tillatter så lange passord som det saltede eks. ditt. Windows Live er ett eks.

[jpsalvesen]

Ja, når et nettsted har en maksgrense på lengden på et passord, så er det et sikkert tegn på at de lagrer data i klartekst og generelt har sviktende innsikt i sikkerhet. Om man bare lagrer en hash'et verdi, så kan brukeren i prinsippet ha hele teksten i Bibelen som passord. Hash'en blir like lang som når passordet er "Hei123".

[Bolson]

Mange nettsteder har maksgrense på lengden av passord (også hasha versjon) av ytelsesmessige årsaker. Å ikke ha grense medfører at man må lagre passordene i databasen på måter som gir svært stor overhead. Med tusenvis av brukere har det en reell betydning.

 

Det er langt fra noe tegn på at passordene lagres i klartekst. Løsninger som Moodle, WordPress, TYPO3, EpiServer med flere har alle begrensinger på passordlengde, men alle er standard satt opp med krypteringløsninger for passord. I TYPO3 kan man velge å bruke flere typer - blant annet Blowfish salted passord og passord kommuniseres aldri. Men man har også mulighet til å bryte alle "fornuftige" regler og lagre ting i klartekst.

 

Men lengden sier klart noe om hvor sterk hashing man har - det er helt korrekt som du skriver at et hash har samme lengden uansett - slik at det ikke er nødvendig å sette begrensing på selve passordet når man bruker hash. Men ofte henger disse begrensingene igjen i systemene selv om sikkerheten er langt bedre i dag.

 

Det finnes også løsninger som er vel så bra som ekstrem hashing - f.eks bruk av nøkkelpar via f.eks RSA-autentisering. Nå løser det ikke nødvendigvis problemet knyttet til at brukeropplysninger kommer på avveie, men som jeg skriver overfor er det å ha en nettløsning som ikke lar seg hacke (minst mulig sannsynlighet for) minst like viktig som selve løsningen knyttet til passord. Det er den totale sikkerheten, hvorav passordsikkerhet er et viktig element, som bør vektlegges - og ikke bare enkeltelementer.

 

Den primære grunnen til at jeg oppfatter dette som vel så viktig er følgende:

- Folk har ofte samme passord flere steder.

- Selv om passordet er meget godt hashet og i realiteten nesten uknekkelig vil resten av brukerinfoen kunne brukes til å krysskobles mot andre data og øke sannsynlighet for at passord kompromitteres og ikke minst brukes til identitetstyveri og lignende aktivitet.

[XmasB]

Jeg har nylig gått gjennom over 120 nettsider for å rydde opp i passordene mine.

 

Det er mange rare varianter av krav til passord der ute. Det vanligste er krav til lengde, gjerne både minimum og maksimum. Det rare er at at noen nettsider har en del krav som gir dårligere sikkerhet, som maks lengde 10 tegn (noen nede i 8) og kun bokstaver og tall. Jeg har problemer med å se den tekniske begrensingen til punktum ikke er lov i passord. Eller som en nettside som klaget på at det fant et ord fra ordboken i passordet mitt (lurer på om det var Telenor). Jeg er i tvil om passordet "Y]34v{2|Hdz;3gL" er sikrere enn "Y]34v{bamsedz;3gL"...

 

Mens noen krever spesialtegn, krever andre at det ikke er der. Det gjør det litt vanskeligere å ha et system på passordene sine. Jeg har alle passordene trygt lagret i LastPass, men vil ikke være helt avhengig av den heller siden jeg ikke alltid er på egne enheter.

 

På de fleste arbeidssteder er det noen krav til passord. Som at de må bytte hver 3 mnd f.eks. Deffor er et typisk passord bygget opp som f.eks Bamse1. Ved bytte: Bamse2. Deretter Bamse3.

Eller de krever at passord ikke skal ligne på de siste passord så passordet er skrevet ned på en post-it lapp under tastaturet...

[jpsalvesen]

Mange nettsteder har maksgrense på lengden av passord (også hasha versjon) av ytelsesmessige årsaker. Å ikke ha grense medfører at man må lagre passordene i databasen på måter som gir svært stor overhead. Med tusenvis av brukere har det en reell betydning.

Dette er demonstrerbart feil. Det tar ganske nøyaktig like lang tid å beregne en hash på et kort passord som på en mellomstor fil:

 

[jps@localhost ~]$ ls -lh /usr/lib64/firefox/firefox
-rwxr-xr-x 1 root root 79K Oct 10 14:41 /usr/lib64/firefox/firefox

 

79Kilobytes. Hvor lang tid tar det?

 

[jps@localhost ~]$ time sha256sum /usr/lib64/firefox/firefox
7f12adeccee539ef350f949db4cb8f8da483cf967f9f7e9ba44ad159dda2edc9  /usr/lib64/firefox/firefox
real	0m0.002s
user	0m0.001s
sys	 0m0.002s

 

For referanse, hash'en er akkurat like lang som når jeg gjør

 

[jps@localhost ~]$ time echo "hei123" | sha256sum
85295ae744b548a5e0cc4f2e578575535fda57f5414f673d3b5276fbcc31d536  -
real	0m0.001s
user	0m0.000s
sys	 0m0.002s

 

Det finnes ingen god grunn til å sette en makslengde på passord.

[AnaXyd]

Hm, interessant observasjon det der.

[Bolson]

@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.

 

Jeg skriver også at ved bruk av hash (som har konstant lengde) er i realiteten denne begrensingen ikke nødvendig lengre - man kan sette varchar til lengden på generert hash (de fleste setter den til 64 som er normal sha256 lengde), men selve begrensingen den ligger ofte igjen fra tidligere tider med annen sikkerhet og mekanismer knyttet til passordhåndtering. Det er også langt mer enn generering av hash som foregår i en slik løsning hvor faktisk lengden på passordstrengen kan ha (har) ytelsesmessig betydning - blant annet minnebruk. Har selv testet løsning (noen år tilbake) der antallet samtidige mulige innlogginger gikk ned med 50 % når vi simulerte med passord på dobbelt lengde. Og det hadde ingenting med hash å gjøre, vi fikk samme resultatet uansett om vi brukte passord i klartekst eller salta hash. I dette tilfellet klarte vi å fikse problemet delvis med å skrive om deler av logikken, men det var langt fra kurant.

 

De fleste nettløsninger som brukes i dag fikk sin databasestruktur og hovedlogikk definert for 5 - 10 år siden, og i samme omgang ble grunnregler knyttet til passordhåndtering laget. På mange løsninger er det faktisk enkelt å legge inn f.eks hashing, men kan være svært komplekst å endre reglene knyttet til min og maks lengde på selve passordet (avhengig av hvordan logikken er bygd opp).

 

Men igjen dette overfokuset på passordhåndtering, problemet for f.eks foto.no var i realiteten ikke det, men en generelt usikker nettløsning (løsning med mange hull). Noe som er et generelt problem for selvutviklede løsninger. Det å få bevissthet rundt sikker koding og kodekvalitet og få aktører til å "ditche" selvutviklede løsninger når de ser at de ikke klarer å få til gode nok miljøer rundt utviklingen er etter min mening vel så viktig. Det vil også tjene passordhåndteringen - da man i større miljøer klart har aktører som i større grad har fokus på og lager løsninger for dette.

[AnaXyd]

Jeg syntes det ikke er overfokus på passordhåndtering når de presterer å lagre passord i klartekst.