NorSIS ber nordmenn droppe 1234 som passord

[SuperKrokodille]

Spørsmål: Hvordan "knekker" man et passord? Vil tro de fleste steder (på nettet da) som etterspør et passord bare vil tillate et ganske begrenset antall forsøk per tidsenhet, eller før de vil be om ekstra koder via e-post, eller lignende?

[Red Frostraven]

Man knekker passord ved å bruke kjente passord -- bruke årstall, kombinert med datoer og andre faktorer.
Bytt IP mellom hvert tredje forsøk.
Bytt offer når det går for lang tid, og passordet tydeligvis ikke er enkelt.
Så klarer du å finne noen som har et dårlig passord.

På en PC, så kan du starte PC-en via USB-oppstartspinne, og finne og hacke passord utenfra -- eller bruke javascript til å forsøke alle mulige passord.
...

Om du trenger en bestemt person sitt sitt passord, så kan du bruke mange PC-er i et bot-nettverk til å forsøke å logge inn på alle tjenestene denne personen besitter, hver med tilfeldig genererte passord eller en prosess med eliminering, helt til man kommer inn på tjenesten.

Eller så får man tilgang til en mer primitiv eller alternativ versjon av tjenesten, som har mindre lag av sikkerhet, og som ikke bryr seg om at du har mange forsøk.

Eller så hacker man serveren som har passordene, får tilgang til filen(e) som inneholder passordene, og dekrypterer.




---

Angående passordsikkerhet:
Tvangen til å begrense passord til "minst en stor og en liten bokstav og ett tegn" ødelegger i stor grad for seg selv, gjennom at tre tegn i passordet er en av ti tall, ett av rundt tredve spesialtegn, eller en av under tredve bokstaver -- i stedet for et totalt ukjente tegn blant rundt 120 muligheter, for helt frivillige tegn.
Passordet OleBanan1$ sine siste to tegn er mindre sikre enn de tidligere -- i et system som krever store og små bokstaver og et tegn da de må være henholdsvis et tall og et tegn, når de første tegnene er bokstaver og inkluderer store og små bokstaver.

OleBanan1$ er sikrere når tjenesten ikke stiller krav enn når den stiller krav.
olebananen er like sikkert som OleBanan1$, om datamaskiner forsøker å bruteforce passordet.

Lengde slår også kompleksitet.

"OransjeBananerSveveroverHorisonten" er mange milliarder ganger sikrere enn "h4w2¤%F5", for eksempel, rent kryptografisk.
Sistnevnte klarer en maskin å hacke i løpet av 6 måneder.
Førstnevnte klarer ikke alle datamaskinene som finnes i verden å brute-force mens den siste stjernen i universet fremdeles lyser -- og spesielt lengre enn det trenger ikke noe jeg eier å lagres trygt.

[Theo343]

Men 4321 er bare å fortsette med....

[Red Frostraven]

4321 er ikke spesielt sikkert.
Du må i alle fall opp i 6789.

---

Sykkellåsen min hadde den tilfeldig genererte koden 1997.
Jeg savner fremdeles sykkelen min.

Endret 22. august 2020 av Red Frostraven

[bshagen]

Red Frostraven skrev (3 minutter siden):

Sykkellåsen min hadde den tilfeldig genererte koden 1997.
Jeg savner fremdeles sykkelen min.

?

Forøvrig veldig informativt den posten over, det var interessant lesning

[vidor]

Veksler mellom '0000' og 'password' så jeg er nok trygg. Skjønner meg ikke på folk som bruker '1234' og 'qwerty' som passord.

[0laf]

SuperKrokodille skrev (2 timer siden):

Spørsmål: Hvordan "knekker" man et passord? Vil tro de fleste steder (på nettet da) som etterspør et passord bare vil tillate et ganske begrenset antall forsøk per tidsenhet, eller før de vil be om ekstra koder via e-post, eller lignende?

Slik det vanligvis foregår, er at man ikke knekker passordet til en bestemt bruker ved å forsøke mange ganger, det er nesten umulig, samt lite hensiktsmessig.

Ingen nettsider med noen som helst respekt for seg selv lagrer passord, det er totalt feil.

Når brukeren velger et passord, så tar man det passordet, legger til et "salt", og så krypteres dette, og saltet og den kypterte løsningen lagres, ikke selve passordet. Man lagrer aldri passord.

Ettersom hverken saltet eller den krypterte strengen kan brukes som passord, så vil det ikke være helt kritisk dersom noen får tak i disse krypterte løsningene, ettersom de ikke har selve passordet.

