I dessa osäkra tider med att spara lösenord... Kan man göra så här?

Det du troligen är ute efter kallas för salt på fikonspråk.

Här finns lite bra info: Skydda dina användares lösenord med hashfunktion och salt.

Nja, salta gör jag också men vad jag förstått så ska det gå att knäcka sånt med. Jag är mer ute efter att göra det helt omöjligt för någon att koppla ihop lösenorden med användaren, lösenorden skulle kunna stå i klartext om man så vill eftersom man ändå inte kan koppla ihop dom med sin användare. Men jag vet inte om min idé är nåt att satsa på, kanske finns kryphål i den...

hashfunktion(global_salt + user_salt + user_name + secret_password) ?

Fast du behöver kanske inte krångla till saker. Om du nu inte vill att man ska kunna koppla filkonton till vanliga användarkonton (?) kanske det vore en idé att generera slumpmässiga kontonummer till användarna och ha hela filarean helt separat från de vanliga kontona efter att ett konto har skapats?

Hmm, vet inte om vi pratar om samma saker men gör en mer utförlig beskrivning för hur jag tänker...

Jag har en tabell för användaren, typ:
Id.................Användarnamn....
1..................Kalle...
2..................Sune...

Och en tabell för lösenorden:
Id.................Lösenord.............AnvändarId
1..................Kallekula..............1
2..................Sunesjul..............2

Men nu vill jag ta bort kopplingen mellan tabellerna, alltså AnvändarId i lösenordstabellen, för att på så sätt göra det omöjligt för en utomstående part att ta reda på Kalles lösenord även om dom skulle komma över databasen och alla applikationsfiler med mera. Så då tänkte jag mig följande för lösenordstabellen:

Id...............Lösenordsnummer..........Lösenord
1................1234Kallesextralösen......Kallekula
2................1234Sunesextralösen.....Sunesjul

Och tabellen för användarna:
Id.................Användarnamn....Lösenordsarea
1..................Kalle.................1234
2..................Sune.................1234

Då finns det ju ingen direkt koppling mellan användartabellen och lösenordstabellen utan det som görs när någon loggar in är att man kollar vilken lösenordsarea användaren är tilldelad, tar den lösenordsarean plus användarens extralösenord som han anger vid inloggningen. Då får man Lösenordsnummret för användaren så att man kan jämföra det lösenordet för det nummret med det som användaren anger vid inloggningen.

...och då får posterna i tabellerna exakt samma kronologiska ordning? Lite skeptisk faktiskt.

Ja, det här var ju ett väldigt förenklat exempel. Som jag skrev i första kan man t.ex. skapa upp säg 1000 lösenord inom samma lösenordsarea som den nya användaren har för att förvirra saker och ting.

Ett annat exempel är att man skulle kunna skapa några miljoner lösenord innan man kör igång live och sen sätta in den nya användarens lösenord någonstans i tabellen.

Eller lösa det på nåt annat sätt...

Ja eller så ser man till så att ingen kommer åt databasen i första läget.
de flesta av senare tidens "databasdumpningar" har ju berott på sql-injections.

Jo, det så klart. Det här är mer tänkt som ett experiment då jag inte tror att någon skulle vara intresserad av att hacka sig in i min lilla databas. Så jag är mest ute efter om det på detta sätt skulle gå att skydda sig mot just detta problem med att lösenord kan kopplas till användare och deras mejladress som varit på tapeten rätt mycket på senare tid om nu någon skulle komma över informationen.

teoretiskt är det ju en bra lösning, men man kommer fortfarande rätt långt med "normala" krypteringsalgoritmer + lite saltning + starka lösenord.
Jag läste någonstans att redan med vanlig md5 så är det lite svårt att knäcka starka lösenord (dvs 8 tecken, minst ett tecken som inte är a-z eller 0-9, blandade gemener/versaler osv) kastar man dessutom på en lagom vettig saltning så kommer dina lösenord att kräva så mycket arbete att knäcka så det inte är värt det.

Ok, fast användare är ju rätt dåliga på att använda starka lösenord (jag själv bland annat :r). Visst, man kan ju tvinga dom att använda minst ett antal tecken och några specialtecken. Sen det där med att det tar lång tid att knäcka. Ja, idag är det så men hur ser det ut om säg tio år, då kanske man skrattar åt en lösning med MD5 + salt och menar på att det är lika säkert som att skriva lösenord i klartext idag, man vet ju aldrig.

Detta kanske kan vara något att använda: http://www.idg.se/2.1085/1.335425/gammal-kryptering-aktuell-pa-nytt

Ja, den verkar ju bra :)

Men är tyvärr ingen grym matematiker. Kollade lite på Wikipedia http://en.wikipedia.org/wiki/McEliece_cryptosystem och det såg alldeles för avancerat ut för mig.

Kryptering används när du vill kunna säkra upp information för att sedan få ut det i klartext igen (med hjälp av en nyckel). Frågan är om det verkligen är det du är ute efter? Att hasha med salt (och en vettig algoritm) brukar vara att föredra för att lagra lösenord då informationen inte ska gå att återställa till klartext.

Jag skulle rekommendera använding av PBKDF2 för högsta säkerhet. Jag har skrivit en klass för PHP som du kan få använda, om du programmerar i det.

Har läst lite nu om PBKDF2 men jag är inte riktigt med på hur det fungerar. Var nån som skrev att man skulle spara ner det värde man får fram + salt + antalet iterationer tillsammans för att kunna jämför det sen när användaren loggar in. Men om man har sparat ner vilket salt som används och antalet iterationer så måste det väl underlätta för en utomstående part att knäcka lösenordet, eller? Är inte med på varför detta sätt skulle vara bättre än att bara köra hash+salt. Visst, om man gör 1000 iterationer så tar det väl längre tid men det är väl fortfarande "knäckbart"?

Man kan ju slumpa antalet bogusposter för varje ny registrering i så fall.

Om man glömmer sitt lösenord då? En reset?

Ja, en reset måste man göra. Om du så bara hashat lösenordet kan man ju inte få tillbaka det så man får ju skicka ut ett nytt lösenord till användaren.