Sikker innlogging - hva må til?

[LaStrada]

Hei!

 

Hva må til for å lage et sikkert innloggingssystem med sessions?

Hvordan må dette bygges opp? Hva slags funksjoner må brukes?

 

Har laget en del loginsystemer i løpet av min "karriere", men jeg har aldri helt skjønt hva som må til for at det skal kunne kalles sikkert..

 

 

Takker for svar!

[????????]

Dette har jeg postet mange svar om i dette forumet, så det beste du gjøre er å søke etter sikkerhet og logg inn eller login her så finner du mye.

[genstian]

bruk SSL eller noe og bruk javascript sha1/md5/sha256 legg passordene i en database og bruk sleep(); på 5sekunder eller noe for og hindre bruteforceing. bruk salt med rand lengde og helst på alle 256 ANSI tegn.

husk og bruk '' og ikke "" da $variabel blir noe.

ikke bruk registred_global

valg fritt:

mhash ditt sda1/md5/sha256 javascript passord for dual sikkerhet

mcrypt session din

ha noe som gjør at kun en bruker med det brukernavnet kan være innlogget

extremt valgfritt:

ha to passord og bruk HMAC i mhash.

ha hemmelig innlogging brukernavn og bruk et alias som skal visses, hvis du ikke har to passord kan du bruke det i HMACen din.

passord++; EKS passord_1 og neste gang passord_2 osv

 

da skulle du ha sikkerhet

[????????]

Okay, jeg skal skrive en liten guide. Hotstian kommer med noen bra forslag, men det er til og med noen der jeg ikke skjønner poenget med.

 

Krypter passord i databasen

Det første du må er å sørge for at alle passordene i databasen er kryptert. Da vil eventuelle hackere som ville klare å hacke seg inn i databasen din likevel ikke kunne logge seg inn i scriptet ditt. Hvis du for eksempel bruker funksjonen md5() så får du en hash som det ikke er mulig å dekryptere.

 

Brute force

Selv om det ikke er mulig å dekryptere med md5() hash så finnes det fortsatt muligheter for å finne ut hva passordet er like vel. For hver string du kjører md5() på returnerer en unik hash. Derfor er det mange som setter opp et script som tester alle mulig kombinasjoner til de finner samme hash. De tester for eksempel md5(”a”), md5(”ab”), md5(”ac”) og så videre hele veien til de finner en match. For å forsøke å hindre dette burde du ha lange passord (minimum 8 tegn) og bruke mange tegn inkl. tall. Det er ikke alltid like lurt som mange foreslår å bruke ekstra tegn som for eksempel Æ Ø Å ( ) # %. Grunnen til dette er at en bruker er kanskje i utlandet når de trenger å logge inn, og det vil ta de evigheter å finne igjen samme tegn på et annet tastatur.

 

Salting

Salting er at du i tillegg til passordet brukeren skriver inn legger til tekst i scriptet. Passordet forblir det samme for brukeren, men hele tiden i scriptet så legger du til samme tekst.

 

I tillegg til å kreve et langt passord burde du salte passordet. Det vil rett og slett si at du legger til for eksempel en string i tillegg til passordet. Hvis passordet er ”hemmeligpassord” kan det da være ”XXXXXXXXhemmeligpassord”. Dette gjør at passordet vil ta mye lengre tid å bruteforce det, eller finne det gjennom rainbowtables. Problemet med salting er dersom du bruker et statisk salt. Bruker du alltid XXXX så vil hackere se det fort og inkludere dette i bruteforcingen og hele poenget med salting er da borte. Bruk derfor et dynamisk salt som baserer seg på brukernavnet, dato, id eller en kombinasjon av dette. Du kan bruke md5(id.brukernavn.SUBSTR(dato,0,5)). Som du ser så la jeg til substr() der slik at man ikke bruker hele dato feltet. Da får du en dynamisk salting.

 

I tillegg kan du endre litt på md5() hashen. Hvis den ser slik ut: aaaaaaaaaabbbbbbbb så kan du endre den til bbbbbbbbbaaaaaaaaaa.

 

Sessions

Det er viktig å merke seg at en hvilken som helst bruker kan når som helst overta en annen bruker sin session. Derfor må du sjekke at brukeren virkelig er den samme brukeren før du gi han tilgang til sessionen. Sjekk ip og browsertypen og lagre en md5() hash av dette i sessionen. Stemmer denne neste gang brukeren går til en annen side så er det stor sjanse for at brukeren er den samme.

 

