Populäraste lösenordet år 2023 är "123456"

Känns som att det kommer en sån här nyhet typ en gång i halvåret
Hur kan det fortfarande ha ett nyhetsvärde?

Dessutom inbjuder det till att kracka passworden då att prova igenom alla alternativ på en rad tripletter av tecken och symboler tar inte så lång stund och gör situationen värre än med NTLM/SMB v.1 som åtminstone krypterade passworden i 7 teckens block med DES och med förkompilerade tabeller ala rainbow så kan man återskapa password av en DES-hashning på sekundnivå.

även om man nöjer sig att göra hash av inmatad password utom de sista 3 tecken och de sista 3 tecknen som en egen hash för att detektera uppräkning i slutet av passwordet när den (forcerat) byts så har man med detta rejält försvagat användarens password då den förlorat motsvarande tre tecken i styrka eller knappt 20 bit entropi efter som den sista hashen med 3 tecken räknas inte ens som ett hinder i attacken då bara max 830584 kombinationer (857375 kombinationer om mellanslag också inkluderas i teckensekvensen) behöver provas igenom för att finna en matchande hashvärde och användarens sista 3 tecken i passwordet blir med detta känd.

Har man också en 3-teckens hash för börja och mitten så är det inte mycket kvar av attackmotståndet i användarens password.

Om inte någon trebokstavs byrå sitter och smyger på någon kvant dator, då är det betydligt mindre oknäckbart

Hehe, jo visst, det kan man ju göra. Var lite försiktig med hur du seedar slumpgeneratorn bara, så du inte delar lösenord med 100 000 andra hemmafixare...

Vad jag läst mig till använder random-funktionen i java systemtiden i millisekunder som default-seed, så det ska nog väldigt mycket till att det råkar vara samma som nån annan...

Ja det är väl ett större problem om man skulle jobba med något språk/bibliotek som sätter en konstant seed som default.

Det beror ju lite på hur en sådan implementation av en lösenordsgenerator används och av hur många...

Men oavsett hur stor risken är att man har otur att det blir samma av en slump så kan det ju vara ett allvarligt problem att vem som helst som vet när lösenordet skapades (åtminstone ungefärligt) får en genväg att återskapa det.

I de flesta språk med ett omfattande standardbibliotek så finns dels en lite förenklad slumpgenerator (i stil med vad det *låter som* att du pratar om), som typiskt har ett lite enklare gränssnitt i stil med att ta ett heltal som seed (ofta används just nuvarande tid som standard) och som genererar tal, och en separat slumpgenerator som är lämplig för säkerhetskänsliga ändamål, typiskt med ett gränssnitt som är mer byte[]-orienterat.
I java-sammanhang är det väl SecureRandom som gäller (som väl f.ö. implementerar samma gränssnitt, så ingen stor skillnad för användaren), den seedar sig själv, såvitt jag försår, som standard med data ur operativsystemets slumpkälla (exvis /dev/random) och generar slumpdata som duger till säkerhetskänsliga användningsområden.

Jag undrar varför qwerty inte är med i topp tio längre.

Jag är så fascinerad över att folk tar så allvarligt på lösenord som används för att logga in på nätbutikssidor och liknande, av mig som är en helt ointressant person. Självklart ska man ha supersäkra lösenord för saker som verkligen är skyddsvärda och där man kan anta att nån med kapacitet kan och vill lägga tid på att knäcka dem på det viset. Men mina, kom igen!

Jag bryr mig personligen inte särskilt vilka lösenord du väljer att använda, det jag tänkte var snarare att eftersom du pratade om ditt lilla projekt och att ett potentiellt problem kommit upp i diskussionen och bekräftats(?) så kunde det vara intressant med feedback hur just den aspekten borde fungera för att faktiskt eliminera problemet istället för att förklara bort det. Det är allt.

Bara bokstäver och siffror är väl inte något egentligt problem såvida man får ha långa lösenord. Längden på lösenordet blir snabbt långt mer avgörande...

Sedan är väl hanteringen av kortuppgifter ett kapitel för sig, som i vissa fall borde styras upp helt oavsett lösenordspolicy.