Noen som har noen forbedringer og komme med?

[ve_gard]

(Beklager men jeg klarer ikke å få det til å se ut som kode, selv om jeg bruker riktig TAGS, og limer inn via GUIDET modus til og med. Men drit nå i d nå (Tips tas imot med takk likevell:p))

 

Her er et innloggingsscript jeg nå har klart å få skrevet, etter mye prøving å feiling.

Vil såklart ha det sikrest mulig så (sett bort ifra SSL), hva mener dere kan endres her? og hvordan få det sikrere... usikker på hvordan jeg skal bruke Session.use_only_cookie her. Kom gjerne med et eksempel på hvordan jeg kan bruke det. Er ny i faget og tar til meg all læring som læres kan:)

 

 

<?php

//Diverse variabler

$brukernavn = $_POST['username'];

$fiksaPassord = $_POST['password'];

 

//Feilsjekk på feltene

if ( empty( $brukernavn ) || empty( $fiksaPassord ) || (empty( $brukernavn ) && empty( $fiksaPassord ) ) ){

echo 'Du må fylle ut alle feltene!';

$feil = true;

}

if(!$feil){

//inkludering av filer

include 'ikobling.inc.php';

include 'ihasjing.inc.php';

 

//SQL-spørring

$user = mysql_query("SELECT * FROM usr WHERE epost='$brukernavn' AND passord='$passordLagret';", $kobling);

$resault = mysql_fetch_row($user);

 

//IF-løkker

if( mysql_num_rows($user)>0 && $user){

if($_POST['remember']){

$expire = time() + 1728000; // Expire in 20 days

setcookie('user', $user['epost'], $expire);

echo "Gratulerer $resault[0] du er logget inn og din epost er kryptert og lagret i en Cookie på din maskin.<br /><br />";

}else{

echo "Gratulerer $resault[0]" . ' ' . "$resault[1]" . ' du ble logget inn<br />';

}

}else{

echo "Beklager du skrev feil brukernan og/eller passord, evnt du er ikke registrert i mitt system!";

}

mysql_close( $kobling );

}

?>

 

mvh Vegard

[trrunde]

ville ha brukt mysql_real_escape_string for å forhindre mysql injections

[ve_gard]

ville ha brukt mysql_real_escape_string for å forhindre mysql injections

7582013[/snapback]

 

Takker... har fått fiksa opp mye nå... 18 timer i strekk satt jeg med dette

 

MvH Vegard

[ZoRaC]

Passord bør hashes, ikke lagres i klartekst... (md5 f.eks)

 

Litt rar feilsjekk? Dette er vel nok:

"if (empty($brukernavn) || empty($fiksaPassord)) {"

 

"SELECT epost FROM usr ..." rekker, har du mange felt i tabellen bør man alltid hente ut bare det man trenger.

 

Hvorfor lagrer du epost i en cookie?

[ve_gard]

Passord bør hashes, ikke lagres i klartekst... (md5 f.eks)

 

Litt rar feilsjekk? Dette er vel nok:

"if (empty($brukernavn) || empty($fiksaPassord)) {"

 

"SELECT epost FROM usr ..." rekker, har du mange felt i tabellen bør man alltid hente ut bare det man trenger.

 

Hvorfor lagrer du epost i en cookie?

7591679[/snapback]

 

lagrer alt i hasha form, enten md5() eller sha1(); + litt egenlaget kryptering etter det i tillegg. I cookien blir det også lagret i hashet form. Hvorfor akkurat e-post... hmm ingen spesifikk grunn til at jeg valgte epost fremofor f.x mobil eller andre unike ID'er. kunne såklart kjørt en egen kolonne i SQL'en med ID AUTO_INCREMENT.. men ble nå så at dette ikke ble gjort da jeg opprettet tabellen da:p

Så må benytte meg av en av de primærnøklene...

 

mvh Vegard

[ZoRaC]

Ah, ok, trodde det var email i klartekst jeg, for det ville ikke vært særlig sikkert

[ve_gard]

Ah, ok, trodde det var email i klartekst jeg, for det ville ikke vært særlig sikkert

7593900[/snapback]

 

enig;) har jobba mer me dette nå... blir bedre for hver gang:)

 

mvh Vegard

[Olavxxx]

Ah, ok, trodde det var email i klartekst jeg, for det ville ikke vært særlig sikkert

7593900[/snapback]

 

enig;) har jobba mer me dette nå... blir bedre for hver gang:)

 

mvh Vegard

7623190[/snapback]

 

http://no.php.net/mysql_real_escape_string

 

Se eksempel 3.A

[ventle]

