Korta lösenord otillräckliga i GPU-åldern

Håller på med en liten hemsida som ska ha en medlemscommunity så då tänkta jag mig att hanteringen av lösenord kunde se ut så här...

När användaren reggar sig så tilldelas han en "lösenordsarea" som t.ex. är en nummer mellan 1000-9999. Han måste även ange ett extra lösenord som ska användas vid inloggning. Det som görs sedan är att hans riktiga lösenord sparas på plats "lösenordsarea"+extra lösenordet, alltså t.ex. 8001mittextralösenord (som hashas och så)

Tabellen ser ut så här:
Lösenordsnummerkolumn Lösenordskolumn
8001extralösenord (hashat...) lösenord (hashat...)
.....
.....
.....
.....

På användaren sparas "lösenordarean" ner men inte det extra lösenordet. När användaren sedan loggar in så får han då ange sitt lösenord plus extralösenordet. Sen kollas vilken "lösenordsarea" han tillhör och slår ihop det med extralösenordet och kollar i lösenordstabellen om lösenordet för den raden stämmer med det användaren angett.

Med detta sätt kan man inte koppla ett lösenord till användaren utan att ha användarens extralösenord som inte sparas ned i databasen så om en utomstående part skulle få tag på databasen borde användarnas uppgifter inte kunna kopplas till deras lösenord.

Och för att göra det extra krångligt tänkte jag mig att lösenordstabellen innehöll en massa lösenord som slumpats fram, t.ex. att när nån reggar sig så för den aktuella "lösenordsarean" som användaren får så skapar man säg 1000 nya lösenord som utgår från de lösenord som användaren angett.

Nån som förstår hur jag tänker och kan komma med synpunkter på om idén funkar eller om det bara är dumt att göra så?

Som de övriga har nämnt, så innebär det högre säkerhet. Mängden lösenord mellan 0-7 bokstäver är ordningen O(28^7). Att dubbla längden ger givetvis en mängdstorlek (och därmed en komplexitetsökning) på O(28^7)^2. Om man vet att det kan vara ett upprepat lösenord (vilket är ett rimligt antagande för en attackerare!), kan man prova först de O(28^7), sedan de upprepade i mängden. Detta innebär endast en ökning med en faktor 2, alltså O(2*28^7). En lösning vore då att upprepa lösenordet, men lägga till en ny bokstav i slutet.

Detta bevis kommer väldigt sannolikt inte att accepteras. Bevismetoden att reducera till random k-SAT är en möjlig metod för att nå ett bevis i framtiden dock, även om självaste Terrence Tao avfärdar det som osannolikt.

Jag skulle också tro att beviset är förhastat, men som sagt spelar det ingen roll i praktiskt hänseende.

Misstänker att här lagras lösenorden i klartext även om det känns pinsamt. De bör åtminstone lagras krypterade och i skilda tablespace. De blir lite svårare då, det behövs 2 databaser för att komma åt allt. Även key och forign key mellan tabellerna ska inte gå att se i klartext.

Kör en del guild war och där har för ett tag sedan många konton blivit hackade. Någon/några hade fått tag på en fil med mailkonto och tillhörande lösenord. Det gick så långt att ncsoft gick ut med en vädjan att alla bör byta lösenord snarast möjligt. Klarade mig för min del men det var många som blev av med sina konton eller fått innehållet länsat.