Håller på att skapa en användardatabas i ASP-Access. Databasen ligger i en katalog utan läsrättigheter "utifrån" och heter något i stil med lajsfklsbadfljsd.mdb. Lösenordet är i samma stil. Lösenord och databasnamn står i klartext emellan <% %> på sidorna.
- Duger säkerheten kring databasen så?
- Vad kan man göra mer? Kryptera databas/lösenord på nåt sätt?
- Är MySql säkrare?
Skulle vilja påstå att databasen är så säker den kan bli. Endast de med tillgång till filerna kan få fram lösenordet och således titta i den men det är ju bara du och hotellet och förhoppningsvis är hotellet så pass seriösa att de inte gör det.
1. Så länge du inte skyddar dig mot SQL-injections, så är inte din databas skyddad oavsett var den befinner sig eller vilka säkerhetsaspekter du har kring den. Sök på SQL-injections så hittar du uppslag så det räcker.
2. En hashning av lösenorden i databasen bör införas, om du inte redan har det.
Det skrivs om "hashning" ... Finns någon bra länk el färdig rutin för att skapa/läsa ?
Poängen med hashning är att om man skulle komma över databasen med lösenord, är de fortfarande krypterade. Det är ett långt ifrån oöverkomligt hinder, men det är iaf ett steg på vägen. Kod för MD5-hashning finns på bl.a. http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html
Som jag läste nånstans, det är bättre att skriva vad man tillåter, än vad man inte tillåter. Om man skulle glömma ett tecken i ens radda av inte tillåtna tecken kan nån jäkel vara där och sabba för en, medan det bara blir ett irritationsmoment om man glömmer att tillåta nåt.
För övrigt tycker jag att A-Z, a-z, 0-9 räcker gott och väl när man bara hanterar användarnamn och lösenord.
Som jag läste nånstans, det är bättre att skriva vad man tillåter, än vad man inte tillåter. Om man skulle glömma ett tecken i ens radda av inte tillåtna tecken kan nån jäkel vara där och sabba för en, medan det bara blir ett irritationsmoment om man glömmer att tillåta nåt.
För övrigt tycker jag att A-Z, a-z, 0-9 räcker gott och väl när man bara hanterar användarnamn och lösenord.
Men varför ska man, ur säkerhetssynpunkt, förbjuda något överhuvudtaget?
Och vad gäller lösenord är det bäst att tillåta så många tecken som möjligt, om man vill ha det säkert. Det gör det svårare för dem som tänker på att göra dictionary attacks.
Såg en lösning nånstans där man hämtade alla användarnamn med tillhörande lösenrod från databasen och sedan kontrollerade inmatningen från användaren mot dessa - databasfrågorna påverkades alltså inte av användaren. Löser visserligen problemet, men det känns ju inte som en speciellt bra lösning...
Såg en lösning nånstans där man hämtade alla användarnamn med tillhörande lösenrod från databasen och sedan kontrollerade inmatningen från användaren mot dessa - databasfrågorna påverkades alltså inte av användaren. Löser visserligen problemet, men det känns ju inte som en speciellt bra lösning...
Det är fel sätt att tänka, eftersom farliga tecken i SQL-frågor sträcker sig så mycket längre än bara i inloggningsförfarandet. Som sagt innan; överallt där det kommer inmatning från användaren är potentiella sökerhetsluckor.
