Er det vanskelig å lage sin egen login-side?

[salah]

Hei.

 

Jeg har som sagt tenkt på å lage hjemmeside, og da har jeg lyst til å få til et registrerings- og logginn-system.

 

Som topic sier, blir det da vanskelig å lage sin egen logginregistersystem hvor brukere logger seg inn, og skriver inn artikler eller tips som blir sendt via mail?

 

Jeg kan selv fikse send-mail-scriptet, men lurer på om det blir vanskelig å få til å lage et logginsystem via bruk av PHP og MySQL.

 

Jeg hat tenkt til å ha et adminsystem hvor jeg kan slette/legge til medlemmer og at medlemmene som logger inn skal være logget inn "overalt" på siden min.

 

Nok en gang spør jeg om dette blir vanskelig!

 

Jeg kan gjøre en del med PHP, og jeg klarer å connecte til MySQL baser via PHP og klarer fint å lage tabeller i MySQL, men er ikke ekspert på PHP.

 

Sorry rotete post, er overtrøtt og vil ikke legge meg fordi det er så morsomt å programmere i PHP.

 

Jeg er takknemlig for alle svar.

 

Edit: Post nummer 100

Endret 18. juli 2004 av pavlion

[Loomy]

Burde ikke være verdens vanskeligste oppgave (ikke at jeg kunne tenkt meg å lage noe altså ). Se på bruk av session slik at brukere kan være logget inn "overalt" på siden.

 

EDIT: Og ja! Det er gøy å mekke PHP *nettopp ferdig med EpleBook v0.9*

Endret 18. juli 2004 av Loomy

[????????]

Hvor vansklig det er å lage et login system er helt avhengig av hvor sikkert du vil ha det. Å bruke sessions er en god løsning så lenge du skal lagre mindre viktige detaler, men dersom du skal lagre noe så viktig som login informasjon må du minst sjekke litt flere ting om brukeren.

 

Det er lett å ta over en session, slik at en annen bruker kan rett og slett ta over identiteten til sessionene - alt men trenger å gjøre er å vite PHPSESS variablene, som en hacker lett kan få tak i.

 

Derfor burde du lagre følgende opplysninger i sessionen i tillegg til brukernavnet og passordet (passordet burde krypteres):

- IP

- Browsertype

- En timestamp

Slå gjerne sammen ip og browser og krypter de også. Så for hver gang brukeren vil åpne siden så sjekker du brukernavn, passord, ip og browseren. Gir du en hacker lang nok tid vil det fortsatt være mulig å lure serveren, så du burde også sjekke en timestamp - er det mer enn 15 min siden brukeren var aktiv på siden må de logge inn på nytt. Glem ikke å oppdatere timestampen hver gang brukeren åpner en ny side og login infoen stemmer.

 

Om bruken av variabler sendt fra brukeren som ip alltid er like heldig er en litt annen diskusjon, siden noen får av og til ny ip. Så lenge scriptet er ikke er ment for aol brukere så er det faktisk et ganske lite problem, for de fleste andre brukere får skjelden ny ip - og skulle de få det er det jo bare å logge inn på nytt.

[salah]

Hm... Så litt avansert ut.

 

Men jeg tror ikke siden min inneholder mye intressant å hacke, utenom at jeg skal legge ut noen ting jeg selv har laget. Men jeg skal huske på det du "???????" sa

 

Jeg bruker kun Linux, er det det samme å hacke Linux som Windows eller er det mer avansert?

 

Loomy: Jaja det er gøy ja

[????????]

Å hacke php scripts er ganske det sammen uavhengig av hvilket server du er på. Serverhacking er en annen sak, men så lenge det er snakk om scripts så hjelper det lite hvilket os du har.

[LoS]

Har du lyst til å utdype det du snakker om ang. session hacking ???????? ?

Altså, hvis jeg md5 enkrypter en session som jeg kaller for "paasswojd", i tillegg som jeg ikke gir ut scriptet til nedlasting, hvor enkelt hadde det da vært å hacke en session?'

 

Som f.eks, hvor enkelt hadde det vært å hacke en session check funksjon som er basert på dette:

function check(){
if(getenv("HTTP_USER_AGENT")!=$_SESSION["browser"] OR getenv("REMOTE_ADDR")!=$_SESSION["ip"] OR !session_is_registered("id") OR !session_is_registered("brukernavn") OR !session_is_registered("mode")){
 	echo "<p>Du må være logget inn for å ta i bruk administrasjonspanelet!<br /></p>";
           exit;
}
}

Hadde vært rimelig kjekt å vite skjønner du

 

