[PHP] Wachtwoord hashen waar moet je rekening mee houden?

[hoi1234]

Mijn vraag
Voor een project dat ik op school doe, moet ik een website bouwen. De front-end heb ik al af. Nu moet ik beginnen aan de back-end. (In PHP) Maar ik vraag me af waar ik rekening moet houden op het gebied van password hashing. Houdt er a.u.b rekening mee dat dit een propedeuseproject is. Mijn website mag zo lek als een mandje zijn, het gaat nu vooral om de codekwaliteit en het opleveren van een werkende website. Toch hoor ik wel graag wat de best-practises zijn in een bepaalde situatie (daar leer ik ook van), maar het kan dus zijn, dat het (nog) te hoog gegrepen is voor mij.

1) Hoe verklein ik de kans dat wachtwoorden gekraakt worden met rainbowtables, brute-force, dictionary attacks en look-up tables?
*Is het voldoende om password_hash() te gebruiken (= PHP functie)
=> Zo nee, wat zijn mijn mogelijkheden, om dit risico zelf te beperken?
a) Voldoende sterke wachtwoorden (lees: wachtwoorden > 30 karakters) te gebruiken.
b) andere, betere oplossingen?

Nadeel aan wachtwoorden > 30 karakters is natuurlijk, dat dit niet echt gebruikersvriendelijk is. Ik ben bang dat je hier ook een flink stuk schijnveiligheid mee creëert. Een hoop mensen zullen hun wachtwoord opschrijven in een word document of in hun agenda.

2) Zijn prepared statements (gebruik PDO) voldoende om de kans op (welke vorm dan ook van) injection, veroorzaakt door het toestaan van vreemde tekens in wachtwoorden te beperken?
Ik heb al een discussie gehad met de docent, of de kans op injection aanzienlijk toeneemt als je vreemde tekens toestaat. Als ik hem goed begrepen heb, is het geen probleem om vreemde tekens te gebruiken, maar op het moment dat (groepjes) van vreemde tekens naast elkaar staan, dit tot ongewenste situaties kan leiden. Mijn docent gaf het advies om prepared statements te gebruiken, om injection te voorkomen. Maar is dit advies compleet?

3) Voldoet Bcrypt of is het verstandig om ARGON 2 te gebruiken?
password_hash() gebruikt standaard het Bcrypt algoritme om een wachtwoord te hashen. Is het verstandig om ARGON 2 te gebruiken, omdat dit veiliger is. (wordt aangeraden door OWASP). Het voordeel aan het standaard algoritme, is dat dit continue geüpdatet wordt. Maar het nadeel is, dat je Bcrypt moet gebruiken. Welke voordelen en nadelen wegen nou zwaarder?

Relevante software en hardware die ik gebruik[
-Windows laptop (i7 6700HQ 8GB RAM en GTX950m GPU)
-XAMPP

Wat ik al gevonden of geprobeerd heb
Ik heb al flink gegoogled en aan mijn docent zijn mening hoe ik dingen zou moeten implementeren. Maar ik blijf toch zitten met vragen. Vooral, omdat ik niet alles op google gevonden krijg (verkeerde zoektermen, misschien) en mijn docent veel vragen beantwoord, met dat hij het ook niet weet, omdat hij geen securityachtergrond heeft, maar dit soort zaken altijd uitbesteedt.

[PatrickH89]

1) Gebruik een goed algoritme (Bcrypt is zeker nog afdoende en een industriestandaard).

2) In principe maakt het niet uit wat voor vreemde tekens er in een wachtwoord staan aangezien je het hasht voordat je iets met de database gaat doen in praktisch alle gevallen. Prepared statements gebruiken (en daarmee user input altijd wantrouwen) zijn voldoende om SQL injection onmogelijk te maken.

3) Bcrypt voldoet prima en wordt in ieder geval nog standaard in Laravel gebruikt. Ik vermoed ook nog steeds in andere vooraanstaande frameworks.

[hoi1234]

PatrickH89 schreef op vrijdag 22 december 2017 @ 16:42:
1) Gebruik een goed algoritme (Bcrypt is zeker nog afdoende en een industriestandaard).

2) In principe maakt het niet uit wat voor vreemde tekens er in een wachtwoord staan aangezien je het hasht voordat je iets met de database gaat doen in praktisch alle gevallen. Prepared statements gebruiken (en daarmee user input altijd wantrouwen) zijn voldoende om SQL injection onmogelijk te maken.

3) Bcrypt voldoet prima en wordt in ieder geval nog standaard in Laravel gebruikt. Ik vermoed ook nog steeds in andere vooraanstaande frameworks.

Bedankt voor het beantwoorden van mijn vragen. Ik sta uiteraard nog open voor de mening van anderen. (zeker op dit gebied, is er veel discussie mogelijk).

[Demonitzu]

password_hash() is prima voor wachtwoorden met Bcrypt en biedt tevens een "salt" aan, waarmee elke hash uniek is ook al zouden al jouw gebruikers hetzelfde wachtwoord gebruiken. Als je persé ARGON2 als algoritme wilt gebruiken, heb je wel php 7.2 nodig (of je laadt een externe library in waardoor je die algoritme wel kan gebruiken). Maar Bcrypt is prima. Zolang je maar geen md5 of iets in die richting gebruikt.

De hash van password_hash() slaat in de string ook de gebruikte algoritme op, waardoor je eenvoudig kan overschakelen naar een andere algoritme als dat ooit nodig zou moeten zijn.

[hoi1234]

Toshin schreef op vrijdag 22 december 2017 @ 17:05:
password_hash() is prima voor wachtwoorden met Bcrypt en biedt tevens een "salt" aan, waarmee elke hash uniek is ook al zouden al jouw gebruikers hetzelfde wachtwoord gebruiken. Als je persé ARGON2 als algoritme wilt gebruiken, heb je wel php 7.2 nodig (of je laadt een externe library in waardoor je die algoritme wel kan gebruiken). Maar Bcrypt is prima. Zolang je maar geen md5 of iets in die richting gebruikt.

De hash van password_hash() slaat in de string ook de gebruikte algoritme op, waardoor je eenvoudig kan overschakelen naar een andere algoritme als dat ooit nodig zou moeten zijn.

Duidelijk! Ik gebruik nu al PHP 7.0.16, deze zou volgens de docent prima moeten zijn, dus dan laat ik het op Bcrypt. In ieder geval fijn dat jullie je mening willen delen. Zorgt er alleen voor dat ik meer leer en mijn keuzes beter kan verdedigen tegenover de docent. (Keuzes verdedigen is wel heel belangrijk bij ons op school)

---

Wat nog niet in de TS staat, maar ik eigenlijk wel wou vragen is het volgende:

