Hoe weten ze of je een onveilig wachtwoord hebt?
Dat kan volgens mij alleen als het wachtwoord onvoldoende geencrypt is opgeslagen.
En als dat het geval is, zijn wat mij betreft de rapen gaar.

Wel handig om te weten wat die eisen dan zijn. Kon wat tips vinden op de site van digid maar mij is niet duidelijk of een wachtwoord als 'correct horse battery staple' toegestaan is. Lengte wordt aangeraden, maar misschien gaat de site klagen over het ontbreken van hoofdletters, cijfers en vreemde tekens (of kan het niet omgaan met spaties).

Het grootste probleem met digid blijft natuurlijk dat je die niet zo vaak nodig hebt, dus dat je gegarandeerd als je weer aangifte moet doen je sterke wachtwoord bent vergeten. Opschrijven mag natuurlijk niet. En hergebruiken al helemaal niet (en terecht)!

Ze laten je ermee inloggen en dwingen je daarna die te veranderen als het niet aan hun 'geheime' eisen voldoet. Ander alternatief is een brute force en word lists op hun eigen database. Dat heeft tweakers.net ook een paar jaar geleden gedaan op al haar users.

Het punt is dat onveilige wachtwoorden te makkelijk gebruteforced kunnen worden, met een brute force op de eigen database kom je er dus ook zo achter WELKE wachtwoorden onveilig zijn.

als je het aantal inlogpogingen enigszins limiteert is het brute forcen niet eens zo'n groot probleem. Je moet natuurlijk geen wachtwoord als 'geheim' of '12345' hebben maar er ligt te veel focus op sterke wachtwoorden, en te weinig op mitigatie van andere aanvallen, wat mij betreft. Daarbij komt dat de meeste eisen juist averechts werken; je verkleint de search space en je forceert veel gebruikers hun wachtwoord op te schrijven

Zou mij niet verbazen als die wachtwoord inderdaad plain-text in de database staan...

de slogan van de belastingdienst is toch "leuker kunnen we het niet maken , maar wel makkelijker !!! en daar zit nu het probleem ,, WEL MAKKELIJKER !!!!!! " whahahahahahha !!!!!!!

Denk dat ze hier naar kijken op het moment dat je bij het inloggen je wachtwoord invoert, zoals Fwiffo ook al aangaf. Anders zouden ze iedereen met een onveilig wachtwoord wel meteen een mailtje sturen.

De vraag is echter of dat legaal is. Als 'klant' vertrouw je erop dat je wachtwoorden veilig opgeslagen worden. Als de site dan jouw wachtwoorden gaat kraken, lijkt het me dat ze illegaal bezig zijn, hoe legitiem de bedoeling ook is.

Een mooie juridische vraag voor Arnoud Engelfriet: Mag een site wachtwoorden van klanten gaan kraken?
(Of is die vraag al eens gesteld)

Hier krijg ik echter de indruk dat je pas bij inloggen gewaarschuwd wordt, en dat kraken dus niet gebeurd.

Ik weet niet of er juridisch verschil in zit, maar je kan natuurlijk een lijst van onveilige wachtwoorden opstellen en de hashes berekenen, deze hashes sla je op (zonder koppeling naar het achterliggende wachtwoord toe).

Als je vervolgens gaat zoeken naar deze wachtwoord hash, weet je enkel dat het wachtwoord op de lijst van niet veilige wachtwoorden staat, zonder te weten wélk wachtwoord het is.

Je zou toch met bv. Java Script in de browser kunnen cheken of er hoofd-/kleineletters, nummerieke-/alphanummeriekecharacters. etc etc. in het WW zit?
Op het moment van daadwerkelijk verzenden (via https/tls) gaat eea encrypt over de lijn, en weet ook de eigenaar van DIGI-D niet wat het pwd is.

(Of is dit te kort door de bocht?)

Waarom?

SSL/TLS versleutelt de data alleen tijdens het transport. Op de webserver is gewoon de plaintext data beschikbaar. Daar is wel tot op zekere hoogte een mouw aan te passen middels challenge response oplossing via javascript:
Server stuurt een verse random string als challenge
Gebruiker typt password in
Client (javascript in browser) berekent hash(hash(password)+challenge) en stuurt dat terug. Ook al wordt dit antwoord onderschept, het kan niet worden hergebruikt.
Server pakt passwordhash uit de DB en berekent ook hash(passwordhash+challenge) en vergelijkt dat met wat de client als antwoord gaf.
(dit is een versimpelde weergave, in werkelijkheid zitten dit soort mechanismes wat ingewikkelder in elkaar, bijvoorbeeld om ook salts te kunnen gebruiken).

Maar in elk geval bij het instellen van het wachtwoord zal dat doorgaans plaintext richting server gaan (via een beveiligde ssl/tls verbinding hopelijk) alwaar het dan gehasht (hopelijk incl. salt) en opgeslagen wordt.

De check of een wachtwoord aan de eisen voldoet zal inderdaad naar ik mag aannemen gewoon plaatsvinden op het moment dat iemand probeert in te loggen. Overhaaste conclusies trekken levert natuurlijk lekker smeuïge reacties op, maar slaan zonder onderbouwing werkelijk als een tang op een varken.

