AK Login Versie 1.0

Wil je het even tussen code tags zetten?

Ik wil even melden dat het wel heel diep gaat hoor, je kunt toch veel beter met regex controleren of de gegevens correct zijn ipv overal een ifje voor..

Ik heb het toch tussen PHP tags?

je kan ook in een aparte if-lus doen, en een fouten variabele, bijhouden, en die vullen als je een niet-ingevuld veld ontdekt.

Naar mijn mening komen al die geneste ifjes de overzichtelijkheid niet ten goede. Daar komt bij dat als je meerdere dingen verkeerd invult je steeds maar voor één een melding krijgt. Dan blijf je dus aan de gang, niet erg gebruikersvriendelijk.

Edit:
Inmiddels een behoorlijke spuit elf. Laat ik er dan nog maar even aan toevoegen dat die exit in de else ook niet erg netjes is, exit/die gebruik je bijna nooit, het breekt namelijk ook je html.

Daar ben ik het helemaal mee eens, Ik zal het onthouden voor de update.

/* Edit */



Ik gebruik ook nooit een exit, Dit is voor een voorbeeld bedoeld.
Het lijkt mij als mensen dit script gaan gebruiken dat ze de exit's er wel uit gaan halen.

En wat als een emailadres langer is? Dankzij het überbrakke MySQL ben je dan een corrupt "emailadres" rijker, die zet de botte bijl in de emailadressen. Er is geen enkele reden te bedenken om een kleiner veld aan te maken dan dat de emailstandaard (is die er?) voorschrijft. Gebruik gewoon een VARCHAR(255), hij bijt niet. Dat in tegenstelling tot MySQL...

De code is verder niet goed leesbaar, maar een wachtwoord ophalen in een SELECT, dat is geen goed plan. Ik heb dan ook m'n twijfels over de rest van de code.

Dit is trouwens ook nog een leuke:

- Gebruiker "jan" met wachtwoord "x"
- Gebruiker "jan" met wachtwoord "y"
Dat zijn 2 verschillende gebruikers, maar met de zelfde username. Vervolgens veranderen de wachtwoorden en kan het zomaar zijn dat de users van identiteit veranderen. Hoe wil jij dit uitelkaar gaan houden?

De gebruikersnaam moet uniek zijn, het wachtwoord zal je een rotzorg zijn. Zolang dit een sterk wachtwoord is, is er weinig aan de hand.

Het begon zo goed met innoDB en geen backtics in je query. Maar helaas, schijn bedriegt :-(. Ik had gehoopt op eindelijk eens een top loginscript waar eigenlijk niets op aan te merken valt, maar helaas, volgende keer beter.

Als je nou eens goed naar de code kijkt. Dan zie je dat er gecontroleerd wordt of de gebruikersnaam al bestaat.

;)

Als je nou eens goed nadenkt, dan bedenk je zelf ook dat deze controle niet betrouwbaar is. Je kunt zomaar met 100 man tegelijk een account aanmaken en zo de boel naar de bliksem helpen. Waarom zou anders een UNIQUE-constraint zijn uitgevonden? Alleen de database kan bepalen of iets uniek is, een SELECT-query levert altijd OUDE informatie op. Geen mens weet hoe die informatie er een duizendste van een seconde later uitziet. Ook jij niet.

En mocht jij gelijk hebben, waar slaat jouw unique-constraint dan op? Die zou dan volkomen overbodig zijn, jij hebt tenslotte jouw eigen controle. Niet dat deze controle goed is, maar dat staat daar even los van.

Kortom, je slaat hier en daar een plankje mis. Geeft niks, maar leer er van. Succes!

@ pgFrank

Inplaats van dat je de hele tijd begint te zeiken kan je ook uitleggen hoe je het kan oplossen en "wat volgens jouw" de beste manier zou zijn.

Een paar foutjes in me script en het lijkt net dat ik een moord heb gepleegd. Mensen zouden het eens bij jouw moeten doen. Misschien leer je er dan nog wat van.

Het staat er al, maar dan hier nog even op een rijtje:
- Nooit wachtwoorden (of eigenlijk: de wachtwoord-hashes) ophalen uit de database. Je hebt ze nooit nodig buiten de database, haal ze dan ook nooit op.
- Zet een UNIQUE-constraint op de gebruikersnaam en niet op een combinatie met andere kolommen.
- Zet geen beperking op de lengte van een veld wanneer er geen beperking is (emailadres). MySQL is onbetrouwbaar en zal jou niet informeren dat er een deel van de data is weggegooid. Voor MySQL is het verkloten van data een standaard functie, daar komt dus geen waarschuwing bij kijken.