edit: fjernet noen ekstrafunksjoner som ikke var nødvendig å ha med.

Endret 19. juli 2004 av LoS

[????????]

Sessions er utrolig lett å hacke, alt en hacker trenger å gjøre for å overta en session er å gjette på riktig PHPSESSID.

 

Det finnes to enkle måter å gjøre dette på:

1. "lytte på trafikken". Dvs. at en hacker fanger opp all trafikk mellom deg og serveren, og på den måten fanger opp PHPSESSID variabelen. En måte å unngå dette på er sette opp en SSL, f.eks. openSSL som krypterer trafikken slik at hackere da først fange den opp å så dekryptere den, noe som vil være veldig vansklig å ta tid.

2. En hacker kan sette opp et script/program som "gjetter" på mulige PHPSESSID verdiger.

 

Dersom en hacker klarer å få tak i PHPSESSID og besøker siden med den, så vil php tro at dette er den samme brukeren som den som hadde sessionen tidligere.

 

Derfor burde en absolut lagre variabler om brukeren, som IP og browser type og sjekke dette. På den måten må hackeren ha samme IP og browser for at scriptet skal bruke den sessionen.

 

Problemet stopper desverre ikke der, variablene burde på en eller annen måte krypteres. De fleste har hjemmesiden sin på et webhotell, og da vil det være mulig for andre brukere å opprette en session for en annen side. Dette forutsetter at det er samme webhotell, men dersom siden din blir stor er det ikke noe problem for en hacker å opprette en konto på samme hotell som deg. Lagre derfor f.eks. variabelen i sessionen på denne måten md5(browsertye."hennelig ord".IP) - og sjekk den derfor på sammen måte.

 

Det er ennå et lite problem. Hvis du gir en hacker lang nok tid blir det lettereå hacke en side. Et bra tips er derfor å sette opp en tidsbegrensning. Dersom det scriptet ikke godtar sessionen f.eks. etter det har gått 5 min så bil der vanskligere å hacke, i tillegg til at du sikrer siden med tanke på at en bruker kan forlate maskinen og noen kan fysisk ta over maskinen. Glem ikke å oppdatere den tiden for hver side brukeren besøker og brukeren blir godkjent. Sessions har en defalut utløpstid på 180 minutter - dette kan være veldig mye tid dersom det er snakk om et beskyttet brukerområde.

[????????]

Samme post kom to ganger.

Endret 19. juli 2004 av ????????

[Nervetattoo]

Selv bruker jeg en saltet og kryptert user_agent streng.

Er vell gjerne AOL som kjører et merkelig og ødelegende system på ip'er for sine brukere.

Slik at IP for en AOL bruker kan forandres når som helst, har valgt og ikke bruke IP pga det.

 

Skal siden være "helt" sikker med tanke på å overta session til en bruker bør du vell også bruke ssl. Om brukernavn og passord sendes i klartekst og noen lytter etter dette vil de jo bare kunne bruke det for å logge seg selv inn som brukeren.

[????????]

Passord burde alltid krypteres! I databasen og i sessionen. Dette hindrer en hacker fra å kunne logge seg inn selv om hackeren klarer å få tak i brukerdatabasen.

 

Et annet vanlig problem er at mange glemmer å "vaske" variabler før de går inn i mysql. Bruk alltid mysql_escape_string() på alle variabler som brukeren har sendt før de sendes til databasen.

 

SSL er alltid kjekt, men ikke alle webhoteller tilbyr dette og det kan i noten tilfeller være litt ekstremt.

[jorgis]

Ville det vert en god ide å kjøre md5-krypteringen _før_ den sendes fra bruker? Altså kjøre et javascript som krypterer det aller viktigste. Kunne forhindret at noen sniffer, ihvertfall.

[????????]

Absolutt, det eneste problemet er at det er hele 10% av alle surfere som av en eller annen grunn ikke har JavaScript. Dette kan skyldes gamle browsere, slått av, brannmurer og lignende.

 

Man løser dette ved å opprette et tomt felt som får en verdi dersom et javascript klarer å kryptere feltet, for har jo brukeren javascript aktivert. En ting som er verdt å merke seg er at md5 ikke er særlig sikkert.

 

El Nino la for en stund siden ut et bra script her på forumet som "dekodet" md5() krypteringer. Av en eller annen grunn ble det scriptet fjernet fordi en moderator som kan PHP oppfattet det som hacking å vise andre hvordan man gjør det! I steden for å sette posten på toppen av forumet for å vise at funksjonen ikke er helt sikker fjernet moderatoren koden.

[Stonescream]

Noen tips:

ikke bruk javascript som validering på passord og annet.