Wat vinden jullie van een minimale lengte, minimaal aantal kleine letters, minimaal aantal grote letters, minimaal aantal vreemde tekens afdwingen voor het wachtwoord? Het nadeel aan regeltjes, is natuurlijk dat een eventuele hacker, makkelijk weet waar een wachtwoord aan moet voldoen en zodoende al een hoop mogelijkheden kan afstrepen. Echter zeker bij de minder lange wachtwoorden, zorgt dit voor een flink sterke wachtwoord (lees: meer mogelijke wachtwoorden mogelijk. Mijn vraag is dus, zorgen dergelijke regeltjes voor voldoende extra 'wachtwoordsterkte' of is het vooral een nadeel, omdat een hacker ook weet wat de regeltjes zijn en makkelijk wachtwoorden kan uitsluiten.

[Jantje2000]

Ik zou persoonlijk niet laten aangeven aan welke regels een wachtwoord moet voldoen, want met die regels kom Aa1@aa bijvoorbeeld er ook gewoon doorheen. (Wanneer 1 hoofdletter, 1 kleine letter, 1vreemd teken en minstens 6 letters.

Bruteforcen zul je gewoon niet helemaal kunnen voorkomen, maar wat ik zou gebruiken als beveiliging is dat je x minuten moet wachten na 3 foute inlogs. Want dan voorkom je het ook, terwijl je mensen geen domme regeltjes e.d. oplegt

[hoi1234]

Jantje2000 schreef op vrijdag 22 december 2017 @ 17:23:
Ik zou persoonlijk niet laten aangeven aan welke regels een wachtwoord moet voldoen, want met die regels kom Aa1@aa bijvoorbeeld er ook gewoon doorheen. (Wanneer 1 hoofdletter, 1 kleine letter, 1vreemd teken en minstens 6 letters.

Bruteforcen zul je gewoon niet helemaal kunnen voorkomen, maar wat ik zou gebruiken als beveiliging is dat je x minuten moet wachten na 3 foute inlogs. Want dan voorkom je het ook, terwijl je mensen geen domme regeltjes e.d. oplegt

Dat is een goede, ja! Op deze manier bereik ik toch mijn doel (= kans op brute-force-attack / dictionary-attack inperken), zonder al die vervelende nadelen. (alleen even kijken hoe ik dat implementeer, maar dat moet wel lukken.)

[Icekiller2k6]

Als tig keer het verkeerde ww gebruikt is, kun je een code naar mail adres sturen als extra bevestiging. Als op eens van een totaal andere locatie wordt aangemeld ook (bv ander land).

Tevens kun je aan wachtwoord een extra woord koppelen bv eerste x cijfers van user/email..
Zodat hash van 2 Users met hetzelfde ww anders gaat zijn

[ Voor 25% gewijzigd door Icekiller2k6 op 22-12-2017 17:48 ]

[Demonitzu]

Precies wat Jantje2000 hierboven zegt. Het irriteert jouw gebruikers alleen maar met het verplichte gebruik van zoveel hoofdletters, zoveel cijfers, etc. ten koste van een echt goed wachtwoord. Als je iets moet kiezen, zou ik een lang wachtwoord proberen te opperen. Minstens 8 tekens en gèèn maximum qua tekens (al geloof ik wel dat Bcrypt alleen de eerste 72 tekens hashed)

[TommieW]

Hashing van een wachtwoord is al een flinke stap in de goede richting. Het is nog beter om het wachtwoord ook te salten. Voordat je het wachtwoord hasht, plak je er een (per gebruiker) willekeurige tekenreeks achter. Deze tekenreeks kan je gewoon als plain-text in je database opslaan. Ook al hebben twee gebruikers hetzelfde wachtwoord, dan zal er alsnog een andere hash uit komen.

[downtime]

Icekiller2k6 schreef op vrijdag 22 december 2017 @ 17:46:
Tevens kun je aan wachtwoord een extra woord koppelen bv eerste x cijfers van user/email..
Zodat hash van 2 Users met hetzelfde ww anders gaat zijn

Ofwel: Als de gebruiker zijn email of username wijzigt, is ie verplicht om het password ook meteen te wijzigen?

[Demonitzu]

TommieW schreef op vrijdag 22 december 2017 @ 17:49:
Hashing van een wachtwoord is al een flinke stap in de goede richting. Het is nog beter om het wachtwoord ook te salten. Voordat je het wachtwoord hasht, plak je er een (per gebruiker) willekeurige tekenreeks achter. Deze tekenreeks kan je gewoon als plain-text in je database opslaan. Ook al hebben twee gebruikers hetzelfde wachtwoord, dan zal er alsnog een andere hash uit komen.

Salten gebeurt automatisch met password_hash()

[hoi1234]

---

Icekiller2k6 schreef op vrijdag 22 december 2017 @ 17:46:
Als tig keer het verkeerde ww gebruikt is, kun je een code naar mail adres sturen als extra bevestiging. Als op eens van een totaal andere locatie wordt aangemeld ook (bv ander land).

Tevens kun je aan wachtwoord een extra woord koppelen bv eerste x cijfers van user/email..
Zodat hash van 2 Users met hetzelfde ww anders gaat zijn

Zeker goede ideeën. Ik ga even uitzoeken hoe je op locatie kunt controleren, maar als dit teveel moeite kost, laat ik het achterwege

Alleen waarom zou je een extra woord aan het wachtwoord willen koppelen? Zoals @downtime al aangeeft, moet je dan wel iedere keer zowel je wachtwoord als gebruikersnaam/e-mail veranderen. Lijkt me niet handig. Dan zal je de user erg veel e-mailadressen moeten hebben of iedere keer een andere gebruikersnaam gebruiken.

---

@TommieW, @Toshin @downtime ik heb jullie reactie ook gelezen. Fijn dat er zoveel tweakers zijn die mijn vragen willen beantwoorden. Ik heb nu in ieder geval genoeg om te implementeren/uit te zoeken.

[eric.1]

1. Iteratieve input-validatie (even nadenken of je alle soorten karakters en combinaties wilt toestaan),
2. Prepared statements (altijd óók inputvalidatie gebruiken! Informatiebeveiliging = gelaagd. Nooit op 1 paard wedden. Er zijn situaties geweest waar prepared statements alleen niet voldoende was),
3. Minimale ww lengte - bijv 12 (vage tekens optioneel),
4. Hash+salt (al is dat vrij standaard),
5. Fout-afhandeling (vaak een ondergesneeuwd kind) - er mag nooit iets gebeuren wat jij niet had voorzien,
6. Generieke foutmeldingen tonen (mag niet afhangen van een verkeerd username of verkeerd password),
7. Beperk het aantal mogelijke pogingen per tijdseenheid (of blokkeer het account na x keer foutief inloggen o.i.d.).

Dan ben je al een heel eind (al is het meeste al genoemd denk ik zo).

[Icekiller2k6]

downtime schreef op vrijdag 22 december 2017 @ 17:50:
[...]

Ofwel: Als de gebruiker zijn email of username wijzigt, is ie verplicht om het password ook meteen te wijzigen?

Ja, kunt uiteraard ook registratie uur/datum gebruiken.

[ Voor 9% gewijzigd door Icekiller2k6 op 22-12-2017 18:24 ]

[CurtPoindexter]

-

[ Voor 122% gewijzigd door CurtPoindexter op 19-10-2019 15:12 . Reden: Leeg ivm privacy ]

[DJMaze]

hoi1234 schreef op vrijdag 22 december 2017 @ 17:16:
Wat vinden jullie van een minimale lengte, minimaal aantal kleine letters, minimaal aantal grote letters, minimaal aantal vreemde tekens afdwingen voor het wachtwoord?

Gewoon minimaal 12 tekens (zelf in te vullen, dus ook spaties) en geef als tip: wachtwoordZIN
Een zin is namelijk makkelijk te onthouden.

[Knutselsmurf]

De genoemde oplossingen zijn in en aantal categorieën in te delen, die er allemaal op hun eigen gebied voor zorgen dat wachtwoorden veilig gebruikt en opgeslagen worden:

1) Zorg dat de gebruiker een wachtwoord kiest dat niet eenvoudig te raden is. Dit kan door het instellen van regels als minimaal 12 tekens, minimaal 2 hoofdletters en 1 leesteken. Maar ook bijvoorbeeld door het gebruik van zxcvbn
2) Zorg er voor dat iemand niet onbeperkt gratis wachtwoorden mag raden. Bijvoorbeeld een afkoelperiode van 10 minuten na een aantal foutieve wachtwoorden.
3) Zorg er voor dat de wachtwoorden veilig op worden geslagen. Bcrypt() is hier geschikt voor. Dit helpt jouw eigen website niet, want men heeft dan al toegang gekregen tot de database. Het helpt je gebruikers echter wél, omdat hun wachtwoorden niet te lezen zijn uit de database. De meeste mensen gebruiken (helaas) hun wachtwoord op meerdere websites.

Om op je originele vragen terug te komen:

1) Als je weet hoe de genoemde aanvalsmogelijkheden werken, kun je je daar tegen wapenen. Bijvoorbeeld een brute-force aanval, daarvoor moet men vele wachtwoorden proberen -> beperkt het aantal pogingen
2) Ja. Sterker nog, het voorkomt ook fouten bij valide invoer. Neem een naam als O'Connor, die je in zonder escaping of parameters in een query probeert te stoppen.

Het is dus een goede gewoonte om ALTIJD gebruik te maken van prepared statements.
3) Voor een normale website lijkt mij bcrypt ruimschoots voldoende. Hoewel ARGON2 wellicht beter is, is het een afweging tussen het gemak van standaard aanwezig, tegenover de (extra) veiligheid. Het is dus NIET zo dan bcrypt niet veilig is.

[hoi1234]

Ik reageer even, om iedereen te bedanken voor de input. Ik heb tot nu toe nog weinig gereageerd, omdat het advies duidelijk genoeg is. Alle reacties worden dus aandachtig doorgelezen, maar ik reageer pas als ik nog extra opheldering nodig heb.

[mclegodude]

YouTube: How NOT to Store Passwords! - Computerphile goeie video over deze vraag

[hoi1234]

mclegodude schreef op zaterdag 23 december 2017 @ 21:36:
YouTube: How NOT to Store Passwords! - Computerphile goeie video over deze vraag

Dankjewel! Ga ik zeker naar kijken.

[DJMaze]

mclegodude schreef op zaterdag 23 december 2017 @ 21:36:
YouTube: How NOT to Store Passwords! - Computerphile goeie video over deze vraag

Alleen zijn antwoord klopt niet helemaal.
Hij vertelt niet dat een hash met salt in MD5/SHA1 ook een slecht idee is.
Daarnaast regelt Bcrypt/Argon2i zelf de salt en hoef je dat dus helemaal niet te doen.

Verder is zijn uitleg natuurlijk wel duidelijk.

[ Voor 5% gewijzigd door DJMaze op 26-12-2017 12:16 ]

[Sissors]

