Derfor er eBay-hackingen så alvorlig

[VargAamo]

To eksperter forklarer farene og hva du kan gjøre.

Derfor er eBay-hackingen så alvorlig

[tommyb]

Husk at ikke bare passordene deres, men også deres "secret questions" på eBay er kompromittert. Disse må også byttes.

 

Det er heller ikke så dumt å bytte epost-adressen i samme slengen for de som har "disposable" epost-adresser. Etter f.eks. Adobe-hacket ble det sendt ut ganske mye spam på de lekkede epost-adressene.

[Anonym75896532654]

"Personopplysningene var imidlertid ikke sikret i det hele tatt"

Hva er vitsen? er jo ikke som om noen kommer til å hacke seg inn på ebay vel? BADUMTSSS

[G]

Er litt glad nå for at jeg aldri har registrert eller kjøpt noe fra e-bay, utrolig nok

 

Håper dette sperrer øynene opp hos bedrifter som har behov for å ha kundedatabaser. Det burde ihvertfall det. Blir spennende å se hvem som blir tatt med buksa nede neste gang.

 

Og ikke har jeg Facebook en gang. Snakk om å være griseheldig ..

Endret 23. mai 2014 av G

[Kirchhoff]

Jeg sliter med å forstå at det er så sykt stor forskjell på et kryptert passord med ukjent krypteringsnøkkel og hashet passord. Det blir påstått at hashing er en enveisprosess, men likevel kan den knekkes tilbake. Et hashet passord blir altså akkurat det samme som et kryptert passord, bare at passordet er krypteringsnøkkelen. Har ikke en krypteringsnøkkel mye større entropi enn ditt passord? Hvor tar jeg feil?

[EnvyAndroid]

Rimelig dårlig opplegg av eBay.

Og selve reset passord funksjonaliteten var ganske dårlig laget!

 

Passordstyrke indikatoren virket ikke skikkelig, og heller ikke kunne man copy paste inn et langt ferdig generert passord fra feks keepass.

[Sozinho]

Rimelig dårlig opplegg av eBay.

Og selve reset passord funksjonaliteten var ganske dårlig laget!

 

Passordstyrke indikatoren virket ikke skikkelig, og heller ikke kunne man copy paste inn et langt ferdig generert passord fra feks keepass.

 

LastPass skriver automagisk inn det nye passordet når man skifter passord på eBay. Er du sikker på at det ikke er en funksjon for dette i keepass også ?

[EnvyAndroid]

 

Rimelig dårlig opplegg av eBay.

Og selve reset passord funksjonaliteten var ganske dårlig laget!

 

Passordstyrke indikatoren virket ikke skikkelig, og heller ikke kunne man copy paste inn et langt ferdig generert passord fra feks keepass.

 

LastPass skriver automagisk inn det nye passordet når man skifter passord på eBay. Er du sikker på at det ikke er en funksjon for dette i keepass også ?

 

 

De har blokkert for copy paste på den websiden, med javascript.

Vil tro lastpass bare inserter det rett i formskjema, ettersom lastpass har direkte tilgang til nettsiden.

 

