Heb je een voorbeeld? "een wachtwoord wat in 5 miliseconden te kraken is" is in ieder geval blatante onzin; de server zal tegen die tijd net zijn eerste responses teruggekaatst hebben en kan zodoende de opmerking niet heel erg serieus nemen (sorry voor de scepsis ;) )

Waarom mail je de sitebeheerder niet ? Heb ik diverse malen gedaan met (on)bevredigende antwoorden, maar in ieder geval altijd antwoorden zodat het weer eens op hun netvlies staat.

Een rant hier helpt je *echt* niet .

Niet omdat MAC-user niet man en paard noemt. Maar als je dat doet krijg je soms de vraag van brave Hendrikken of je dit eerst aan de sitebeheerder hebt gemeld. Alsof een melding door 1 persoon helpt en alsof dit geen common knowledge/best practice is voor elke sitebeheerder;

Wel omdat het MAC-user helpt om zijn frustratie van zich af te schrijven;

Wel omdat het lezers van security.nl met zo'n site die (opmerkelijk, OK) nog niet wisten dat het toestaan van lange wachtwoorden (waaronder pass-phrases) jouw site en opgeslagen (gebruikersgegevens) veel veiliger maakt;

Wel omdat het lezers van security.nl kan aanmoedigen om er bij beheerders van sites die nog geen lange wachtwoorden ondersteunen, er wel om te vragen. Pas als velen dat doen, heb je een kansje dat een (tot nu toe blinde) sitebeheerder een keer het licht ziet;

Wel omdat het mij geruststelt dat ik niet de enige/een van de weinigen ben op security.nl die zich hier zorgen over maakt (voorbeeld: [1]);

Wel omdat hoe meer en hoe vaker hierover geklaagd wordt, hoe groter de kans is dat dit een keer doordringt bij "slechthorende" sitebeheerders;

Wel omdat hoe meer en hoe vaker hierover geklaagd wordt, hoe groter de kans is dat doordringt bij instanties als de autoriteit persoonsgegevens dat een brakke wachtwoordpolicy betekent dat persoonsgegevens onvoldoende worden beschermd met boetes voor "dove" sitebeheerders als gevolg.

[1] P.S. "ruim minder" = 8192 maal zwakker, dezelfde verhouding als tussen 1 dag en ruim 22 jaar.

Je verzekeraar heeft vast een beperking dat je max. 5 keer mag proberen voor het account volledig wordt geblokkeerd?
Dan is het enige risico van een iets zwakker wachtwoord dus dat iemand die de database in handen krijgt je ww kan achterhalen?

Lijkt me niet echt een groot probleem dan:
1. Je wachtwoord is toch per site anders dus niet interessant om te weten
2. Als dat wachtwoord gelekt is heeft maak ik me meer zorgen om de rest van de gegevens die dan vast mee zijn gegaan (medische data enzo).
3. Je verzekeraar is verplicht dit te melden. Als de database groot genoeg is weet jij het dus ver voor iemand de hashes heeft achterhaald.

Niets waardeloos dus, maar wellicht voor verbetering vatbaar door de tijd.

Dus, gewoon even responsible melden bij die partij en netjes betaald krijgen zodat ze het ook nog even een keer door hun risico analyse heenhalen.

Heb ik 2x gedaan en een antwoord gekregen. Die sitebeheerder leest hier echt niet. De rant komt niet aan waar die hoort, nl. bij de developers van die site.
Dat maakt me geen brave Hendrik, dat maakt me iemand die het probleem neerlegt daar waar het hoort.

Ik ga toch ook niet bij m'n docenten klagen dat Cito z'n zaakjes niet goed voor elkaar heeft en dat ze dat allemaal tegen elkaar moeten gaan roepen op hun forums? Dat doe ik bij Cito.

Meestal is het wachtwoord niet de enige sleutel tot een account.
Het hangt vvat de site af, maar bijna altijd is er ook een usernaam nodig met een bepaalde minimale lengte,
en zijn slechts een beperkt aantal foutieve inlogpogingen toegestaan.

