Ze leven daar duidelijk in een andere wereld, ver weg van de realiteit; waarom trek je de grens dan op 20 karakters en niet 100 of 120 ?

De beperking tot maar 20 tekens is nergens voor nodig en zoals uitgelegd onveilig. We leven niet meer in de jaren '90: er is geen technologische reden om te beperken tot 20 tekens.

ING beperkt ook niet-alfabetische ASCII karakters. Zoals het nu is voegen die paar toegestane karakters weinig toe aan de veiligheid, terwijl wel de indruk wordt gewekt dat het substantieel veiliger is. Dat is misleidend.

Banken zouden ook unicode moeten toestaan, dan is het aantal mogelijkheden veel groter en dus is het veiliger.

Is het niet beter, als ze gewoon van een UserID / Wachtwoord inlog methode afstappen?

Nee, daarmee gooi je de baby met het badwater weg. Het moet goed worden geimplementeerd met moderne inzichten en mensen moeten van koudwatervrees af en passphrases toestaan. De implementatie moet worden aangepast aan de veiligheidseisen en de menselijke methoden, niet andersom.

Zo te zien kunnen heel wat mensen gaan soliciteren bij ING voor security officer.

Die gasten hebben echt wel door wat ze doen, maak je daar maar niet druk om.

Die 20 zal nog wel een record-grens in het mainframe zijn :-)

Je moet dus niet op banken willen vertrouwen voor solide advies op het gebied van computerbeveiliging. Ook niet erg op het gebied van investeren, hypotheken, geldmanagement, en zo verder, overigens. Waar ze dan wel goed voor zijn ontgaat me even, maar ze worden nog steeds dik betaald. Wie is er zo gek om geld aan banken te geven?

Aangezien van een wachtwoord alleen de hash opgeslagen dient te worden is een limiet op de lengte of een beperking van de tekenset eigenlijk onzinnig. M.i. zijn er maar twee valide redenen om enige beperkingen hieraan op te leggen:
1. Het berekenen van de hash moet niet buitensporig veel resources in beslag nemen, dus een wachtwoord van een paar gigabyte lang is niet acceptabel, maar duizend tekens lang zou geen technisch bezwaar moeten zijn.
2. Het wachtwoord moet voor de gebruiker redelijkerwijs foutloos in te voeren zijn, maar dit is eerder aan de gebruiken om te beoordelen.
Zelf laat ik mijn wachtwoord manager wachtwoorden genereren op basis van de tekens die gemakkelijk in te voeren zijn met een standaard toetsenbord (dus grofweg ASCII zonder de control-symbols) en beperk ik de lengte tot zo'n 30 tekens. Ik erger me er altijd erg aan als mijn wachtwoord geweigerd wordt omdat er een limiet van bijv, 20 tekens is.

Zoiets wordt heus niet zo maar doorgezet in een mainframe. Hashing... Als ze geen hashing doen, dan zou het heel triest zijn. Maar waarom zou je een complete roman in willen typen? 128 bit is maar 16 bytes.

Bij dit soort keuzes (toegestane lengtes en karaktersets) moet je over lange tijd en over een hele keten systemen garanderen dat je keuze werkt.
Als je 1000 karakters unicode wilt toestaan moet je weten dat werkt , en blijft werken over een jarenlange evolutie van OSen en browsers. Zonder dat een browser update misschien automatisch een linewrap (\r\n) in een invulveld introduceert.
tabs en spaties zijn , voor hashes, NIET hetzelfde .
Zonder dat een OS of keyboard instelling een 'optisch hetzelfde' karakter vervangt door een andere unicode .
Een 'ij' (i en j ) bijvoorbeeld mag niet zomaar vervangen worden door de nederlandse lange ij (in sommige fonts net iets anders dan i+j ) .

Dat is m.i. een veel belangrijker (en in elk geval terechtere) reden dan resource issues van een hash op een input van 20 danwel 2048 bytes.

En het zijn aspecten die de gebruiker NIET zelf kan beoordelen - de gebruiker die een cut&paste doet weet niet of z'n OS dat schoon overbrengt .

