19 svar · 584 visningar · startad av Donatello
Hej.
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?
Tacksam för svar...
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.
Okänd skrev:
"En kedja är inte starkare än dess svagaste länk"
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 ?
Det kan ju vara en bra hjälp på vägen till en säkrare databas.
Samt jag är riktigt nyfiken själv på svaret *ler*
Håller som ett första steg på att anpassa så bara A-Z, a-z och 0-9 tillåts överallt... men ställer även jag samma fräga som Zaiman. :)
Visst finns en del att läsa på
http://www.swesecure.com
Men... det mesta där är kodexempel för .NET Om inte allt ( har inte läst allt än).
Donatello skrev:
Håller som ett första steg på att anpassa så bara A-Z, a-z och 0-9 tillåts överallt... men ställer även jag samma fräga som Zaiman. :)
Var någonstans? I lösenorden eller i SQL-frågorna?
Zaiman skrev:
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
Var någonstans? I lösenorden eller i SQL-frågorna?
Typ överallt in princip... Överallt där jag hämtar data från annan källa än själva scriptet. Mao databasen, querystring, form etcecera...
Donatello skrev:
Var någonstans? I lösenorden eller i SQL-frågorna?
Typ överallt in princip... Överallt där jag hämtar data från annan källa än själva scriptet. Mao databasen, querystring, form etcecera...
Om jag vill spara ett utropstecken i din databas då? Eller en punkt kanske? ;)
Då säger scriptet skit ner dig, å kastar ut dig. :p
Varför då? Är det inte bättre att se till att det funkar lika bra med alla tecken?
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.
Donatello skrev:
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.
Läste att det var det säkraste sättet att skydda sig mot sqlinjections...
Nej. Det säkraste sättet är att använda parametriserade frågor.
http://www.swesecure.com/?ID=dc6ea60a-12ae-4e7e-9e9c-59489ccafa90&IID=d628e96e-f8fd-44ed-9537-4061c817e9b1
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...
Nej, det är tvärtom en ganska kass lösning. Bättre då att göra en databasfråga som inte pajar allt.
jonnyz skrev:
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.
Skulle någon kunna tänka sig att ge mig en grundlig förklaring till det där med parametiserade frågor? Visa vad dom menar här: http://www.swesecure.com/?ID=dc6ea60a-12ae-4e7e-9e9c-59489ccafa90&IID=d628e96e-f8fd-44ed-9537-4061c817e9b1
... för jag hajjar ärligt talat inte... :l
För övrigt tror jag inte att alla nånsin kommer komma överens om vad som är "säkrast". :p