Na bereiken van die inloglimiet wordt je account geblokkeerd, en wordt je op hoogte gesteld.
Het kan wel eens zijn dat username en/of wachtwoord dan wordt vervangen.
Daarom is het denk ik niet helemaal eerlijk om de entropie van een wachtwoord te gaan vergelijken met de entropie van een versleutelde verbinding, en kan een wachtwoord van 16 karakters ook nog veilig zijn (lijkt mij).

Uiteraard dienen ieders wachtwoorden voor de website dan wel stevig gehasht en gesalt en afgeschermd
te zijn opgeslagen (en liefst ook de inlog-gebruikersnamen van alle klanten).
Dit dient overigens altijd te gebeuren. Ook bij gebruik van langere wachtwoorden.
Als ze zelfs daar niets aan doen, dan helpen ook langere wachtwoorden geen zier bij geslaagde aanvallen op de server
waar de wachtwoorden op staan...

Goeroehoedjes

Eigenlijk vind ik de rant van MAC-user nogal geneuzel en vooral een kokervisie.

En wat ik redelijk oneens ben met de uitspraak die je hier doet is de implicatie dat een password met extreme sterkte in dit type scenario (website login) nog echt security toevoegt .

Bij het aanvalsscenario 'dictionary attack op de website login' zijn de password eisen niet _zo_ extreem .
Het aantal mogelijke testen per seconde hoort laag te zijn (expliciet in de code, of gewoon van nature omdat dikke java sites niet zo snel zijn) , bij voorkeur ook met een lockout van het account na een handvol verkeerde pogingen . En erachter een blacklist voor de systemen waarvan de aanvallen vandaan kwamen , en natuurlijk bij keuze de echt slechte eruit filteren.
*Dat* helpt - tegen kloppen op de voordeur.

Voor andere aanvalsscenario's , zoals een aanvaller met toegang tot de password (hash) file moet (m.i.) het password en data toch al als 'compromised' beschouwd worden.

Als iemand de (gehashte ?) passwords weet te bemachtigen weet ik niet waarom ik me veilig kan blijven voelen indien mijn password toevallig 20 pure random karakters had .

Werd er uberhaupt een hash gebruikt ? En zo ja, was het een sterke en trage hash ? En zo ja, hoe zeker kan ik zijn dat die aanvaller niet tijdenlang meekeek op de input (pre-hash) van de passwords ?
En waarom zou een aanvaller die erin slaagde bij de password file (of hashes) te komen er niet in geslaagd zijn bij de feitelijke data te komen ?

Is de gehackte partij uberhaupt in staat om de scope van de hack vast te stellen (zeker weten dat je echt gevonden hebt hoe de hack gedaan is en hoe diep men doorgedrongen is kan heel serieus moeilijk zijn ) , en voor zo ver ze dat werkelijk kunnen, zijn hun publieke uitspraken erover betrouwbaar ?
Nadat je password file op pastebin staat zul je _dat_ wel moeten toegeven, maar wat meer ?

Al met al zie ik dus heel weinig reden waarom ik-als-supersterk-password-gebruiker me gerust zou blijven voelen omtrent dat password , of de data als (minimaal) een authenticatie backend gecompromitteerd heeft kunnen worden.

Ik zie een excessieve focus op _nog_ sterkere passwords (cq alle audit-aandacht daarop richten) als een verkeerde prioriteit . En typisch ook indicatie van beperkt begrip van security .

Eens met je.
Voor websites ben ik toch al wantrouwend over de security.
- Een webshop (app) van een starter zal een hoog doe het zelf gehalte hebben. Het doel is verkoop winst maken. Klaag je bij de bouwer/maker/ondernemer dan komt het bij een prioriteitslijstje ergens achteraan. Wat je daar moet met sterke passwords snap ik niet. Ik koop (of niet) daarna gaat na levering/garantie de noodzaak om iets vast te houden weg.
- Heb je met de website (app) van een groot bedrijf/organisatie met een meer permanent karakter dan zijn de beheer bouwer en de verantwoordelijke geheel gescheiden. De beheerder heeft een opgedragen beperkt aantal taken en kan/mag verder weinig. Je moet een ander kanaal in om je klacht ergens neer te leggen. De heldesk (geoutsourced b.v. naar India) is voor simpele vragen/antwoorden. Daar kom je niet ver. Ze zijn wel vaak heel goed om een en ander glad te strijken zodat je niet gaat klagen. (Responsible Disclosure Policy).
- Zolang er met OWASP SQL injection in de top staat zijn er wel andere zaken om je druk over te maken. Ik heb nog nooit opgevangen dat de security als proces afgescheiden is van de web-content. Ja er bestaan wel technologiën in die hoek zoals met https://www.redbooks.ibm.com/redbooks/pdfs/sg247350.pdf Dat is voor de grote Enterprises intern, ook daar niet voor het publieke dmz naar internet buiten een vertrouwde omgeving.