Als gebruiker: Er is geen schijn van kans dat iemand een wachtwoord van 8 tekens gaat bruteforcen zolang jouw database niet gestolen is. De mensen die hier 12 tekens als minimum adviseren zijn net zo goed gebruikertje aan het pesten als het verouderde idee dat er speciale tekens en cijfers in moeten zijn. (Je weet wel, waardoor elk wachtwoord van appelboom naar App3lb00m! is gegaan).

Voor nagenoeg alle zaken zal 8 tekens waarbij standaard wachtwoorden (12345678) niet toegestaan zijn voldoende zijn. Is het echt iets heel gevaarlijks als andere er toegang tot hebben? Dan kan je het minimum verhogen, of 2FA gebruiken wat eigenlijk een beter idee is.

[hoi1234]

Sissors schreef op dinsdag 26 december 2017 @ 09:26:
Als gebruiker: Er is geen schijn van kans dat iemand een wachtwoord van 8 tekens gaat bruteforcen zolang jouw database niet gestolen is. De mensen die hier 12 tekens als minimum adviseren zijn net zo goed gebruikertje aan het pesten als het verouderde idee dat er speciale tekens en cijfers in moeten zijn. (Je weet wel, waardoor elk wachtwoord van appelboom naar App3lb00m! is gegaan).

Voor nagenoeg alle zaken zal 8 tekens waarbij standaard wachtwoorden (12345678) niet toegestaan zijn voldoende zijn. Is het echt iets heel gevaarlijks als andere er toegang tot hebben? Dan kan je het minimum verhogen, of 2FA gebruiken wat eigenlijk een beter idee is.

Mag ik vragen waarom 8 karakters volgens jou al voldoende zijn?

Tegenwoordig heb je erg krachtige videokaarten waarmee je flink wat guesses per seconde kunt uitvoeren. Oké 12 of 16 karakters geven helemaal niet zo gek veel extra mogelijkheden. Maar dan weet ik nog steeds niet waarom 8 voldoende is. (Ben gewoon benieuwd, je zult ongetwijfeld een goede reden hebben, waar ik -als leek- niet aan denk)

[DJMaze]

Sissors schreef op dinsdag 26 december 2017 @ 09:26:
Er is geen schijn van kans dat iemand een wachtwoord van 8 tekens gaat bruteforcen zolang jouw database niet gestolen is.

Plesk/DirectAdmin gebruiken standaard 8 tekens ofzo, en toch worden die accounts gebruteforced.
Een gewone website bezoeker is natuurlijk veel minder interessant omdat die geen database heeft en niet kan e-mailen.

En hoe weet jij zo zeker dat de database niet wordt gestolen?
En dan is 8 tekens gewoon: https://www.betterbuys.co...-password-cracking-times/

[GlowMouse]

hoi1234 schreef op dinsdag 26 december 2017 @ 10:32:
[...]

Tegenwoordig heb je erg krachtige videokaarten waarmee je flink wat guesses per seconde kunt uitvoeren. Oké 12 of 16 karakters geven helemaal niet zo gek veel extra mogelijkheden. Maar dan weet ik nog steeds niet waarom 8 voldoende is. (Ben gewoon benieuwd, je zult ongetwijfeld een goede reden hebben, waar ik -als leek- niet aan denk)

"Flink wat guesses per seconde" lukt niet met bcrypt. Als je 25/s haalt ben je een flinke jongen.