Det som vanligvis skjer, er at en inntrenger kommer seg inn, å får tilgang til databasen med krypterte passord.
Nå er det flere større nettsider som har gått på en smell, hvor de faktisk har lagret passord, men forhåpentligvis er det veldig få som gjør dette nå.

Inntrengeren har så saltet, og en kryptert streng, det man gjør da, er å bruke saltet sammen med et passord man gjetter på, for å se om den krypterte strengen man får stemmer med den man har stjålet, gjør den det, så har man passordet.

Man prøver da en rekke muligheter, i et eller annet system, ikke bare helt tilfeldig utvalgte ting.

Dette kan åpenbart gjøres på egen maskin, eller en maskin med bedre kapasitet, for eksempel med flere skjermkort ettersom GPU'er normalt er raskere til å regne ut slike ting.

Saltet og krypteringsalgoritmen gjør at slik "gjetting" ofte går tregt, og har man brukt et langt salt, og en tilstrekkelig sikker algoritme, så vil det være nesten umulig å gjette passordene.

Mange nettsider har gått på en smell her også, hvor de ikke har brukt salt eller særlig sikker algoritme, slik at alle brukernavn og passord på nettsiden har blitt kompromittert, selv om de er kryptert.

For å knekke slik kryptering, så kan man enten bruke brute-force, hvor man starter med "a" og går til "å", så til "aa" til "åå" ... osv.
Desto større tegnsett, altså om passordet kan inneholde tall, bokstaver, spesielle tegn osv, øker vanskeligheten, ettersom det tar lengre tid å forsøke flere tegn.

Brute-force vil ta lengre tid, desto lengre passordet er, slik at lange passordet motvirker dette, forutsatt at nettsiden har brukt en algoritme som tar litt tid for en datamaskin å regne ut.

En annen måte er å bruke ordlister, dersom man tror passordene består av ord. Da bruker man rett og slett alle ordene i ordboka, eller en egendefinert liste, å tester disse ordene, samt en rekke kombinasjoner av ordene.

Ordlister motvirkes dersom man bruker uvanlige ord, eller litt pussige kombinasjoner med tall midt i ord osv. fordi slike ord trolig ikke finnes i ordlistene.

En tredje mulighet, er å bruke regnbuetabeller. Regnbuetabeller er tabeller som allerede inneholder krypterte strenger med gitte løsninger, slik at dette går mye raskere å teste ettersom datamaskinen ikke trenger å regne ut algoritmen for hvert forsøk.

Regnbuetabeller motvirkes med et "salt", ettersom tabellene ikke kan inneholde slike salt, det blir for omfattende, og ved å bruke forskjellige salt for hver bruker, ikke ett salt for hele nettsiden, så motvirker man også generering av nye regnbuetabeller som inneholder saltet.

Det er en myte at hackere sitter å forsøke å hacke nettopp din konto, det forekommer sikkert, men det er langt mer vanlig at de forsøker å hacke hele nettsider, for å finne innloggingsinfo til mange brukere samtidig, det er både lettere og mer effektivt.

Endret 22. august 2020 av 0laf

[Shruggie]

Passord er feil løsning.

[Theo343]

7 hours ago, Shruggie said:

Passord er feil løsning.

Voila. Passord skal evt. være så langt og komplekst at en maskin aldri skal kunne knekke det, men brukeren skal aldri behøve å forholde seg til passordet. Men generelt sett er passord helt feil metode ja.

Det er ikke langt inn i fremtiden at ungdommen lurer på hvorfor vi drev å lagde passord og pinkoder vi måtte huske og tastet inn. De vil riste på hodet av det.

Endret 22. august 2020 av Theo343

[Merko]

SuperKrokodille skrev (10 timer siden):

Spørsmål: Hvordan "knekker" man et passord? Vil tro de fleste steder (på nettet da) som etterspør et passord bare vil tillate et ganske begrenset antall forsøk per tidsenhet, eller før de vil be om ekstra koder via e-post, eller lignende?

Enkelt forklart:
La oss si at du oppretter en bruker på ett nettsted med passord: "Mittpassord:" - Da vil nettsiden kryptere dette og lagre det i databasen som feks.: 268fc7334566d0033845f97420a14f6f

Når du da logger på neste gang, så vil den igjen kryptere "Mittpassord" så se om den krypteringen setmmer over ens med det som allerede ligger i databasen.