Sjekk passord for hver side

For hver eneste side brukeren går inn på så sjekker du logg inn info. Det holder ikke å sette en session variable til true. Det er ikke sikkert. I verste fall deler din side faktisk sessions med andre sider om du velger et vanlig webhotell isteden for en egen server. Lagre derfor md5() av passordet og brukernavn i sessionen og sjekk dette for hver side.

 

PHP kan stoppe

Ekstremt viktig er det å merke seg at PHP kan stoppe. Det vil da si at Zend engine sender selve teksten i scriptet videre til http serveren, og det som vises er selve kodene dine. Du må derfor aldri lagre passord og lignende i filer brukere kan åpne. Lagre alt dette i en egen mappe du beskytter med htaccess. Det samme gjelder også logg inn scriptet. Dette er det også viktig at ingen får se!

 

MySQL bruker med begrensede rettigheter

Et veldig enkelt triks er å bruke opprette en MySQL bruker (dersom du lager logg inn info i en MySQL database) er å opprette en egen bruker som har få rettigheter. Alt brukeren i utgangspunktet trenger tilgang til er å INSERT og SELECT, UPDATE og lignende er også kjekt. Men ikke mer enn dette. På den måten kan de ikke bruke den brukeren for å opprette en ny MySQL bruker å hacke databasen din.

 

Andre tips

Å bruke en funksjon som sleep() på login er kjekt for det reduserer mulighet til å hacke seg inn, men det stopper det ikke.

 

Bruk alltid mysql_real_escape_string() på all data fra brukeren.

 

Lagre alle logg inn forsøk. På den måten kan du se om samme brukeren har forsøkt å logge seg inn mer enn for eksempel 10 ganger. I så fall vis brukeren en link til glemt passord og ikke gi den mulighet til å logge inn igjen på for eksempel en time.

 

Bruk SSL. Det er da ikke nødvendig å bruke JavaScript og lignende for å kryptere passord. Dette burde heller aldri erstatte SSL.

 

Dette var en liten guide men det er viktig at du tar disse tipsene og søker videre på for eksempel google.com. I tillegg må du holde deg oppdatert om sikkerhetshull i PHP. Les også om sikkerhet i manualen, det er viktig! Kikk også på phpsec.org – den siden er fortsatt ganske ny, men den kommer seg.

 

Lykke til

[Cucum(r)]

Svært bra, ????????.

[genstian]

SSL kan også knekkes!!!

derfor synnes jeg SSL + javascript kryptert passord gjør jobben.

du kan også prøve AES da det er sikkrere en SSL.

[????????]

Hehe... hotstian, hvis du noen gang skulle treffe på en hacker som klarer å "knekke" SSL 128 bit kryptering så vil ikke javascript kunne hindre han på noen som helst måte, hvorfor?

Javascript lastes ned til brukeren, og hvem som helst kan se kilden og hvordan krypetringen foregår. Dermed tar det ikke mange sekunder å hacke det også.

 

Tanken er god hotstian, men som du sikker skjønner så er effekten så minimal - og spesielt dersom du møter på et hackerteam som klarer å dekryptere SSL.

[genstian]

Hehe... hotstian, hvis du noen gang skulle treffe på en hacker som klarer å "knekke" SSL 128 bit kryptering så vil ikke javascript kunne hindre han på noen som helst måte, hvorfor?

Javascript lastes ned til brukeren, og hvem som helst kan se kilden og hvordan krypetringen foregår. Dermed tar det ikke mange sekunder å hacke det også.

 

Tanken er god hotstian, men som du sikker skjønner så er effekten så minimal - og spesielt dersom du møter på et hackerteam som klarer å dekryptere SSL.

Joda, SSL er lett og knekke egentig og det er kange som har gjort det. AES-256(som brukes av dnbnor.no og mange andre) er være og TCL(?)-1024 er noe av det strengeste du kan få. RSA2(512++) er veldig bra, men har hørt at du heller burde bruke DSA(512++).

RSA2 som brukes i SSH1 er veldig sikkert og jeg bruker det selv.

 

AES som brukes av bankene må jo være sikkert også.

 

DSA som brukes i SSH2 er sikkerere en RSA2, jeg bruker det når brukere logger inn.

 

TCL(?) er utrolig sikkert og jeg tror ingen har greit og knekke det. TCL er ikke gratis.

 

Serveren burde bruke chroot apache med hardened php og oprativsystemet burde være Linux med SSP-PIC binærer og SELinux eller OpenBSD.

 