Het gaat om de wachtwoorden die bij DigiD zijn opgeslagen, niet bij de belastingdienst. De belastingdienst heeft de eisen ook niet verscherpt, maar DigiD in opdracht van de minister.
Ik moest mijn wachtwoord inderdaad wijzigen, eisen zijn: minimaal: 1 hoofdletter, 1 kleine letter, 1 cijfer, 1 leesteken en 8 karakters (max 32). (er verschijnt een popup met deze informative als je je nieuwe wachtwoord in wil vullen.

Het ging hier om een brute force op de eigen wachtwoordendatabase. Jouw methode werkt dan alleen als je geen SALT gebruikt in je wachtwoord-hashes. Dat maakt je gevoelig voor aanvallen met een rainbow-table (de tabel met hashes die je zelf voorstelt maar dan met de wachtwoorden). Als je naast de gewone wachtwoordcontrole bij aanloggen deze hash wilt berekenen en tegen die tabel aanhouden dan kan je natuurlijk net zo goed het wachtwoord zelf op voldoende kwaliteit controleren en heb je die tabel niet nodig. En da's vermoedelijk precies wat ze bij Digid nu doen.

Daar gaat de belastingsdienst helemaal niet over, zij nemen de DigiD dienst af.
Logius gaat daarover, dus BZK. Dus het is zijn minst een vreemd bericht.

Op basis van de situatie zoals die reeds voor de invoering van DigiD bij de Belastingdienst bestond kan ik het volgende melden:
De interne regels, die deels in hard- en software zijn geïmplementeerd, verbieden een brute force op de passwords.
De passwords zijn niet plaintext beschikbaar, ook niet voor beheerders.

Daar had ik overheen gelezen, maar dat klopt natuurlijk. Het zou vreemd zijn, dat als je via een gemeente inlogt, nog wel je minder veilige wachtwoorden mag gebruiken. De belastingsite vermeld slechts dat de eisen zijn aangescherpt. Oftewel, de titel van dit artikel klopt niet.

Moet heel makkelijk kunnen. Alleen zie ik op de inlogpagina maar één JS script actief en daar staat een datum van juli 2013 in de comment. Dus blijkbaar zit daar geen aanpassing in.

Crap...dat weet ik zelf eigenlijk ook wel...te gemakkelijk gereageerd. Maar inderdaad...zonder verdere maatrelen heeft de ontvanger de beschiking over de (plain)text die is opgestuurd.

Ben benieuwd of ze een dergelijk mechanisme toepassen.

Plaintext als voor de ontvanger bedoel je? Voor luisternde boefjes op de lijjn is eea. encrypt.

Ik zou zeggen bij het aanmaken van het password. Niet bij iedere inlog. Of begrijp ik je verkeerd?

Uh... slaat dit op mijn reactie, of is het in 't algemeen?

Als jje bij de belastingdienst tijdens een sollicitatie met sluitende argumenten aangeeft dat DiGiD niet deugt.....

CEH, CISSP. (zegt niets, niet aan de overheid vertellen....)


Ik betaal liever nog meer belasting voor betere kwaliteit.

Al is de belastingdienst dan nog een zwak lampje vergeleken met de duisternis bij het gemeentelijk apparaat......

Eh...multi factor authenticatie, dat is ook mogelijk met Digid, dmv een sms code. Waarbij ik overigens niet begrijp dat men nog de keuze heeft dit wel of niet te kunnen gebruiken...

Inderdaad.
Ze hebben de eisen aangepast en checken nu (warschijnlijk) bij inlog of je 'oude' wachtwoord nog aan die nieuwe eisen voldoet.
Nee, dat sloeg niet op jouw reactie :)

Het is echt stuitend om te zien hoe alle instanties, bedrijven, diensten e.d. elkaar napraten over wat een veilig
wachtwoord is. Allemaal eisen over tekenset, lengte, erin voorkomen van woorden, etc.

Laten we om te beginnen stellen dat authenticatie met een wachtwoord nooit veilig is. Je wilt een persoon authenticeren
en dan ga je gebruik maken van kennis. Kennis en persoon zijn niet aan elkaar gekoppeld dus het is zowizo onveilig.

Maar los daarvan: een wachtwoord is veilig als het niet bij de inbreker bekend is, en het authenticatie systeem beveiligd
is tegen brute-force attacks. Dat laatste moeten ze zelf regelen (door tellers/timers op inlogpogingen en door deugdelijke
opslag van de wachtwoorden).

Dat het wachtwoord niet bij een ander bekend is maak je nauwelijks waarschijnlijker door die idiote eisen eraan te stellen.
ALS dat al uitmaakt, dan maak je het eerder WAARSCHIJNLIJKER, slechter dus. Immers zodra een gebruiker niet meer
zelf een handig wachtwoord kan kiezen zal hij het gaan opschrijven. En dat houd je niet tegen.

M.a.w. dit soort policies werkt contraproductief. Dat "iedereen het doet" maakt dat niet minder waar, is alleen maar een
treurige indicatie van de status van beveiliging.

NIET BELASTINGDIENST bullshit journalisten weer, eisen komen van logius ofwel DIGID iedereen weet en zeker security.nl zou dat moeten weten dat iedereen die wil aansluiten op DIGID aan de voorwaarden van LOGIUS moeten voldoen.

ik snap er niets van ben nu vanaf zaterdag bezig om mijn aangifte blad te krijgen. Ik ben niet zo handig, en weet dus niet wat ik nu steeds fout doe. Termen als een catchacode, bergijp ik niet. Ik ga morgen maar weer eens naar de balastingdienst toe. zou wat graag een papieren aangifte willen doen.

bestaat er ook een mogelijkheid om extra geheugen in mijn boven kamer te krijgen om al deze "veilige" wachtwoorden in op te slaan want ik wordt zo langzaam aan gek van de codes die ik moet onthouden om iets gedaan te krijgen
en ja het plakkertje met het nieuwe wachtwoord schittert alweer op mijn monitor want onthouden is er niet meer bij