Gå til innhold

Dette monsteret finner passordet ditt


Anbefalte innlegg

Hashcat som ble brukt?Knekking av Windows-passord er jo bare tull. Mye lettere å gå forbi hele passordbeskyttelsen med eksempelvis Kon-boot.Skulle likt å sett maskinen knekke WPA2-hasher med Pyrit.

Skulle gjerne også sett hvordan krypteringsprgrammer som Truecrypt og LUKS klarer seg, og også private PGP og SSH nøkler. Bruker en PGP nøkkel med 8 tall/bokstaver passord for å kryptere noen ting, ser ut som at jeg er i faresonen..

Endret av fa2001
Lenke til kommentar
Videoannonse
Annonse

Hjelper ikke med 1 sekk sperre eller max X forsøk.

For å finne ut om det er rett passor trykker ikke masninen enter, den finner det ut i binære bekreftelser fra OS lenge før det.

Lyst å utdype denne litt? Gjerne med et eksempel og en kilde eller to. Det er da virkelig mulig å implementere ventetid uavhengig hvordan kallet gjøres. Det bør ikke være et annet kall brukt mot sjekk om man trykker enter eller bruker et API direkte..

Lenke til kommentar

Lyst å utdype denne litt? Gjerne med et eksempel og en kilde eller to. Det er da virkelig mulig å implementere ventetid uavhengig hvordan kallet gjøres. Det bør ikke være et annet kall brukt mot sjekk om man trykker enter eller bruker et API direkte..

 

Det finnes 2 mulige brute force angrep: online og offline.

Online: du har ikke kontroll over hele systemet, du må snakke med et annet system (f.eks. en webserver eller en domenekontroller) for å sjekke om passordet er riktig. Serveren kan da begrense hastigheten.

Offline: du har all informasjon om systemet bortsett fra at du ikke vet passordet. Det er f.eks. relevant hvis det ligger en kryptert fil på PCen. Du kan prøve passord så fort som PCen klarer å jobbe. Eksempelet over er at Windows bare lagrer hash for passordene, og man prøver å finne passordet som hører til hashen. Det kan være nyttig hvis du på en eller annen måte har fåt tilgang til filen med hasher, men ikke har fysisk tilgang til harddisken, eller prøver å logge på et annet system som har samme passord. [Oppdatert: Jeg tror også det er noen feil i login protokollen for Windows som gjør at hashen sendes over nettverket, så man trenger bare å plukke opp trafikk fra en bruker som logger seg inn på et domene, så kan man kjøre et offline attack på den hashen ]

 

Oppdatering 2: Det er derfor man bør bruke lange passord for full-disk kryptering, som man alltid kan bruke offline angrep på (kansjke begrenset av TPM). For nettbanken er det nok med 8 bokstaver, for de begrenser hvor fort/mange ganger man kan prøve. Hvis noen hacker banken og stjeler hashene er det en fordel å ha lange passord.

 

Det finnes måter å gjøre offline angrep tregere: f.eks. hvis du hasher passordet 100 ganger, må hackeren også gjøre det for å se om det er riktig. F.eks. du starter med et passord, hasher det, hasher hashen osv. osv. 100 ganger.

Endret av fa2001
  • Liker 1
Lenke til kommentar

Men det vil igjen kreve at "Hackeren" er fysisk tilstede ved din stasjonære, laptop etc.

noe som igjen gjør Kon-Boot til et bra værktøy siden du bypasser all login authentication oppføringer ved å erstatte dem med dummy filer under Boot prosessen. det er disse oppføringene som blir erstattet under boot som gjør at maskinen ikke vil kreve passord. men programmet vil stå ubrukelig for remote hacking.

for at det skal kunne virke remote må du kunne først infisere maskinen med en virtuell CDRom/USB port som skal stå som default under start og maskinen må kunne "Boot from NIC" noe som står etter min erfaring default avslått i BIOS.

Men får du til alt dette, og tilfeldighetene liner seg opp i din favør kan du bare ta kontroll over maskinen med noe så enkelt som forced teamwiever ol. (hvis det er kontroll over maskinen som er målet)

