Gevorderde beveiliging
Alvast bedankt!
Ps: waar het mij vooral ook aan draait is dat ik het snap. Klakkeloos scripts van andere mensen overnemen kan iedereen en daar leer je niets van.
volgens mij hoort dit bij script aanvraag of koffie hoek thuis :o
michael schreef op 22.01.2008 17:41:
volgens mij hoort dit bij script aanvraag of koffie hoek thuis :o
Nee beiden niet. Ik hoef geen kant en klaar script, want zoals ik al zei; daar leer je niets van. Ik heb het liever dat ik 't begrijp wat er staat ;)
discussie op het forum waarin uitgebreid ingegaan werd op het gebruik van verschillende methoden voor beveiliging. Misschien dat je er wat uit kunt halen?
Er was laatst een Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
Oke bedankt ;) Er staat inderdaad veel in.
1. Authenticatie (Wie ben jij)
2. Authorisatie (Wat mag je)
3. Veiligheid van het script (zijn er manieren om om methode 1 en 2 heen te komen?)
Daarnaast zijn er nog andere overwegingen mee te nemen als:
Kan de informatie die nu verstuurd wordt onversleuteld over het web? (SSL).
Bij stappen 1 en 2 komen vaak sessies aan het woord. Een onderdeel daarvan is de discussie die aangestipt wordt over salt en hashes. Deze discussie is inprincipe niet zo erg interessant. Het cliche: het systeem is zo sterk als de zwakste schakel op. De bovenstaande discussie gaat over de marge van kraakbaarheid van wachtwoorden, terwijl bijvoorbeeld de manier waarop je met je SQL en je data omgaat veel gevoeliger is voor lekken dan of drie verschillende hashes uitmaakt boven een hash en een salt.
Deze gegevens sla ik (samen met het IP) op in de database. Alleen op ID inloggen is dan al niet mogelijk. Je moet precies dezelfde sessie hebben opgezet, en je computer (ip, browser, accept-language) moeten allemaal hetzelfde zijn, anders wordt je uitgelogd en kan je helemaal niets doen.
Ik geef toe dat dit niet waterdicht is, maar al een stuk beter dan veel van de scripts die uitgaan van een simpel ID voor authenticatie.
Daarnaast heeft Arend helemaal gelijk als hij zegt dat beveiliging eigenlijk het geheel is... In mijn systeem zit er in de database ook een koppeling met een usergroup, die op hun beurt weer met een koppeling (normaliseren! :P) aan rechten worden gekoppelt. Dat is dan weer niets meer dan "welke pagina mag je wel, of juist niet bewerken of zien".
Dus om door te gaan op Arend zijn bericht:
1. Wie ben jij: Kan je alleen doen door in te loggen.
2. Wat mag jij: Koppeling met die rechtentabel
3. Omweg: Alleen als je de sessie kan stelen, het ip naabootst en de rest van het systeem. -> Niet zo gemakkelijk als het lijkt!