Wat ik in bovenstaande discussie nog mis is het gebruik van een gestolen wachtwoorddatabase. Als iemand een nieuw wachtwoord instelt, moet je even kijken of hij daarin voorkomt. Je kunt dan de makkelijke dingen als p4ssw0rd en qwerty123 weigeren (omdat die in zo'n database voorkomen) zonder eisen op te leggen op het gebruik van bepaalde tekens.

[Demonitzu]

Minstens 8 tekens is een guideline van United States National Institute for Standards and Technology (NIST) die vaak als referentie gebruikt wordt

[johnkeates]

Gebruik een bestaande library die goed onderhouden wordt, iets met PBKDF2 support, en stel de cost in op basis van je threat model.

[GlowMouse]

johnkeates schreef op dinsdag 26 december 2017 @ 17:33:
Gebruik een bestaande library die goed onderhouden wordt, iets met PBKDF2 support, en stel de cost in op basis van je threat model.

Dat is niet zo'n goed idee, zie de opmerking over PBKDF2 op https://medium.com/@mprez...crypt-bcrypt-1ef4bb9c19b3

[ Voor 3% gewijzigd door GlowMouse op 26-12-2017 17:36 ]

[johnkeates]

GlowMouse schreef op dinsdag 26 december 2017 @ 17:35:
[...]

Dat is niet zo'n goed idee, zie de opmerking over PBKDF2 op https://medium.com/@mprez...crypt-bcrypt-1ef4bb9c19b3

Dat hangt dus af van de cost config. Je kan prima PBKDF2 gebruiken met scrypt, bcrypt, sha3, of een andere functie. PBKDF2 is niet alleen in de default mode te gebruiken, en ook niet alleen zinvol om te gebruiken voor set-and-forget, vooral door de metadata die je over je crypto automatisch op moet slaan om het te kunnen gebruiken.

Normaal heb je een user ID (bijv. email of username) en een hashed password, en dan misschien een los opgeslagen salt per user. Maar als je PBKDF2 goed gebruikt (en dus niet hardcoded cost [algo, rounds, salts] hebt) sla je per user ook op welk algoritme gebruikt is, hoe veel rounds, en de user-specific salt.

Als je ooit je cost wil veranderen kan je gewoon je gewenste setup instellen en als een user dan nog met oude configuratie inlogt kan je dat naadloos 'upgraden'. Stel dat je van algo switcht, of de salts periodiek wil verversen, dan is dat een stuk makkelijker als je een systeem gebruikt dat het van tevoren haast verplicht stelt om die data variabel op te slaan.

[Sissors]

hoi1234 schreef op dinsdag 26 december 2017 @ 10:32:
[...]

Mag ik vragen waarom 8 karakters volgens jou al voldoende zijn?

Tegenwoordig heb je erg krachtige videokaarten waarmee je flink wat guesses per seconde kunt uitvoeren. Oké 12 of 16 karakters geven helemaal niet zo gek veel extra mogelijkheden. Maar dan weet ik nog steeds niet waarom 8 voldoende is. (Ben gewoon benieuwd, je zult ongetwijfeld een goede reden hebben, waar ik -als leek- niet aan denk)

Ik schreef daarom specifiek dat het voldoende is zolang de database niet gestolen is. Als iemand dan het weet te bruteforcen is het probleem niet de password policy, maar dat jouw server tienduizenden login pogingen prima vindt.

En als acht voor nist voldoende is, waarom dan niet voor hier? Sowieso is meer dan twaalf veiliger? Het zou best kunnen dat veel vaker dezelfde wachtwoorden worden gebruikt als je zo'n lang wachtwoord verplicht. (Minder woorden van meer dan 12 tekens dan van meer dan 8 tekens. Geen bron voor overigens, gewoon iets wat ik me afvraag)

[DJMaze]

Sissors schreef op dinsdag 26 december 2017 @ 18:57:
Sowieso is meer dan twaalf veiliger? Het zou best kunnen dat veel vaker dezelfde wachtwoorden worden gebruikt als je zo'n lang wachtwoord verplicht.

Daarom moet je mensen opvoeden. Ooit gaf Alexander Klöpping een tip in een tech talk tijdens DWDD.
Die tip gebruik ik al jaren en werkt prima, en daarom ben ik het met hem eens.

Stap 1: bedenk één wachtwoord en onthoud die goed
Stap 2: prefix/postfix je wachtwoord bij de betreffende website

Bijvoorbeeld:
je wachtwoord is: "DansMetMij"
op tweakers is het: "DansMetMijTweakers" of "TweakersDansMetMij"
op facebook is het: "DansMetMijFacebook" of "FacebookDansMetMij"

of een kleur:
op tweakers: "GeelDansMetMij"
of facebook: "BlauwDansMetMij"

of afgekort:
op tweakers: "TwDansMetMij"
of facebook: "FbDansMetMij"

je kan natuurlijk ook een wachtwoord manager gebruiken, die doet sowieso veel tekens.
Nadeel vind ik hierbij, als ik even moet inloggen op een ander PC/Tablet, dat ik dus niet het lange wachtwoord uit mijn hoofd weet en zeker niet "even" de wachtwoord manager op die PC/Tablet ga installeren.

Daarnaast heb ik wel verschillende wachtwoorden op basis van belangrijk.
Facebook en Google hebben bij mij een ander standaard wachtwoord dan de webshop waar ik eens iets heb besteld. Dit komt omdat ik Google en Facebook ook gebruik voor OpenID Connect en OAuth.
Dan nog hoef ik maar twee wachtwoorden te onthouden.

[ Voor 11% gewijzigd door DJMaze op 27-12-2017 00:36 ]

[Gropah]

DJMaze schreef op woensdag 27 december 2017 @ 00:29:
[...]

Daarom moet je mensen opvoeden. Ooit gaf Alexander Klöpping een tip in een tech talk tijdens DWDD.
Die tip gebruik ik al jaren en werkt prima, en daarom ben ik het met hem eens.

Stap 1: bedenk één wachtwoord en onthoud die goed
Stap 2: prefix/postfix je wachtwoord bij de betreffende website

Bijvoorbeeld:
je wachtwoord is: "DansMetMij"
op tweakers is het: "DansMetMijTweakers" of "TweakersDansMetMij"
op facebook is het: "DansMetMijFacebook" of "FacebookDansMetMij"

of een kleur:
op tweakers: "GeelDansMetMij"
of facebook: "BlauwDansMetMij"

of afgekort:
op tweakers: "TwDansMetMij"
of facebook: "FbDansMetMij"

je kan natuurlijk ook een wachtwoord manager gebruiken, die doet sowieso veel tekens.
Nadeel vind ik hierbij dat als ik even moet inloggen op een ander PC/Tablet dat ik dus niet het lange wachtwoord uit mijn hoofd weet en zeker niet "even" de wachtwoord manager op die PC/Tablet ga installeren.

Daarnaast heb ik wel verschillende wachtwoorden op basis van belangrijk.
Facebook en Google hebben bij mij een ander standaard wachtwoord dan de webshop waar ik eens iets heb besteld. Dit komt omdat ik Google en Facebook ook gebruik voor OpenID Connect en OAuth.
Dan nog hoef ik maar twee wachtwoorden te onthouden.

Ja, je wachtwoord is dan uniek, maar:

- Als iemand je wachtwoord te pakken krijgt (en jou specifiek wil targetten) ben je alsnog een makkelijk doelwit
- Als een site gehacked word moet je dus een nieuwe zin bedenken, waarna je je bij elke website alsnog moet afvragen welke van de X standaard zinnen je nu moet gebruiken.

Daarom gebruik ik zelf een keepass, een password manager, die ook een readable phrase generator plugin heeft om wel goed leesbare zinnen te hebben, maar dan willekeurig genereert waardoor het ook geen probleem meer moet zijn als je op een andere computer moet inloggen.

Overigens is deze discussie over sterke wachtwoorden wel interessant maar wel een beetje offtopic

[DJMaze]

@Gropah Natuurlijk kan je overal wel een gat in vinden. Zelfs als je overal SSO gebruikt.
Ik gebruik zelf overal, waar mogelijk, TOTP/FIDO U2F.

[ Voor 33% gewijzigd door DJMaze op 27-12-2017 03:49 ]

[Sissors]

Vooral die eerste is natuurlijk weer een toppunt van schijnveiligheid. Die gaat er compleet vanuit dat kwaadwillende hersendood zijn, enige wat je daarmee voorkomt zijn de simpelste geautomatiseerde pogingen om jouw login details ook op andere websites te gebruiken.

[MSalters]

hoi1234 schreef op dinsdag 26 december 2017 @ 10:32:
[...]
Mag ik vragen waarom 8 karakters volgens jou al voldoende zijn?

Tegenwoordig heb je erg krachtige videokaarten waarmee je flink wat guesses per seconde kunt uitvoeren. Oké 12 of 16 karakters geven helemaal niet zo gek veel extra mogelijkheden.

Ben jij bekend met het idee van exponentiële functies? Als we ons even beperken tot A-Z dan heb je met 12 karakters 26*26*26*26 meer mogelijkheden dan met 8. Dat is bijna een half miljoen keer meer mogelijkheden. Gaan we uit van A-Za-z0-9, dan heb je het al over 15 miljoen keer zoveel.

Dat is toch net iets anders als "helemaal niet zo gek veel extra"

[hoi1234]

GlowMouse schreef op dinsdag 26 december 2017 @ 13:12:
[...]

"Flink wat guesses per seconde" lukt niet met bcrypt. Als je 25/s haalt ben je een flinke jongen.

Wat ik in bovenstaande discussie nog mis is het gebruik van een gestolen wachtwoorddatabase. Als iemand een nieuw wachtwoord instelt, moet je even kijken of hij daarin voorkomt. Je kunt dan de makkelijke dingen als p4ssw0rd en qwerty123 weigeren (omdat die in zo'n database voorkomen) zonder eisen op te leggen op het gebruik van bepaalde tekens.

Wat bedoel je precies?

Als ik het goed begrijp bedoel je dat ik moet kijken of het wachtwoord dat de gebruiker wil instellen, voorkomt in een gestolen database, toch?

Ik dacht trouwens dat een array van videokaarten wel wat maar dan 25/s doet. Of gaat het dan om zwakke algoritmes zoals md5?

[hoi1234]

Knutselsmurf schreef op zaterdag 23 december 2017 @ 12:54:

2) Ja. Sterker nog, het voorkomt ook fouten bij valide invoer. Neem een naam als O'Connor, die je in zonder escaping of parameters in een query probeert te stoppen.
[afbeelding]
Het is dus een goede gewoonte om ALTIJD gebruik te maken van prepared statements.

Misschien niet helemaal gerelateerd aan het onderwerp. (maar vind het een beetje onzin om een nieuw topic aan te maken) Maar ik moet ook een voornaam op kunnen slaan in de database. De meeste namen gaan goed, maar namen als D'jay gaan fout, vanwege de apostrof. Zijn prepared statements ook hier voldoende of moet ik gaan escapen?

En als ik moet escapen, hoe? Ik moet verplicht Microsoft SQL server 2016 gebruiken. Is STRING_ESCAPE dan de functie die ik zoek, of kan het ook met een PHP functie als addslashes?

PHP:

if (isset($_POST['voornaam']) && strlen($_POST['voornaam'] <= 32)) {
    if (preg_match('/[A-Z]+[a-z]+/', $_POST['voornaam'])) {
        $voornaam = valideerFormulierinput($_POST['voornaam']);
    } else {
        echo "U mag alleen hoofdletters en kleine letters in uw voornaam gebruiken.";
    }
}

[ Voor 14% gewijzigd door hoi1234 op 27-12-2017 16:35 ]

[GlowMouse]

hoi1234 schreef op woensdag 27 december 2017 @ 16:11:
[...]

Als ik het goed begrijp bedoel je dat ik moet kijken of het wachtwoord dat de gebruiker wil instellen, voorkomt in een gestolen database, toch?

Klopt.

Ik dacht trouwens dat een array van videokaarten wel wat meer dan 25/s doet. Of gaat het dan om zwakke algoritmes zoals md5?

Dat gaat inderdaad om simpele algoritmes als md5.

[Demonitzu]

hoi1234 schreef op woensdag 27 december 2017 @ 16:34:
[...]

Misschien niet helemaal gerelateerd aan het onderwerp. (maar vind het een beetje onzin om een nieuw topic aan te maken) Maar ik moet ook een voornaam op kunnen slaan in de database. De meeste namen gaan goed, maar namen als D'jay gaan fout, vanwege de apostrof. Zijn prepared statements ook hier voldoende of moet ik gaan escapen?

En als ik moet escapen, hoe? Ik moet verplicht Microsoft SQL server 2016 gebruiken. Is STRING_ESCAPE dan de functie die ik zoek, of kan het ook met een PHP functie als addslashes?

PHP:

if (isset($_POST['voornaam']) && strlen($_POST['voornaam'] <= 32)) {
    if (preg_match('/[A-Z]+[a-z]+/', $_POST['voornaam'])) {
        $voornaam = valideerFormulierinput($_POST['voornaam']);
    } else {
        echo "U mag alleen hoofdletters en kleine letters in uw voornaam gebruiken.";
    }
}

Prepared statements zijn voldoende om onbedoelde injecties met bijvoorbeeld een apostrof te voorkomen. Als je geen prepared statements kan gebruiken, dan heb je mysqli_real_escape_string nodig. Addslashes laat bepaalde tekens wel door.

(Ik weet niet of die code slechts als voorbeeld dient, maar daar zit nog verbetering in. Sowieso een foutmelding voor de eerste if statement)

[hoi1234]

Toshin schreef op woensdag 27 december 2017 @ 17:13:
[...]

Prepared statements zijn voldoende om onbedoelde injecties met bijvoorbeeld een apostrof te voorkomen. Als je geen prepared statements kan gebruiken, dan heb je mysqli_real_escape_string nodig. Addslashes laat bepaalde tekens wel door.

(Ik weet niet of die code slechts als voorbeeld dient, maar daar zit nog verbetering in. Sowieso een foutmelding voor de eerste if statement)

Dat is geen voorbeeldcode. Dat is de code die ik nu heb. Een errormelding voor het eerste if statement heb ik al, maar dat is hier dus niet te zien. mysqli_real_escape_string is als ik het goed begrijp alleen voor MYSQL terwijl ik verplicht MS SQL moet gebruiken. (don't ask why) Maar volgens mij kan ik gewoon prepared statements gebruiken.

[ Voor 3% gewijzigd door hoi1234 op 27-12-2017 17:47 ]

[DJMaze]

hoi1234 schreef op woensdag 27 december 2017 @ 16:34:

PHP:

if (isset($_POST['voornaam']) && strlen($_POST['voornaam'] <= 32)) {
    if (preg_match('/[A-Z]+[a-z]+/', $_POST['voornaam'])) {
        $voornaam = valideerFormulierinput($_POST['voornaam']);
    } else {
        echo "U mag alleen hoofdletters en kleine letters in uw voornaam gebruiken.";
    }
}

Je preg_match accepteert dingen als:

• HENkie
• $#%$#Gho
• Hey "$#%'$#

Laat die dus gewoon weg.

strlen() is ook fout, bepaalde mensen mogen dus niet op je website:
https://www.vernoeming.nl...e-voornamen-van-nederland

En dan gelijk ook even achternamen: https://www.vernoeming.nl...achternamen-van-nederland

En plaatsnamen: https://www.alletop10lijs...plaatsnamen-in-de-wereld/

Dus.. gebruik gewoon PDO met trim($_POST['voornaam'])

[hoi1234]

DJMaze schreef op woensdag 27 december 2017 @ 18:07:
[...]

Je preg_match accepteert dingen als:

• HENkie
• $#%$#Gho
• Hey "$#%'$#

Laat die dus gewoon weg.

strlen() is ook fout, bepaalde mensen mogen dus niet op je website:
https://www.vernoeming.nl...e-voornamen-van-nederland

En dan gelijk ook even achternamen: https://www.vernoeming.nl...achternamen-van-nederland

En plaatsnamen: https://www.alletop10lijs...plaatsnamen-in-de-wereld/

Dus.. gebruik gewoon PDO met trim($_POST['voornaam'])

Dankjewel voor de feedback! Maar als ik trim, dan moet ik neem ik aan een character_mask instellen? Of hoe voorkom ik dat gebruikers bijvoorbeeld cijfers in hun voornaam kunnen gebruiken. Neem namelijk aan dat ik mijn database een beetje schoon wil houden.

Vind het wel een beetje apart want mij is aangeleerd om !preg_match() te gebruiken om te input te filteren. (of werkt het dan wel?)

Had nog niet echt nagedacht over de strlen(). Wou dat nog op school navragen hoe ik dat het beste aan kan pakken. De docent had wel gezegd dat hij ooit een onderzoekje gedaan heeft waar als langste naam een naam met 32 karakters uit kwam. (en zag dit ook in een filmpje op youtube, dus dacht dat het wel goed was)

[DJMaze]

hoi1234 schreef op woensdag 27 december 2017 @ 19:32:
Maar als ik trim, dan moet ik neem ik aan een character_mask instellen? Of hoe voorkom ik dat gebruikers bijvoorbeeld cijfers in hun voornaam kunnen gebruiken. Neem namelijk aan dat ik mijn database een beetje schoon wil houden.

Cijfers. KOI8, Grieks, Emoji, etc. Alles voor de Iñtërnâtiônàlizætiøn 🤖🐛
Ik begrijp dat je het "schoon" wil houden, maar totaal geen rekening houdt met trema's enzo, dus kijk maar even hier: http://php.net/manual/en/regexp.reference.unicode.php
En dan:

PHP:

preg_match("/^[\\p{P}\\p{L}\\p{Zs}]+$/Du")

[ Voor 3% gewijzigd door DJMaze op 28-12-2017 04:46 ]

[Gomez12]

hoi1234 schreef op woensdag 27 december 2017 @ 16:11:
[...]
Ik dacht trouwens dat een array van videokaarten wel wat maar dan 25/s doet. Of gaat het dan om zwakke algoritmes zoals md5?

De vid-kaarten kunnen misschien wel meer als 25/s doen, maar zolang jij geen 25/s toestaat hebben die vid-kaarten alleen zin als jouw database gestolen is.

Ikzelf vind het altijd wel makkelijk om een timer per user bij te houden en die bij elke mislukte inlogpoging te verdubbelen (ok, eigenlijk is het een semi-random nr tussen 1,5 en 2,5 om bots die timeattacks doen van slag af te brengen)
Dan begin je gewoon met 2 ms, dat haalt een mens niet qua input. Na 10 pogingen mag hij dan grofweg 1 seconde niet meer inloggen en na 25 pogingen mag hij 9+ uur niet meer inloggen.
Veel plezier met tegen die logica aan gaan brute-forcen en zolang je de logins die binnen de timeout vallen niet meetelt kan ook niemand anders echt iemand irriteren en een lock-out veroorzaken.

[DJMaze]

Gomez12 schreef op donderdag 28 december 2017 @ 09:28:
Ikzelf vind het altijd wel makkelijk om een timer per user bij te houden en die bij elke mislukte inlogpoging te verdubbelen.

En daarnaast heb ik ook op het login proces zelf een timer zitten.
Een login pagina genereren kost in mijn code ongeveer 75ms, een gebruiker kost het minimaal 3 seconden om de html te tonen + de login gegevens in te vullen + POST (zelfs bij auto-fill).
Dus als tussen het tonen van de login pagina => POST gegevens, minder dan 3 seconden wordt gedetecteerd, wordt je poging ook geblokkeerd.

PHP:

if ('POST' == $_SERVER['REQUEST_METHOD']) {
    if (!empty($_SESSION['LOGIN'])
        && 3 <= time() - $_SESSION['LOGIN']['time']
        && $_SESSION['LOGIN']['csrf_token'] == $_POST['csrf_token']
    ) {
        // do login
    }
}
if (!$logged_id) {
    $_SESSION['LOGIN'] = array(
        'csrf_token' => bin2hex(random_bytes(16)),
        'time' => time()
    );
    echo 'login pagina
    <input type="hidden" name="csrf_token" value="'.htmlspecialchars($_SESSION['LOGIN']['csrf_token']).'"/>';
}

Ik zie bots namelijk vaak supersnel veel login pogingen doen (zoals laatst bij WordPress websites).

[ Voor 5% gewijzigd door DJMaze op 28-12-2017 12:01 ]

[hoi1234]

Dus als ik het goed begrijp, dan kun je met een timer meten (vanaf het moment dat de pagina is geladen) hoelang het duurt voordat de gebruikersnaam en het wachtwoord zijn ingevuld en verstuurd? Is de timer < 3 seconden, kun je er van uitgaan dat een robot probeert in te loggen. Is de timer > 3 seconden, dan zou het ook een gebruiker kunnen zijn die inlogt.

Ik vind het echt heel fijn dat jullie mij willen helpen. En ik kom goede ideeën tegen.

[ Voor 57% gewijzigd door hoi1234 op 28-12-2017 16:18 ]

[DJMaze]

@hoi1234 klopt!
Ik heb wel de pseudo code wat duidelijker gemaakt omtrend de "3".
Verstandig als je even mijn quote uit je post haalt (is ook onnodig omdat je direct reageerde)

[ Voor 36% gewijzigd door DJMaze op 28-12-2017 12:02 ]

[Gomez12]

DJMaze schreef op donderdag 28 december 2017 @ 10:45:
[...]
En daarnaast heb ik ook op het login proces zelf een timer zitten.
Een login pagina genereren kost in mijn code ongeveer 75ms, een gebruiker kost het minimaal 3 seconden om de html te tonen + de login gegevens in te vullen + POST (zelfs bij auto-fill).
Dus als tussen het tonen van de login pagina => POST gegevens, minder dan 3 seconden wordt gedetecteerd, wordt je poging ook geblokkeerd.
...
Ik zie bots namelijk vaak supersnel veel login pogingen doen (zoals laatst bij WordPress websites).

Tja, ik snap wat je probeert te doen. Maar ik zou deze methode nooit hanteren, alles boven de 76 ms is namelijk 100% afhankelijk van de client.
Oftewel je loopt een risico om snelle clients te blokken. en dat risico wordt enkel maar groter hoe sneller de clients en browsers worden.

Dit is een methode die hoe verder in de tijd hoe meer die je gaat tegenwerken imho.
Dat het nu op 3sec werkt lijkt mij meer een combi van "niet-efficiente html" en trage client, verander je iets aan die factoren dan ga je mank.

[DJMaze]

@Gomez12 ik begrijp je punt. Ook al duurt het ophalen en visueel renderen van een pagina 0ms, ik ken niemand die binnen 3 seconden op de login knop klikt.
Je moet immers je muis naar die knop bewegen en klikken.

Als het iemand wel lukt staat dat netjes in mijn error log en kan ik het aanpassen naar bijvoorbeeld 2 seconden.

[ Voor 21% gewijzigd door DJMaze op 28-12-2017 13:38 ]

[Onbekend]

DJMaze schreef op donderdag 28 december 2017 @ 13:37:
@Gomez12 ik begrijp je punt. Ook al duurt het ophalen en visueel renderen van een pagina 0ms, ik ken niemand die binnen 3 seconden op de login knop klikt.
Je moet immers je muis naar die knop bewegen en klikken.

Als het iemand wel lukt staat dat netjes in mijn error log en kan ik het aanpassen naar bijvoorbeeld 2 seconden.

Door de browser de logingegevens laten bewaren en meteen op de entertoets klikken als die standaard is geselecteerd.

Ik doe het volgende:
3 gefaalde inlogpogingen voor een ip-adres binnen 5 minuten betekend 5 minuten geen loginmogelijkheid voor dat ip-adres.

15 gefaalde inlogpogingen voor een ip-adres binnen een uur is meteen geen loginmogelijkheid voor de gehele dag voor dat ip-adres + een mailtje naar de beheerder.

[Gomez12]

DJMaze schreef op donderdag 28 december 2017 @ 13:37:
ik ken niemand die binnen 3 seconden op de login knop klikt.
Je moet immers je muis naar die knop bewegen en klikken.

Grappig hoe anders jij denkt.

Ik denk, ik mieter vanuit useability oogpunt bij betreden van de inlogpagina de focus automagisch op het username veld, waardoor de focus automatisch op het te submitten formulier staat en je bij elke behoorlijke browser dus enkel maar op enter hoeft te klikken om het te submitten.

Oftewel met remembered credentials kan de gebruiker gewoon op enter drukken en dan is het gepost. Beetje keyboard-persoon redt dat makkelijk hoor. En redt dat ook makkelijk in 2 seconden en ook in 1 seconde.

Menig wachtwoordreminder plugin kan ook zelf nog even op enter drukken waardoor je al snel in milliseconden tijd uitkomt.

En tja, error log... Laat ik het zo zeggen, je moet wel een heel bijzondere dienst hebben dat ik erop ga zitten wachten dat een beheerder de error log doorleest en daar echt actie op onderneemt, elke gewone dienst schuif ik dan aan de kant en ga ik op zoek naar de volgende die hetzelfde aanbied.

[DJMaze]

@Onbekend en @Gomez12 Inderdaad als het veld autofocus is en autocomplete.
Bij mij is dat niet zo omdat je de mogelijkheid hebt om eerst een login methode te kiezen (Database, OAuth, OpenID Connect, IMAP, etc.).

Er is tevens de mogelijkheid voor een identifier login. Je vult gewoon iets in in één veld en het systeem detecteert de invoer voor de juiste methode.
Voorbeelden:
"[e-mail]" => OpenID Connect
"[e-mail]" => OpenID Connect
"openid.aol.com/naam" => OpenID v2
"[e-mail]" => IMAP

Is er geen actieve match dan krijg je het standaard login scherm.
Vandaar dat die 3 seconden bij mij werkt

Het systeem is ook zo dat je dus Database EN verschillende SSO aan één gebruiker account kan hangen.
Je kan dus bijvoorbeeld inloggen met Google en Facebook en Database.
Voordeel hierbij is dat als je je facebook account opzegt (of facebook is offline om wat voor reden dan ook), nog steeds kan inloggen op de website.
Dit is een probleem die andere websites met SSO ondersteuning niet bieden.
Ik zie dan ook vaak grote rode balken met een waarschuwing, zoals: https://support.waveapps....count-or-Yahoo-ID-OpenID-
Maar dat staat dan niet op de "register" pagina

De IMAP of LDAP activeer ik specifiek voor bedrijven.
Als daar een werknemer vertrekt en zijn IMAP is uitgeschakeld, kan de ex-werknemer ook niet inloggen op de website.
Komt er een nieuwe werknemer met een eigen e-mailadres, dan kan die dus direct met die gegevens ook inloggen op de website.

Maar goed, ik ga hier redelijk ver offtopic met veel meer mogelijkheden dan "wachtwoord hashen"

[ Voor 47% gewijzigd door DJMaze op 28-12-2017 14:54 ]

[hoi1234]

DJMaze schreef op donderdag 28 december 2017 @ 13:37:
@Gomez12 ik begrijp je punt. Ook al duurt het ophalen en visueel renderen van een pagina 0ms, ik ken niemand die binnen 3 seconden op de login knop klikt.
Je moet immers je muis naar die knop bewegen en klikken.

Als het iemand wel lukt staat dat netjes in mijn error log en kan ik het aanpassen naar bijvoorbeeld 2 seconden.

Maar ik ga er van uit dat het niet verstandig is om een foutmelding te geven als je te snel inlogt of wel? Neem aan dat je dan namelijk hackers teveel informatie geeft over jouw systeem.

[Gomez12]

hoi1234 schreef op donderdag 28 december 2017 @ 16:19:
[...]

Maar ik ga er van uit dat het niet verstandig is om een foutmelding te geven als je te snel inlogt of wel? Neem aan dat je dan namelijk hackers teveel informatie geeft over jouw systeem.

In dit geval zou ik wel een foutmelding produceren. Je moet aangeven dat het geen fout in naam/wachtwoord is maar een fout qua te snel inloggen. En dan kan je bijv in grootheden aangeven wat de wachttijd is, dus niet aangeven dat iemand nog 600 seconden niet kan inloggen, maar een naar boven afgeronde grootheid van 5 minuten en zeggen dat hij het over een kwartier nogmaals kan proberen.

Het is wel zo handig om te melden dat iemand de komende 24 uur niet kan inloggen anders blijft hij het elke 5 minuten proberen en raakt steeds gefrustreerder.
Je moet alleen geen exacte tijd meegeven waardoor in theorie iemand een botje kan schrijven die het op de seconde nauwkeurig retried.

[Onbekend]

Gomez12 schreef op donderdag 28 december 2017 @ 17:39:
[...]

In dit geval zou ik wel een foutmelding produceren. Je moet aangeven dat het geen fout in naam/wachtwoord is maar een fout qua te snel inloggen. En dan kan je bijv in grootheden aangeven wat de wachttijd is, dus niet aangeven dat iemand nog 600 seconden niet kan inloggen, maar een naar boven afgeronde grootheid van 5 minuten en zeggen dat hij het over een kwartier nogmaals kan proberen.

Het is wel zo handig om te melden dat iemand de komende 24 uur niet kan inloggen anders blijft hij het elke 5 minuten proberen en raakt steeds gefrustreerder.
Je moet alleen geen exacte tijd meegeven waardoor in theorie iemand een botje kan schrijven die het op de seconde nauwkeurig retried.

"Too many failed login attempts. Try again later..."

Net genoeg informatie voor een normaal persoon, en je weet niet hoe lang je moet wachten.

[Gomez12]

Onbekend schreef op donderdag 28 december 2017 @ 18:26:
[...]

"Too many failed login attempts. Try again later..."

Net genoeg informatie voor een normaal persoon, en je weet niet hoe lang je moet wachten.

Tja, maar bij mij gaan de later-tijden steeds grofweg x2, ik heb op een site mensen staan die het voor elkaar hebben gekregen om die tijd op te rekken naar 1 jaar.

Dan zit ik er niet echt op te wachten dat zij het elke 5 minuten opnieuw gaan proberen, dan kan je best in grootheden aangeven dat ze het maar even een jaartje niet meer moeten proberen.

[Onbekend]

Gomez12 schreef op vrijdag 29 december 2017 @ 10:50:
[...]

Tja, maar bij mij gaan de later-tijden steeds grofweg x2, ik heb op een site mensen staan die het voor elkaar hebben gekregen om die tijd op te rekken naar 1 jaar.

Dan zit ik er niet echt op te wachten dat zij het elke 5 minuten opnieuw gaan proberen, dan kan je best in grootheden aangeven dat ze het maar even een jaartje niet meer moeten proberen.

Ik denk zelf dat het verkeerd is om mensen een jaar lang geen loginpoging meer te laten doen.
Als het een echt persoon is die graag wil inloggen, ga je hem geen jaar lang tegenwerken. Je helpt de persoon dan met het inlogprobleem. Dat hij dan een dagje moet wachten is niet zo erg, maar een jaar is erg lang.

Als het een bot is, dan blokkeer je gewoon een ip-adres of ip-range met de mededeling dat de website niet beschikbaar is. Daar zet je gewoon "levenslang" op.

[ACM]

hoi1234 schreef op woensdag 27 december 2017 @ 19:32:
Of hoe voorkom ik dat gebruikers bijvoorbeeld cijfers in hun voornaam kunnen gebruiken. Neem namelijk aan dat ik mijn database een beetje schoon wil houden.

Waarom wil je dat voorkomen? Wat als iemand iets als 'de 1ste' in zijn naam heeft? Dan mis je dat cijfer en die spatie.

Als het goed is weten mensen zelf het beste wat hun voor- en/of achternaam is. Daar validaties op proberen te doen zal vrijwel altijd misgaan. Hetzelfde geldt trouwens voor het adresveld, dat wordt vaak in Nederland als straat+huisnummer gedaan zonder vervolgens stil te staan dat er hele complexe namen zijn. Zoals meerdere nummers (gebouw + appartement) of het huisnummer geen cijfer is of er niet is.

Wat je wel moet doen is tijdens het gebruik van die namen (en andere input) het goed afstemmen op de bedoelde output, dat daar geen gekke dingen gebeuren (vaak escaping genoemd). In het geval van opnemen binnen html heeft php daar onder andere de functies htmlspecialchars en htmlentities voor, de Twig-template taal (en vast anderen) doen dat zelfs automatisch voor je. Voor javascript/json, xml, etc zijn er andere functies of gebeurt het soms automatisch (zoals in json_encode) of moet je ze zelf maken.

[begintmeta]

offtopic:
ACM schreef op vrijdag 29 december 2017 @ 12:26:
... Hetzelfde geldt trouwens voor het adresveld,...

Bij e-mailadressen gaat het 'valideren' ook vaak mis... men staat vaak simpele en regelmatig gebruikte tekens zoals '+' nieteens toe...

[downtime]

Onbekend schreef op vrijdag 29 december 2017 @ 11:04:
[...]

Ik denk zelf dat het verkeerd is om mensen een jaar lang geen loginpoging meer te laten doen.
Als het een echt persoon is die graag wil inloggen, ga je hem geen jaar lang tegenwerken. Je helpt de persoon dan met het inlogprobleem. Dat hij dan een dagje moet wachten is niet zo erg, maar een jaar is erg lang.

Als het een bot is, dan blokkeer je gewoon een ip-adres of ip-range met de mededeling dat de website niet beschikbaar is. Daar zet je gewoon "levenslang" op.

Eerst vind je een jaar te lang maar vervolgens wel een levenslange blokkade voorstellen?

Zolang een gebanned IP-adres in principe morgen alweer van een legitieme bezoeker kan zijn vind ik permanente IP-bans niet slim. Niks op tegen om zo’n blokkade na een paar dagen weer op te heffen. Als die bot dan nog actief is krijgt ie na een paar pogingen vanzelf weer een ban van een paar dagen.

[Onbekend]

downtime schreef op vrijdag 29 december 2017 @ 12:53:
[...]

Eerst vind je een jaar te lang maar vervolgens wel een levenslange blokkade voorstellen?

Als het een normale gebruiker is, dan is een jaar te lang. Maar voor een bot is dat prima.
Als je ziet dat er 10 inlogpogingen zijn gedaan, dan is het een grote kans dat het een normaal persoon was. Als je ziet dat er 1000 inlogpogingen zijn gedaan, dan kan je met zekerheid zeggen dat het een bot is.

Zolang een gebanned IP-adres in principe morgen alweer van een legitieme bezoeker kan zijn vind ik permanente IP-bans niet slim. Niks op tegen om zo’n blokkade na een paar dagen weer op te heffen. Als die bot dan nog actief is krijgt ie na een paar pogingen vanzelf weer een ban van een paar dagen.

IP-adressen veranderen niet zo snel, maar het kan inderdaad zo zijn dat een gebruiker ineens zo'n probleem van een gebanned-ip krijgt. Maar dat is nu ook het geval als je iemand (een ip-adres dus) blokkeert voor een jaar, en een dag later krijgt iemand anders dat ip-adres toegewezen.

[downtime]

Onbekend schreef op vrijdag 29 december 2017 @ 13:00:
[...]

Als het een normale gebruiker is, dan is een jaar te lang. Maar voor een bot is dat prima.
Als je ziet dat er 10 inlogpogingen zijn gedaan, dan is het een grote kans dat het een normaal persoon was. Als je ziet dat er 1000 inlogpogingen zijn gedaan, dan kan je met zekerheid zeggen dat het een bot is.

Als je uberhaupt 1000 inlogpogingen toelaat dan heb je al gefaald. Limiteer dat eerst naar bijvoorbeeld 25. Als iemand 25 mislukte pogingen doet binnen een dag dan kun je redelijk aannemen dat ie het juiste password echt niet meer gaat vinden en het tijd wordt voor een password reset.

[Infinitive]

Steel je niet veel meer de show door OAuth2 (oid) te gebruiken en het hele login-gebeuren met two-factor-authentication/timeouts/etc aan Facebook/Google over te laten?

[ACM]

Voor degenen die limieten op ip-addressen willen plaatsen; vergeet niet dat scholen en grote bedrijven nog altijd best vaak een beperkte set ip's gebruiken... Waar we hier op Tweakers ook nog wel eens 'last' (het is tegelijk een eer) van hebben is dat we af en toe voor lesmateriaal gebruikt worden en er dan vanuit die school ineens vrij veel nieuwe accounts aangemaakt worden.

Verder natuurlijk niet vergeten om bij ipv6 niet naar individuele ip's te kijken; daar hadden we gelukkig al bescherming voor, maar er was iemand die tijdens het malafide-crawlen voor iedere request een ander ipv6-adres had... En die probeerde honderdduizenden requests te doen

[Anoniem: 80910]

Je kunt ook beter de username blokkeren, dat treft alleen die gebruiker, heel veel bedrijven hebben maar 1 ip adres, indien je meerdere gebruikers hebt, blokkeer je ze niet allemaal maar alleen die gebruiker met 5x foutieve inlog, voor 15min bijvoorbeeld. Bruteforcen met 20x per uur gaat niet

[ACM]

Anoniem: 80910 schreef op vrijdag 29 december 2017 @ 17:35:
Je kunt ook beter de username blokkeren, dat treft alleen die gebruiker, heel veel bedrijven hebben maar 1 ip adres, indien je meerdere gebruikers hebt, blokkeer je ze niet allemaal maar alleen die gebruiker met 5x foutieve inlog, voor 15min bijvoorbeeld. Bruteforcen met 20x per uur gaat niet

Daar moet je ook mee oppassen, dan stel je je weer open voor Denial of Service attacks

Als ik dan jouw account onklaar wil maken moet ik gewoon geautomatiseerd steeds expres verkeerd inloggen.

Wij zijn uiteindelijk uitgekomen op zowel IP als username. Dus zowel bij veel pogingen per username als veel unieke usernames per ip (bijvoorbeeld om een gebruikelijk wachtwoord bij veel usernames te proberen) treedt e.e.a. in werking. Daarbij hebben we voor heel gebruikelijke ip's een lijstje opgestelt waarvan we vinden dat ze meer pogingen mogen doen dan reguliere.

Als je site niet al te groot is, zou ik voor dat laatste geen moeite doen, zelfs bij Tweakers is de noodzaak niet heel groot. De kans dat er binnen X tijd meer dan je Y unieke logins van dezelfde instelling komen en allemaal falen is wel heel erg klein
Je wil vooral voorkomen dat persoon Z niet heel het bedrijf blokkeert omdat hij een paar keer verkeerd inlogde.

Of een blokkade echt nodig is, is natuurlijk ook nog discutabel. Je kan ook een captcha in het leven roepen om geautomatiseerde pogingen in te dammen, de kans dat een hacker handmatig super vaak gaat proberen in te loggen is toch wel erg klein. Dan moet het account of verkrijgen van toegang wel van heel veel waarde zijn...

[Anoniem: 80910]

Ik denk dat dat wel meevalt indien je een csrf token moet meesturen in je post en die als voorwaarde voor user lookup zet, dus die zonder csrf token probeert in te loggen, kan niet inloggen.

[Gomez12]

ACM schreef op vrijdag 29 december 2017 @ 14:22:
Voor degenen die limieten op ip-addressen willen plaatsen; vergeet niet dat scholen en grote bedrijven nog altijd best vaak een beperkte set ip's gebruiken...

Vergeet ook niet mobiele gebruikers, de opkomst van mobieltjes met inet is niet echt bijgehouden door providers die ipv4-adressen kochten. Daar zitten ook nog veel nat en proxy-oplossingen tussen.

[Onbekend]

ACM schreef op vrijdag 29 december 2017 @ 14:22:
Voor degenen die limieten op ip-addressen willen plaatsen; vergeet niet dat scholen en grote bedrijven nog altijd best vaak een beperkte set ip's gebruiken... Waar we hier op Tweakers ook nog wel eens 'last' (het is tegelijk een eer) van hebben is dat we af en toe voor lesmateriaal gebruikt worden en er dan vanuit die school ineens vrij veel nieuwe accounts aangemaakt worden.

Als het goed is, zitten er ook veel goede loginpogingen tussen en heb je weinig foute er tussen zitten?

Verder natuurlijk niet vergeten om bij ipv6 niet naar individuele ip's te kijken; daar hadden we gelukkig al bescherming voor, maar er was iemand die tijdens het malafide-crawlen voor iedere request een ander ipv6-adres had... En die probeerde honderdduizenden requests te doen

Dat is inderdaad een goede tip om niet naar afzonderlijke ipv6-adressen te kijken. Toch maar op IPv6-ranges filteren.

[Brakius]

TommieW schreef op vrijdag 22 december 2017 @ 17:49:
Hashing van een wachtwoord is al een flinke stap in de goede richting. Het is nog beter om het wachtwoord ook te salten. Voordat je het wachtwoord hasht, plak je er een (per gebruiker) willekeurige tekenreeks achter. Deze tekenreeks kan je gewoon als plain-text in je database opslaan. Ook al hebben twee gebruikers hetzelfde wachtwoord, dan zal er alsnog een andere hash uit komen.

Bij een db hack valt dat op. Wat ik zelf doe is het registreren van aanmelddatum en dit in salt verwerkten.

[Reptile209]

Brakius schreef op vrijdag 29 december 2017 @ 22:55:
[...]


Bij een db hack valt dat op. Wat ik zelf doe is het registreren van aanmelddatum en dit in salt verwerkten.

Dan voeg je dus enkel wat obscurity toe. Ga er maar vanuit dat iemand die je DB heeft, ook de broncode van je site heeft en deze truuk dus kent. Sterker nog: je stuurt je salt naar iedere cliënt die wil inloggen...
Het idee van een salt is juist dat je deze niet geheim hoeft te houden. De salt zorgt dat a) dezelfde passwords niet dezelfde hash opleveren, en b) je niet één rainbowtable voor de hele db kunt gebruiken.