(Jeg bare disablet javascript for websiden, limte inn passordet, og enabled JS igjen

Endret 23. mai 2014 av EnvyAndroid

[PoTski]

Er ikke alt han snakker om i videoen hashing?

[Gjest Slettet-t8fn5F]

NORSIS bekymrer meg. Skal liksom være så inne på sikkerhet, men har til gode å se de anbefaler to-faktorautentisering på viktig-mailen din...

[007CD]

Jeg sliter med å forstå at det er så sykt stor forskjell på et kryptert passord med ukjent krypteringsnøkkel og hashet passord. Det blir påstått at hashing er en enveisprosess, men likevel kan den knekkes tilbake. Et hashet passord blir altså akkurat det samme som et kryptert passord, bare at passordet er krypteringsnøkkelen. Har ikke en krypteringsnøkkel mye større entropi enn ditt passord? Hvor tar jeg feil?

 

En hash kan du aldri knekke tilbake til hva det var, det er som å vite at svaret fra regnestykket var 100, og hvilke regneoperasjoner kan gi 100 som svar?

Så for å knekke ett hash så må du prøve ALLE bokstav, tall og symbolkombinasjoner for å se når svaret er korrekt.

Selvfølgelig finnes det hashe algoritmer som er svakere og lettere å rase igjennom å finne svar enn andre, og i noen tilfeller som MD5 så har noen knaset igjennom alle mulighetene og laget "Rainbow tables" det vil si at det allerede står hva "ABCD" resulterer i som MD5 hash, og sparer deg jobben og CPU krafta med å knekke dette på egenhånd.

 

[Kirchhoff]

007CD, den 24 Mai 2014 - 03:25, sa:007CD, den 24 Mai 2014 - 03:25, sa:

 

Kirchhoff, den 23 Mai 2014 - 19:59, sa:Kirchhoff, den 23 Mai 2014 - 19:59, sa:

Jeg sliter med å forstå at det er så sykt stor forskjell på et kryptert passord med ukjent krypteringsnøkkel og hashet passord. Det blir påstått at hashing er en enveisprosess, men likevel kan den knekkes tilbake. Et hashet passord blir altså akkurat det samme som et kryptert passord, bare at passordet er krypteringsnøkkelen. Har ikke en krypteringsnøkkel mye større entropi enn ditt passord? Hvor tar jeg feil?

 

En hash kan du aldri knekke tilbake til hva det var, det er som å vite at svaret fra regnestykket var 100, og hvilke regneoperasjoner kan gi 100 som svar?

Så for å knekke ett hash så må du prøve ALLE bokstav, tall og symbolkombinasjoner for å se når svaret er korrekt.

Selvfølgelig finnes det hashe algoritmer som er svakere og lettere å rase igjennom å finne svar enn andre, og i noen tilfeller som MD5 så har noen knaset igjennom alle mulighetene og laget "Rainbow tables" det vil si at det allerede står hva "ABCD" resulterer i som MD5 hash, og sparer deg jobben og CPU krafta med å knekke dette på egenhånd.

 

 

"En hash kan du aldri knekke tilbake til hva det var" -> "Så for å knekke ett hash så må du prøve ALLE bokstav"

 

? Du må prøve alle mulige krypteringsnøkler om du ikke vet nøkkelen til en kryptering også. Så lenge skurkene ikke har krypteringsnøkkelen så er det jo ingen forskjell?

Endret 24. mai 2014 av Kirchhoff

[007CD]

 

007CD, den 24 Mai 2014 - 03:25, sa:007CD, den 24 Mai 2014 - 03:25, sa:

 

Kirchhoff, den 23 Mai 2014 - 19:59, sa:Kirchhoff, den 23 Mai 2014 - 19:59, sa:

Jeg sliter med å forstå at det er så sykt stor forskjell på et kryptert passord med ukjent krypteringsnøkkel og hashet passord. Det blir påstått at hashing er en enveisprosess, men likevel kan den knekkes tilbake. Et hashet passord blir altså akkurat det samme som et kryptert passord, bare at passordet er krypteringsnøkkelen. Har ikke en krypteringsnøkkel mye større entropi enn ditt passord? Hvor tar jeg feil?

 

En hash kan du aldri knekke tilbake til hva det var, det er som å vite at svaret fra regnestykket var 100, og hvilke regneoperasjoner kan gi 100 som svar?

Så for å knekke ett hash så må du prøve ALLE bokstav, tall og symbolkombinasjoner for å se når svaret er korrekt.

Selvfølgelig finnes det hashe algoritmer som er svakere og lettere å rase igjennom å finne svar enn andre, og i noen tilfeller som MD5 så har noen knaset igjennom alle mulighetene og laget "Rainbow tables" det vil si at det allerede står hva "ABCD" resulterer i som MD5 hash, og sparer deg jobben og CPU krafta med å knekke dette på egenhånd.

 

 

"En hash kan du aldri knekke tilbake til hva det var" -> "Så for å knekke ett hash så må du prøve ALLE bokstav"

 

? Du må prøve alle mulige krypteringsnøkler om du ikke vet nøkkelen til en kryptering også. Så lenge skurkene ikke har krypteringsnøkkelen så er det jo ingen forskjell?

 

 

Ja og nei, en stor vesentlig forskjell er at du ved en dekryptering kan lese resultatet i klartekst og at du da vet hva passordet var og kan hente det fram igjen, men dette vet du ikke om du har en hash selv med tilgang til databasen, du må altså ha rett input og kan kun se på slutt resultatet hva det var.

Kryptering som du tenker på det ville vært en kryptering på databasen som måtte dekrypteres før bruk (Brukeren taster inn passordet på innloggingen) for å verifisere, det betyr at du kan hente ukrypterte data ut mens databasen og innloggingen kjører, passordene kunne i så fall ha vært lagret i en .txt fil og vært like lite sikre.

En hash derimot så er ikke passordet leselig for noen, du trenger ikke å dekryptere noe som helst, alt du sammenligner er svaret du får fra hva brukeren har tastet inn, og matcher dette mot hva som ligger i databasen og er de like så er det greit og klart for innlogging.

 

Serveren vet ikke hva du har som passord om det er hashet, men dette vites om det er kryptert.

Det er også en forskjell på algoritmene som skal benyttes for hashing, de er gjort trege med fullt overlegg for å øke "kostnaden" ved brute force knekking.

 

[Josten]

Kryptering av passord kan gjøres på mange ulike måter. Men når personer kommer med utsagn som "ikke bruk kryptering, bruk hashing", er det ikke alltid helt lett å vite hva slags kryptering det siktes til.

Én mulighet: Alle passord i databasen er kryptert og nøkkelen ligger i applikasjonen. Applikasjonen henter opp passordet, dekrypterer det og sammenligner med passordet sendt fra brukere. Noe bedre enn klartekstlagring, men dersom hovedpassordet også lekker ut, eller er enkelt å gjette, har man tilgang til alle passord.

En annen mulighet: Det brukes to tekstfelt i databasen. Den ene (a) er en tilfeldig generert tekstreng og den andre (b) er en kryptert versjon av denne, kryptert med brukerens passord. Et passord valideres basert på om kryptering av felt a med passordet oppgitt av brukeren gir resultatet i b. Her er det riktignok ikke passordet i seg selv som er kryptert.

Jeg antar det er førstnevnte metode det siktes til, for jeg klarer ikke se at metode to er noe vesentlig dårligere eller anderledes enn salting og hashing.

Endret 24. mai 2014 av Josten

[PoTski]

 

 

 

007CD, den 24 Mai 2014 - 03:25, sa:007CD, den 24 Mai 2014 - 03:25, sa:

 

 

Kirchhoff, den 23 Mai 2014 - 19:59, sa:Kirchhoff, den 23 Mai 2014 - 19:59, sa:

 

Jeg sliter med å forstå at det er så sykt stor forskjell på et kryptert passord med ukjent krypteringsnøkkel og hashet passord. Det blir påstått at hashing er en enveisprosess, men likevel kan den knekkes tilbake. Et hashet passord blir altså akkurat det samme som et kryptert passord, bare at passordet er krypteringsnøkkelen. Har ikke en krypteringsnøkkel mye større entropi enn ditt passord? Hvor tar jeg feil?

En hash kan du aldri knekke tilbake til hva det var, det er som å vite at svaret fra regnestykket var 100, og hvilke regneoperasjoner kan gi 100 som svar?

Så for å knekke ett hash så må du prøve ALLE bokstav, tall og symbolkombinasjoner for å se når svaret er korrekt.

Selvfølgelig finnes det hashe algoritmer som er svakere og lettere å rase igjennom å finne svar enn andre, og i noen tilfeller som MD5 så har noen knaset igjennom alle mulighetene og laget "Rainbow tables" det vil si at det allerede står hva "ABCD" resulterer i som MD5 hash, og sparer deg jobben og CPU krafta med å knekke dette på egenhånd.

 

"En hash kan du aldri knekke tilbake til hva det var" -> "Så for å knekke ett hash så må du prøve ALLE bokstav"

 

? Du må prøve alle mulige krypteringsnøkler om du ikke vet nøkkelen til en kryptering også. Så lenge skurkene ikke har krypteringsnøkkelen så er det jo ingen forskjell?

Ja og nei, en stor vesentlig forskjell er at du ved en dekryptering kan lese resultatet i klartekst og at du da vet hva passordet var og kan hente det fram igjen, men dette vet du ikke om du har en hash selv med tilgang til databasen, du må altså ha rett input og kan kun se på slutt resultatet hva det var.

Kryptering som du tenker på det ville vært en kryptering på databasen som måtte dekrypteres før bruk (Brukeren taster inn passordet på innloggingen) for å verifisere, det betyr at du kan hente ukrypterte data ut mens databasen og innloggingen kjører, passordene kunne i så fall ha vært lagret i en .txt fil og vært like lite sikre.

En hash derimot så er ikke passordet leselig for noen, du trenger ikke å dekryptere noe som helst, alt du sammenligner er svaret du får fra hva brukeren har tastet inn, og matcher dette mot hva som ligger i databasen og er de like så er det greit og klart for innlogging.

 

Serveren vet ikke hva du har som passord om det er hashet, men dette vites om det er kryptert.

Det er også en forskjell på algoritmene som skal benyttes for hashing, de er gjort trege med fullt overlegg for å øke "kostnaden" ved brute force knekking.

 

Det stemmer ikke helt. Du kan lese begge ved dekryptering.

 

Hashing gir fixed output og kryptering så "scrambler" den dataen. så den kan ha hvilken som helst lengde på output.

 

Serveren veit ikke hva du har som passord når du krypterer heller. Fordi sha er "key" til krypteringen.

[tommyb]

De har blokkert for copy paste på den websiden, med javascript.

Vil tro lastpass bare inserter det rett i formskjema, ettersom lastpass har direkte tilgang til nettsiden.

 

(Jeg bare disablet javascript for websiden, limte inn passordet, og enabled JS igjen

 

 

Obs!

Hvis du gjør dette, får du sannsynligvis lov til å legge inn passord som ikke virker. Javascriptet begrenset også lengden til 20 tegn og blokkerte mellomrom.

[tommyb]

En forskjell med kryptering og hashing er at kryptering betyr at det finnes en nøkkel for å dekryptere. Klarer man på et eller annet vis å få tak i eller finne den med forsøk, så låser man opp ikke bare det ene passordet, men alle passord som er kryptert på samme vis. Gjerne er dette en krypteringsalgoritme som bruker samme metode/nøkkel for hele databasen.

 

Med hashing må man teste ett og ett passord i hele databasen.

 

Begge metodene har fordel av et personlig salt, som gjør at hver enkelt bruker får forskjellig metode/nøkkel - men dette saltet må også lagres et sted.

 

Om man kjenner algoritmen for hashing, kan man kjøre ordbokoppslag eller brute force, og matche alle som har enkle passord raskt. Så uansett vil det alltid lønne seg å ha et vanskelig passord.

Endret 24. mai 2014 av tommyb

[MartinGM]

En forskjell med kryptering og hashing er at kryptering betyr at det finnes en nøkkel for å dekryptere. Klarer man på et eller annet vis å få tak i eller finne den med forsøk, så låser man opp ikke bare det ene passordet, men alle passord som er kryptert på samme vis. Gjerne er dette en krypteringsalgoritme som bruker samme metode/nøkkel for hele databasen.

 

Med hashing må man teste ett og ett passord i hele databasen.

 

Begge metodene har fordel av et personlig salt, som gjør at hver enkelt bruker får forskjellig metode/nøkkel - men dette saltet må også lagres et sted.

 

Om man kjenner algoritmen for hashing, kan man kjøre ordbokoppslag eller brute force, og matche alle som har enkle passord raskt. Så uansett vil det alltid lønne seg å ha et vanskelig passord.

Forskjellen på kryptering og en hash? Blir som å sammenligne epler og sjokoladepålegg.

 

Kryptering har ikke noe med om det finnes en nøkkel eller ikke.

 

En hash er en kombinasjon av symboler som er et resultat av en hash-krypteringsalgoritme.

 

En hash-krypteringsalgoritme vil generere strenger med lik lengde uansett lengden til det opprinnelige passordet og disse kan krypteres med eller uten en krypteringsnøkkel.

 

Hvis hensikten er å verifisere integriteten av en fil vil det være lite hensiktsmessig å bruke en krypteringsnøkkel, mens når man lagrer passord vil det være det-

 

Men siden samme krypteringsnøkkel ville resultert i samme hash for brukere med samme passord er det vanlig å salte passordet før krypteringen. Siden en endring på bare ett tegn vil resultere i totalt forskjellig checksum trenger ikke saltet være spesielt stort og det trenger heller ikke en gang å være hemmelig og kan lagres i klartekst sammen med hashen.

 

Dette er fordi:

(passord og salt) + krypteringsnøkkel => checksum

 

mens det er umulig å kunne utlede krypteringsnøkkelen fra checksumen og saltene.

 

Og selv om man kjenner krypteringsnøkkelen er ikke den ment for å reversere checksumen siden checksumen ikke inneholder dataene man genererte checksumen fra.

 

Når brukeren forsøker å logge på med passordet sitt hentes saltet hans, legges til passordet checksumen genereres ved hjelp av krytperingsnøkkelen og checksummene sammenlignes.

 

Derfor vil en passordfil der man har brukt salting og kryptering i praksis være verdiløs.

 

Hvis det derimot ikke var brukt salting ville man kunne samle like hasher og de hashene som var brukt flest ganger ville da gjerne være passordene 1234, passord etc,.

 

Helt avslutningsvis: hvis passordene (eller annen data) er kryptert med tanke på å dekrypteres - det vil si at man vil ta vare på det opprinnelige innholdet - vil også dataene være sårbare for dekryptering.

Endret 27. mai 2014 av MartinGM

[tommyb]

Ja, hvis passordene er lagret med tanke på å dekrypteres (sjokoladepålegg), vil de være mulige å dekryptere mens om de er hashet eller lagret med enveiskryptering, vil de ikke være mulig å dekryptere (epler).

 

 

 

Hvis man kjenner passordet, krypteringsalgoritmen og det lagrede resultatet kan man finne saltet, uten at dette har noen verdi dersom saltet er personlig.

 

Hvis man kjenner passordet og det lagrede resultatet og det ikke er brukt salt, eller det er brukt et felles salt som er kjent, kan man teste forskjellige kjente krypteringsalgoritmer og finne hvilken som er brukt.

 

Finner man en kjent toveis krypteringsalgoritme, kan man lese av alle passord.

 

Dersom det er brukt et salt, men dette er lagret i klartekst eller med samme toveis krypteringsalgoritme i databasen, er resultatet det samme, man kan teste forskjellige kjente krypteringsalgoritmer, og dermed finne krypteringsalgoritmen om en slik er brukt.

 

Er det brukt personlig salt, lagret utenfor databasen, og man har hentet dette også, er scenarioet det samme som om det lå i databasen.

 

Er det brukt salt, lagret som fil utenfor databasen, og man kun har hentet databasen, er det ikke mulig å regne ut passordene.

 

I alle tilfeller hvor det er brukt en kjent toveis krypteringsalgoritme og saltet er kjent eller ikke-eksisterende, kan man finne passordet i klartekst, riktig nok med forskjellig vanskelighetsgrad.

 

Legger man på hashing eller enveis kryptering, går det ikke an, selv om man kjenner både algoritme, salt, hashen og noen av de opprinnelige passordene. Da må man brute-force gjennom samme algoritme og se om resultatet blir likt, for hver eneste passord. Da først hjelper det å ha et sterkt passord. :g Med personlig salt vil det da heller ikke være mulig å sortere passordene på hvilke som er mest brukte, så man kan ikke se om et passord er svakt eller sterkt før man begynner å brute-force.

 

 

 

Ellers så vet jeg ikke så mye om dette, poengene var opprinnelig bare at

1) toveis kryptering er toveis, og

2) dersom det personlige saltet er kjent og det er brukt en kjent toveis krypteringsalgoritme, kan man finne alle passordene uten brute-force, som er vesentlig raskere enn å forsøke knekke passordene ett etter ett, mens

3) hashing er ikke toveis.

Endret 28. mai 2014 av tommyb

[EnvyAndroid]

 

De har blokkert for copy paste på den websiden, med javascript.

Vil tro lastpass bare inserter det rett i formskjema, ettersom lastpass har direkte tilgang til nettsiden.

 

(Jeg bare disablet javascript for websiden, limte inn passordet, og enabled JS igjen

 

 

Obs!

Hvis du gjør dette, får du sannsynligvis lov til å legge inn passord som ikke virker. Javascriptet begrenset også lengden til 20 tegn og blokkerte mellomrom.

 

 

Litt sent svar kanskje, men:

 

Det ville isåfall vært horribelt utført av eBay (slik som blokkeringen av copy paste), om de ikke skulle sjekket gyldigheten til passordet på serversiden før de sa at passordet var "ok" til meg.