Waarom je trouwens zo graag 30 in plaats van 20 gegenereerde tekens wilt hebben ontgaat me.
Als random gekozen karakters , ook uit een beperkter alfabet is 20 al meer dan genoeg voor alles wat een password aan veiligheid kan bereiken .

ING raadt klanten het gebruik van een wachtwoordmanager om wachtwoorden voor internetbankieren op te slaan af.

Hier ben ik het volkomen mee eens.

Ik heb Lastpass maar mijn paswoord bank zet ik daar niet in.
Er hoef maar iets fout te gaan.

Ik neem geen risico met zeer belangrijke gegevens.

ING met advies ?
Is dat niet die bank die een kopie maakt van je idbewijs en dan zegt neehoor we scannen alleen de echtheidskenmerken om vervolgens het bestand stiekem op te slaan en s'nachts te verzenden naar het hoofdkantoor.
Handig voor de bigdata en het volgen van je klanten.
En lekker niets zeggen past helemaal in het klant centraal stellen ??!

Moet je eens bij de Duitse bank DKB kijken: Precies 5 (vijf!) karakters lang moet je wachtwoord daar zijn.

Dat is wel erg makkelijk te beantwoorden hoor.
Een zin bestaat namelijk al snel uit maar dan 20 karakters en is zeer eenvoudig te onthouden.
Als je het afkapt op 20 karakters moeten mensen hun eenvoudige zinnen afkappen en of 'cryptische' wijze verkort noteren.

Ja, 2048 zal overdreven lang zijn en 'nooit' gebruikt worden door een gebruiker, maar 20 is wel erg kort.

Feit is (veelvuldig onderzoek heeft dit aangetoond) dat met een wachtwoord van slechts 8, 10 of 12 karakters, men nog altijd 1 woord wil gebruiken (naam, voorwerp, kleur, whatever), waar men vervolgens een getal achter zet (e.g. 2015) en/of een non-alfabetisch karakter (e.g. de !).
Lees: deze zijn in enkele minuten te kraken.
Zinnen van 13 t/m 20 karakters zijn mogelijk, maar erg moeilijk/beperkend.
Lees: keur 'gewoon' wachtwoorden tot e.g. 128 karakters goed; grote kans dat men hier sowieso niet overheen gaan, en staat mensen toe een eenvoudig te onthouden wachtwoord te gebruiken

Onzin. Waar het over gaat is het bereik van de karakter set. Die is beperkt door het gebruik van alleen alfanumerieke karakters plus wat extra tekens. Laten we dat afronden op 64 mogelijkheden. Dat is dus slechts 64 van de 256. Voor 20 van dergelijke karakters zijn dat 40 "effectieve bits".

Hashes dienen minstens 256 bits te zijn, voor bankair gebruik is het veel beter een hash te kiezen die tot ver in de toekomst zal voldoen. MD5 en SHA1 zijn al jaren niet meer ok en meer dan 20 jaar oud. Overigens is SHA1 160 bytes en dat komt overeen met 20 karakters. Toeval?

Over dat feit zijn we het eens. Nu nog naar de oorzaak en mitigatie.

Oorzaak:
- Mensen zijn in het algmeem niet in het staat veel lastige veranderende informatie uit het hoofd te onthouden (sterk geheugen). Het is voor de sociale omgang beter dan het niet sterk is.
- Sterke wachtwoorden veel in aantal en veel verandering neemt aant dat iedereen een sterk geheugen heeft .... Fout!

Gevolg:
- gebruik van zwakke wachtwoorden
- inzetten van andere hulpmiddelen (password managers)
Oei wat zijn die gebuikers dom. Kunnen we niet beter het signaal dat het niet goed werkt (dat feit) oppakken?

Mitigaties:
- Verminder het aantal accounts met sterk wachtwoord (SSO)
- Verminder de veranderingssneldheid
Waarom verplicht maandelijks veranderen bij incidenteel maandelijks gebruik.
- Functiescheiding met privilege escalatie procedureel oplossen.
De kritische gevoelige werkzaameheden wil niet overal open en bloot openstellen
- 2FA (multifactor)
Meerdere Simpele handelingen met een tijdsfactor zijn beter dan 1 enkele toegangsmethode.
Hier kan ook iets bij zijn wat je bezit.


