Sikkerthetsspørsål ang. sessions, passordkryptering og brukerautentisering m.m

[hakonvl]

Hei

 

Har en side/CMS som etter planen skal være ferdig bortigmot ferdig i morra så jeg i allefall får vist den frem til de som skal bruke den. Har en del igjen å gjøre og har det ganske travelt, så jeg spør noen spørsmål her jeg garantert finner svar på selv.

 

1. Pr. i dag har jeg en session variabel som f. eks heter $_SESSION['live']. Denne er satt til true hvis brukeren er logget inn, og false hvis brukeren er logget inn. Er dette er grei måte å gjøre det på? Jeg har ikke gjort noe mer med sessionen en det som er standard i PHP.

2. Bruker autentiseringen foregår sånn:

		$sql = "SELECT * FROM users WHERE username = '" . $username . "' and password = '" . $password . "'";

	$result = db::query($sql);

	if(db::affected_rows() === 1){


		return true;

	}else{

		return false;

	}

Er dette greit, eller finnes det bedre måter å gjøre det på?

3. Hva er den beste måten å kryptere passord på? Bruker nå sha1, men jeg vet at dette ikke er den beste måten på da det finnes sikrere krypteringsfunksjoner. Poenget er i allefall at i en del databaser til f. eks fluxBB så ser jeg en tabell som heter salt? Kan noen forklare meg litt av prinsippet bak dette? Det lille jeg har tenkt på det sier meg ikke så mye.

 

Jeg vet at jeg finner svar på dette selv på nettet, men det hadde vært fint om noen kunne ha svart meg her siden jeg har det litt travelt nå. Tror det er bedre å få et svar her en mange forskjellige på nettet som jeg igjen må finne ut hva som er riktig.

 

Tusen takk

Endret 12. oktober 2010 av Rockie

[Ernie]

1.

Det vil varierer veldig, men generelt sett nei. Det er to problemer med en slik fremgangsmåte. For det første blir man svært sårbar i forhold til angrep fra andre som har tilgang til samme server (forutsatt lagringsstedet for session er delt, noe det pr. default fort er). For det andre, og dette er hovedgrunnen til at det er en dårlig ide, så kan fremmede glatt overta session. Spesielt vil dette være enkelt å gjennomføre hvis noen er innlogget over en usikret kanal (ingen SSL og f.eks. åpent WLAN).

 

Hvis dette er noe problem: Det du bør gjøre er å sikre deg at brukeren som er logget inn faktisk tilhører den maskinen man er på. Primært bør man derfor lagre IP-adressen og sjekke den mot brukeren for hver sidevisning.

 

2.

Litt avhengig av hvor du får $username og $password fra. Er ikke disse sikret så er man sårbar for SQL-injection. Utover det er det ingen problemer med fremgangsmåten.

 

3.

Sha-1 er en pr. dags dato OK algoritme for enveiskryptering, så det i seg selv er ikke noe problem. At endel systemer benytter salt i passordet har sammenheng med at de ikke ønsker at brukerenes passord lett skal kunne knekkes skulle noen få uautorisert tilgang til databasen. Har man ikke salt kan man i praksis kjøpe seg eller selv lage lookup-tabell for resultateter av en sha-1-hashing. Tilfører man salt i passordet og dette er unikt for hver bruker, f.eks. sha1($pwd.$salt), blir disse lookup-tabellene helt ubrukelige og man gjøre det verre for uvedkommende å finne ut hva passordet til brukerene er.

[hakonvl]

1. Ok, så lenge jeg også sjekker IP addresser, eventuelt nettleser og andre tilgjengelige opplysninger så der det ok?

2. Jeg sikrer de med mysql_real_escpape_string() og jeg åasser på at tall faktisk er en int og ikke en string. Har lest dette i en bok om PHP der de mener det er nok. Er det det?

3. Dette gjelder selv om salt er tilgjengelig i databasen? Har ikke helt satt meginn i krypteringsalgoritmer, tror jeg burde det etterhvert.

Endret 13. oktober 2010 av Rockie

[BlueEAGLE]

3. Dette gjelder selv om salt er tilgjengelig i databasen? Har ikke helt satt meginn i krypteringsalgoritmer, tror jeg burde det etterhvert.

Salt har ingen kryptologisk verdi men bør være unik per bruker. Grunnen til det er at hvis en angriper får tak i databasen så vil man ikke kunne se at Petter og Arne har samme passord ut i fra strengen i passordfeltet.

 

Hvis en angriper kjenner et brukernavn så vil en eventuell salting ikke hjelpe mot påloggingsgrensesnittet da du nødvendigvis vil måtte bruke det samme saltet for å sjekke passordet fra angriperen som du vil bruke for å sjekke passordet fra brukeren.

 

Hvis du skulle miste kontroll over databasen så sliter du som oftest allerede der da det som regel kun er passordet som er obfuskert og en angriper allikevel vil ha såpass god tilgang til systemet at passordet i databasen har begrenset betydning.

 

Konklusjonen blir derfor at du gjerne kjører hash på (brukernavn+passord) men at du heller gjør deg flid med å legge en sperre på antall passordforsøk i et gitt tidsrom.

[hakonvl]

Ja, det ligger egentlig i planene for hva jeg skal gjøre videre. Da hasher jeg i allefall passordene med sha1 så lenge, eventuelt noe annet sterkere.

 

Takk