28. januar 2004 - 21:04Der er
10 kommentarer og 1 løsning
SSL og følsomme oplysninger
Hejsa
Bruger skal logge ind via brugernavn og password. Spørgsmålet er, om det er sikkerhed nok, at vi benytter SSL-krypteret kommunikation på de følsomme sider på sitet? Og/eller bør vi også benytte kryptering af password når det sendes til serveren ved oprettelse af nye brugere, samt gemme disse oplysninger krypteret i databasen?
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
1) SSL Alt du ikke sikrer med HTTPS, vil kunne opsnappes (meget let) af indtrængende. Brugernavn/Password vil være ukrypterede og stå så man let kan få fat på dem.
2) KRYPTERING AF PASSWORDS Personligt krypterer jeg altid brugernes passwords, så de ligger krypteret i databasen. Jeg bruger MD5 som er en envejs kryptering. Mine systemer kontrollerer så brugerens MD5 krypterede password med det der ligger i databasen. Detter er for en sikkerheds skyld, så brugerne kan vide sig sikre på, at ingen kan læse deres passwords fra databasen (eller på en side, der er sat forkert op, så den skriver en brugers password). BEMÆRK at dette ikke sikrer at indtrængene kan opsnappe det originale password fra brugeren og bruge det.
Det vil altså sige, at hvis man benytter SSL-beskyttede sider, og samtid krypterer passwordsene i databasen med fx hashing, så er det efterhånden temmelig sikkert?
ja, så er der kun hackere og dårlig programmering tilbage at bekymre sig om (det sidste kan også være slemt. Hvis du ikke har lavet en side ordentligt, så jeg for eksempel kunne sende noget SQL kode med i steden for mit navn og slette din DB, så ville det ikke være så godt).
Jeg forstå bare ikke hele problematikken, for hvis man bruger SSL-kryptering på de sider, hvor følsomme data skal indtastes og præsenteres, hvor kan der så opstår sikkerhedsbrists - udover sql-injections. Hvorfor er der behov for at kryptere passwords, hvis disse alligevel sendes krypteres ml klient og server via SSL? Og hvis en hacker kan få adgang til database-serveren er det vel ligegyldigt om passwordet ligger krypteret, hvis han har adgang til alle andre data i databasen...?
Det er heller ikke strengt nødvendigt. Men jeg har et lille eksempel fra den virkelige verden, som ligesom illustrerer hvor man bør overveje at kryptere sine passwords i databasen.
Jeg har haft et webhotel (lige meget hvilket et ;-), som havde en helpdesk hvor man kunne lægge tickets om problemer/ønsker og betale fakturaer. Det var da også fint nok, hvis ikke det var sådan at de under ens indtillinger viste brugeren sit eget password. Og hvad være var: de havde ikke programmeret det særligt godt. Efter at have været kunde i ca. 20 min. fandt jeg ud af at de oppe i url-adressen skrev noget i retning af userid=212. Lidt nysgerig prøvede jeg at ændre tallet til 211 og VUPTI; jeg kunne se og ÆNDRE en anden brugers password osv. Nu er jeg jo ikke typen der bruger bruger sådanne oplysinger til at hacke så jeg oplyste webhotellet om fejlen, så de kunne rette den.
Hvad kan man så lære af ovenstående? Jo bare det at du har TÆNKT over om du vil kryptere brugers passwords i databasen eller ej, giver dig en langt større indsigt, da du nok i samme tankegang ville komme frem til, at det nok ikke giver nogen mening at oplyse en bruger om hvilket password han har på din hjemmeside.
Ja for at gøre en lang historie kort ;o) Det vigtige er at du tænker over hvilke risici der er og hvordan du vil håndtere brugers info.
Ok, men den problematik kan man vel bare komme uden om ved at benytte brugerens brugerid som session, og så selvf. lade være med at vise password, og iøvrigt være påpasselig med hvilke parametre man sender rundt i systemet. Men vi er enige om, at sålænge man benytter SSL-kryptering på kommunikationen og iøvrigt tager højde for ikke at sende følsomme data rundt i url'en, og sætter en check-funktion på alle inputfelter, så er der vel ingen grund til at sætte andre sikkerhedsforanstaltninger op? Hvor let er det egentlig at hacke sig ind på en mysql databaseserver? Grunden til jeg spørger er fordi, at jeg flere steder har hørt folk skrive om, hvor usikkert det er at opbevare data på en webserver og hvor let det er at bryde ind på db-serveren og udtrække data...kan det passe?
Ved ikke personligt noget om det. Jeg tror ikke det er db'en der er usikker, men dem som står for selve db-serveren der ikke gør det ordentligt. Jeg har engang set et ret skræmmende eksempel (på linux), hvor en af mine venner viste mig hvordan han via en simpel ftp-konto kunne uploade et lille script, som så gav ham root rettigheder over maskinen.
Så hvis udbyderen ikke er med og sikrer sig mod den slags indgreb; ja, så er db'en også i fare.
Men det kan selvfølgelig også være at mysql har nogle (for mig ukendte) sikkerhedshuller, som kan udnyttes.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.