De fout met de moelijke password kan een eenvoudig iets zijn zoals het afkappen op een bepaalde lengte. Dan komen alleen de eerste 8 dan wel 16 tekens door en de rest gaat naar de bittenbak. Dat heb ik nu al een paar keer gezien. Dit naast de leuke effecten met bijzondere tekens die ergens in de keten een bijzondere betekenis hebben maar je wel kan invoeren. Leuk die hash met salt .. ook dat tegengekomen dat je hem leesbaar vond en zo kon gebruiken. Geen noodzaak om het originele password te zien. Lek? ja zeker. Actie? Nee, want best practices volgens de leverancier/bouwer.

Ik dacht dat de meeste verzekeraars inmiddels digid met sms gebruiken?

Sjeemig wat een naïevelingen op security.nl - of spelen jullie allemaal advocaat van de duivel? Met als bijwerking dat amateuradmins denken "zie je wel, zelfs op security.nl staan velen achter het concept van denk vooral aan jezelf en niet aan de sukkels die hier inloggen"?

Als dat in alle gevallen zo zou zijn, volstaat een pincode van 4 cijfers; op je bankpas is dat ook goed genoeg (zo goed dat skimmers veel moeite doen om ook de ingetikte pincode te achterhalen). Vermoei me dan niet met minstens 8 karakters met daarin tenminste 1 kleine-, 1 hoofdletter, 1 cijfer en 1 leesteken, waarin bovendien niets van je eigen naam en de naam van de site mag terugkomen.

Probleem: bij de meeste sites werkt account lockout geheel niet of kan worden omzeild. En, "omdat de klant er toch bij moet kunnen" treden er, na account lockout, vaak "wachtwoord vergeten" mechanismes in werking waarmee de klant (of de aanvaller) alsnog kan inloggen. Want antwoorden op bijv. de vraag naar de meisjesnaam van de moeder staat gewoon op Facebook.

Kom maar kom maar kom maar op met de reactie "maar dat ligt aan de stommiteit van die gebruikers". Maar als je toch weet dat dit de praktijk is, hoe naïef ben je dan als je zo'n mechanisme bedenkt? Ligt een fatsoenlijke risicoanalyse (waar je verderop naar refereert) hieraan ten grondslag, waarbij deze, algemeen bekende, informatie is meegenomen?

Een miskend groot probleem is onrechtmatige toegang tot een e-mail account van een klant, want veel password reset systemen maken gebruik van die route. Helemaal dramatisch is het dan als jouw site gehacked wordt (waarbij niet of slecht gehashte wachtwoorden worden gekopieerd en gepubliceerd) en sommige gebruikers hetzelfde wachtwoord voor hun webmail blijken te gebruiken - als gevolg van de naïeve inlogsystemen die worden bedacht - en die jij goedkeurt.