krypter filsystem og Zend encrypted PHP fil skader ikke

[????????]

Nå var det ikke det jeg svarte på, men at bruken av javascript i det tilfellet ville være meningsløst.

 

Når det kommer til selve brukern av SSL så kan du ikke komme å si at det er lett å dekode. Hvis du mener at du selv kan knekke det så kan jeg gjøre det kjempelett for deg å bevise hvor lett det er. Du skal få både min ip, en SSL server ip og tidspunkt jeg sender en request. Så kan vi poste her hva som står i meldingen serveren sender til meg. For å gjøre det lettere kan vi begrense oss til et ord.

 

Poenget er ikke at SSL er det beste som fins, men jeg regner med at 99% av brukerene av dette forumet ikke har egen server - men et webhotell - og må klare seg med SSL.

 

Si fra hvis du tar i mot utfordringen til å dekode SSL, hadde vært artig om du klarte det.

[genstian]

vel er ikke noen super hacker, men prinsipet er det samme.

SSL krypteringen bruker md5 fingerprint og CSR identifisering på serfikatet med bruk av DES eller var det RSA.

 

SSL er ikke konstant den strengen. jo bedre CSR jo sikrere, OpenSSL er ikke like sikkert som mange andre SSL motorer.

 

 

Prinsipet er enkelt resten kan være vanskelig.

 

Men uanset SSL er sikrere en ingenting

Endret 20. august 2005 av hotstian

[zokra]

Synes nesten at Henrik Lied's innlegg burde vært stichy, ettersom de fleste php-prosjekter som ligger på nett inneholder en admin eller medlems-system

[Sono Juventino]

Du mener vel ????????(?)

Endret 21. august 2005 av ett

[Zic0]

Nå som vi er inne på det med SSL. Jeg har et webhotell som støtter SSL. Hvordan er det man kan bruke det?

[????????]

I de fleste tilfeller så holder det å gå inn på https://www.dittdomene.no. Dersom du da ikke får opp din side så har serveren sikkert en egen mappe for https file. Denne mappen pleier å hete private_html.

 

Edit:

Du vil sikkert få opp en advarsel om at dataene er kryptert, men at det ikke finnes et sertifikat. De fleste kontrollpanelbaserte hosting selskaper lag deg legge inn ditt eget sertifikat som du kan kjøpe fra f.eks. www.verisign.com eller www.geotrust.com.

Endret 21. august 2005 av ????????

[genstian]

du kan jo skaffe deg et gratis serfikat.

 

på verisign.com koster det $995 for et år

Endret 21. august 2005 av hotstian

[????????]

Det er ikke noe problem, du kan til og med lage et eget. Problemet er at uten nøkkelen fra f.eks. verisign så vil advarselen likevel dukke opp - og da er det ikke mye poeng. Det finnes kjempebillige alternativer, men disse har meget dårlig browserstøtte.

[Zic0]

Jeg har SSL serfika key. Så det er ikke farlig

[jorgis]

Å bruke en funksjon som sleep() på login er kjekt for det reduserer mulighet til å hacke seg inn, men det stopper det ikke.

 

Bruteforcing over nettet går uansett såpass treigt at sleep() bare vil føre til at folk blir irritert over lang innloggingstid.

[????????]

Hei jorgis,

det høres litt ut som du gjetter her - merk: jeg forsøker å si det med en hygelig tone.

 

Det er lenge siden hackere man kunne beskrive en hacker som en person med en gammel data som surfer over et modem. I dag er det hackere med tilgang til hele serverparker, og når du først får besøk av et hacker team så er det ikke snakk om at ting går tregt. Det er serveren din som reduserer hastigheten deres. Tenk deg at de sender 10 000 login requests til serveren din, og du har en sleep på 2 sek. Da betyr dette at de må venten 20 000 sekunder eller over 5 og en halv time ekstra. Mens for en vanlig person så betyr 2 sekunder ingen ting. Glem ikke at den vanligste tidsfristen en surfer er villig til å vente er 10 sekunder. Så jeg håper du ser fordelen

 

Videre så har denne sleep() funksjonen ingen ting å gjøre med bruteforce. Bruteforce foregår enten på en hacker sin maskin, i et nettver av maskiner til hackere eller i rainbowtalbes. Der knekker de koden før de forsøker å logge inn. Så dette har ingen ting å gjøre med bruteforce.

 