Ser absolutt poenget ditt, men kan for eksempel legge inn en skjult grub4dos bootloader som prioriterer konboot kontra chainloading av bootmgr på kommando. Vet ikke helt hvorfor dette skulle være ønskelig da man allerede har kontroll over maskinen, med mindre man trigger en restart fra en passordlåst og idle maskin.

Lenke til kommentar

Standardpassordet mitt er over 55 karakterer langt og inneholder bokstaver og tegn, så da burde jeg vel føle meg trygg litt til?

Ikke om du bruker samme passord på mer enn 1 tjeneste.

 

Scenario: jeg lager en nettside der du må lage en bruker med e-post og passord. Jeg kan da prøve samme e-post og passord på veldig mange tjenester. Trolig vil det virke noen plasser. Evt. har man tjenester som LinkedIn osv. som lekker passordet ditt med dårlig eller ingen hashing.

Endret av Matsemann
Lenke til kommentar

Et par feil:

 

Dette får Microsofts NTLM-algoritme, som har vært i bruk siden Windows Server 2003, til å skjelve i buksene. Serveren, med sine 25 AMD Radeon-grafikkort, vil med andre ord lage hakkemat av Windows-baserte arbeidsmiljøer – så lenge passordene er korte nok, vel å merke.

NTLM har vært i bruk siden NT4.

 

I løpet av under seks timer vil klyngen ha gått gjennom 6,6 billiarder kombinasjoner. Det er nok til å ha sjekket hvert eneste passord på åtte tegn, inkludert store og små bokstaver, tall og symboler.

 

Om du bare legger til ett ekstra tegn (ni tegn totalt), vil det plutselig ta opptil 500 timer å finne riktig kombinasjon. Med ti tegn stiger dette dramatisk til nesten 5,5 år.

Dersom det tar 500 timer eller 5.5 år å hashe hele nøkkelrommet vil det i gjennomsnitt ta 250 timer og 2.75 år å finne riktig kombinasjon.

Lenke til kommentar

Øvde oss på AP-stjeling av passord på skolen, jeg fikk alle passordene og brukernavn på 20 sek.

De andre fikk 2-3 på 1 time.

 

Det viser seg å ta ut og inn strømmen til ap så alle må koble seg opp igjen har sine fordeler.

 

Det bør ikke være et annet kall brukt mot sjekk om man trykker enter eller bruker et API direkte.

Når du skriver inn en produktnøkkel så vips er pila grønn uten at du har trykket enter og evt brukt et forsøk.

Det er ikke så lett å blokke for eks HTTP brute-force-verktøy.

Med en lang liste over åpne proxyservere vil hvert angrep komme med unik IP-adresse.

Ofte er det også forskjellige brukernavn og passord for hver gang det prøves.

 

Man kan legge inn blokkering som vil gjøre det værre men da kan man som BF-angriper stenge tusenvis av kontoer på gøy, og man kan ikke stenge kontoer som ikke finnes og dermed kan man samle inn gyldige kontoer som man kan lage en liste over.

Siden man da stenger tusen kontoer så blir help-desk nedringt og da har man skapet scene man kan utnytte.

Man kan jo også kjøre BF hele tiden så når admin åpner kontoen så stenger den igjen og da har man makten til å sette en helt konto ute av spill. Det finnes også slow-attacks som prøver noen få ganger i timen, disse kan komme igjennom på lettere passord.

Det finnes også en måte som prøver ett passord i en hel liste av brukervavn, disse vil slippe inn.

Adminkontoer er ofte unntatt forsøkskvote og disse kontoene er enda mer verdifull å bryte seg inn i.

 

 

Alle tiltak vil ha en rekke svakheter.

Lenke til kommentar

Øvde oss på AP-stjeling av passord på skolen, jeg fikk alle passordene og brukernavn på 20 sek.

De andre fikk 2-3 på 1 time.

 

Det viser seg å ta ut og inn strømmen til ap så alle må koble seg opp igjen har sine fordeler.

 

 

Når du skriver inn en produktnøkkel så vips er pila grønn uten at du har trykket enter og evt brukt et forsøk.

Det er ikke så lett å blokke for eks HTTP brute-force-verktøy.

Med en lang liste over åpne proxyservere vil hvert angrep komme med unik IP-adresse.

Ofte er det også forskjellige brukernavn og passord for hver gang det prøves.

 