Dat die webwinkels allemaal een Eigen user/ww geregistreerd willen zien, tja.
Hier hebben we het over je toegang tot je geld. Niet echt handig om die twee te vermengen.

Dit zegt ING in de vijfde tip:
Ze noemen wachtwoordmanagers niet expliciet.

Natuurlijk, logisch gezien impliceert wat ze zeggen dat een wachtwoordmanager dus ook niet kan, maar ik kan me heel goed voorstellen dat de mensen met verstand van zaken daar wel aan dachten maar dat alle managers en PR-mensen die zich geroepen voelden een plasje op de tekst te doen de vermelding van wachtwoordmanagers hebben geblokkeerd omdat ze zelf moeite hadden het te snappen, wachtwoordmanagers daarom als te geavanceerd voor gewone gebruikers beschouwden, en dus vonden dat het voor de begrijpelijkheid van de tips maar beter niet vermeld kon worden. Ik weet niet of het zo gegaan is, maar als mogelijkheid vind ik het volkomen plausibel.

Dat je soms even iets nieuws moet leren gebruiken om daarna veel gemak ervan te ondervinden wordt tegenwoordig als een onacceptabele drempel beschouwd. In mijn herinnering was dat dertig jaar geleden anders. Maar dertig jaar geleden werden we nog in de verste verte niet met de hoeveelheden noninformatie gebombardeerd die we tegenwoordig moeten incasseren. Misschien is ervoor kiezen je in te spannen om iets nuttigs te leren tegenwoordig wel echt moeilijker omdat er zoveel meer is dat constant onze aandacht vraagt.

Bij de ABN kun je ook een inlogcode van 5 tekens maken. Die is alleen geschikt om je saldo te bekijken. En volgens mij kun je er ook geld mee overmaken naar nummers uit het adresboek. Verder niet.

Als je een WW van 5 tekens combineert met maar 3 inlogpogingen, waarna die inlogmethode vervalt, dan valt het wel mee.

Er is al vele jaren een beweging *naar* Unicode gaande in plaats en niet naar andere character sets. OS'en ondersteunen het massaal, browsers ondersteunen het massaal, het is gewoon op dit moment de universeel toepasbare manier om teksttekens te coderen, en er is voor zover ik weet niets anders in ontwikkeling met de potentie om Unicode te vervangen. Als Unicode niet zeker genoeg is op de lange termijn, wat dan wel?

Aan invoervelden die precies weergeven wat de gebruiker heeft ingetoetst en niet net iets anders zal altijd behoefte bestaan. Een applicatie kan makkelijk regelovergangen toevoegen maar kan geen automatisch toegevoegde regelovergangen verwijderen omdat er geen manier is om ze te onderscheiden van wat een gebruiker zelf heeft ingetoetst. Het invoegen van regelovergangen maakt geen kans om in een W3C-standaard opgenomen te worden en als een browser het zelf introduceert dan is dat een bug.

En je sprong van 20 naar meteen 1000 tekens is trouwens nogal fors, daar ligt nog een hoop tussen.
Omdat het hier ook gaat om tekens die mensen zelf intoetsen, en dan is de zin die jij net schreef een stuk makkelijker in te toetsen en te onthouden dan Wjtzg30!pv20gtwh0gm.

20 karakters is meer dan lang genoeg. Met de huidige rekenkracht duurt 11 karakters al een eeuwigheid, dus er is nog zat marge. En daarnaast kun je maar een beperkt aantal keer proberen; veel strikter dan meeste fora/community websites. Gezeik over niets door amateurs ...

Je ziet de boekjesdeskundigen weer tegen elkaar opbieden met hun weetjes over veilige wachtwoorden enz, uiteraard
zoals altijd met deze boekjeswijsheden weer totaal irrelevant!!

Een wachtwoord van een stuk of 8 tekens is veilig zat voor dit soort dingen.
Niet alleen is het risico na een inbraak vrij klein (je kunt dan nog GEEN geld overboeken ofzo!) maar ook sluit ING de
boel af als je een paar keer een verkeerd wachtwoord invoert, dus exhaustive search is helemaal niet aan de orde.