[ Voor 5% gewijzigd door Reptile209 op 29-12-2017 23:21 ]

[hoi1234]

ACM schreef op vrijdag 29 december 2017 @ 12:26:
[...]

Waarom wil je dat voorkomen? Wat als iemand iets als 'de 1ste' in zijn naam heeft? Dan mis je dat cijfer en die spatie.

Als het goed is weten mensen zelf het beste wat hun voor- en/of achternaam is. Daar validaties op proberen te doen zal vrijwel altijd misgaan. Hetzelfde geldt trouwens voor het adresveld, dat wordt vaak in Nederland als straat+huisnummer gedaan zonder vervolgens stil te staan dat er hele complexe namen zijn. Zoals meerdere nummers (gebouw + appartement) of het huisnummer geen cijfer is of er niet is.

Wat je wel moet doen is tijdens het gebruik van die namen (en andere input) het goed afstemmen op de bedoelde output, dat daar geen gekke dingen gebeuren (vaak escaping genoemd). In het geval van opnemen binnen html heeft php daar onder andere de functies htmlspecialchars en htmlentities voor, de Twig-template taal (en vast anderen) doen dat zelfs automatisch voor je. Voor javascript/json, xml, etc zijn er andere functies of gebeurt het soms automatisch (zoals in json_encode) of moet je ze zelf maken.

