Wachtwoordbeleid



Toon eerste bericht

108 reacties

Reputatie 4
Badge
@ARDAXI en @WELEY: Ik hoop dat KNAB hiermee verder kan en de discussie rond de dwangmatige halfjaarlijkse wachtwoordwijziging een afronding kan krijgen.(ik pik de rode draad van jullie verhalen wel op maar kan daarin geen bijdrage leveren)
Als gebruiker en als discussie vraag ik me wel af waarom zo'n zware beveiliging noodzakelijk is.
1, voor toegang tot de cijfers van de rekeningen en sub-rekeningen ?
2. beveiliging van het adresboek ?
Hierin zie ik toch wel verschillen. Punt 1 zie ik als privacygevoelig maar niet direct met financiële schade ? Voor overboekingen zijn wereldpas en pincode noodzakelijk (icm cardreader) !
Punt 2 kan door manipulaties van een indringer wel financiële schade betekenen - wijzigen van banknummers zonder naamswijziging. Banken controleren de relatie tenaamstelling en IBAN niet meer.
In deze context zou een zware beveiliging van het adresboek relevant zijn.
Met deze aanpak kun je een comfortabele toegang hebben tot je mutaties, saldi enz. maar de toegang tot het adresboek is zwaar afgegrendeld.
Hoe zien jullie deze redenatie?
Reputatie 4
Badge
Ander idee voor toegang tot de desktopomgeving::
Na het invoeren van je gebruikersnaam presenteert KNAB een variabele QR-code die met je smartphone een variabel wachtwoord toont dat handmatig ingevoerd moet worden om samen met de reeds ingevoerde gebruikersnaam toegang tot de desktopomgeving verschaft = variabel wachtwoord en zonder wachtwoordmanager.Dus ook geen halfjaarlijkse wijzigingen meer.
Bedankt voor de reacties op mijn verhaal, het geeft in ieder geval aan dat er hier mensen zijn die daadwerkelijk iets weten over security en dat er een goede discussie gevoerd kan worden. Waar het mij in ieder geval om gaat is dat een partij als Knab zit inzet om mensen mede bewust te maken van hun veiligheid, als bank laat je dan ook zien dat het je menens is met security.

Mijn punt over het wijzigen van een wachtwoord blijft onveranderd, ik heb liever een goed wachtwoord dat niet te kraken is en die ik niet hoef aan te passen dan dat er een schijnveiligheid is van iedere 6 maanden je wachtwoord aan te passen van 'Pukkie201701' naar 'Pukkie201707', gechargeerd gezegd, daar de gemiddelde gebruiker die 32 posities simpelweg niet volmaakt en gemiddeld een redelijk simpel wachtwoord hanteert dat niet veiliger wordt na een wijziging. Wel wordt het lastiger voor de gebruiker om alles te onthouden, omdat het gewijzigd is, daarom mijn voorkeur voor een wachtwoord manager.

Verder ben ik prima tevreden over Knab, ik heb het gevoel dat deze club echt naar de klanten luistert. Al zeg ik er bij, ik ben pas 7 maanden klant...
Reputatie 1
Ik wil ook even deze blog post van Troy Hunt toevoegen aan deze discussie, compleet met lijst van NIST aanbevelingen waarvan Knab meer dan de helft breekt:

https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/

Met name:

Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length

All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well.

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets
Hele goede column van Troy Hunt, ik beschouw dit als een must-read voor Knab.
Goedemorgen,

Ik wil jullie er even op wijzen dat onderzoek uitwijst dat dit soort ongefundeerde 'security' practices alleen maar voor ZWAKKERE wachtwoorden zorgen. Zie FTC onderzoek van rond maart: https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes

Please, please, doe dit niet. Behalve als er een hack/veiligheidslek is geweest.


Dat klopt KNAB.

Het wachtwoord steeds moeten aanpassen is superirritant en totaal overbodig.
Je krijgt dingen zoals 123Piet en 234Piet enzovoort.
Geef op zijn minst die optie om dat niet te hoeven doen.
Bijvoorbeeld, bij personeel dat een bankaccount beheert voor het bedrijf lijkt me (iets) nuttig. Maar als ZZP-er niet.
Reputatie 5
Badge +1
Hoi allemaal! Het heeft lang geduurd voordat wij jullie een update hebben kunnen geven over dit onderwerp, maar hij is er nu! 🙂 We hebben voor jullie geprobeerd zo veel mogelijk informatie uit onze security collega's te trekken:

Wachtwoorbeleid van nu
Er is, toen Knab 5 jaar geleden begon, voor gekozen om onze klanten regelmatig hun wachtwoord te laten veranderen. Deze keuze is toen een afweging geweest tussen veiligheid en gebruiksgemak. Aan de ene kant veiligheid door onze gebruikers elk half jaar het wachtwoord te laten wijzigen om zo te voorkomen dat een gebruiker op meerdere sites hetzelfde wachtwoord gebruikt. En aan de andere kant het gebruikersgemak zodat jullie niet elke keer de cardreader erbij hoeven te pakken.

Velen hebben gemeld dat dit een achterhaald principe is, en mijn veiligheidscollega’s zijn het hier ondertussen ook deels mee eens. Om die reden wordt er druk gekeken naar alternatieven. Jullie hebben al wat suggesties genoemd, deze heb ik hieronder opgesomd inclusief redenen waarom wij daar tegen zijn:

- Passwordmanager
“Als jullie dan zo willen dat ik mijn wachtwoord vaak verander, waarom mag ik dan geen passwordmanager gebruiken?” Ook hier zit een veiligheidsgedachte achter; sommige passwordmanagers slaan je wachtwoorden op in de cloud. Om te voorkomen dat, wanneer die gehackt worden, mensen kunnen inloggen op je Knab omgeving hebben we alle passwordmanagers helaas zo veel mogelijk moeten blokkeren.`

Edit 16-08 2018: Passwordmanagers worden niet tegengewerkt op onze website. Aan de andere kant werken wij ook niet actief aan het ondersteunen ervan; compatibiliteit met Knab wordt bepaald door de software van de passwordmanager.

- Passphrase gebruiken
Hoewel een passphrase gezien wordt, ook bij ons, als zeer veilig willen wij mensen niet dwingen om dit te doen. Hierbij is het niet voor iedereen vriendelijke optie, en ook hier kan het gebeuren dat mensen dezelfde passphrase op meerdere plekken gaan gebruiken. Dat risico proberen we dus nu uit te sluiten door het vragen om een nieuw wachtwoord in te stellen.

- Alle bijzondere tekens toe staan
We bieden een beperkt aantal bijzondere tekens aan voor het kiezen van je wachtwoord. We hebben gevraagd dit uit te breiden. Helaas kunnen niet alle bijzondere tekens worden ingevoerd, er zijn een aantal beperkingen waar wij aan onze kant rekening mee moeten houden waardoor we dat niet mogelijk kunnen maken.

- Gebruik QR scanner uit de app
Er is overwogen om de QR scanner uit de app te gebruiken voor het inloggen op de Knab website. Er is binnen Knab een goed overwogen besluit genomen om dit niet te doen.

Wachtwoordbeleid van de toekomst
Er lopen projecten binnen Knab om het inloggen op de Knab site aan te passen. Hierbij worden de verschillende voors en tegens van diverse beveiligingsopties tegen het licht gehouden. Op dit moment is de verwachting dat wij een 2-staps verificatie gaan invoeren. De verwachtte termijn voor een invoer hiervan is ongeveer 6 tot 12 maanden. Dit geeft ook nieuwe perspectieven voor het periodiek moeten veranderen van wachtwoorden; zoals het er nu uit ziet gaan we dit inderdaad uitfaseren. Als we dit eerder kunnen doen, dan zullen we dat ook zeker eerder doen.

Vanuit de security collega’s willen wij jullie ook laten weten dat zij alles mee hebben gelezen en alle opties, suggesties en tips meenemen in de overwegingen om goede en degelijke keuzes te maken voor de beveiliging van de Knab omgeving.

Natuurlijk kan ik mij voorstellen dat er misschien vragen zijn, zeker over details van bepaalde beslissingen. Omdat het over beveiliging gaat kunnen wij niet ‘het achterste van de tong’ laten zien. Daarbij moeten we sommigen misschien teleurstellen dat wij niet verder in kunnen gaan op bepaalde details.

Mijn collega’s van security zitten bovenop dit onderwerp en werken continue hard aan de beveiliging van Knab ookal is dat vaak onzichtbaar.
Reputatie 1
Laten we dit dan eens stuk voor stuk bekijken.
- Passwordmanager
“Als jullie dan zo willen dat ik mijn wachtwoord vaak verander, waarom mag ik dan geen passwordmanager gebruiken?” Ook hier zit een veiligheidsgedachte achter; sommige passwordmanagers slaan je wachtwoorden op in de cloud. Om te voorkomen dat, wanneer die gehackt worden, mensen kunnen inloggen op je Knab omgeving hebben we alle passwordmanagers helaas zo veel mogelijk moeten blokkeren.

Komt erop neer dat je je klant niet vertrouwt. Prima instelling, maar waarom ophouden bij het blokkeren van passwordmanagers? Als je mensen een wachtwoord zelf laat kiezen is er een kans dat ze een onveilig wachtwoord kiezen. Dan kun je beter een wachtwoord voor ze verzinnen.

Sterker nog, als je mensen online laat inloggen heb je een kans dat ze per ongeluk op een nepsite inloggen. Je kunt dus beter helemaal geen internetbankieren aanbieden, dat is een stuk veiliger.

Waarom hebben jullie deze ontzettend arbitraire grens bij een passwordmanager gezet?


- Passphrase gebruiken
Hoewel een passphrase gezien wordt, ook bij ons, als zeer veilig willen wij mensen niet dwingen om dit te doen. Hierbij is het niet voor iedereen vriendelijke optie, en ook hier kan het gebeuren dat mensen dezelfde passphrase op meerdere plekken gaan gebruiken. Dat risico proberen we dus nu uit te sluiten door het vragen om een nieuw wachtwoord in te stellen.

Het is natuurlijk onzin om een zelfgekozen wachtwoord te limiteren "omdat het kan gebeuren dat mensen hetzelfde wachtwoord op meerdere plekken gaan gebruiken." Dat kun je alleen maar voorkomen door mensen niet zelf een wachtwoord te laten kiezen. Er is geen enkele andere oplossing voor dat probleem, want degene die hun wachtwoord hergebruikt verandert dezelfde 1 in een 2 op elke website die ze dwingt om hun wachtwoord te rouleren.


- Alle bijzondere tekens toe staan
We bieden een beperkt aantal bijzondere tekens aan voor het kiezen van je wachtwoord. We hebben gevraagd dit uit te breiden. Helaas kunnen niet alle bijzondere tekens worden ingevoerd, er zijn een aantal beperkingen waar wij aan onze kant rekening mee moeten houden waardoor we dat niet mogelijk kunnen maken.

Het feit dat er beperkingen zijn aan jullie kant maakt me echt gigantisch achterdochtig over de veiligheid van jullie authenticatie. Hashen jullie wel?

De enige beperkingen die er technisch gezien mogelijk zijn leiden tot verminderde beveiliging van mijn gevoelige informatie. Zijn jullie er comfortabel mee dat toe te geven?
Reputatie 4
Badge
@ARDAXI: BRAVO :)
@KNAB: Ik hoop dat jullie de (voor-)ingenomen standpunten herzien door de opmerkingen van ARDAXI. Misschien is een concurrentieonderzoek - hoe doen andere banken het - op zijn plaats om geen buitenbeentje te worden die het wiel opnieuw probeert uit te vinden.
Reputatie 3

Ik wil jullie er even op wijzen dat onderzoek uitwijst dat dit soort ongefundeerde 'security' practices alleen maar voor ZWAKKERE wachtwoorden zorgen. Zie FTC onderzoek van rond maart ... Please, please, doe dit niet. Behalve als er een hack/veiligheidslek is geweest.


Ik kom hiet nogmaals op terug nadat ik WEER op een meest ongelukkig moment een wachtwoord verandering moest doen. Waarom zou je dit in godsnaam in het midden van een iDeal transactie forceren?

Alsjeblieft KNAB. Jullie verbeteren zo goed met de app etc, waarom deze onkundige onzin?
Reputatie 3
- Passwordmanager
“Als jullie dan zo willen dat ik mijn wachtwoord vaak verander, waarom mag ik dan geen passwordmanager gebruiken?” Ook hier zit een veiligheidsgedachte achter; sommige passwordmanagers slaan je wachtwoorden op in de cloud. Om te voorkomen dat, wanneer die gehackt worden, mensen kunnen inloggen op je Knab omgeving hebben we alle passwordmanagers helaas zo veel mogelijk moeten blokkeren.


Password managers zijn veiliger dan mensen. Daarnaast worden de wachtwoorden bij password managers als LastPass en OnePassword als salted hashes opgeslagen. Mensen zijn mensen, het is dus onmogelijk dat ze voor elke website een ander veilig wachtwoord in hun hoofd onthouden. Welke stagaire heeft besloten password managers te blokkeren weet ik niet, maar stuur hem eens naar Defcon of Blackhat om met echte pentesters te praten.

Passwords are not the weak link in your customers.

- Alle bijzondere tekens toe staan
We bieden een beperkt aantal bijzondere tekens aan voor het kiezen van je wachtwoord. We hebben gevraagd dit uit te breiden. Helaas kunnen niet alle bijzondere tekens worden ingevoerd, er zijn een aantal beperkingen waar wij aan onze kant rekening mee moeten houden waardoor we dat niet mogelijk kunnen maken.


De enige reden dit niet te doen is dat je als developer bang bent voor injectie attacks of parse fouten. Dat ligt puur aan industry standard code schrijven die met * en ; kan omgaan zonder je database op te blazen. Deze uitleg is toch wel zo onzinnig...

Wachtwoordbeleid van de toekomst
Op dit moment is de verwachting dat wij een 2-staps verificatie gaan invoeren. De verwachtte termijn voor een invoer hiervan is ongeveer 6 tot 12 maanden. Dit geeft ook nieuwe perspectieven voor het periodiek moeten veranderen van wachtwoorden; zoals het er nu uit ziet gaan we dit inderdaad uitfaseren. Als we dit eerder kunnen doen, dan zullen we dat ook zeker eerder doen.


Praise the lord. Een lichtpuntje. Zolang na de 2FA implementatie mandatory password changes maar worden uitgezet.

Laat ik even duidelijk zijn. Deze redeneringen zijn dom en onzinnig, stroken niet met de realiteit van technologie en zijn een belediging naar de klant. Daarbij zeg ik wel dat andere banken nog slechter zijn, en vaak niet eens communiceren.

Ik waardeer de communicatie.

Ik be teleurgesteld over de conclusies.

Edit: spelling
Reputatie 1
Badge
Welke stagaire heeft besloten password managers te blokkeren weet ik niet, maar stuur hem eens naar Defcon of Blackhat om met echte pentesters te praten.


Ik geloof niet, dat het een stagaire was. Maar echt verstand van computer had deze persoon niet, inderdaad. Wat je nog vergeten heeft:

Het is gewoon niet mogelijk "passwordmanagers te blokkeren". Ten minste niet effectief. Je kunt het opslaan van een password namelijk afdwingen:
https://ostermiller.org/bookmarklets/password.html

Je gebruikt zo een bookmarklet en dan slaat je brouwser het password gewoon op, ook als de webpagina dit niet wil toestaan. Ik heb het zo gedaan, nadat mij dit password beleid erg op de zenuwen werkte.

Maar om het goede perspectief te behouden: Prima dat een 2FA komt. Graag dan of de gewone pasreader, die we al hebben, of als dat niet gewenst is, dan ten minste een openbare industrie standaard gebruiken, die dus niet alleen bij Knab werkt. Denk aan FIDO U2F en zoiets.
Reputatie 2
Badge

- Passwordmanager
“Als jullie dan zo willen dat ik mijn wachtwoord vaak verander, waarom mag ik dan geen passwordmanager gebruiken?” Ook hier zit een veiligheidsgedachte achter; sommige passwordmanagers slaan je wachtwoorden op in de cloud. Om te voorkomen dat, wanneer die gehackt worden, mensen kunnen inloggen op je Knab omgeving hebben we alle passwordmanagers helaas zo veel mogelijk moeten blokkeren.

Is dit inmiddels al niet achterhaald? Zoals in eerdere reacties is beschreven, dit bezwaar is door de password manager makers erkend en opgelost. Ik gebruik Bitwarden nu een aantal weken. Laten hackers de cloud maar 'leeghalen'. Ze hebben er niets aan.
Reputatie 5
Badge +1
Na een nieuw overleg met onze security mensen zijn er een paar dingetjes die ik even wil aanstippen naar aanleiding van de reacties.

Gemiddelde gebruiker
Voordat ik er in duik is het belangrijk te melden dat de gemiddelde gebruiker in gedachten wordt gehouden en vervolgens hoe deze om gaat (en om kan gaan of kennis en kunde heeft) met verschillende beveiligingsmogelijkheden. Dat zal ongetwijfeld soms botsen met jullie expertise.

Vertrouwen in de cloud
Het is allereerst natuurlijk een vreemd en verwrongen beeld dat wij klanten niet vertrouwen. Het gaat hier om de passwordmanagers waar het pijnpunt zit. Er is natuurlijk onderscheid tussen een passwordmanager uit de cloud en een passwordmanager die de cloud niet gebruikt, maar dat zal een gemiddelde gebruiker niet door hebben.

Wachtwoordwijzigingen
Dan komen we terug op het wijzigen van wachtwoorden. De overtuiging bij security blijft dat een kleine wijziging van wachtwoord, voor nu, als veiliger beschouwd kan worden dan gebruik van hetzelfde wachtwoord. Dit is dus een maatregel om te voorkomen dat hetzelfde wachtwoord op meerdere plekken wordt gebruikt. Het gebruik een passphrase is een prima beveiligingsmaatregel. Omdat niet iedereen deze techniek kent en gebruikt behouden wij de verplichting om cijfers en speciale karakters te gebruiken.

Zoals eerder vermeld snappen we dat het als irritant wordt ervaren dat een wachtwoord regelamtig veranderd moet worden. We verwachten dat we een andere manier van inloggen kunnen gaan aanbieden vanaf 6-12 maanden van nu waarbij dit niet langer nodig zal zijn.

Hashen en speciale tekens
De wachtwoorden worden uiteraard gehashed opgeslagen in de database. Het feit dat bepaalde speciale tekens worden geweigerd heeft te maken met de generieke inputvalidatie die gebruikt wordt om SQL-injectie af te vangen. Het is een terechte opmerking dat dit geen issue zou moeten zijn. Omdat er grote wijzigingen aankomen met het inloggen zal er nu geen energie worden gestoken in het beschikbaar maken van meerdere speciale tekens.

Beveiliging = check
Wij zijn er comfortabel mee toe te geven dat je gegevens zichtbaar en onzichtbaar goed beveiligd zijn. We worden ook regelmatig door verschillende partijen getoetst op ons beleid om er voor te zorgen dat wij alles zo goed mogelijk beveiligen. Als bank kun je je ook geen beveiligingsproblemen permitteren. Graag wil ik nogmaals aangeven dat wij niet alles kenbaar maken van hoe wij onze systemen beveiligen. Die informatie geven wij ook gewoon echt niet prijs. Dat is een kwestie van vertrouwen.

Gebruiker-informatie
Op onze site hebben wij wel een pagina die vertelt over veiligheid en beveiliging. Nu zijn wij heel erg benieuwd naar hoe wij de informatie beter kunnen overbrengen; wat mis je, welke informatie die wel belangrijk is ontbreekt er nu? Belangrijk om te weten is dat dit een pagina is voor de gemiddelde gebruiker, de informatie moet daarom ook zo toegankelijk mogelijk zijn. Wat zijn jullie ideeën daarbij? Ik en mijn security collega's zijn benieuwd naar jullie input!
Reputatie 2
Badge
Als gemiddelde gebruiker vind ik het prima zoals het nu gaat. Dank voor de reactie.
Reputatie 1
Wachtwoordwijzigingen
Dan komen we terug op het wijzigen van wachtwoorden. De overtuiging bij security blijft dat een kleine wijziging van wachtwoord, voor nu, als veiliger beschouwd kan worden dan gebruik van hetzelfde wachtwoord. Dit is dus een maatregel om te voorkomen dat hetzelfde wachtwoord op meerdere plekken wordt gebruikt. Het gebruik een passphrase is een prima beveiligingsmaatregel. Omdat niet iedereen deze techniek kent en gebruikt behouden wij de verplichting om cijfers en speciale karakters te gebruiken.

De overtuiging bij security botst met de overtuiging van mensen die een daadwerkelijk een welverdiende reputatie binnen de security community hebben opgebouwd, en hun standpunt ook een stuk beter onderbouwen. E.e.a. is al hierboven geplaatst. Heeft weinig zin om daar meer aan toe te voegen.


Hashen en speciale tekens
De wachtwoorden worden uiteraard gehashed opgeslagen in de database. Het feit dat bepaalde speciale tekens worden geweigerd heeft te maken met de generieke inputvalidatie die gebruikt wordt om SQL-injectie af te vangen. Het is een terechte opmerking dat dit geen issue zou moeten zijn. Omdat er grote wijzigingen aankomen met het inloggen zal er nu geen energie worden gestoken in het beschikbaar maken van meerdere speciale tekens.

Dat is dus volledige onzin. Er zijn twee mogelijkheden: of de wachtwoorden worden gehashed opgeslagen in de database, of je moet inputvalidatie doen om SQL-injecties af te vangen. Als je hashes opslaat is inputvalidatie volledig nutteloos.

Ik stel mijn vraag nogmaals. Welke van de twee opties is correct? Worden wachtwoorden gehashed opgeslagen of moeten jullie input sanitation doen?
Reputatie 5
Badge +1



Hashen en speciale tekens
De wachtwoorden worden uiteraard gehashed opgeslagen in de database. Het feit dat bepaalde speciale tekens worden geweigerd heeft te maken met de generieke inputvalidatie die gebruikt wordt om SQL-injectie af te vangen. Het is een terechte opmerking dat dit geen issue zou moeten zijn. Omdat er grote wijzigingen aankomen met het inloggen zal er nu geen energie worden gestoken in het beschikbaar maken van meerdere speciale tekens.

Dat is dus volledige onzin. Er zijn twee mogelijkheden: of de wachtwoorden worden gehashed opgeslagen in de database, of je moet inputvalidatie doen om SQL-injecties af te vangen. Als je hashes opslaat is inputvalidatie volledig nutteloos.

Ik stel mijn vraag nogmaals. Welke van de twee opties is correct? Worden wachtwoorden gehashed opgeslagen of moeten jullie input sanitation doen?


Beide opties zijn correct. Meer dan dat kan ik je niet melden.
Reputatie 1



Hashen en speciale tekens
De wachtwoorden worden uiteraard gehashed opgeslagen in de database. Het feit dat bepaalde speciale tekens worden geweigerd heeft te maken met de generieke inputvalidatie die gebruikt wordt om SQL-injectie af te vangen. Het is een terechte opmerking dat dit geen issue zou moeten zijn. Omdat er grote wijzigingen aankomen met het inloggen zal er nu geen energie worden gestoken in het beschikbaar maken van meerdere speciale tekens.

Dat is dus volledige onzin. Er zijn twee mogelijkheden: of de wachtwoorden worden gehashed opgeslagen in de database, of je moet inputvalidatie doen om SQL-injecties af te vangen. Als je hashes opslaat is inputvalidatie volledig nutteloos.

Ik stel mijn vraag nogmaals. Welke van de twee opties is correct? Worden wachtwoorden gehashed opgeslagen of moeten jullie input sanitation doen?


Beide opties zijn correct. Meer dan dat kan ik je niet melden.

Dat is onmogelijk. De output van een hashfunctie is een getal. Hoe je dat verder opslaat moet je zelf weten, maar inputvalidatie heb je niet nodig om een getal op te slaan.

Overigens heb je het sowieso niet nodig als je een database driver gebruikt die in de afgelopen tien jaar ontwikkeld is maar dat terzijde.

Je weet precies wat de output range is van je hash functie. Er komen of alleen maar cijfers uit, of je doet er iets mee om er een string van te maken. Either way komt het uit je eigen implementatie en kan ik er als aanvaller onmogelijk iets uit laten komen wat als valide SQL geaccepteerd zal worden.

Ik begin me nu heel erg zorgen te maken om de beveiliging. Ik ga er voorlopig maar voor het gemak vanuit dat er ergens een policy is dat je overal input validation op moet doen, want als het echt nodig is voor de beveiliging is mijn bank account nog slechter beveiligd dan een Wordpress release van vijf jaar geleden.
Hallo Knab,

Heb vandaag weer mijn wachtwoord moeten veranderen om in te kunnen loggen bij Knab.
Heel irritant en onhandig!

Knab wenst dat ik mijn wachtwoord geheim houd, Knab adviseert om het wachtwoord niet ergens op te schrijven.
Knab adviseert om een moeilijk wachtwoord aan te maken en dit wachtwoord niet voor andere sites te gebruiken.

Hoe kan je je wachtwoord ooit onthouden als je het steeds weer moet wijzigen?
Vreselijk irritant dit!
Ik heb zoals waarschijnlijk iedereen toch ergens een boekje liggen waarin alle wachtwoorden staan opgeschreven. Tja, niet veilig, maar hoe anders?
Is gewoon of voor alles eenzelfde wachtwoord gebruiken, of ze ergens noteren.
In dit geval was het helemaal lastig omdat ik in wilde loggen via mijn iPad op een andere plek dan thuis en ik de nieuwe inlogcode dus niet direct in mijn boekje kon noteren. Wat een gedoe weer!

Zou prettig zijn als Knab niet slechts aan eigen belang denkt bij het nemen van dit soort maatregels maar er ook over nadenkt wat werkbaar is voor haar klanten.

U hoeft mij niet te bellen met een uitleg want ik snap wel dat dit met veiligheid te maken heeft. Gaat mij erom dat u niet alleen aan uw veiligheid denkt maar ook aan uw klant.
Bovendien heb ik er geen zin in om na een telefonisch contact met een van uw medewerkers, waarbij het gesprek al werd opgenomen om de service in de toekomst nog verder te verbeteren, ik per mail weer een klein vragenlijstje voorgeschoteld krijg (neemt slechts enkele minuten van mijn tijd in beslag) als klant-tevredenheidsonderzoek om mij in de toekomst nog beter van dienst te kunnen zijn.

Nou, deze klant is dus niet tevreden over het steeds moeten wijzigen van de inlogcode en stelt die onzinnige klant-tevredenheidsonderzoekjes ook niet op prijs. Ik denk overigens dat ik hierin niet alleen sta.

Lex B
Reputatie 5
Badge +1
Hallo Knab,

Heb vandaag weer mijn wachtwoord moeten veranderen om in te kunnen loggen bij Knab.
Heel irritant en onhandig!


Hoi Lex, ik heb je opmerking verplaatst naar het wachtwoorden-topic. Hier vind je de hele discussie die gevoerd wordt over ons wachtwoord beleid.
Reputatie 2
Badge

Hoe kan je je wachtwoord ooit onthouden als je het steeds weer moet wijzigen?
Vreselijk irritant dit!

Heel simpel Lex, met oa. Bitwarden (https://bitwarden.com)
discussie over hashes / SQL-validatie
Je hebt gelijk dat hashes ervoor zorgen dat er geen sprake kan zijn van SQL injectie, maar dat lijkt hier niet zo relevant.

Wat ik uit de reactie van Knab afleid is dat er gebruik wordt gemaakt van een webapplicatiefirewall, een programma dat alle inkomende requests en responses controleert en filtert ("generieke inputvalidatie"). Ná dat programma zal de bank/databaseapplicatie ongetwijfeld hashes toepassen (ik neem aan dat er audit-criteria zijn), maar Knab heeft er dus duidelijk voor gekozen geen uitzondering in de WAF te maken voor het wachtwoordveld (om te voorkomen dat die een request blokkeert) maar in plaats daarvan inputvalidatie in de front-end toe te voegen.

Dat is natuurlijk jammer, omdat ik (lees: mijn password kluis) ook graag meer speciale tekens gebruik, maar ik snap de redenering van Knab wel.
Reputatie 1
discussie over hashes / SQL-validatieWat ik uit de reactie van Knab afleid is dat er gebruik wordt gemaakt van een webapplicatiefirewall, een programma dat alle inkomende requests en responses controleert en filtert ("generieke inputvalidatie"). Ná dat programma zal de bank/databaseapplicatie ongetwijfeld hashes toepassen (ik neem aan dat er audit-criteria zijn), maar Knab heeft er dus duidelijk voor gekozen geen uitzondering in de WAF te maken voor het wachtwoordveld (om te voorkomen dat die een request blokkeert) maar in plaats daarvan inputvalidatie in de front-end toe te voegen.

Kijk dit is dus zoiets dat me totaal niet gerust stelt. Een WAF mag DDoS beveiliging doen enzo, maar niet input validatie. Dat doe je gewoon netjes in de backend. Op zo'n manier een firewall toepassen is pleisters plakken en levert je op den duur alleen maar meer problemen op.

Afgezien daarvan zijn de speciale tekens die ik invoer naar mijn weten voor geen enkele applicatie schadelijk, dus is het mij volstrekt onduidelijk waarom die door een firewall tegengehouden moeten worden. Als je hasht, als je een goede ORM laag gebruikt voegt elke vorm van input validation niets van waarde toe.


Hashen en speciale tekens
De wachtwoorden worden uiteraard gehashed opgeslagen in de database. Het feit dat bepaalde speciale tekens worden geweigerd heeft te maken met de generieke inputvalidatie die gebruikt wordt om SQL-injectie af te vangen. Het is een terechte opmerking dat dit geen issue zou moeten zijn. Omdat er grote wijzigingen aankomen met het inloggen zal er nu geen energie worden gestoken in het beschikbaar maken van meerdere speciale tekens.


KNAB's idee van beveiliging is dus

- obscure meldingen geven "Het inloggen is helaas niet gelukt, probeer het alsjeblieft opnieuw. (xxxxx)" zodat je het meermalen gaat proberen (want er staat niet dat je username/password incorrect is, want SUPERMEGAVEILIG!!1!) zodat je account geblokekerd wordt
- password reset via de KNAB reader die met een eveneens vage melding komt omdat je account geblokkeerd is vanwege voorgaande

en na contact met telefonische helpdesk, als je account gedeblokeerd is, een nieuw wachtwoord door je passwordmanager laat genereren en uiteindelijk de optie 'speciale tekens' maar uitzet omdat iemand bij KNAB toch nog bang is voor een SQL injection attack vector.

Over dat laatste wil ik deze geniale en to-the-pointe XKCD delen:



Inmiddels heb ik mijn rekeningen bij KNAB opgezegd. Dit ging trouwens makkelijker dan inloggen.
Reputatie 3
Ik kom nogmaals terug in dit thread na een geforceerde password change.

Opmerking 1: Het is duidelijk dat het security team niet evidence-based is. Het doet mijn hart pijn. I want to like you, maar er is inmiddels genoeg tijd verstreken even goed onderzoek te doen en te concluderen dat dit allemaal onzin is.

Om de gemiddelde gebruiker even te quoten:

Knab wenst dat ik mijn wachtwoord geheim houd, Knab adviseert om het wachtwoord niet ergens op te schrijven.
Knab adviseert om een moeilijk wachtwoord aan te maken en dit wachtwoord niet voor andere sites te gebruiken.

Hoe kan je je wachtwoord ooit onthouden als je het steeds weer moet wijzigen?
Vreselijk irritant dit!
Ik heb zoals waarschijnlijk iedereen toch ergens een boekje liggen waarin alle wachtwoorden staan opgeschreven. Tja, niet veilig, maar hoe anders?


Hoe komt het security team in dit plaatje tot de conclusie dat geforceerde veranderingen enig effect heeft? Nogmaals, 2FA is the way to go. En pak gewoon bestaande protocols die met Google Authenticator/Authy gebruikt kunnen worden.

**Rule 1 of crypto: don't roll your own crypto.**

Opmerking 2: Zie screenshot (ongebruikt ww, no security breach here mr stropdas), fix your regex please.



Nogmaals, ik waardeer veel van wat jullie doen, maar deze issue is echt heel sneu. En dubbel zo erg omdat het allemaal onnodig is.

Reageer