Besserwisser
· Västra Götalands
· 11 210 inlägg
Kan bara instämma. Frågan är hur det klarar att komma ur sängen om mornarna. 
Hmm, fast Lars, du måste erkänna att RT är begränsade i längden lösenord de kan knäcka. Tex pm jag sätter ett lösenord med 20 tecken :hejsanmigkanduinteta. Så kan den hashen hackas med en RT som är skapad på upp till 15 tecken (azAZ etc) medans ett lösenord :aSnl(9@"6aa går att ta med den tabellen (om alla tecken ingår i RT'n).
Annars har jag helt missförstått det hela. Länka gärna till en sida (inte avhandlingen tack) där det beskrivs hur man hackar lösenord med baserade på fler tecken än RT är genererad med.
(9@"6aa går att ta med den tabellen (om alla tecken ingår i RT'n). Annars har jag helt missförstått det hela. Länka gärna till en sida (inte avhandlingen tack) där det beskrivs hur man hackar lösenord med baserade på fler tecken än RT är genererad med.
Besserwisser
· Västra Götalands
· 11 210 inlägg
Hej, nej det är trivialt riktigt. Men det spelar som sagt ingen roll, eftersom längden på nyckel osett entropi anpassar försvaret till ett specifikt angrepp (ja dvs, tom bara en parameter hos ett specifikt angrepp) som är enkelt att göra starkare. (Som man säger på NSA; "Kom ihåg, angrepp blir bara bättre, de blir aldrig sämre").
Om du har en nyckel med tillräcklig entropi (mätt i antal bitar) så spelar det *ingen roll* om det är kort eller långt (dvs faller över eller under en viss längdgräns) eftersom det inte kommer att finnas i någon rainbow-table (eller annan knäckningsmekanism) ändå. Vi kan inte generera en fullständig tabell/genomsökning över/av alla möjliga 128-bitars hashvärden (som behövs för en pre-image attack), kunde vi det så hade hela övningen varit meningslös, utan man måste ändå välja vilka tänkta lösenord man vill stoppa in i sin tabell/pröva och då är de de med låg entropi som ryker.
Som jag sagt tidigare, om du envisas med att ett dåligt lösenord/nyckel (dvs med låg entropi) är säkrare mot angrepp med en rainbow-table idag om det är långt hellre än kort så är det riktigt. Men egentligen inte så intressant, eftersom det är trivialt att ändra sina rainbow-tables s.a. de också kommer att innehålla det långa (lågentropiska) lösenordet. Detta kommer garanterat att hända i framtiden eftersom lagringsutrymme och processorkraft stadigt ökar.
Nu spelar det som sagt liten roll, eftersom ett skydd mot rainbow-tables är trivialt (saltning) och i fallet WPA så har man ändå en starkt begränsad maximal längd, så man måste göra det bästa med det man har.
Om du vill veta mer om ämnet så håller vi två alldeles utmärkta kurser i kryptografi här på BTH; vi har hittat en riktig matematiker som kursansvarig, istället för jag själv, som bara låtsas vara det på jobbet. (Rainbow tables tar jag dock själv upp i min kurs.)
Så, ingen länk till någon avhandling, jag skrev än istället... Om du vill veta mer så föreslår jag att du sätter dig in i entropibegreppet som det tillämpas inom kryptografin, eller frågar så skall jag förklara efter bästa förmåga.
P.S. Och det är "Stefan", inte "Lars".
Om du har en nyckel med tillräcklig entropi (mätt i antal bitar) så spelar det *ingen roll* om det är kort eller långt (dvs faller över eller under en viss längdgräns) eftersom det inte kommer att finnas i någon rainbow-table (eller annan knäckningsmekanism) ändå. Vi kan inte generera en fullständig tabell/genomsökning över/av alla möjliga 128-bitars hashvärden (som behövs för en pre-image attack), kunde vi det så hade hela övningen varit meningslös, utan man måste ändå välja vilka tänkta lösenord man vill stoppa in i sin tabell/pröva och då är de de med låg entropi som ryker.
Som jag sagt tidigare, om du envisas med att ett dåligt lösenord/nyckel (dvs med låg entropi) är säkrare mot angrepp med en rainbow-table idag om det är långt hellre än kort så är det riktigt. Men egentligen inte så intressant, eftersom det är trivialt att ändra sina rainbow-tables s.a. de också kommer att innehålla det långa (lågentropiska) lösenordet. Detta kommer garanterat att hända i framtiden eftersom lagringsutrymme och processorkraft stadigt ökar.
Nu spelar det som sagt liten roll, eftersom ett skydd mot rainbow-tables är trivialt (saltning) och i fallet WPA så har man ändå en starkt begränsad maximal längd, så man måste göra det bästa med det man har.
Om du vill veta mer om ämnet så håller vi två alldeles utmärkta kurser i kryptografi här på BTH; vi har hittat en riktig matematiker som kursansvarig, istället för jag själv, som bara låtsas vara det på jobbet.
(Rainbow tables tar jag dock själv upp i min kurs.)Så, ingen länk till någon avhandling, jag skrev än istället...
Om du vill veta mer så föreslår jag att du sätter dig in i entropibegreppet som det tillämpas inom kryptografin, eller frågar så skall jag förklara efter bästa förmåga.P.S. Och det är "Stefan", inte "Lars".
Ok (Stefan ) då är det som jag trodde? Hashar (exvis cached credentials på Windows maskiner tex) blir svåra att knäcka genom att tex :
Använda 'långa lösenord'
Använda lösenord med 'osannolika' tecken så de inte finns med i RT'n
Nu är det som du säger trivialt, är bara insatt i Windows världen och där kan man ju alltid köra med 'passing the hash' om man väl har hashen...
) då är det som jag trodde? Hashar (exvis cached credentials på Windows maskiner tex) blir svåra att knäcka genom att tex :Använda 'långa lösenord'
Använda lösenord med 'osannolika' tecken så de inte finns med i RT'n
Nu är det som du säger trivialt, är bara insatt i Windows världen och där kan man ju alltid köra med 'passing the hash' om man väl har hashen...