Maar leuk geprobeerd weer, jongens!

Anoniem 8:48, op twitter noemen ze wachtwoordmanagers wel. Zie link in artikel.

https://twitter.com/ingnl/status/632156693120598016

Leuk een sterk wachtwoord. Maar realizeren ze zich wel dat brute force aanvallen veel minder gebruikt worden vandaag de dag dan bijvoorbeeld keyloggers ?


De vraag hoe vaak je een wachtwoord mag proberen (en of een account lockout al dan niet tijdelijk van aard is), is heel wat belangrijker. Probeer jij maar wachtwoord 4g!#Z te raden, indien je 3x mag proberen. Waarna het account op slot gaat, en het wachtwoord niet langer bruikbaar is.

Ik vind de discussie over sterke wachtwoorden zo 20e eeuws. Met goede security controls kan je brute force aanvallen vrijwel onmogelijk maken. En het kiezen van een sterk wachtwoord moet door diezelfde controls ook worden afgedwongen.

En de ING bank ? Die moet eindelijk eens one time tokens gebruiken, net als overige banken.


Ongetwijfeld sterk, omdat een ander wachtwoord niet geaccepteerd mag worden door het systeem van de bank. Indien de mogelijkheid bestaat om een ''zwak ING-wachtwoord'' te hebben, dan moet de ING bij zichzelf te rade gaan waarom dat is.

Sterke wachtwoorden dwing je immers af in je security policy, en niet door vrijwillige medewerking te vragen middels security awareness programma's. Indien ING klanten zwakke wachtwoorden kunnen kiezen, dan is dit mede de verantwoordelijkheid van de beveiligers van de bank.

Precies, wat een nonsens om 20 characters te beperkt te vinden. Je weet wat er dan gebeurt, precies hetgeen je wilt voorkomen. De gewone gebruiker gaat het wachtwoord opschrijven, bij zich houden, want onthouden wordt lastig.
En inderdaad als je een keer of 3 fout inlogt, wordt je geblokkeerd, dus nogmaals, praat geen onzin over dat 20 tekens te weinig zou zijn.

Wat betreft ABN amro, daar gebruik je idd 5 tekens op b.v je mobiele app, maarrrr, je bent beperkt in het overschrijven van geld naar andere rekeningen. Bij bestemmingen die je nog niet eerder geld hebt overgemaakt moet je gewoon je e-reader gebruiken.
Fijne dag!

Lees de reacties voor je reageert. De argumenten zijn veiligheid en bruikbaarheid. Zie "20:15 door Anoniem". Het bits argument is een side track van trol karma4 die er nog minder van heeft begrepen.

Rekenen is een kunst. Met 64 mogelijkheden (base64) heb je 6 bits *2**8=256 2**6=64) en met 20 tekens 6*20 120 bits geen 40. Ik sluit me aan bij de andere posts na mijn "mitigaties".l

Dit heeft helemaal niets met base64 te maken. Je hebt de klok horen luiden en je weet niet waar de klepel hangt. Je moet echt eens ophouden met het verspreiden van baarlijke nonsens op fora.

Unicode is een manier een veel grotere variatie aan tekst/karakter elementen op te slaan dan mogelijk is in ascii .
Dat is prettig waar de tekst bedoeld is om gelezen te worden door mensen .
Het _kunnen_ opslaan en weergeven van subtiele typografische verschillen, en wat coderingskeuzes leidt ertoe dat een verschillende reeks bytes er voor de menselijke kijker erg hetzelfde kan uitzien .
Of, andersom, dat de invoer van een bepaalde volgorde van toetsaanslagen een andere reeks bytes oplevert . Bijvoorbeeld afhankelijk van de taal/keyboard instelling van het systeem, of van veranderende keuzes van browser of OS.
Of verschil van cut & paste uit een localized document of pw manager applicatie versus direct intikken.