Bedankt voor je input. Ik kan me zeer goed voorstellen dat de developer nooit rekening kan houden met alle mogelijke namen en adressen.

Je hebt me in ieder geval wel aan het denken gezet. Want ik kan zo snel niet bedenken waarom het belangrijk is om te controleren op niet bestaande voornamen, achternamen ed. Ik denk dat ik na de vakantie maar eens de mening van mijn docent ga vragen.

---

Ik vind het overigens best dat er op dit moment een hele discussie begint over hoe je kunt voorkomen dat gebruikers gehackt worden als je verdachte loginpogingen detecteert. Ik denk echter dat ik al een heel eind kom als ik de tot nu toe gegeven tips uitwerk. Zaken als hele ip-reeksen blokkeren is voor mij te hoog gegrepen en absoluut niet nodig. (kun je van een beginner niet verwachten, vind ik) Neemt niet weg, dat ik jullie input zeer waardeer, maar het moet wel te volgen zijn voor mij. (zou jammer zijn als jullie tijd steken in mij helpen en ik er niks mee kan)

[ Voor 15% gewijzigd door hoi1234 op 30-12-2017 11:00 ]

[Olaf van der Spek]

hoi1234 schreef op vrijdag 22 december 2017 @ 17:04:
Bedankt voor het beantwoorden van mijn vragen. Ik sta uiteraard nog open voor de mening van anderen. (zeker op dit gebied, is er veel discussie mogelijk).