Aan de andere kant, op sommige sites is het systeem "zo goed" dat ook de rechtmatige eigenaar er niet meer bij kan (lang leve de cloud waarbij niemand weet of je een hond bent [1]. Ik had zelf een oud Hotmail account (waar ik mail van Microsoft in ontving) waar ik al ca. 2 jaar niet op had ingelogd, en nu kom ik er helemaal niet meer in (waarschijnlijk heb ik een melding over het moeten wijzigen van mijn wachtwoord, ook niet gezien). Ik kon namelijk niet iets vertellen over de inhoud van enkele recente e-mails (die ze dan kennelijk ook nog gaan zitten lezen).

Terug naar de wachtwoordeis. Het is aantoonbaar moeilijk (en in veel gevallen onmogelijk) voor mensen om wachtwoorden, die voldoen aan deze eisen, te onthouden voor veel (zeg meer dan 5) websites, vooral als men daar niet regelmatig inlogt (zoals bij een verzekeraar, NUTSbedrijf, sommige webshops etc.) waarbij ook nog eens van ze wordt verwacht om te onthouden welk moeilijk wachtwoord van welke website was. Moet je nagaan dat er dan ook nog sites zijn die eisen dat je jouw wachtwoord regelmatig wijzigt; het moet niet gekker worden...

Daar ken ik 2 goede oplossingen voor:
1) passphrases met een minimale lengte-eis maar dan niet de eis voor kleine/hoofd letters, cijfers en leestekens, want dan dwing je mensen tot iets anders dan in hen opkwam en ze dus moeilijker of niet kunnen onthouden. Voor websites waar niet regelmatig op wordt ingelogd zal het, voor verreweg de meeste mensen, noodzakelijk zijn om deze passphrases op te schrijven. Ook dan helpen hoofdlettergevoeligheid en eisen voor cijfers en leestekens niet.
2) random gegenereerde wachtwoorden die de gebruiker in een eigen wachtwoorddatabase opslaat.
De gestelde wachtwoordeisen beperken deze mogelijkheden aanzienlijk en/of verzwakken het systeem onnodig.

Dat is niet het enige en grootste risico. Risico's zijn dat het aantal mogelijke wachtwoorden, onnodig, lettelijk gigantisch, wordt beperkt. Daarmee dwing je gebruikers tot onverstandig handelen zoals het hergebruiken van eenvoudige wachtwoorden. En dat is een risico dat veel verder strekt dan jouw eigen, wellicht onbelangrijke (gezien de gevoeligheid van gevraagde en/of opgeslagen vertrouwelijke gegevens) website.

"me"? Wie is dat? Vanuit welke achtergrond en kennisniveau?

Zie boven (doorsnee mensen kunnen niet veel van dit soort korte, semi-random wachtwoorden onthouden, en dan ook nog eens weten welk onthouden wachtwoord bij welke site hoort).

In de basis, ja, maar als het gekraakte wachtwoord afkomstig is van de gehackte site van bijv. een reisverzekeraar (en er geen bruikbare bankgegevens zijn ontvreemd), en het wachtwoord wordt hergebruikt (je kunt natuurlijk je ogen sluiten voor de praktijk), heeft de gebruiker wellicht grotere problemen. Mede doordat jouw site onvoldoende was beveiligd, maar OOK doordat, onder andere, jij die gebruiker dwong om een wachtwoord met stompzinnige eisen daaraan te gebruiken.
Boewahahaha van onder welke steen ben jij zojuist gekropen? Kruip er maar weer onder en droom verder.

Wil je van mij weten wat zij denken als ze jouw bericht ontvangen?

LOL! Als ze al iemand betalen, is het meestal hun advocaat.

Als jij denkt dat een mailtje van een of andere klant aanleiding is om een risico-analyse over te doen, door dezelfde onbenullen (die kennelijk geen wetenschappelijke publicaties hierover lezen) die eerder zeiden dat het prima was zo, denk ik inderdaad dat het beter is dat jij weer onder jouw steen kruipt.

[1] https://en.m.wikipedia.org/wiki/On_the_Internet,_nobody_knows_you%27re_a_dog