Det er der i mot flott at du kommer med din mening. Det blir opp til hver enkelt programmerer å avgjøre om de mener 2 sek virkelig betyr noe som helst for de som logger inn. Det er et stort hinder for hackere og det kan vel være en del å tjene på det.

Endret 27. august 2005 av ????????

[jorgis]

Hei jorgis,

det høres litt ut som du gjetter her - merk: jeg forsøker å si det med en hygelig tone.

 

 

Helt greit.

 

Det er lenge siden hackere man kunne beskrive en hacker som en person med en gammel data som surfer over et modem. I dag er det hackere med tilgang til hele serverparker, og når du først får besøk av et hacker team så er det ikke snakk om at ting går tregt. Det er serveren din som reduserer hastigheten deres. Tenk deg at de sender 10 000 login requests til serveren din, og du har en sleep på 2 sek. Da betyr dette at de må venten 20 000 sekunder eller over 5 og en halv time ekstra. Mens for en vanlig person så betyr 2 sekunder ingen ting. Glem ikke at den vanligste tidsfristen en surfer er villig til å vente er 10 sekunder. Så jeg håper du ser fordelen

 

At det er lenge siden folk satt på modem og snoket rundt (sett "hackers" i det siste? ) vet jeg, og det er heller ikke det som er poenget. La oss si noen prøver å komme seg inn i et script jeg lager uten å ha tilgang til f.eks. databasen hvor md5-hashete passord ligger lagret. Uansett om jeg legger på to sekunders sleep() eller ikke vil det ta temmelig lang tid for dem å knekke ett enkelt passord. Og om de har md5-hashene og f.eks. metoden jeg bruker vil ikke 10 000 logins være nødvendig (om ikke de har 10 000 brukere de vil stjele).

 

La oss si jeg har serverplass på et gjennomsnittlig webhotell. Serveren jeg er på er da sånn passe småtreig, og for en vanlig bruker vil login ta noen sekunder inkl. lasting av alle data, og om noen skal prøve 10 000 login requests (eller mest sannsynlig mer) vil bare HTTP-overføringen av alle data (for ikke å snakke om inntrengeren, som må parse dataene for å finne ut om han kom inn) fra serveren min gjøre ting for treigt. Det eneste jeg ser sleep() vil gjøre er å redusere lasten på serveren som blir angrepet, og forhåpentligvis hindre at PHP kræsjer og blotter all kildekoden.

 

Videre så har denne sleep() funksjonen ingen ting å gjøre med bruteforce. Bruteforce foregår enten på en hacker sin maskin, i et nettver av maskiner til hackere eller i rainbowtalbes. Der knekker de koden før de forsøker å logge inn. Så dette har ingen ting å gjøre med bruteforce.

 

Det avhenger jo om de har hashen (og metoden jeg bruker for å hashe) før de prøver å komme seg inn, så det er ikke helt riktig. Men om de har hashen (typisk default IPB hvor noen finner en SQL injection exploit og henter ut admin-passord el.l.) og metoden, så stemmer nok det, ja.

 

Det er der i mot flott at du kommer med din mening. Det blir opp til hver enkelt programmerer å avgjøre om de mener 2 sek virkelig betyr noe som helst for de som logger inn. Det er et stort hinder for hackere og det kan vel være en del å tjene på det.

 

Jeg er for optimalisering, og dermed vil jeg så langt det er mulig unngå å legge til tregheter i systemet. Det jeg heller anser som mye viktigere er å sikre hva som skjer videre etter innlogging, da det ofte er lett å slurve på det punktet.

 

 

Det er forresten ikke alle tips som er mulig å følge om man f.eks. skal skrive kode ment for å passe på så mange plattformer/oppsett som mulig, eller om kildekoden er fritt tilgjengelig (GPL). Da er det spesielt viktig å sørge for f.eks. at man ikke bare stoler på at en omrokering av md5-hashen vil løse problemet eller at et statisk salt vil fikse alt. Å bruke htaccess er ikke mulig, da det er en apache-only greie, og å opprette nye mySQL-brukere er ikke alltid mulig heller.

 

Greit at disse tipsene er veldig greie å ha om man styrer serveren selv, eller skriver for ett spesielt oppsett, men portabilitet og effektivitet er høyt på min prioriteringsliste.

 

Ren og oversiktelig kode er forresten også noe som har blitt fryktelig nedprioritert hos enkelte (*host*cutenews*host*PHPnuke*hark*). Security by obscurity er feilslått når man har med GPL å gjøre.