[js][regex] Filter van een niet alphanumerieke karakters

[shades]

Hallo,

Ik heb een regex die voldoet aan de volgende eisen:
* min 8, max 16 karakters
* moet beginnen met een letter
* moet een cijfer in zitten
* moet een hoofdletter in zitten:

code:

^[a-zA-Z](?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,16}

Toe zover gaat het goed..

Nu wil ik een aantal karakter er uit hebben omdat die niet mogen maar dat krijg ik niet voor elkaar.

code:

[^%@'"-]

(procent, at-teken, streepje en enkele en dubbele quote)

Als ik dat dan wil verwerken in wat ik al had

code:

^[a-zA-Z](?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[^%@'"-]).{8,16}

Dan triggert deze alleen als het eerste karakter een "verboden" karakter is maar dat komt doordat het met een letter moet beginnen en als het tweede karakter een verboden karakter is.

Ik heb zitten lezen er de [^%@'"-] zou gewoon moeten werken. Heb ook lopen stoeien met posities en gebogen haken maar ik kom er niet uit - ik heb voornamelijk regex101.com gebruikt op te testen.

Weet iemand wat ik fout doe?

[NMe]

Waarom moet het in één expressie? Daar maak je je het jezelf een stuk lastiger mee. Maar goed: je zoekt naar negative lookahead assertions. Als je met jouw code een string hebt die eruit ziet als "ab@ABavAV" matcht hij gewoon omdat "ab" gematcht wordt door .*[^%@'"-]. Je wil dat de hele lookahead faalt op het moment dat dat karakter voorkomt, dus (?!=.*[%@'"-])

De expressie waar je vanuit gaat klopt al niet, trouwens. Hij matcht strings van 9 t/m 17 karakters.

Overigens lijkt het (gezien de karakters die je filtert) erop dat je hiermee SQL-injectie wil voorkomen. Klopt dat?

[RobIII]

shades schreef op donderdag 29 juni 2017 @ 11:33:
Weet iemand wat ik fout doe?

Er van uitgaande dat 't hier om wachtwoord vereisten gaat: vooral dat je al die eisen (max 16 chars, beginnen met letter, moet cijfer bevatten, moet een hoofdletter inzitten) stelt - behalve een minimum lengte.

quote: https://nakedsecurity.sop...es-what-you-need-to-know/

Size matters. At least it does when it comes to passwords. NIST’s new guidelines say you need a minimum of 8 characters. (That’s not a maximum minimum – you can increase the minimum password length for more sensitive accounts.)

Better yet, NIST says you should allow a maximum length of at least 64, so no more “Sorry, your password can’t be longer than 16 characters.”

Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji!

[...]

No composition rules. What this means is, no more rules that force you to use particular characters or combinations, like those daunting conditions on some password reset pages that say, “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not &%#@_, and the surname of at least one astronaut.”

Let people choose freely, and encourage longer phrases instead of hard-to-remember passwords or illusory complexity such as pA55w+rd.

Daarnaast: waarom zo moeilijk? Laat gewoon een tweede regex los die kijkt of er niet-toegestane tekens aanwezig zijn. Je regex is nu al aardig onleesbaar.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. -- Jamie Zawinski

NMe schreef op donderdag 29 juni 2017 @ 11:50:

Overigens lijkt het (gezien de karakters die je filtert) erop dat je hiermee SQL-injectie wil voorkomen. Klopt dat?

Oh gawd, ik hoop 't niet zeg In that case, @shades : Over het gebruik van Parametrized Queries

[ Voor 65% gewijzigd door RobIII op 29-06-2017 11:57 ]

[shades]

@NMe: Ik probeer dat inderdaad te voorkomen. Het is verre van perfect maar onderwater (c#) wordt alles ook nog een keer extra gecheckt en geparameteriseerd een procedure ingegooid. Dit is slecht een clientside check om alvast het ergste uit te sluiten. Ik snap even de 9 t/m 17 niet zo goed.. Komt dat doordat de eerste de ^[a-zA-Z] is en ik daarna pas {8,16] doe?

@RobIII: Gaat om een oracle wachtwoord - de 16 karakters is inderdaad geen limiet van het systeem maar van mensen . Oracle vindt overigens wel meer karakters niet leuk of gevaarlijk. Ik mis de "\", "&" en de "^" nog eigenlijk.

Ik heb nu twee losse en die werken apart goed.. Dat kan ik natuurlijk ook doen... Dat komt de leesbaarheid inderdaad wel ten goede.

code:

/^[a-zA-Z](?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{7,}/
/^[^%@'"-]+$/

Reguliere expressies blijven toch een vak apart (net zoals awk)

@RobIII: Het gaat inderdaad niet plain de query in maar via parameters - gewoon een basale check op de client

(Er is veel veranderd in de forumsoftware zeg sinds mijn laatste bezoek)

[ Voor 11% gewijzigd door shades op 29-06-2017 12:09 ]

[Stoelpoot]

Regex lijkt me hier VEEL te zwaar voor. Dit kan je net zo goed met een kleine lap code doen. Bovendien heb je met complexe Regex-expressies als deze ook nog de kans dat het lang gaat duren

Overigens... zodra je een wachtwoord limiet van 16 tekens aanhoud krijg ik t in mijn wachtwoord generator niet eens meer standaard gegenereerd. Ik zou er gewoon 255 als limiet op zetten en niet over nadenken. Er zijn mensen die er op gaan afhaken. (zoals ook zou moeten met een wachtwoord maximale lengte limiet...)

Als je je afvraagt wat voor lengtes wachtwoorden mensen gebruiken: Ik genereer 64 tekens lang, puur omdat dat even snel is als 32 en ik ze toch niet zelf hoef te onthouden. 16 gaat langer duren.

Overigens... Geen wachtwoord hashes? Daar hoef je sowieso niet bang te zijn voor verboden karakters.

[NMe]

rikpro schreef op donderdag 29 juni 2017 @ 12:12:
Regex lijkt me hier VEEL te zwaar voor. Dit kan je net zo goed met een kleine lap code doen. Bovendien heb je met complexe Regex-expressies als deze ook nog de kans dat het lang gaat duren

Natuurlijk is het zwaarder dan gerichtere checks, zeker met al die lookaheads... Maar je overdrijft wel een klein beetje. We hebben het hier nog steeds over enkele milliseconden max op zo'n korte string als een wachtwoord.

[shades]

Heb de check op de client ieder geval werkend. Viel wel mee nu de regex in twee etappes gaat.
Dank voor de hints

[RobIII]

shades schreef op donderdag 29 juni 2017 @ 12:03:
@RobIII: Het gaat inderdaad niet plain de query in maar via parameters - gewoon een basale check op de client

Waarom zou je die 'basale check" dan überhaupt nog doen Zolang je parameterized queries gebruikt zijn die tekens helemaal geen probleem (en zou je geen parameterized queries gebruiken, wat je natuurlijk wél moet doen, dan moesten die tekens nog geen probleem zijn want dan zou je ze gewoon moeten escapen). Either way moeten die tekens gewoon geldige (wachtwoord)tekens zijn.

[ Voor 6% gewijzigd door RobIII op 29-06-2017 13:15 ]

[Stoelpoot]

NMe schreef op donderdag 29 juni 2017 @ 12:58:
[...]

Natuurlijk is het zwaarder dan gerichtere checks, zeker met al die lookaheads... Maar je overdrijft wel een klein beetje. We hebben het hier nog steeds over enkele milliseconden max op zo'n korte string als een wachtwoord.

Nee, die Regex controleert of het een korte string is. Of het een korte string is moet je nog maar afwachten. Wat gebeurd er als ik het Oxford Dictionary erin zet? De Regex komt ie niet door... maar daar komt ie wel bij.

[NMe]

rikpro schreef op donderdag 29 juni 2017 @ 13:22:
[...]

Nee, die Regex controleert of het een korte string is. Of het een korte string is moet je nog maar afwachten. Wat gebeurd er als ik het Oxford Dictionary erin zet? De Regex komt ie niet door... maar daar komt ie wel bij.

Als iemand zo nodig Hamlet in een wachtwoordveld wil copy/pasten is het gewoon zijn eigen schuld als het allemaal wat langer duurt. Met dat soort redenen voor optimalisaties ga ik mijn tijd in elk geval niet verspillen tenzij ik anders duimen zou zitten draaien...

[Caelorum]

rikpro schreef op donderdag 29 juni 2017 @ 13:22:
[...]
Nee, die Regex controleert of het een korte string is. Of het een korte string is moet je nog maar afwachten. Wat gebeurd er als ik het Oxford Dictionary erin zet?[...]

Ik hoop dat je post dan sowieso al te lang is en je webserver het gewoon afkapt. Dat soort onzinnige requests moet je niet eens iets mee willen doen.

[.oisyn]

NMe schreef op donderdag 29 juni 2017 @ 13:32:
[...]

Als iemand zo nodig Hamlet in een wachtwoordveld wil copy/pasten is het gewoon zijn eigen schuld als het allemaal wat langer duurt. Met dat soort redenen voor optimalisaties ga ik mijn tijd in elk geval niet verspillen tenzij ik anders duimen zou zitten draaien...

Oneens. De persoon in kwestie heeft er alsnog geen last van (want het blijft milliseconden werk), maar het opent wel een DDoS attack vector. Maar goed, controleren op lengte doe je natuurlijk absoluut niet met een regex

[windwarrior]

.oisyn schreef op donderdag 29 juni 2017 @ 13:48:
[...]


Oneens. De persoon in kwestie heeft er alsnog geen last van (want het blijft milliseconden werk), maar het opent wel een DDoS attack vector. Maar goed, controleren op lengte doe je natuurlijk absoluut niet met een regex

offtopic:
Dit heeft inderdaad wel eens een attack vector opgeleverd, bijvoorbeeld in het populaire Python webframework Django. Zie ook hier. Uiteindelijk hebben ze de password lengte gecapped op 4096 bytes.

[NMe]

.oisyn schreef op donderdag 29 juni 2017 @ 13:48:
[...]

Oneens. De persoon in kwestie heeft er alsnog geen last van (want het blijft milliseconden werk), maar het opent wel een DDoS attack vector. Maar goed, controleren op lengte doe je natuurlijk absoluut niet met een regex

We hebben het hier over een regex in Javascript though. Tenzij we het over Node.js of iets dergelijks hebben is het dus gewoon de client z'n eigen probleem.

[.oisyn]

NMe schreef op donderdag 29 juni 2017 @ 14:02:
[...]

We hebben het hier over een regex in Javascript though. Tenzij we het over Node.js of iets dergelijks hebben is het dus gewoon de client z'n eigen probleem.

Niet zo relevant. Het lijkt me dat je de checks die de backend doet wilt reproduceren in de frontend. En zolang je in de backend een lengtecheck doet, wil je dat in de frontend ook doen. Draai je dit om door te zeggen dat de frontend de check niet hoeft te doen, dan zou je daaruit op kunnen maken dat het ook in de backend niet nodig is.

[Stoelpoot]

NMe schreef op donderdag 29 juni 2017 @ 13:32:
[...]

Als iemand zo nodig Hamlet in een wachtwoordveld wil copy/pasten is het gewoon zijn eigen schuld als het allemaal wat langer duurt. Met dat soort redenen voor optimalisaties ga ik mijn tijd in elk geval niet verspillen tenzij ik anders duimen zou zitten draaien...

Per ongeluk het wachtwoord niet kopieren met je vette vingers misschien en een lang stuk tekst erin plakken?

Overigens denk ik dat dit geen optimalisatie is, meer een verkeerde aanpak. Ik heb in een fractie van de tijd als dat TS met zo'n Regex bezig is de validatie method. Die is dan ook nog eens veiliger, en makkelijker te debuggen / aanpassen als er ooit iets moet worden aangepast.