AI knäcker de vanligaste lösenorden på under en minut

"AI" password-styrkeräknaren är helt menlös och verkar bara räkna entropi per tecken ala javascript lokalt på browsern.

]r)qrWCmB 2 veckor
]r)qrWCmBt 5 år
]r)qrWCmBtr 356 år
]r)qrWCmBtrp 30000 år
]r)qrWCmBtrpq 2 miljoner år

gav samma resultat som del av passfras

"dust-bageri-n" för 2 miljoner år

dvs samma resultat vid 13 tecken och samma tendens vid färre tecken.

en 3-ords passfras ur en alfabete av 7776 ord knäcks fullständingt (100% av räknerymnden) med brute force på mindre än halv sekund vid 1000 miljarder tester i sekunden - den behöver hjälp av rätt mycket keystretching innan det är starkt nog

kör man 6 ord i passfrasen så räcker det i 3500 år utan keystretching
kör man 6 ord+1 tecken så är det 27 miljoner år - så attacktiden eskalerar väldigt fort upp med antalet ord i passfrasen - så länge de är framslumpade...

Du har precis beskrivit hur ai utför en brute force attack

Ditt missförstånd ja, en ordboksattack är en brute force attack, AI assisterad eller inte. Du behöver fortfarande verifiera varenda försök. Så attacken förutsätter att det inte finns någon begränsning på antal loginförsök, eller att databasen som är helt osäkrad har hamnat i fel händer.

Om man väljer orden helt slumpmässigt så är just AI inte till någon hjälp. Med fyra ord valda slumpmässigt från en lista av de 2000 vanligaste orden så blir det fortfarande 2^44 bitar entropi. Om du däremot väljer 4 ord med något slags samband (som du kanske tror bara du tänker på), ja då finns det viss risk att en vältränad AI kan hitta det sambandet och reducera entropin avsevärt.

Det som stod i det föregående inlägget, men för att förtydliga.

Om lösenordet bara används på en tjänst, så spelar det ingen större roll om det är lätt eller svårt att knäcka från en kopia på hashade lösenord.
Tjänsten i fråga är ju redan körd, och är lösenordet unikt påverkar det inte andra siter.

Nej för du har inte 1% chans att vinna på lotto, sannolikheten att få 7 rätt är 1 på 6.724.520. Så den förväntade vinsten vs. kostnaden har redan lämnat byggnaden för länge sedan och hela den här grejen med att inte behöva dela vinsten med andra spelar ingen som helst roll. Och ska du täcka tillräckligt med lottoserier för att ha en statistisk chans till garanterade vinst så måste du täcka in alla de nummer som din AI avråder ifrån ändå för de har exakt lika stor chans till vinst som alla andra nummer och väljer du bort dem så väljer du också bort vinstmöjligheter.

Problemet är ju bara att många använder samma lösenord på mer än ett ställe.

Det finns många fler lotterier än det du avser, jag gav ett hypotetiskt exempel för att illustrera en poäng. Du har rätt i att det vanligtvis är irrationellt att investera i lotter för att maximera sin vinst, men OM man insisterar, så är det bättre att satsa på sifferserier man delar med så få andra som möjligt.

Ja, det är problemet. Men den intressanta poängen som @ajn gör är att OM man har unika lösenord överallt, så är styrkan på lösenordet i sig mindre viktig.

Använd med fördel citatfunktionen, så att det blir tydligt vad som åsyftas.

Jag tänker att det spelar roll ändå, ty jag tänker att användarnamn och lösenordshashar kan läcka utan att tjänsten som helhet nödvändigtvis är komprometterad.

Det finns ganska mycket olika siffror därute.
Men just 8 tecken testas extra mycket. Det är nämligen väldigt vanligt med 8 tecken långa lösenord så det är av extra stort intresse.

https://wccftech.com/multiple-nvidia-geforce-rtx-4090-gpus-ca...

Det verkar gå att testa alla kombinationer med 95^8 (alltså lite fler specialtecken) på ca 6-7 timmar med ett RTX 4090.
Så antal testade lösenord per sekund är en hel del högre än en miljon per sekund .

Det man testar mot är hashar i läckta databaser - yes.

PBKDF2-HMAC-SHA256:             :  9473.2 kH/s (typisk vid inloggningar mm.)

Hum. Är inte poängen med PBKDF2 att det ska ta lång tid per hash? Att den klarar nästan 10 miljoner per sekund är ju galet. Jag trodde det skulle ligga under långt, långt lägre. Som i åtminstone 10 000 gånger lägre, egentligen mer.

