Det pratas ganska mycket om hur man ska skydda sig när någon har kommit över databasen. Men vad är det från första början som gör att någon kommer över databasen? Hur ska man skydda sig bäst mot sånt? Tänkte att det kanske är bättre att försöka stoppa folk redan i dörren och inte behöva kasta ut dem när de redan är inne, så att säga.

Självklart ska man även kryptera hit och dit i fall någon tar sig in. Men kan någon ta sig in och plocka ner databasen, så kan de säkert även ställa till med annat som man säkert vill stoppa?

Det där lät intressant. Har du några referenser för påståendet?

Min erfarenhet är att användarna inte gillar krångliga lösenord, däremot brukar dom acceptera att lösenordet måste vara ganska långt, åtta tecken.
Ett lösenord på åtta tecken är väldigt mycket mera svårforcerat än ett på enbart sex tecken. Det är alldeles för många som väljer lösenord i stil med "hej" eller "johan".

1. det är ganska logiskt. Folk stör sig på det och har svårt att minnas de olika lösenorden.
2. Jag har läst om det för bara ett år sedan ca. Skriver inte upp var jag hittar all info jag bara läser o minns ;).
Men google ger dig säkert svar.

Jag hatar siter som inte tillåter vettiga lösenord (dvs längdbegränsning, eller filtrering av tecken), och jag hatar siter som ställer annat än längdkrav. Stämmer inte mitt lösenord in på mallen så måste jag hitta på ett nytt lösenord, och sedan, utöver att komma ihåg det nya lösenordet utöver mitt vanliga, även komma ihåg på vilken site som jag har vad..

Jag kan stå som referens.

Trots att jag använder alfanumeriska lösenord blir jag ibland tvingad till att använda X antal tecken (antingen minimum eller MAXimum!), speciella karaktärer (och andra som INTE tillåter speciella karaktärer) eller t.o.m inte ens få byta mitt lösenord!

Det blir ganska snurrigt till slut.

Det sistnämda är helt sjukt, och gjort att jag varit tvungen att skriva ned lösenordet eftersom jag bara använder det på en sida, och kommer därför aldrig ihåg det.

har slutat att försöka komma ihåg alla lösen för länge sen... använder keepass till det numera vilket funkar bra.

Ska vi inte ta och börja hålla oss till ämnet?

Kryptera lagrade e-mailadresser, lösenordshashar och ev annan känslig information. Då blir en DB-dump inte särskilt användbar om man inte samtidigt kommer åt att läsa PHPn där kryptoknyckeln står. Eller så kan man lösa krypteringen och dekrypteringen med en stored procedure i SQLen som användaren PHP loggar in med inte har rättigheter att läsa, bara att köra.

Man kan även köra flera "omgångar" MD5 för att göra bruteforcning 'dyrare'.
md5(md5(md5(md5(...(pw|salt)...
Då går det helt plötsligt åt mycket mer CPU-tid för att cracka ett lösenord.

om man kör md5 i flera "omgångar" hur påverkar det prestandan för databasen/servern?