Så er det over til selve "Hackingen".
Det er hovedsaklig når databasen med de krypterte passordene kommer på avveie. Da kan "Hackerne" bruke denne databasen lokalt, genere mange tusen passord i sekundet (eller bruke store passord-bibloteker hvor krypteringen allerede er ferdig), så sjekker den opp mot innholdet i databasen. Er det match, så vet de hva passordet egentlig er, da de sitter både på krypterte versjonen, og den ukrypterte.

Derfor er det lurt med et langt passord, siden det vil ta ekstremt lang tid for en maskin og prøve forskjellige kombinasjoner når lengden er en viss lengde.

[Chris93]

Strengt tatt så bliri kke passord i databaser kryptert, de blir hashet.

[Merko]

Chris93 skrev (6 minutter siden):

Strengt tatt så bliri kke passord i databaser kryptert, de blir hashet.

 

Jepp, men nå prøvde jeg så godt jeg kunne å forklare det sånn halvveis hvordan det fungerer for "mannen i gata"  

[0laf]

Chris93 skrev (7 minutter siden):

Strengt tatt så bliri kke passord i databaser kryptert, de blir hashet.

Korrekt, ettersom de algoritmene som brukes ikke kan reverseres, det finnes ingen dekryptering.

Rent teknisk hadde det ikke vært noe i veien for å kryptere i stedet for å hashe, men det er unødvendig og mer usikkert, ettersom den som lagrer hashede passord uansett ikke bør ha mulighet til å reversere krypteringen, å da heter det altså hashing.

Det er dog ofte enklere å forklare ting med "kryptering", de fleste forstår det, mens de færreste som ikke driver med utvikling vet hva hashing er.

Endret 22. august 2020 av 0laf

[ITtraktor]

0laf skrev (På 18.8.2020 den 19.34):

Æsj, nå må jeg endre passordet mitt, jeg som har brukt 1234 i flere tiår ?
 

Det som er pussig, er at svært mange tjenester fremdeles krever spesielle tegn, store bokstaver eller lignende i passordet, og at man stadig anbefaler ditt og datt, men ikke anbefaler det aller enkleste, en frase som er lett å huske, men som har uvanlige ord og høy entropi.

Et passord som "Lykka kjæm itj rækan på ei fjøl" har en entropi på nesten 200 bits, og vil være nesten helt umulig å knekke med brute-force, samt at det trolig er like umulig med ordlister.

Enklere varianter, som "Dizzie Tunes er tipptopp" har fremdeles entropi på over 100 bits, og vil være usedvanlig vanskelig å knekke.

Til sammenligning har passord som "X£{|%&(OR0" eller "AF=_ÅA*S""¤" entropi på 40-50 bits, og er nærmest umulig å huske, men er mye lettere å knekke.

Er det ikke litt upraktisk med et passord man bare får ligget inn med med et norsk tastatur?

[Merko]

Ser ikke ut som bildet mitt kom med på forrige side så prøver på nytt. ?

[SuperKrokodille]

Merko skrev (På 22.8.2020 den 23.29):

Jepp, men nå prøvde jeg så godt jeg kunne å forklare det sånn halvveis hvordan det fungerer for "mannen i gata"  

Ai ai den svei gitt?!

Dere sier at en «hash» ikke er reversibel, men på en eller annen måte må det jo være mulig å sjekke et passord opp mot databasen ved nye innlogginger. Men hvis en «hash» snarere er et slags kontrollnummer, slår det meg at man, selv om det sikkert er høyst usannsynlig å slumpe til med noe slikt, vil kunne klare å logge seg inn med et «galt» passord, som har resultert i samme hash som det korrekte passordet.

[Merko]

SuperKrokodille skrev (15 minutter siden):

Ai ai den svei gitt?!

Hvorfor det?

Jeg aner ikke hvilken kunnskap du sitter på, så derfor forklarte jeg det som om "mannen i gata" skulle forstå det. Altså en fult oppegående person, men som nødvendigvis ikke har noe innsikt i det det var snakk om, i dette tilfellet passord kryptering / hashing ol.

[0laf]

SuperKrokodille skrev (52 minutter siden):

Dere sier at en «hash» ikke er reversibel, men på en eller annen måte må det jo være mulig å sjekke et passord opp mot databasen ved nye innlogginger. 

For å ta et eksempel, du går inn på en nettside, og registrer deg.

Du må skrive inn brukernavn og passord.

Brukernavn : SuperKrokodille
Passord : krokodillen

Nettsiden tar deretter passordet du har valgt, legger til et salt, og hasher det.

Salt generes tilfeldig for hver bruker, og ble denne gangen : 84B03D034B409D4E
Passordet + salt = krokodillen84B03D034B409D4E