Sinds PHP's password_hash / verify is er voor password storage voor normale sites eigenlijk geen discussie meer nodig (IMO).

Geen wachtwoorden gebruiken (sign in by email) is ook een optie.

[ Voor 7% gewijzigd door Olaf van der Spek op 03-01-2018 10:45 ]

[hoi1234]

Olaf van der Spek schreef op woensdag 3 januari 2018 @ 10:42:
[...]

Sinds PHP's password_hash / verify is er voor password storage voor normale sites eigenlijk geen discussie meer nodig (IMO).

Geen wachtwoorden gebruiken (sign in by email) is ook een optie.

Denk dat ik het maar houd bij gebruikersnaam + wachtwoord. Ik denk dat dat ook verwacht wordt. (kan ik eventueel wel navragen)

[hoi1234]

Had vandaag assessment en heb een 6.4 gehaald voor de opdracht.

Helaas kost het toch meer tijd dan ik dacht om alle voorgestelde functionaliteiten te implementeren, dus was daar niet meer aan toegekomen. Ben eigenlijk alleen aan het hashen toegekomen. In ieder geval heb ik veel gehad aan jullie tips en ga deze tips ook zeker meenemen voor een volgende keer.

[DJMaze]

begintmeta schreef op vrijdag 29 december 2017 @ 12:35:

offtopic:
ACM schreef op vrijdag 29 december 2017 @ 12:26:
... Hetzelfde geldt trouwens voor het adresveld,...

Bij e-mailadressen gaat het 'valideren' ook vaak mis... men staat vaak simpele en regelmatig gebruikte tekens zoals '+' nieteens toe...

offtopic:
Of ze accepteren de "+" maar wordt veranderd in een "spatie" (Ziggo, kuch kuch)

[DJMaze]

@hoi1234 Mooi dat je een voldoende hebt.
Hebben ze ook aangegeven waarom je geen 9 hebt?

[CH4OS]

Olaf van der Spek schreef op woensdag 3 januari 2018 @ 10:42:
Geen wachtwoorden gebruiken (sign in by email) is ook een optie.

Is geen optie, als je het mij vraagt, iedereen met toegang tot de mailbox kan dan inloggen. 2FA lijkt mij echt het beste; oauth2 icm password, bijvoorbeeld.

[Olaf van der Spek]

CH4OS schreef op woensdag 24 januari 2018 @ 18:31:
[...]
Is geen optie, als je het mij vraagt, iedereen met toegang tot de mailbox kan dan inloggen. 2FA lijkt mij echt het beste; oauth2 icm password, bijvoorbeeld.

Met toegang tot de mailbox kun je het wachtwoord ook resetten.

[CH4OS]

Olaf van der Spek schreef op woensdag 24 januari 2018 @ 18:49:
Met toegang tot de mailbox kun je het wachtwoord ook resetten.

Daarom; 2FA.

[Olaf van der Spek]

CH4OS schreef op woensdag 24 januari 2018 @ 19:06:
[...]
Daarom; 2FA.

Op de mailbox?

[CH4OS]

Olaf van der Spek schreef op woensdag 24 januari 2018 @ 19:40:
Op de mailbox?

Nee, 2FA gebruiken voor inloggen, maar ook password resets.

[Olaf van der Spek]

CH4OS schreef op woensdag 24 januari 2018 @ 22:47:
[...]
Nee, F2A gebruiken voor inloggen, maar ook password resets.

F2A?
En hoe ga je om met een verloren 2FA?

[CH4OS]

Olaf van der Spek schreef op donderdag 25 januari 2018 @ 08:47:
En hoe ga je om met een verloren 2FA?

Bij een moderne 2FA heeft de user reset codes ontvangen en anders dient de user gewoon 2FA opnieuw in te stellen? Zie het probleem niet zo. En ik ga er stiekem eigenlijk ook wel van uit dat jij dat ook wel weet.

[ Voor 11% gewijzigd door CH4OS op 25-01-2018 09:54 ]

[Olaf van der Spek]

@CH4OS Eigenlijk niet..
Hoe stel je 2FA "gewoon" opnieuw in (zonder reset codes)? Via alleen email is dus niet veilig..

[ Voor 9% gewijzigd door Olaf van der Spek op 25-01-2018 10:44 ]

[CH4OS]

Olaf van der Spek schreef op donderdag 25 januari 2018 @ 10:42:
@CH4OS Eigenlijk niet..
Hoe stel je 2FA "gewoon" opnieuw in? Via alleen email is dus niet veilig..

Dan zou ik zeggen verdiep je even in OAUTH2. En kijk even naar de diverse apps hoe die dat doen. Kan je nu verklappen dat email niet aan te pas komt.

[hoi1234]

DJMaze schreef op woensdag 24 januari 2018 @ 18:18:
@hoi1234 Mooi dat je een voldoende hebt.
Hebben ze ook aangegeven waarom je geen 9 hebt?

Heb alleen aan de minimale eisen voldaan. En de docent had nog een paar opmerkingen over de website, dus een 6.4 is zeker een redelijk cijfer. Ik had uiteraard liever hoger gehaald, maar ik weet in ieder geval waarom het niet gelukt is.