Kommunikasjonen mellom server og database bør være kjørt i sql prepared setninger.

 

fjern tekstelementer som kan gi div. kode som: <> () osv...

finnes php funksjoner for dette mener at heter noe som stripslashes eller no i den dur.

 

på phpfreaks.com ligger tutorial for nivåbasert medlemsskapsystem.

admin, superbruker, vanlig osv...

 

om ikke en fasit så gir den deg nok noen tips

[Nervetattoo]

Validering av input felter kan absolutt gjøres med javascript.

Men for all del ikke stol på det, kjør alt server side med php etterpå.

Poenget med å bruke javascript validering er slett ikke og validere, men å kunne tilby brukeren en kjapp respons om for eksempel et felt skulle mangle.

 

Kryptering av passord i database bør altids gjøres selvfølgelig. En annen funksjon for å øke sikkerhet med tanke på bruteforce cracking av passord om noen skulle få tak i databasen er og bruke en såkalt "salted string", saltet streng.

Eksempel:

 

$salt = "abc123";

$passord = $salt.$vasketPassord;

 

Så kan du enten kryptere hele passord variabelen, eller bare legge til en salt på et allerede kryptert passord.

Bruk samme "saltet" for en side. Da må den som skal finne ut av passordet fra databasen som han har klart å få tak i vite hva du bruker som salt for å komme noen vei.

[????????]

Å "salte" passordet er en god løsning, men ikke på den måten. Siden f.eks. md5() vil returnere et bestemt antall tegn, så "saltingen" må legges i stringen.

[Nervetattoo]

Som jeg sa kan du salte og så kryptere, eller legge til saltet på en kryptert streng.

Du kan fint legge en salt på et bestemt punkt, si etter tegn 5 i md5 strengen. Det vil da være helt umulig for den som vil bruteforce md5 strengen din å vite at du har lagt inn en x lang salt mitt i md5 strengen.

Så du må ikke salte strengen før kryptering heller for å gjøre det vanskelig, men det er selvsagt lettest

 

Merkelig at alle disse svarene og diskusjonen kom i nettop en tråd hvor noen spør om det er vanskelig og lage en login. Håper ikke trådstarter tror at alt dette må til.

 

Det hadde kanskje vært en ide om vi hade satt sammen en sticky tråd hvor vi listet opp tekniker og metoder som brukes for å lage en login som er noenlunde sikker. Så kan man bare referere til den for å vise hvilke muligheter man har for å sikre seg ??

[Blodhemn]

Mye omtale av salt i det siste. Hvorfor heller ikke kjøre md5 på en streng som allerede er kryptert med md5. Vil ikke dette være det samme som å salte en streng?

 

Det vil jo gjøre det vanskeligere å bruteforce en streng med tanke på at 32 tegn i hexadecimal gir en stakkar mildt sagt en bråte med mulige kombinasjoner?

 

Eller er det noe jeg har gått glipp av når det gjelder dette?

 

EDIT:

Ved ettertanke så ser jeg kanskje et problem her. Bruteforcing går jo mer eller mindre ut på å lagre forskjellige ord og så md5'e de og legge det inn i en database. Er ingenting som hindrer de å legge på både annen generasjon og tredje generasjon md5 i tillegg da.

Endret 21. juli 2004 av Blodhemn

[????????]

Det blir litt verre å finne å finne tilbake til en enkel string dersom den er kryptert flere ganger, men ikke mye. Siden det er flere som gjør det på denne måten er det desverre ikke sikkert det heller.

Endret 21. juli 2004 av ????????

[????????]

Blodhemn: jeg sendte deg en PM - svar på den hvis du vil ha et eksempel på svakheten ved md5(). Som nevnt tidligere i denne tråden så ble scriptet til El Nino slettet så jeg ønsker ikke å vise hvordan det gjøres, da jeg opplyser om dette for å stoppe hacking og ikke fremme det.

 

El Nino la ut scriptet for å vise svakheter han også, og ikke for å fremme hacking.

Endret 21. juli 2004 av ????????

[Blodhemn]

Å vise folk hvor lett md5 kan knekkes er en god måte å overbevise hvor usikkert det er og hvordan man best beskytter seg mot det.

På en annen side så kan jeg lett forstå at man ikke ønsker å vise fram et slikt script på den måten. Det kan veldig lett gjøre mye skade.

 

 

Jeg ante ikke at det kunne knekkes så raskt. 8 sekunder på en 4 karakterer lang streng er ganske raskt. Spesielt med tanke på at folk gjerne velger passord som er lette å huske (og derfor ofte veldig korte)

Endret 21. juli 2004 av Blodhemn