En voortaan niet gaan jammeren wanneer je wat commentaar krijgt, daar kies je zelf voor. Er zijn mensen die meer weten dan jij, probeer daar van te leren. Daar word jij beter van.

En nee, ik weet lang niet alles. Maar ik weet wel veel van databases.

Hé !, Dat is een bruikbare comment ! Dankje wel !



Koop een lolly en ga het vieren. ;-)

@ pgFrank

Zou je dan nog eens kunnen kijken of de dingen nu correct zijn?

Als je in plaats van controleren of een variabele wel bestaat, controleert of hij niet bestaat, hoef je niet die else erachter te zetten. Dat scheelt weer inspringen, en zet de melding van de "fout" dichter bij de controle.


wordt dan

@ Jelmer

Klopt, Je hebt helemaal gelijk.

Bedankt voor je voorbeeldje, Ik ga het toepassen bij de update.

Toch is dit wel een van de betere moet ik zeggen

Als uitbreiding op de voorgaande stukjes commentaar:
- Maak een variable aan met daarin de fout berichten. Gebruik dan

of


Bij de laatste moet je dan via een foreach() alle foute berichten aan de gebruiker laten zien.

- Ipv exit moet je een manier bedenken waarop je script stopt EN de restjes html laat zien (kan door te kijken of je variable met fouten nog leeg is).

Veel plecier met verder coderen.

@ EuWas

Bedankt voor je reactie.

Zoals ik al eerder aangaf in de comments, Gebruik ik die exit's om het even snel af te breken. Natuurlijk gebruik je geen exit's !, Maar dit is als een voorbeeld bedoeld. In de volgende update zal ik voor de mensen die er toch zo een commentaar op hebben de exit's eruit halen.

Het lijkt mij, Als iemand dit script gaat gebruiken dat die er nog wel in gaat <strong>bewerken</strong>.

Dus nogmaals mensen, A.U.B geen commentaar meer op die exit's want die zal ik er uithalen in de volgende update !

Als jij je "AK login versie 1.0" beter wilt maken zorg er dan voor dat er SALT en SHA1 zooi bij komt..

Is md5 zo makkelijk te kraken dan?

Zo ja, Geef me dan eens een voorbeeld.

Het probleem bij md5 is, is dat de encryptie niet uniek is. Sha1 heeft dit nooit. Een salt in je sha1 maakt het moeilijker om het te bruteforcen.

@ Pepijn

Bedankt voor je reactie.

Als je het wachtwoord als md5 opslaat & bijvoorbeeld een wachtwoord als php77$ gebruikt, Dan is de kans om dat te bruteforcen toch echt miniem? Of zie ik dat nu verkeerd?

En gaan mensen echt heel veel moeite nemen om een wachtwoord te bruteforcen en om weken, Maanden te wachten totdat het is gebruteforced?

Joepie.. 19e in een dozijn

Uhm... een dozijn is 12 ;-) Dan kan je moeilijk 19e zijn.

Tegen bruteforcen heb je login time outs ;)

Wat is er gebeurd dan?

Zo te zien vrij duidelijk. Onze ark kan er niet zo goed tegen dat er commentaar geplaatst wordt bij een script.

@ Midas

Je 1e comment in dit script en je denkt gelijk waar het over gaat?
Ga toch dromen jongen.

Doe eerst eens wat research voordat je een conclusie trekt.

Wat is er dan gebeurd :O?

Lekker kinderachtig weer allemaal. Grow up.
@Ark: doe wat met het commentaar wat is gegeven en laat je niet zo uit de tent lokken. MD5 is niet veilig genoeg, dat is al meerdere keren bewezen, als je het niet gelooft, gebruik Google maar. Als je hierin een Salt en SHA1 encryptie gebruikt is dit al veel veiliger. Ook de opmerking van Iltar van der Berg was helpful, je kan bruteforcen afkappen door een timeout te geven, na 5 foute inlogpogingen ban je het IP voor 5 minuten (bijvoorbeeld), zo voorkom je dit.

@de rest: verlaag je alsjeblieft niet naar het niveau hoe hij reageert maar probeer professioneel te blijven en te helpen, want tenslotte is het altijd nog phpHULP en niet phpAFZEIK..