Man kan legge inn blokkering som vil gjøre det værre men da kan man som BF-angriper stenge tusenvis av kontoer på gøy, og man kan ikke stenge kontoer som ikke finnes og dermed kan man samle inn gyldige kontoer som man kan lage en liste over.

Siden man da stenger tusen kontoer så blir help-desk nedringt og da har man skapet scene man kan utnytte.

Man kan jo også kjøre BF hele tiden så når admin åpner kontoen så stenger den igjen og da har man makten til å sette en helt konto ute av spill. Det finnes også slow-attacks som prøver noen få ganger i timen, disse kan komme igjennom på lettere passord.

Det finnes også en måte som prøver ett passord i en hel liste av brukervavn, disse vil slippe inn.

Adminkontoer er ofte unntatt forsøkskvote og disse kontoene er enda mer verdifull å bryte seg inn i.

 

 

Alle tiltak vil ha en rekke svakheter.

 

Hvordan løser dere problemet med Captcha ved 3 feil på samme konto, uansett IP, og blokkering etter 10 feilede forsøk på rad (på kryss av alle kontoer) fra én IP-adresse?

 

(Altså: Om 3 separate IP-adresser feiler å logge på én og samme konto og feiler, så blir Captcha aktivert på den gjeldende kontoen. Om én IP-adresse forsøker å logge på og feiler, logges feilforsøket på IP-adressen, og du får maks 10 feilforsøk per time, 20 per dag, 50 per måned og 100 per år.)

Lenke til kommentar

[snip]

Mye mulig det er et hull i Windows som tillater dette, men innlegget til War ga ingen spesifikk informasjon om hva det var snakk om. Er dette virkelig tilfellet så er det en designfeil, det er helt klart mulig å implementere en løsning som kan sette en stopper mot bruteforcing i form av delay på serversiden.

 

Derfor blir det feil å si at det ikke hjelper å ha delay, når det kun ikke hjelper om det er en åpenbar designfeil. Om noe burde det blitt spesifisert hvilken løsning det gjaldt.

 

Ingen XKCD referanse ennå? Denne passer bra i denne diskusjonen.

http://xkcd.com/538/

Denne og/eller denne blir nesten postet hver eneste gang noen diskuterer passord. Tror folk begynner å bli litt smålei den nå, i alle fall er jeg det.

Endret av Occi
Lenke til kommentar

Hvorfor legger man ikke bare inn en tidssperre på 1 sekund etter man har skrevet feil passord? Det burde være en effektiv stopper mot slike maskiner.

 

En ting er et påloggingspassord, som kan ha en forsinkelse, samt kanskje 5 forsøk og du må vente 5 minutter for å gjøre 5 nye forsøk, eller liknende. Noe annet er om du har en kryptert fil med et kort og dårlig passord, da kan sikkert en slik maskin skure på og finne passordet ganske kjappt.

Lenke til kommentar

Hvorfor legger man ikke bare inn en tidssperre på 1 sekund etter man har skrevet feil passord? Det burde være en effektiv stopper mot slike maskiner.

 

Du må vel ha missforstått noe. Den tester ikke passord opp mot en webside, dette vil jo kreve at de sender data frem til websiden, og venter på respons. Det eksisterer rett og slett ikke nok båndbredde for å sende så mange pakker i sekundet over nettet.

 

En bokstav er ofte rundt 2 byte, - det vil si 8 bokstaver = 16 byte. Overføring av 8 bokstaver krever da 16 byte av din båndbredde. Skal du nå sende 350 milliarder kombinasjoner til serveren på ett sekund vil dette bruke ca 44800Gbit/s båndbredde. I tilegg så må brukernavnet overføres. Så da nermer vi oss fort 100,000Gbit/s...

 

Dette er da om tegnene var bare 2 byte, dette er absolutt minimum når en snakker om tegn, bokstaver og tall. - kommer ann på hvordan bokstavene er encodet. I tilegg så er det masse annen data som skal overføres, og hentes bare for å skrive et passord og brukernavn på en webside.

 

Sikkerhetsrissikoen er om de får tilgang til de kypterte passordene i databasen til websiden, da kan de løse krypteringen med rå brute-force, så lenge hvor passordet ikke er lengre en 9 tegn da.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...