Je kunt je inderdaad afvragen of dit een probleem is en zo ja wiens probleem dit dan is.
Het is natuurlijk de fout van de gebruiker om zijn/haar wachtwoorden te hergebruiken over websites heen. Aan de andere kant, moeten we de gebruiker soms ook tegen zichzelf in bescherming nemen.
Als het password spraying betreft, ja dan valt er wel iets voor te zeggen dat NS dat had moeten detecteren en blokkeren. Maar als dat steeds vanaf verschillende IP's op verschillende accounts op langzaam tempo gebeurd, dan is dat nog best lastig om goed te doen. Accounts blokkeren bij x aantal foutieve pogingen is namelijk ook te misbruiken, voor dat je het weet kan je bewust iemand anders zijn/haar account blokkeren waardoor deze niet meer kan inloggen... Vaker zie je daarna exponential backoff bij foutieve pogingen, maar meestel geen volledige blokkades op publieke accounts.
Als we even terug komen op password reuse als probleem. Dan is er wel een standaard die daar wat over zegt, namelijk de OWASP Application Security Verification Standard 4.0.
PDF:
https://owasp.org/www-pdf...ation_Standard_4.0-en.pdf
Als je uitgaat van level 2 'Most applications', waaronder ik de app van NS ook zou laten vallen, dan wordt er eigenlijk verwacht dat het authenticatie systeem bepaalde wachtwoorden blokkeert. Dat kan zijn op basis van een lijst met veelvoorkomende wachtwoorden of door een externe API te gebruiken.
2.1.7 Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new nonbreached password. (C6)
Je zou dit soort aanvallen dus kunnen beperken door de gelekte lijst van Have I Been Powned op te nemen in je identity oplossing. Of als het wat meer realtime moet werken, de API van Have I Been Powned kunnen aansluiten. Dekt dat alles af? Zeker niet, niet alle lekken staan meteen in de database maar kan wel helpen.
Een betere oplossing is wat mij betreft het inzetten van MFA / 2FA. Is meestal niet heel toegankelijk of gebruiksvriendelijk, maar het zal zeker helpen de accounts beter af te schermen omdat de partij die misbruik maakt van een account door een gelekt wachtwoord meestal geen toegang heeft tot de tweede factor. Aandachtspuntje is dan wel het kanaal waarover de 2e factor OTP verzonden wordt, als dat een SMS of e-mail box is die toegankelijk is met een gebruikersnaam/wachtwoord combinatie zonder MFA loop je daar mogelijk weer op vast als daar ook hetzelfde wachtwoord is gebruikt.
De gebruiker blijft altijd de zwakste schakel, maar we kunnen vanuit technisch oogpunt wel wat maatregelen nemen om de kans op het voordoen van het risico te verkleinen. Laten we de gebruikers vooral verleiden om MFA in te zetten door het ze zo eenvoudig mogelijk te maken.