enhver som kjenner verdien av $user['epost'] kan sette en slik cookie manuelt og dermed få tilgang til nevnte brukers konto...

 

har selv laget ett innloggingssystem der brukerens id-nummer (hvilken id han har fått i sql-tabellen som lagrer brukerkontoene), brukerens passord i klartekst (dette er en mulig sikkerhetsbrist, men ikke så alvorlig som man skulle tro, kommer tilbake til det senere), og ett boolsk tall settes sammen til en tekststreng adskilt med | i cookien (dere skjønner da sikkert at jeg bruker explode("|") til å få ut dataene igjen).

 

På serveren er passordet kun lagret kryptert med md5 slik at det ikke kan dekrypteres, når scriptet oppdager cookien blir klartekstpassordet kjørt gjennom md5() og sammenlignet med lagret verdi i databasen, og brukeren blir gitt eller nektet tilgang. På denne måten hindrer man uautorisert tilgang, ettersom det bare er brukeren selv som kan gi dette passordet, og den må passe sammen med id-nummeret.

 

Sikkerhetsbristen her er at passordet blir lagret i klartekst på den lokale maskinen. I utgangspunktet skal dette være sikkert, i hvertfall så lenge brukeren har kontroll over sin egen maskin. For å sikre dette kan man kryptere passordet med en nøkkel som bare den som har laget scriptet kjenner til, på en slik måte at det kan dekrypteres når scriptet må sjekke mot databasen.

 

Den boolske variabelen til slutt settes til 1 dersom brukeren huker av en boks merket 'husk meg' når han logger inn, eller 0 hvis ikke. Hvis variabelen er lik 0, blir ikke expire-tiden satt, og cookien blir slettet når nettleservinduet lukkes.

Endret 3. januar 2007 av ventle

[ZoRaC]

enhver som kjenner verdien av $user['epost'] kan sette en slik cookie manuelt og dermed få tilgang til nevnte brukers konto...

Han lagrer md5($user['epost']) i cookien, så man må kjenne MD5-hashen...

 

Hvorfor lagrer du passordet i klartekst?

Kan du ikke bare lagre md5($passord) i cookien og sjekke direkte mot databasen? Det er jo mye sikrere...

 

Hvordan må det passe med id-nr?

Når brukeren logger inn oppgir han vel brukernavn og passordet?

[ventle]

Hvorfor lagrer du passordet i klartekst?

Kan du ikke bare lagre md5($passord) i cookien og sjekke direkte mot databasen? Det er jo mye sikrere...

 

Hvordan må det passe med id-nr?

Når brukeren logger inn oppgir han vel brukernavn og passordet?

7637658[/snapback]

 

det er dette som er det geniale. dersom man oppgir id-nummer og det originale passordet hver gang han cookien blir sjekket, må brukerens pc oppgi verdier som ikke er mulige å hente ut av databasen. Å gamble på at en ondsinnet bruker aldri vil få tilgang til databasen er en alvorlig sikkerhetssvakhet, for akkurat det har skjedd flere ganger før.

[ZoRaC]

Så det passordet som ligger lagret i cookien er ikke det samme som det brukeren oppgir når han logger inn?

 

Hva oppgir brukeren når han logger inn da?

[ventle]

jo, det som brukeren oppgir og det som lagres i cookien er det samme, men poenget er at denne verdien kan man ikke hente ut av databasen, eller noe annet som ligger lagret på nettsiden, kun brukeren selv kan (i teorien) oppgi denne verdien, videre husker brukerens pc (og ikke serveren, det er her cluet ligger) denne verdien så lenge brukeren tillater det.

 

edit: brukeren oppgir naturligvis brukernavnet ved innlogging, men kun id-nummeret lagres i cookien for enkelhets skyld og en ekstra deception, slik at man ikke kan lese både brukernavn og passord rett fra cookien. Dersom passordet i cookien krypteres på en måte slik at kun serveren/scriptet kan dekryptere det er sikkerheten optimal med denne metoden, etter min erfaring.

Endret 3. januar 2007 av ventle

[ZoRaC]

Da er det bare for meg og se innholdet i cookien da, så har jeg jo passordet?

 

Hvorfor ikke lagre md5($password) i cookien?

Så sjekker du:

if ($_COOKIE['passord'] == $row['md5Password']) // innlogget

i stedet for:

if (md5($_COOKIE['passord']) == $row['md5Password']) // innlogget

 

Da har du plutselig sikret passordet på klientsiden også...

 

Lagre $_COOKIE['id'] og $_COOKIE['password'] (evnt $_COOKIE['husk'], men ser ikke behovet for den?) i stedet for å lagre alt separert med "|".

Hva skjer om en bruker har "|" i passordet sitt forresten?