In de meeste gevallen is dit een, voor aanvallers vaak eenvoudig te achterhalen e-mailadres (zeker voor aanvallers "met ervaring", zie verderop). Dat meestal onversleuteld wordt opgeslagen (want anders kun je klanten geen reclame e-mails sturen). En waarmee, wellicht, account-reset mogelijk is voor de betreffende website (als de aanvaller zo'n hele site weet te hacken, zal de account-reset info voor die site hem natuurlijk een biet zijn, maar voor andere sites kan deze info waardevol zijn).

Helaas zie ik nog regelmatig meldingen van systemen die onderscheid maken tussen "wachtwoord onjuist" en "account onbekend". Daarmee kunnen aanvallers, die niet zeker weten of iemand een account heeft op een website, vaststellen of dat zo is of niet. Daarnaast kun je van veel mensen relatief eenvoudig achterhalen waar ze verzekerd zijn en bij welke ISP's ze mailboxes hebben.

Als een aanvaller een website heeft weten te hacken, zal zij waarschijnlijk alle te vinden e-mail adressen verzamelen, zomogelijk aangevuld met (meestal niet gehashte, gok ik) gegevens zoals de meisjesnaam van de moeder (voor password reset op deze site, maar ook op andere sites), en ook (zeker plaintext, nodig voor de eigen mailings) aanhef, voor- en achternaam, adres en postcode, telefoonnummer en bankrekeningnummer etc.

Met e-mail adres en gekraakt wachtwoord kan de aanvaller wellicht toegang krijgen tot de webmail van dat e-mail account. Lukt dat niet, dan beschikt die aanvaller vaak al over allerlei persoonlijke informatie waarmee het voor de beheerder van jouw website mogelijk was om de identiteit van de klant vast te stellen als zij (of iemand die zich voordoet als haar) zegt dat ze haar wachtwoord vergeten is. Informatie die ook geautomatiseerde functionaliteit of medewerkers van andere websites (waaronder de goudmijn webmail) van die identiteit kan overtuigen - onterecht dus.

Omgekeerd, als een aanvaller een andere site heeft gehacked en daarmee gegevens heeft verzameld, heeft zij mogelijk van jouw klanten gegevens zoals:
- e-mailadres, mogelijk door jouw site gebruikt als accountnaam;
- gekraakt (of nog plaintext opgeslagen) wachtwoord dat hetzelfde kan zijn als op jouw site;
- identiteit-bevestigende gegevens waarmee mogelijk (evt. telefonisch) een password-reset kan worden uitgevoerd.

Kortom, je inlog ID is vaak een e-mal adres. Zo niet dan heb je zelden de vrije keuze en moet je maar afwachten of het onvoorspelbaar genoeg is en het zelf nergens (per ongeluk) is gepubliceerd. Het is daardoor meestal eenvoudig te achterhalen (evt. via een phishing mailtje: "voer uw login ID in en denk vervolgens 3x na of u op de juiste website zit voordat u uw wachwoord prijsgeeft"). Bovendien, mocht dit veld een vrije keuze zijn, dan ken ik niemand die zo masochistisch is dat ook hiervoor een random karakterreeks wordt ingevuld - en wordt onthouden (immers voor het vergeten van een wachtwoord bestaat meestal wel password-reset functionaliteit - vergelijkbare functionaliteit voor een vergeten login-ID ben ik nog niet vaak tegengekomen, maar mijn.ing.nl zal wel zoiets hebben). Last but not least worden login-ID's door webbrowsers (en apps en/of mobiele besturingssystemen) gecached. Als ze niet worden vóóringevuld, volstaat vaak 1 toets om gelijksoortige velden te vullen, waardoor dit sort "geheimen" mogelijk met Javascript (door kwaadaardige sites) zijn te achterhalen. Je moet dit soort velden dus nooit als "geheim" beschouwen.

Helemaal mee eens!

Ik merk inderdaad vaker op dat als iemand tegen iets aanloopt waar de meeste ICT'er mee werken, dit hier door de "experts" meteen geridiculiseerd wordt. Mijn ervaring met zogenaamde "ICT-experts" is dat ze zó hoog van de toren blazen, veelal last hebben van "self fullfilling prophecy" en dermate arrogant reageren op iets wat aan de kaak wordt gesteld, dat men iemand volstrekt niet meer serieus neemt. Schandelijk gedrag.

Laat ik maar even duidelijk maken aan al die zogenaamde "experts": waar ik werk heb ik ook te maken met dergelijke vogels. Ik heb al meerdere keren serieuze veiligheidskwesties aangekaart, maar zelfs tot 5 jaar ná dato zijn deze nog steeds niet opgelost. In een professioneel bedrijf werken met zwaar verouderde browsers, Java-engines die al sinds 2010 niet meer ondersteund worden, verouderde Flash-players die een serieus risico vormen, én.... daar gaan we weer: je wachtwoorden laat genereren die pertinent onveilig zijn. Het is een Godswonder dat er nog niets gebeurd is.

Kaart je dit aan, wordt je genegeerd, krijg je een grote bek enzovoorts. En maar hoog van de toren blijven blazen. Flikker toch een end op. Je mag dan ooit je Microsoft-certificaatjes (even arrogant terug doen!) hebben gehaald, ze zeggen mij helemaal niets. Ik heb weliswaar geen Microsoft-certificaatjes behaald, maar ik tik de gemiddelde ICT'er met gemak weg op vele onderdelen. Als ik het zou willen zou ik binnen twee minuten het hele systeem op mijn werk plat kunnen leggen. Ik heb geen slechte inborst, dus doe ik het niet. Maar die constante minachting vanuit ICT'ers en anderen die er verstand van denken te hebben begint me een doorn in het oog te worden.

Stop daarmee, luister ook eens naar anderen die het vanuit een andere invalshoek bekijken. Ook van mensen die "er minder verstand van hebben". Misschien steken jullie er dan nog eens iets van op....

Als je WP op je eigen pagina draait niet.

Ik kan me wel vinden in Erik zijn gedachten.

Wat zou het ultieme wachtwoordbeleid stellen?
Wetenschappelijke link is welkom!

Dank voor jouw, zeer herkenbare, bijdrage. Ik hoop dat jij niet verantwoordelijk bent (of je voelt) voor informatiebeveiliging bij jouw organisatie. Zo ja: je bent niet de enige die er zo over denkt; veel sterkte gewenst!

Het gewenste "security by design" begint bij het je verantwoordelijk voelen en dat dan overal in alle lagen van de organisatie.
Daarvoor moet je willen samenwerken ook in alle lagen van de organisatie. Bedenk dat er helaas vele raddraaiers tussen zitten. Het gaat vaak goed door onwetendheid, er is vaak genoeg de kwade opzet die alsnog naar buiten komt.

Zoiets als: https://www.cl.cam.ac.uk/~rja14/shb10/angela2.pdf
"Over 10 years ago, Adams & Sasse [1] found that password policies that do not meet users’ work practices caused high levels of dissatisfaction, and led to insecure practices and low security motivation. "
en http://cups.cs.cmu.edu/rshay/pubs/RichThesis.pdf (2015) Zoek in dat document eens op SQL injection "2.1.3. Real-World Password Breaches
In the past few years, it has become common to hear about stolen password sets. In 2010, these breaches were common enough for some to call for an end to passwords altogether [62]. However, researchers have argued that text passwords will likely persist because, despite their shortcomings, they are entrenched and there is no especially promising alternative"

Neem dan een kijkje bij OWASP https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
Het zijn de "best practices" die het zelf nadenken en de noozakelijke verbeterprocessen in de weg zitten.

Ik heb jou, dacht ik heel duidelijk, gevraagd niet meer op mijn bijdragen te reageren omdat je, bij herhaling, mijn woorden verdraait [1]. Met deze bijdrage suggereer je dat alle drie de quotes van mij zijn, wat niet zo is. TROLL

[1] https://www.security.nl/posting/471973#posting472151

Helaas komt dat ook voor, ja. Heb er geen zicht op hoe vaak precies. Even niet aan gedacht,
omdat het wat mij betreft niet zo voor de hand ligt i.g.v. fraudegevoelige privezaken.
Maar bij een onnozele webwinkel die denkt handig en goedkoop te zijn, zou het bijv. best kunnen gebeuren.
Of bij Youtube, en veel van dat soort goedkope publieke services waar je meestal met je privacy betaalt.
Echter solide en security-bewuste bedrijven waar je belangrijke zaken mee doet,
zullen je bij zo'n security-incident meestal per briefpost inlichten. In ieder geval Nederlandse bedrijven.

Maar bedankt voor het uitleggen waarom emailadres niet altijd zo geschikt is als username
(hoef ik het niet meer te doen... ;-)
Het toont het belang aan om ook op dit soort zaken te letten, voordat je besluit met een bedrijf of service in zee te gaan.

Overigens: het kunnen ook juist de klanten zelf zijn die kennelijk graag onveiliger willen werken!
Voorbeeld: http://www.klacht.nl/inloggen-mijnfbto/:

Goeroehoedjes

Of deze experts weten aanzienlijk beter hoe de infrastructuur werkt, dan jij als eind gebruiker dit weet?
Misschien lopen de versie wel achter, omdat eerst alle applicaties getest moeten worden met een nieuwe versie?
Of misschien werkt de core applicatie juist alleen maar met Java 1.6.16?

En ja dan zou je die applicaties moeten aanpakken, maar daar dat die expert die jij aan de lijn hebt niet over. Als het aan hem lag was die waarschijnlijk allang geupdate. Maar het bedrijf of afdeling X of manager Y wilt/kan dit niet.

Zo heb ik momenteel nog XP draaien, met Java 1.6.x, oude flash. En dit ligt niet aan mij.
Zo heb ik ook nog Windows 7 draaien, met minimaal 1 oudere versie van Flash, Java en Adobe. Waarom? Omdat de eerst de applicaties getest moeten worden met de nieuwe versies. Regelmatig moet er namelijk eerst aanpassingen gedaan worden in de business applicaties om die werkend te krijgen met de nieuwe versies. Je weet wel, waar het hele bedrijf op draait.......

ICT doet trouwens ook alleen maar wat de business wilt / betaald.

Dus misschien moet je eerst even verder denken voordat je iets roept, want het zijn niet de ICT's die dit beleid bepalen.
Dit zijn juist de ergste gebruikers, die denken het beter te weten..... Maar totaal geen idee hebben hoe de omgeving werkelijk werkt..... En daarom aannames doen, waarom de ICT zo slecht werk levert.

Jammer, ik ben het daar in niet met je eens.

Goeroehoedjes

Die 5ms die wachtwoordgeneratoren aangeven als tijd tot kraken van het wachtwoord is ook exact dat: kraken van het wachtwoord. Het heeft geen betrekking op het brute-forcen van een wachtwoord via de site zelf. De wachtwoordgenerator gaat er vanuit dat het versleutelde wachtwoord, samen met dat van vaak miljoenen anderen, publiek wordt. Dan gaat een cracker ermee aan de slag om je echte wachtwoord te achterhalen.

Dan hoop je in ieder geval dat jij een beter wachtwoord hebt dan 99% van de anderen, zodat ze het op een gegeven moment opgeven als ze voldoende andere wachtwoorden hebben.

Het helpt natuurlijk niet als ze specifiek jouw wachtwoord willen hebben. Maar dan is het eenvoudiger om gewoon jouw PC te kraken en lokaal je wachtwoord af te luisteren.

Peter

Trollig hoor, om valsheid in geschrifte te plegen (wie het ook zij)
Redactie en anderen: TROLALERT!!!

De enige echte Goeroehoedjes

Iets wat mij ook mateloos irriteert, is dat vaak helemaal niet duidelijk is wat de wachtwoordeisen zijn. Totdat je op de laatste pagina van je account aanmaken komt. En dan nog moet je maar gokken wat de eisen zijn zoals TS schrijft.

Ik weet nog dat toen een paar jaar geleden DigiD 'verbeterd' werd door middel van 'vreemde tekens', zoals ik ze noem, ik in een forum van Tweakers moest uitvinden wat de precieze eisen waren. Ik weet nu nog niet precies welke vreemde tekens hier toegestaan zijn en welke niet (niet allemaal volgens mij). Wat is er de zin van deze informatie te verbergen achter vele schermen bij het aanmaken van een account?

Een nieuw wachtwoord aanmaken/wijzigen is een zorgvuldig proces. Of je die nu opschrijft of onthoudt (of opschrijft en later dit papiertje vernietigt). Tijdsdruk leidt tot slechtere wachtwoorden, die bovendien sneller vergeten worden (maakt voor een aanvaller verder niet uit, dat ze vergeten zijn, die vindt ze wel).