Dermed hashes det, jeg bruker SHA256 for enkelthets skyld, og man ender opp med :

51B4C9E1EEC598DB46DB268E25E9011FAEDCADADE29B91534492DB0852D6A629

Så lagrer vi dette i databasen :

Brukernavn : SuperKrokodille
Salt : 84B03D034B409D4E
Passord : 51B4C9E1EEC598DB46DB268E25E9011FAEDCADADE29B91534492DB0852D6A629

Legg merke til at passordet du valgte ikke lagres.

Neste gang du besøker denne nettsiden, så skriver du inn brukernavnet ditt, og passordet.
Nettsiden slår opp oppføringen som passer med ditt brukernavn.
Saltet hentes, og legges til det passordet du nettopp tastet inn, som blir

krokodillen84B03D034B409D4E

Dette hashes på nytt, og man ender opp med :

51B4C9E1EEC598DB46DB268E25E9011FAEDCADADE29B91534492DB0852D6A629

Nå kan vi sammenligne den verdien med den vi har lagret i databasen fra tidligere, og dersom de er like, så er passordet riktig, uten at nettsiden noen gang har lagret passordet ditt, eller trenger å "dekryptere" noe som helst.

Dersom noen får tak i databasen, så har de brukernavn, saltet, og et hashet passord.
Det hashede passordet kan åpenbart ikke brukes til å logge inn, ettersom det da ville bli hashet på nytt, med saltet en gang til, å ikke lengre stemme.

Skal inntrengeren få logget inn som en bruker, så må passordet knekkes.

Man må da ta tilfeldige passord, legge til saltet, og prøve seg frem

aaa84B03D034B409D4E = 799183D323F3305D2D6970BEA9D3D6A26403652AAB9C9B4C0E6B858C0F32EC6F (fail)
bbb84B03D034B409D4E = 73DA425AF9AB93C081BF0C33CE0CCC718F60B93EF2E9D5CC4A235D2A48F116F8 (fail)
ccc84B03D034B409D4E = 67BBFB6BA775FFB06F3A893CBF4DF2258484D06E22CEC1C1CA67D217F1FD0787 (fail)
ddd84B03D034B409D4E = 53DA7231B8674DFADDA5DB348F396410C8047A2DBDC0A079FE4851687B908E01 (fail)
.... og så videre ....

inntil man kommer til "krokodillen84B03D034B409D4E", som vil være det eneste passordet som får en hashet verdi som matcher.

Dette gjøres med software, som Hashcat eller lignende, men med en tilstrekkelig treg algoritme, og en middels lang hash, vil det ta årevis, trolig mange tiår med ren brute-force å knekke dette.

Et passordsystem trenger kun å hashe verdiene, altså enveisløsning som ikke har innebygget dekryptering.
Det er ikke behov for en løsning som kan kryptere, og så dekryptere verdiene i et slikt system.
 

Endret 24. august 2020 av 0laf

[SuperKrokodille]

Merko skrev (57 minutter siden):

Hvorfor det?

Jeg aner ikke hvilken kunnskap du sitter på, så derfor forklarte jeg det som om "mannen i gata" skulle forstå det. Altså en fult oppegående person, men som nødvendigvis ikke har noe innsikt i det det var snakk om, i dette tilfellet passord kryptering / hashing ol.

Det var sagt på spøk du .

Jeg vet null og niks om temaer som dette, men det er interessant, da.

 

0laf skrev (25 minutter siden):

For å ta et eksempel, du går inn på en nettside, og registrer deg.

Du må skrive inn brukernavn og passord.

Brukernavn : SuperKrokodille
Passord : krokodillen

Nettsiden tar deretter passordet du har valgt, legger til et salt, og hasher det.

Salt generes tilfeldig for hver bruker, og ble denne gangen : 84B03D034B409D4E
Passordet + salt = krokodillen84B03D034B409D4E

Dermed hashes det, jeg bruker SHA256 for enkelthets skyld, og man ender opp med :

51B4C9E1EEC598DB46DB268E25E9011FAEDCADADE29B91534492DB0852D6A629

Så lagrer vi dette i databasen :

Brukernavn : SuperKrokodille
Salt : 84B03D034B409D4E
Passord : 51B4C9E1EEC598DB46DB268E25E9011FAEDCADADE29B91534492DB0852D6A629

Legg merke til at passordet du valgte ikke lagres.

Neste gang du besøker denne nettsiden, så skriver du inn brukernavnet ditt, og passordet.
Nettsiden slår opp oppføringen som passer med ditt brukernavn.
Saltet hentes, og legges til det passordet du nettopp tastet inn, som blir

