Er dette login script sikkert?

Du kan jo vælge at benytte klasser i stedet for id, så undgår du de valideringsfejl.

Umiddelbart ser scriptet ret sikkert ud, men jeg vil anbefale at hash'e passwords i databasen med fx md5.

Jeg ved ikke om scriptet er specielt sikkert eller ej, men det lugter langt væk af at være mega-gammelt når det bruger session_register og ikke $_SESSION. Alene af den grund skal du kigge efter noget andet. Nej, jeg har ikke et bedre link ;)

Som der står i bunden af guiden skal du nok overveje at bruge hashede passwords og salts. Jeg har selv skrevet en (engelsk) guide om hvordan du kan gøre dette effektivt:)
http://guides.ricehigh.dk/?p=1

At hashe passwords i din database hjælper til at sikre dine brugeres passwords i tilfælde af at en hacker tilegner sig adgang til din database.
Hvis engelsk er et problem for dig, vil jeg meget gerne gennemgå hovedtrækkene i min guide for dig på dansk:)

Som #1 skriver kan du jo bruge CSS classer istedet for ID's.
Eksempel:
<style type="text/css">
.en_klasse {
color:#ffffff;
}

#en_id {
color:#ff00ff;
}
</style>

...

<div class="en_klasse">
noget indhold2
</div>
<div id="en_id">
noget indhold2
</div>


Den fundamentale forskel er egentligt at klasser kan bruges så mange gange du ønsker, hvorimod en ID er rettet mod styles der kun skal bruges på et enkelt objekt.

Håber det hjalp:)

#2
Han skal så nok ikke lige bruge MD5:P
- MD5 er særdeles sårbar over for collision attacks.

Jeg vil anbefale brug af en SHA hash istedet.

Generelt:
Men i stedet for at benytte sig af frames eller masterpages(ASP.Net), er det så en "ok" måde at lave en ny side for hver "underside" hvor man bare genbruger de samme billeder som på hovedsiden? Det bliver jo godt nok til en masse underfiler, men siden loader vel stadig forholdsvis hurtigt når billederne først er blevet vidst én gang ikke?

mstorgaard:
Tak for tippet, det var jeg ikke lige klar over :) Så nu har jeg en ren valideret side, dejligt.. Mht. md5 er det klart noget jeg vil prøve at eksperimentere med - i hvert fald en eller anden form for kryptering ;)

erikjacobsen:
Kunne man eventuelt ikke bare erstatte session_register med en $_SESSION["logged_ind"] = true; ? For som mstorgaard skriver virker det ellers sikkert :S

psychopixi:
Tak for gennemgangen ;) Jeg har førhen brugt classes, men var ikke lige klar over at man kunne bruge dem flere gange uden at få samme fejl som med Id's.. Så nu har jeg en ren valideret side, dejligt... Mht. den anden kommentar du skrev forstod jeg ikke så meget af den, da jeg ikke ved hvad collision attacks er. Men er SHA nogenlunde samme princip som med MD5?

Og lige et bonus spørgsmål i forbindelse med login-systemet.. Er det let nok at kode det sammen med en cookie funktion?

I så fald.. Hvad er formålet med at benytte sig af sessions, hvis man har en cookie liggende i sin mappe, der bestemmer at man er logget ind? (er ny på det område som i nok kan høre :D)

Princippet i SHA er nøjagtigt det samme som MD5 - SHA er blot bedre:)

Collisions er sandsynligheden for at finde strenge der giver samme sum som den oprindelige streng. Normalt bruger man bruteforce angreb til at cracke hashes, men en forskergruppe fandt i 2004 en analytisk metode til at gøre netop dette for MD5 hashes.

Det er i princippet let nok at kode det sammen med et cookie system, men med cookies skal du bare passe rigtigt godt på mht. sikkerhed, da:
1) Brugeren til enhver tid kan ændre cookies til hvilken somhelst værdi
2) Brugeren kan være udsat for cookie theft, hvilket betyder, at hvis fx det hashede password står i cookien, så er brugeren relativt dårligt stillet.

Jeg har sådan set også lavet en guide ang. cookies på http://guides.ricehigh.dk/?p=7

"bare erstatte session_register med en $_SESSION" - jo måske. Men hvorfor?

Erfaringen viser, at det er "farligt" at hænge fast i gammel kode. Ikke fordi jeg har fundet problemer i koden, men gammel kode på nettet burde udryddes.

<ole>

At bruge MySQL og 'hacke' sig ud af beskyttelse mod sql-injections er lidt som at pakke et brandsår ind i fed brandsalve og bandager. Det var 'god tone' engang, men ingen burde gøre det idag.

Kik i stedet på:
    http://dk2.php.net/manual/en/book.mysqli.php

- eller:
    http://dk2.php.net/pdo

Det er dagens og (foreløbig) fremtidens måden at bruge MySQL på under PHP  ;o)

/mvh
</bole>