Ja tills deras löenord läcker, då har man hur många försök som helst. 😬

Man itererar ett antal gånger med rehashes innan en färdig hash ut i PBKDF2, Veracrypt kör också med PBKDF2 men också mycket högre iterationsvärde och i flera led och därför långsammare per färdig slutlig hash.

Sedan skall man komma ihåg att dessa riggar jobbar kanske tusentals gånger snabbare än en ordinarie dator samt att när tillämpningarna införs så kör man med den tidens acceptabla fördröjning med antal itereringar och 10 år senare så behöver man typ 10-dubbla värdet för samma tidsåtgång.

Grundproblemet är att man använder Hash som per design är tänkta att hantera data snabbt - som tex när du vill ha en hash-värde av din 256 GB stora diskimage-fil - och använder samma hash-algoritm för att tugga en användares 12 teckens lösen...

Och att det är extremt jobbigt att verifiera en ny hash-algoritm då dessa i regel inte kan bevisas matematiskt.

SHA1 kunde man bevisa svagheter först efter man kört extremt mycket data på den och visar problem med den interna strukturen, och man är orolig att del av strukturproblemen eventuellt ärvts vidare in i SHA2-serien - därför finns också SHA3-seriern (Kecac) med helt annan design och inte har någon släktskap med SHA1 och SHA2 i sin innermekanik. BLAKE2 var också en av kandidaterna för SHA2 på sin tid men anses inte riktig lika kryptografiskt säkert som algoritmen bakom SHA2 utan att det är bevisat, men mycket snabbare och används gärna för tex. hashvärden av sektorblock i tex. filsystem (som alternativ hash i BTRFS) och program som jämför filer (tex. rmlint)

I linux börjar man numera inte ha fasta itereringsvärden för använda hash då de blir snart utdaterade (alltså för lågt värde) - utan bygger på att man mäter hur många cykler man hinner med på säg en sekunds fördröjning i systemet man kör på och sedan stoppar in det i systemet som LUKS-crypt (diskryptering) eller inloggningen i själva linux. - och det kan bli lite snopet om man lägger upp sin LUKS-crypt-volym på sin värstingdator - och använder filsystemet senare på en RPI där man upptäcker att man hinner med ett varv på muggen från att man lägger in lösen tills volymen öppnar.

och veracrypt skall man inte tala om man inte höll reda på vilken lösen man hade och skall prova igenom en uppsättning där någon av dem är den rätta - och det ger 30-90 sekunder per prov på äldre dator och då oftast på 90 sekunder om det är fel (jo, jag har också varit där)...

ganska dumt när man missar att det inte fungerar

Problemet är bara att jag har sett denna teori presenterad förr som ett faktiskt tips. I vanliga lotto så går du back betydligt mer än 55 öre på varje satsad krona, snarare X antal tusen kronor på varje satsad krona. Ska man sen bara använda siffror som är högre än 31 så har man ju dessutom exkluderat 89% av alla vinstlotter så du kan vi nog prata om X antal hundratusen i förlust per investerad krona.

Fast alla lotterier baseras ju på samma system för huset vill ju definitivt inte förlora så de har ju alla en vinstchans ala 1 på X flera antal miljoner, tom så att den form av lotto som är mer vanlig utomlands, dvs 6/49, har sämre vinstchans än de 7/35 som vi har i Sverige. Ska man följa det mönster som jag först citerade så exkluderar man 89% av alla vinstlotter så nej det är definitivt inte bättre att satsa på sifferserier man delar med så få andra som möjligt för dina vinstchanser dalar ner i närheten av negativ oändlighet (och det från redan dåligt startläge).

Japp och inget som jag öht bestred, personen som först svarede på @ajn gjorde det misstaget ja, men det var en annan person än mig, jag bara råkade svara på @ajn:s svar mot honom utan att ha sett ursprungskommentaren där det framgick att @ajn mycket väl visste om detta.

Jo men du får ju jämföra det med vad den ersätter. Dvs PBKDF2-HMAC-SHA256 med 9473.2 k/s ersätter ju en ensam SHA256 på 23012.1 M/s, dvs PBKDF2 har här gjort hashen 2429ggr långsammare. Dvs tanken är inte att den ska vara just långsam utan att den ska vara långsammare utan att man ska kunna snabba upp med mha parallellism.

Verkar som jag är ganska säker på den fronten iaf! 😜

"An AI would need about
6 quadrillion years
to crack your password"