Er zijn twee veel gebruikte login methoden. Ik ken zelfs mensen die ze allebei gebruiken. twee keer login dus.
1) met behulp van .htaccess en htpasswd. (Google en vind)
2) met behulp van PHP sessions.
De eerst daar kun je in mijn beleving niet zo heel veel aan fout doen zolang je de htpasswd maar buiten de webroot houdt.
De tweede is wel een kleine studie.
Je moet zelf zorgen voor een inlogformulier en het controleren op gebruikersnaam en password. Je bent er ook zelf verantwoordelijk voor dat je de passwords versleuteld! opslaat. dit kan vrij makkelijk minimaal met sha1(). Het is niet perse noodzakelijk om de gebruikers op te slaan in de database (compleet met gebruikersnaam en password) maar het wordt vaak gedaan. de veiligheid van je gegevens is altijd in het geding als je zwakke wachtwoorden gebruikt voor je phpmyadmin, controlpanel, ssh en ftp.
even uit mijn hoofd een paar zaken waar je minimaal rekening mee moet houden ivm veiligheid:
- mysql injectie
- cross site scripting
- versleutelen wachtwoorden
- session hijacking
Captcha is voor een login niet nodig, voor een openbaar aanmeld script zou het wel kunnen.
Ip heb je niets mee te maken. met de session wordt er een cookie opgeslagen op de computer met daarin het session id.
[size=xsmall]Toevoeging op 09/12/2014 01:35:44:[/size]
Verder zijn er tal van zaken die de kans op een inbraak kunnen verkleinen:
- voorwaarden stellen waaraan een password minimaal moet voldoen
- na een aantal mislukte inlogpogingen de sessie blokkeren
- na een aantal mislukte inlogpogingen onder telkens dezelfde gebruikersnaam de gebruiker blokkeren
- de administrator waarschuwen bij een brute force aanval
- ip nummer blokkeren (kans bestaat hierbij wel dat iemand door een ander de dupe wordt)
Eerst wil ik je bedanken voor het plaatsen van je bericht, er staan heel veel dingen wat ik echt aan heb.
1) dit was ik vergeten door jou weet ik weer dat htaccess beveiliging nog extratje was. Hiermee kan je wachtwoord in een map plaatsen waarmee je eerst moet inloggen dat je daarna pagina kan zien.
2) dat is geen probleem om iets in elkaar te knutsellen eerlijk is eerlijk php is leuk en ik wil vooral zo goed als jullie worden dus jullie adviezen zijn goudwaard.
Dus als ik het goed heb kan je username en password (met sha1) in formulier gebruiken.
Dit spreken mij erg aan waarschijnlijk snap ik het:
-mysql injectie (gekke tekens verbieden)
-cross site scripting (javascripten etc etc)
-versleutel wachtwoord (moeilijke wachtwoord versleutel naar sha1 code)
-session hijacking (dit is waarschijnlijk cookie maar hoe kunnen we het best veilig houden?)
Oke, captcha is voor persoonlijke login niet nodig.
Dus we moeten met sessie cookies werken.
Inbraak verkleinen:
-minimaal 1 hoofdletter, 1 cijfer en minimaal 8 karaters gebruiken
-hoe kunnen we dit doen?
-hoe kunnen we dit doen?
-dit wil zeker leren
-dit wil ik als het eerste leren kan je mij hier meer over uitleggen?
-bij een ip blokkeren kan je zonder dat je het weet hele school en of bedrijf blokkeren.
Inbraak verkleinen:
-minimaal 1 hoofdletter, 1 cijfer en minimaal 8 karaters gebruiken
-hoe kunnen we dit doen?
-hoe kunnen we dit doen?
-dit wil zeker leren
-dit wil ik als het eerste leren kan je mij hier meer over uitleggen?
-bij een ip blokkeren kan je zonder dat je het weet hele school en of bedrijf blokkeren.
Eerst wil ik je bedanken voor het plaatsen van je bericht, er staan heel veel dingen wat ik echt aan heb.
1) dit was ik vergeten door jou weet ik weer dat htaccess beveiliging nog extratje was. Hiermee kan je wachtwoord in een map plaatsen waarmee je eerst moet inloggen dat je daarna pagina kan zien.
2) dat is geen probleem om iets in elkaar te knutsellen eerlijk is eerlijk php is leuk en ik wil vooral zo goed als jullie worden dus jullie adviezen zijn goudwaard.
Dus als ik het goed heb kan je username en password (met sha1) in formulier gebruiken.
Dit spreken mij erg aan waarschijnlijk snap ik het:
-mysql injectie (gekke tekens verbieden)
-cross site scripting (javascripten etc etc)
-versleutel wachtwoord (moeilijke wachtwoord versleutel naar sha1 code)
-session hijacking (dit is waarschijnlijk cookie maar hoe kunnen we het best veilig houden?)
Oke, captcha is voor persoonlijke login niet nodig.
Dus we moeten met sessie cookies werken.
Inbraak verkleinen:
-minimaal 1 hoofdletter, 1 cijfer en minimaal 8 karaters gebruiken
-hoe kunnen we dit doen?
-hoe kunnen we dit doen?
-dit wil zeker leren
-dit wil ik als het eerste leren kan je mij hier meer over uitleggen?
-bij een ip blokkeren kan je zonder dat je het weet hele school en of bedrijf blokkeren.
Nee; geen (gekke) tekens verbieden. Zeker niet in een wachtwoord. Door wachtwoord gecodeerd op te slaan, maakt een 'gek' teken niet uit. Sterker nog: het maakt een wachtwoord sterker (immers: hoe meer letters/cijfers/tekens gebruikt mogen worden, hoe moeilijker het wachtwoord te raden/kraken is).
Johan de wit op 09/12/2014 05:15:32
-versleutel wachtwoord (moeilijke wachtwoord versleutel naar sha1 code)
Niet een moeilijk wachtwoord versleutelen, maar elk wachtwoord ;-)
Koen Hollander wijst er terecht op dat je beter geen sha1 meer kunt gebruiken.
[quote="Johan de wit op 09/12/2014 05:15:32"]
-mysql injectie (gekke tekens verbieden)
Nee; geen (gekke) tekens verbieden. Zeker niet in een wachtwoord. Door wachtwoord gecodeerd op te slaan, maakt een 'gek' teken niet uit. Sterker nog: het maakt een wachtwoord sterker (immers: hoe meer letters/cijfers/tekens gebruikt mogen worden, hoe moeilijker het wachtwoord te raden/kraken is).
Johan de wit op 09/12/2014 05:15:32
-versleutel wachtwoord (moeilijke wachtwoord versleutel naar sha1 code)
Niet een moeilijk wachtwoord versleutelen, maar elk wachtwoord ;-)
Koen Hollander wijst er terecht op dat je beter geen sha1 meer kunt gebruiken.
[/quote]
Wat hij zegt klopt, en ik zou zeker MD5 afraden, iedereen kentc die term wel, en als je op google typt MD5 crack heb je zo paar honderd pagina's. Zelf zou ik sha256 aanraden
Misschien is dit een interessante pagina: https://crackstation.net/hashing-security.htm
Nog beter is je website te voorzien van een SSL certificaat. (eigenlijk een TLS certificaat tegenwoordig).
[size=xsmall]Toevoeging op 09/12/2014 11:09:04:[/size]
Het gaat bij mysql injection niet om gekke tekens. Queries worden geschreven in plain text formaat. Gegevens die gebruikers in jouw web formulier invullen is ook in plain text. De moeilijkheid is dus om gegevens gescheiden te houden van database opdrachten. Gelukkig kun je het tegenwoordig vrij makkelijk voorkomen door prepared statements te gebruiken met de mysqli functies van PHP of met PDO. Met de mysql functies (zonder i dus) moet je zeker niet meer willen werken.
cross site scripting betekend gewoon dat er vanaf andere computers naar jouw pagina ge-POST wordt. Jouw PHP script neemt als zoete koek aan dat de aangedragen gegevens oké zijn maar dat hoeft niet zo te zijn. Een manier om dit te voorkomen is een hidden inputfield in je <form> plaatsen met daarin een random sleutel. Deze sleutel bewaar je tevens in je database samen met de huidige datetime. Wordt het formulier gepost dan controleer je of deze sleutel inderdaad door jou is uitgegeven en niet al te oud is.
Session hijacking is het afpakken van een geldige session_id van een ander. Dit is moeilijk om helemaal te voorkomen. Maar een aantal dingen kunnen helpen. Maak naast de standaard sessie sleutel ook een eigen sleutel en zet deze in een cookie van de gebruiker. controleer de sleutel bij ieder request. Daarnaast helpt het erg goed om een TLS certificaat aan te schaffen voor de website.
Zo hey wat zijn er zoveel reacties, daar ben ik echt blij om. Hiervoor wil ik iedereen bedanken.
Natuurlijk mag je wat zeggen Kevin, ik ben gek op kritieken omdat ik daar veel van kan leren.
Met gekke tekens bedoelde ik " ' & tekens.
Voor TLS moet ik gewoon SSL bestellen? Er zijn veel soorten maakt dat ook wat uit?
Dus huidige systeem die op mysql is gebaseerd kan daarnaast mysqli ondersteunt worden?
Met cross bedoelde zo iets als dit? Dus iemand slaat je pagina als html op en past kleine dingen aan om vanaf zijn computer form te laten?
Naast sessie sleutel heb je ook eigen sleutel, wat noem je zo'n eigen sleutel dan zal ik even op google zoeken.
Ik zou die er gewoon in laten zitten. Kunnen gebruikers extra goed hun wachtwoord beveiligingen, bij naam zou ik hem er wel eventueel uit halen.
Voor TLS moet ik gewoon SSL bestellen? Er zijn veel soorten maakt dat ook wat uit?
Ik weet niet of ik mag linken hier, anders word de link snel verwijderd: https://www.secure.versio.nl/ssl
Daar vind je goede uitleg van SSL en ook bieden ze er een aantal aan.
Dus huidige systeem die op mysql is gebaseerd kan daarnaast mysqli ondersteunt worden?
Vaak wel maar kan per host verschillen maar het lijkt mij heel onwaarschijnlijk dat ze MySQLi uit hebben staan, ik zou ook zeker raden om MySQLi te gaan programmeren I.V.M. MySQL ouder raakt
Met cross bedoelde zo iets als dit? Dus iemand slaat je pagina als html op en past kleine dingen aan om vanaf zijn computer form te laten?
Zover mijn kennis is bedoeld hij dit.
Even nog toevoeging, ik raad aan om 1 van deze 2 te gaan gebruiken:
- htmlspecialchars()
- mysql_real_escape_string()