krokodillen84B03D034B409D4E

Dette hashes på nytt, og man ender opp med :

51B4C9E1EEC598DB46DB268E25E9011FAEDCADADE29B91534492DB0852D6A629

Nå kan vi sammenligne den verdien med den vi har lagret i databasen fra tidligere, og dersom de er like, så er passordet riktig, uten at nettsiden noen gang har lagret passordet ditt, eller trenger å "dekryptere" noe som helst.

Dersom noen får tak i databasen, så har de brukernavn, saltet, og et hashet passord.
Det hashede passordet kan åpenbart ikke brukes til å logge inn, ettersom det da ville bli hashet på nytt, med saltet en gang til, å ikke lengre stemme.

Skal inntrengeren få logget inn som en bruker, så må passordet knekkes.

Man må da ta tilfeldige passord, legge til saltet, og prøve seg frem

aaa84B03D034B409D4E = 799183D323F3305D2D6970BEA9D3D6A26403652AAB9C9B4C0E6B858C0F32EC6F (fail)
bbb84B03D034B409D4E = 73DA425AF9AB93C081BF0C33CE0CCC718F60B93EF2E9D5CC4A235D2A48F116F8 (fail)
ccc84B03D034B409D4E = 67BBFB6BA775FFB06F3A893CBF4DF2258484D06E22CEC1C1CA67D217F1FD0787 (fail)
ddd84B03D034B409D4E = 53DA7231B8674DFADDA5DB348F396410C8047A2DBDC0A079FE4851687B908E01 (fail)
.... og så videre ....

inntil man kommer til "krokodillen84B03D034B409D4E", som vil være det eneste passordet som får en hashet verdi som matcher.

Dette gjøres med software, som Hashcat eller lignende, men med en tilstrekkelig treg algoritme, og en middels lang hash, vil det ta årevis, trolig mange tiår med ren brute-force å knekke dette.

Et passordsystem trenger kun å hashe verdiene, altså enveisløsning som ikke har innebygget dekryptering.
Det er ikke behov for en løsning som kan kryptere, og så dekryptere verdiene i et slikt system.
 

 

Takk for utfyllende svar, Olaf.

Hvis jeg har forstått deg rett, så oppnår man altså med systemet du beskriver (hash og salt framfor tungt krypterte passord)

a)       Å spare mye datakraft som ellers ville gått med til hele tiden å dekryptere passord ettersom nye brukere vil logge seg på

b)      At hvert «passord» er sikret med unike «salter», slik at om en inntrenger klarer å knekke ett passord, så er alle de andre passordene fortsatt (noenlunde) trygge.

[0laf]

SuperKrokodille skrev (31 minutter siden):

a)       Å spare mye datakraft som ellers ville gått med til hele tiden å dekryptere passord ettersom nye brukere vil logge seg på

Mnja, hvor mye datakraft man sparer vet ikke jeg, men kryptering er en toveis-funksjon, det kan reverseres med dekryptering.

For passord i et slikt system, så er det null behov for dekryptering, i stedet benytter man en enveis-funksjon som ikke kan reverseres.
Det øker åpenbart også sikkerheten når de verdiene som er lagret ikke kan dekrypteres tilbake sin opprinnelige verdi.
 

SuperKrokodille skrev (31 minutter siden):

b)      At hvert «passord» er sikret med unike «salter», slik at om en inntrenger klarer å knekke ett passord, så er alle de andre passordene fortsatt (noenlunde) trygge.

Nja, egentlig ikke, saltet er i hovedsak der for å gjøre det vanskeligere å knekke alle passordene med et system, som regnbuetabeller.
Det blir åpenbart litt mer komplisert når man skal legge til et unikt salt hver gang man skal forsøke å knekke et passord, og lengden på strengen som må hashes for å sammenligne, øker også, som igjen gjør at det tar lengre tid.

Målet er jo egentlig å gjøre det slik at det tar så lang tid, gjerne hundrevis av år, at det ikke er hensiktsmessig å forsøke å finne alle passordene.

Dersom en angriper klarer å knekke ett passord på noen minutter, så hjelper ikke unike salt stort, da vil vedkommende generelt sett klare å knekke resten av passordene på noen minutter også. De unike saltene er lagret i databasen, så det vil egentlig være trivielt å lage et system som henter de inn for hver bruker osv, så de øker ikke sikkerheten nevneverdig, annet enn når ferdiglagde tabeller brukes, som åpenbart ikke kan inneholde unike salt.

Endret 24. august 2020 av 0laf