Het is niet zo vaakl dat gebruikersinput feitelijk rechtstreeks beschouwd wordt als een bitstring die exact moet kloppen.
Juist bij passwords is dat het geval - de invoer gaat een hash in en dat klopt of klopt niet . Geen fuzzy match,geen wildcard, eentje is goed en 2^160-1 zijn fout .

Het is al een uitdaging bij filesystems (filenaam opslag, en invoer vanuit filebrowsers), en daar zijn namen tenminste nog bereikbaar door het OS. (Linus heeft een boeiende rant over HFS+ wat dat betreft )

De uitdaging bij passwords is dat een set van 20+ toetsaanslagen nu , over veel OSen, browsers en jaren , dezelfde hash uitkomst geeft wanneer dezelfde toetsen aangeslagen worden.
En de plek waar de de invoer verwerkt wordt zit relatief ver (in termen van api's ) van de plek waar de toetsen ingedrukt worden - het is of de website van de bank, of hooguit de javascript code in de browser . Met os/libraries/en browser buiten het domein van de bank - en het strak vastleggen daarvan ('werkt met OS 1.2.3 browser 40.2.1' ) is nu juist zo ongewenst.

Kortom - als het fout gaat is het vrijwel onmogelijk uit zoeken ('password fout'), de gebruiker doet feitelijk niet verkeerd, want die tikt echt de juiste letters in, en toch werkt het niet .


Je gaat in op een triviaal voorbeeld maar mist het generieke probleem.


En 20 is te kort maar 30 precies goed ?
Mensen doen uberhaupt niet aan lang intypen van passphrases - voor dit soort toepassingen zijn passwords gewoon nogal beperkt in rendement. Een ultra lang password toestaan is vooral nep veiligheid -

Kijk, hier kun je al stoppen .
Als je praat over 'in minuten te kraken' ga je uit van een aanvalsmodel waarbij de aanvaller de passwords off-line onbeperkt kan testen.
Als je dat een reeel model vindt, is de bank al van voor tot achter gehacked, en weet je gewoon dat 70-90% van de passwords eruit gaat rollen. Je kunt dan net zo goed aannemen dat de passwords bij invoer in plaintext meegelezen zijn - ook dat kan prima , als de aanvaller diep genoeg zit. Misschien zelfs net iets makkelijker dan de hash-database kopieren.

Een off-line scenario betreft bijvoorbeeld gecrypte harddisks die gestolen worden - dan kan de aanvaller inderdaad onbeperkt testen en is het alleen de lengte en onvindbaarheid/onvoorspelbaarheid van de passphrase die het moet tegenhouden.

terug naar de acceptgiro...

https://nl.wikipedia.org/wiki/Base64 "Base64 is een 6 bitscodering. Dat betekent dat er 2^6 = 64 verschillende tekens zijn, vandaar de naam base64."

https://nl.wikipedia.org/wiki/Advanced_Encryption_Standard sleutel waarden van 128 bit hebben bij encryptie een betekenis hoe snel het met brute force gekraakt zou kunnen worden. https://nl.wikipedia.org/wiki/Brute_force_(methode)

Hetgeen jij onzin noemt is gewoon openbaar terug te vinden.
Dat staat nog los van de getoonde fout met de rekenvaardigheid.

toen ik in Frankrijk was en door de tol poorten heen moest.
hoefte ik aleen een pinpas er in te stoppen , ZONDER PINCODE word het bedrag afgeschreven.

is dit bij alle pinpassen ?

tevens vind ik het contactloos betalen wel makkelijk maar veileg nee nog niet !

weet je nog toen er mobieltes werden gehackt via blautooth door iemand op een station die jij mobiel dan liet bellen naar een 0900 nummer van $$$ per min. dat hij daarvoor had aangevraagt ?

dit kan lijkt me ook met het contcact loos betalen. echter staat dan wel het pinapparaat geregistreerd maar nog.

de vogel die vliegt er zo vandoor.

Uit de jaren '80...

Dat is op zich juist, maar het wil helemaal niet zeggen dat een karakterset beperkt tot 64 tekens "Base64" genoemd moet, of kan, worden.

Base64 encoding is een specifieke codering om hele bytes te coderen met een set van 64 ascii karakters.
Dat betekent bijvoorbeeld dat een 1-letter Base64 bericht niet kan bestaan, maar dat Base64 bericht altijd uit een groep van 4 karakters bestaat . Aan het eind kan padding gebruikt worden (=, == ) wanneer de bron niet precies een veelvoud van vier was.

Als je daarintegen een password invoer gewoon definieert als 'ascii karakters gekozen uit een set van 64 letters' kan dat best een invoer van lengte 1 zijn. En wat je ermee doet staat totaal los van het encoderen van een binaire string in een reeks van printable ascii karakters.

Kortom : een invoer beperkt tot 64 printable karakters heeft gewoon niks te maken met "Base64 encoding" .
Wat ze gemeenschappelijk hebben is het gebruik van alleen printable ascii omdat dat 'overal' hetzelfde wordt weergegeven en in te voeren is, waar allerhande andere ascii waarden niet in te voeren zijn, of verminkt worden bij transport/overdracht .


So ? Wat heeft AES te maken met het kraken van passwords ? In de context van passwords gaat het vrijwel altijd over hashes.
Die hebben hun eigen bitlengtes - langer dan encryptie sleutels omdat (cryptografische) hashes ook collisions moeten vermijden - waarbij de birthday paradox ertoe leidt dat (hashlengte / 2 ) al "voldoende groot" moet zijn.


Een password samen te stellen op basis van een alfabet van 64 tekens staat nog steeds los van "Base64 encoding".
Dus dat is inderdaad onzin .

@karma4

base64 is een encoding en niet van toepassing.

Er zitten 6 significate bits per karakter in een wachtwoord met 64 mogelijke karakters. Als je weet dat er maar 64 mogelijkheden zijn in plaats van 256, is dat slechts 1/4 van de mogelijkheden. Bij 20 karakters is dat 20 * 6 = 120 bits. En dus niet 20 * 8 = 160 bits. De 40 bit verschil zijn significant. Dat komt door de kwadratering van iedere volgende bit.

"kwadratering van iedere volgende bit" is onjuist.
(4e klas middelbare school ... )
Een bit erbij is een verdubbeling van het getal .

2^2 -> 2^3 van vier naar acht . (verdubbeling, geen kwadraat ) .
2^15 -> 2^16 van 32768 naar 65536 . Verdubbeling .

Alleen als je de _bitlengte_ *2 doet (verdubbeling van het aantal bits) , is dat een kwadratering van het getal.
(2^n)^2 = 2^(2n) .
2^2 -> 2^4 - van vier naar zestien . (4 kwadraat).

120 bits keyspace doorzoeken is nog steeds veel te veel .

Alleen als het gaat over hashes is het vinden van een collision in een 120 bits hash wellicht binnen bereik met heel veel werk, en een 160 bits hash wel buiten bereik.

Het grote gevaar van het ING advies is dat het universeel is, dat ook voor wachtwoorden in ander situaties zou gelden zoals email, sociale media en andere zaken (zoals effecten beheer sites?):
"4. Gebruik niet overal hetzelfde wachtwoord, maar gebruik een apart wachtwoord voor Mijn ING, een apart wachtwoord voor uw e-mail en sociale netwerken en een apart wachtwoord voor andere zaken."

In dat universele kader is 3 een uitermate slecht en amateuristisch advies dat off-line hackers doet watertanden:
"3. Verzin een willekeurig woord en vervang letters of woorden door cijfers en speciale tekens. ‘Sesamstraat123’ wordt dan bijvoorbeeld: ‘S3samstr@@T12drie!’"

De ING verbiedt min of meer opslaan van wachtwoorden op je computer, maar de cloud wordt niet genoemd!

Dat het totale advies zelfs voor de ING situatie niet toereikend is wordt wel duidelijk als de hashes een keer gestolen worden.
Voor on-line bescherming met blokkering na 6 keer, voldoen 8-20 willekeurige tekens natuurlijk wel, maar ze limiteren daarmee wachtzinnen tot gemiddeld zo'n 3 willekeurige woorden en dat is onbegrijpelijk voor mij, omdat ik de off-line hack voor wil zijn.