- så jeg er helt på linje med erikjacobsen: Find noget tidssvarende  ;o)

psychopixi:
Jeps okay.. Jeg vil prøve at kigge lidt mere på SHA, hvis det er mere sikkert så ;) Hmm... jeg har godt nok læst lidt rundt omkring på nettet med at cookies er "farlige", men er det ikke dem alle de større communities benytter sig af? De fleste har jo en husk-mig knap ved login nu til dags, men det kan måske også lade sig gøre at lave det på sessions i stedet? I så fald - du skulle vel ikke vide hvordan jeg implementerer det på det login system jeg henviste til og skulle det så være mere sikkert end cookies :o ?

erikjacobsen:
Grunden til at jeg skrev det var at jeg blot troede det var måden den session blev oprettet på :S Har nemlig ikke lige bedre alternativer for tiden :)

olebole:
Hmm ja okay.. Jeg vil prøve at kigge mig rundt omkring efter noget nyere så, men har bare ikke lige bedre alternativer for tiden. Har ikke selv evnerne til at kode et op fra bunden af endnu desværre ;)

Generelt:
Jeg overvejer lidt at prøve at implementere enten Joomla eller Typo3 i stedet for, hvis det er til at have med at gøre :) De er vel sikre og går nok ud fra at de kan bruges på et større community site :?

Ps. hvis i gerne vil have jeres points siger i bare til

Ingen point til mig, tak.

De skal kunne klare dit community site ;) Men de er ikke sikre. Du skal regne med, at der bliver fundet huller i dem, og at du hver gang der er en opgradering, skal opgradere. Og selvfølgelig have en backup af databasen, hvis der skulle ske noget.

#12
Jeg mener da bestemt at min cookie guide skulle give dig indblik i hvordan du implementerer cookies på en forholdsmæssigt sikker måde.

Det "farlige" ved cookies er at der relativt ofte kommer metoder frem, hvormed man kan "stjæle" cookies fra brugere. Dette gør at du ikke må skrive følsom information i cookien såsom det hashede password - da man i princippet altid kan brute-force sig frem til det oprindelige password. Bruteforcen bliver dog besværliggjort en hel del ved brug af salts, som jeg også skriver i min hashing guide.


Hvis du ingen erfaring har med at kode sikkerhed overhovedet vil jeg næsten anbefale at du benytter et færdiglavet community - men kun hvis du er instillet på at opdatere dette HVER GANG der kommer en ny opdatering.
Grunden hertil er indlysende: kildekoden til frie community sites er frit tilgængelig, hvilket giver en potentiel hacker mulighed for at analysere sig frem til potentielle sikkerhedshuller - og hvis denne finder ét, så kan angrebet jo bruges mod ALLE communities af den type.

Konklusion: Hvis du vil bruge tid på at sætte dig ind i sikkerhed er dette klart at foretrække. Hvis du ikke vil bruge tid på det er det bedre at bruge et færdigt lavet community istedet for at strikke halvgennnemsigtige sikkerhedsløsninger sammen;)

Held og lykke med dig projekt:)

Ja okay... Jeg tror jeg vil prøve at lave det selv i stedet så i første omgang. Det er begrænset hvilket kendskab jeg har til sikkerhed, men hvis jeg prøver at følge din guide og benytter mig af salts kan det vel ikke gå helt galt på det punkt. Jeg lærer trodsalt heller ikke rigtig noget ved blot at benytte mig af opensource og er ikke interesseret i at benytte mig af deres themes :S

Så hvis jeg selv prøver at kode det og løbende få nogle eksperter til at følge op på det og eventuelt prøve at se om de kan knække systemet når det er færdigt, kan det vel ikke gå helt galt heh :)

Men tak for hjælpen.. Hvis der var flere, der gerne vil have points må i lige smide et svar inden i aften..

Jeg har lige fået kigget på din guide nu psychopixi.. Og da jeg skal bruge systemet til et community (hvor der højst sandsynligt vil komme mange brugere ind), vil det vel ikke være særlig hensigtsmæssigt at bruge SHA alligevel eller hvad?

For som du selv skriver i din guide er det ikke at foretrække, hvis man skal bruge det i et større sammenhæng, hvor mange godt kan finde på at logge ind/oprette brugere indenfor samme tidsinterval :S

Dét jeg skriver der kan være meget server belastende er at multi-hashe sine passwords, og derfor ikke anbefales til sider med mange requests.

Resten af systemets (i mine øjne) eneste ulempe er at den hashede streng bliver temmelig lang med SHA-256 hvilket naturligvis kan skabe problemet hvis du har rigtigt mange brugere og begrænset plads.
Det er normalt intet problem, men kan løses ved at benytte fx SHA1 istedet. - Men det er klart at der er en beslutning du skal tage inden du begynder at oprette brurege:)

Husk iøvrigt at generer et nyt statisk salt, samt evt. at ændre længden på det random salt:)