To tredjedeler av alle nettbrukere kan være rammet

[Kahuna]

Da bør du nok gjøre matten. Som sagt med grunnleggende spesialtegn gir 11 tegn (som ikke er et sterkt passord!) entropi på 73 bit ~ 9.444732966×10²¹, mens fire tilfeldige ord fra 170000^4 = 8.3521×10²⁰ ~ 70 bits entropi.

Legg merke til at i xkcd-stripa opererer man ikke med 11 helt tilfeldige tegn men med 11 tegn som er bygget opp etter et kjent metode og det reduserer entropien vesentlig. Så lenge man har brukt flere tiår på å lære folk at dette er måten å bygge passord på så vil det være en svært nyttig forenkling for de som driver og brute-forcer hash-filer..*

 

 

Nå vil jeg si at et godt passord har over 128 bits entropi, som betyr 20 tilfeldige tegn eller 8 ord fra 170.000 eventuelt 9 fra en på 20.000 ord (mer realistisk). 9 ord på gjennomsnitt 5 tegn gir hele 45 bokstaver i passordet før det er akseptabelt.

Så snakker vi om to forskjellige typer passord. Maskin-til-maskin passord bør være så lange og komplekse som overhodet mulig. Menneske til maskin passord er derimot begrenset av vår begrensede evne til å håndtere dem. Et 4-ords passord vil ha ca samme styrke som 8 helt tilfeldige karakterer, (komplekst karaktersett) men fortsatt være enklere å håndtere 'manuelt'.

 

 

 

*Det med brute-forcing av passord-hash er en øvelse for spesielt interesserte og ikke noe vanlige brukere skal ta hensyn til. Så lenge man sørger for å bruke unike passord må man bare gå ut fra at nettjenestene har gjort visse sikkerhetsforanstaltninger som å begrense antall påloggingsforsøk i sekundet..

[Emancipate]

gå ut fra at nettjenestene har gjort visse sikkerhetsforanstaltninger som å begrense antall påloggingsforsøk i sekundet..

Tilbake til det egentlige temaet i tråden: jeg stusset over det at exploiten bare kunne kjøres igjen og igjen for å hente ut mer data. Burde de ikke hatt et filter som begrenset antall tilkoblinger per ip-adresse per tid slik at dette ikke kunne skje?

[TheKims]

Regner med at jeg er trygg. Bytte passord på alle sidene blir jo bare knot. Klarer akkurat å huske alle passordene jeg har nå.

Endret 10. april 2014 av KimWhinesAlot

[endrebjo]

 

gå ut fra at nettjenestene har gjort visse sikkerhetsforanstaltninger som å begrense antall påloggingsforsøk i sekundet..

Tilbake til det egentlige temaet i tråden: jeg stusset over det at exploiten bare kunne kjøres igjen og igjen for å hente ut mer data. Burde de ikke hatt et filter som begrenset antall tilkoblinger per ip-adresse per tid slik at dette ikke kunne skje?

 

Poenget med Heartbeat-utvidelsen er å holde tilkoblingen åpen, aktiv og oppdatert ved å sende litt data innimellom. Dermed kan det bli litt bakvendt å sette en lav begrensning på hvor ofte pollingen kan skje.

Og selv hvis en angriper kan polle hvert eneste sekund (som egentlig er veldig tregt i nettverkssammenheng) i flere år kan det hentes ut store mengder data. Det største problemet er forøvrig å skille dritt-data fra verdifull data, sortere dette og få brukt det til noe "fornuftig". Selv om et menneskeøye klarer å spotte en kryptonøkkel innimellom masse tulledata, så betyr det ikke at det er like lett for en datamaskin. Vi tenker på fundamentalt forskjellige måter.

[anders iver]

Edit: way too late, denne hadde visst vært åpen en stund ja..

Endret 10. april 2014 av anders iver

[Emancipate]

 

 

Poenget med Heartbeat-utvidelsen er å holde tilkoblingen åpen, aktiv og oppdatert ved å sende litt data innimellom. Dermed kan det bli litt bakvendt å sette en lav begrensning på hvor ofte pollingen kan skje.

Takk.

 

 

Det som slår meg når jeg leser koden er at den er lett å lage trøbbel for seg selv med. F.eks. en macro som er definert sånn:

 

#define n2s(c,s) ((s=(((unsigned int)(c[0]))<< 8)| \
(((unsigned int)(c[1])) )),c+=2)

uten den ringeste kommentar på hva den skal gjøre. Macro med side-effect i såpass sikkerhetskritisk kode virker rimelig dumt rett og slett. Eller har de en drivende god grunn til det?

Den gamle koden bruktes også magic numbers for å kalkulere bufferlengden på svaret (3 + payload + padding), hva er 3? Jo, 1 byte for en ting, og 2 byte for noe annet, som han bare har lagt sammen i hodet, og det skal folk tankelese ti år etterpå. Hvordan er det mulig at noe sånt kryper inn i sikkerhetskritiske systemer?

[0stepop]

 

Det som slår meg når jeg leser koden er at den er lett å lage trøbbel for seg selv med. F.eks. en macro som er definert sånn:

#define n2s(c,s) ((s=(((unsigned int)(c[0]))<< 8)| \
(((unsigned int)(c[1])) )),c+=2)

n2s makroen trenger, strengt tatt, ingen kommentar, da alt den gjør er å ta vare på 2 bytes (pakker dem) i en (i dette tilfellet) unsigned og deretter flytter pekeren "c" 2 typeposisjoner frem. Helt standard binær operasjoner. Fordelen med denne makroen er at du ikke trenger å spesifiere typene til "s" og "c". Noe som er bedre løst med templates i c++.

 

De magiske tallene og den dårlige navngivingen er på ingen måte bedre enn før, helt enig. Og hører absolutt ikke hjemme i en så viktig kode som OpenSSL.

 

Men essensen i fiksen er sanity checkingen som ikke var der før. Helt hårreisende dårlig kode, både før og etter.

[AlC0]

 

Endret 12. april 2014 av AlC0