[ventle]

dersom du klarer å få tilgang til cookien, altså enten har du allerede tilgang til serveren som nevnte script kjører på, eller du har tilgang til pc'en til brukeren, eller du overvåker tilkoblingen (om du gjør det er det bare SSL som er trygt), så ja, da kan du hente passordet til nevnte bruker. Er derfor jeg foreslo en kryptering med en hemmelig nøkkel, slik at scriptet (og bare scriptet) kan dekryptere passordet. Hele vitsen med det jeg har foreslått her, er at man ikke skal ha mulighet til å logge seg inn med en annen brukers konto ved hjelp av info man kan få ut fra databasen, det oppnår man med min løsning.

 

Man kan ved registreringen passe på at brukere ikke tillates å bruke | i passordet. Rimelig enkel sak å løse.

 

$_COOKIE['husk'] som du kaller den er der for å implementere en funksjon der du kan la brukere velge å bli husket eller ikke når de logger inn, slik at han eventuelt logges ut automatisk når nettleservinduet lukkes. En helt klar sikkerhetsfordel ved bruk av pc'er som brukes av mange personer. Man reduserer da også det kritiske ved å la passordet være lagret på pc'en.

[ZoRaC]

dersom du klarer å få tilgang til cookien, altså enten har du allerede tilgang til serveren som nevnte script kjører på, eller du har tilgang til pc'en til brukeren, eller du overvåker tilkoblingen (om du gjør det er det bare SSL som er trygt), så ja, da kan du hente passordet til nevnte bruker.

Du kan ikke få tilgang til cookien på serveren, for den ligger bare på klienten.

 

Er derfor jeg foreslo en kryptering med en hemmelig nøkkel, slik at scriptet (og bare scriptet) kan dekryptere passordet.

Hvorfor vil du dektryptere passordet??

 

Jeg vil gjøre det slik:

1. Bruker skriver inn brukernavn og passord og trykker "logg inn"

2. Passordet hashes med MD5 og hashen sjekkes mot databasen sammen med brukernavnet

3. Hash og ID lagres i en session-variabel som sjekkes på hver side

4. Hvis bruker har krysset av for "husk meg" lagres hashen i cookien sammen med brukerID (eller brukernavn) med en expire-tid

5. Når bruker besøker siden igjen sjekker scriptet om det er satt $_COOKIE['passord'], hvis så sjekk det mot databasen sammen med brukerID

 

Man kan ved registreringen passe på at brukere ikke tillates å bruke | i passordet. Rimelig enkel sak å løse.

Hvorfor vil du nekte bruker å ha "|" i passordet? Det krever mindre koden å legge det du vil lagre i hver sin cookie-variabel enn å styre med explode og sånt...

 

$_COOKIE['husk'] som du kaller den er der for å implementere en funksjon der du kan la brukere velge å bli husket eller ikke når de logger inn, slik at han eventuelt logges ut automatisk når nettleservinduet lukkes.

Hvorfor lagrer du den i cookien? Om "husk" er satt, setter cookien du med expire, hvis ikke uten. Er jo ikke noe behov for å lagre dette i selve cookien? Endret 4. januar 2007 av ZoRaC

[ventle]

har gjentatt meg selv så mange ganger at jeg gidder ikke mer nå, lar i hvertfall trådstarter få neste ord.

[ZoRaC]

Ja, vi har nesten kapret tråden...

 

Men, du har jo fortsatt ikke fortalt HVORFOR du vil ha mulighet til å dekryptere passordet når det ligger i MD5-format i databasen uansett.

 

Er jo litt unødvendig sikkerhetshull dette:

$passord = decrypter($_COOKIE['passord']);

$passordMD5 = md5($passord);

if ($passordMD5 === $row['passord']) // innlogget

[ventle]

det jeg mener er at klienten, evt. klientens maskin må oppgi informasjon som ikke er lagret på serveren i noen som helst form som det går an å lese seg til fra serveren/databasen, for å få tilgang.

 

Det eneste sikkerhetshullet i den koden du nevner der, er hvis andre har tilgang til den nøkkelen som trengs for å dekryptere passordet, har man for eksempel kryptert passordet ved hjelp av en nøkkel på 32 vilkårlige tegn som ingen andre enn den som har laget scriptet kjenner til, er passordet så godt kryptert at det er nesten like vanskelig å finne det ut (uten nøkkelen) som det er å dekryptere en md5-hash. Point made?

[ZoRaC]

Hvorfor finne opp en egen krypterings-algoritme når du bare kan bruke MD5-direkte - det er det jeg lurer på.

 

Du har jo ikke behov for å dekryptere passordet?