Opsturen vergeten wachtwoord 'not done'

[Jo0p]

Via de mail van mijn werkgever kreeg ik onlangs een 'vergeten wachtwoord' opgestuurd, waarschijnlijk omdat iemand anders daar een verzoek toe heeft gedaan (door mijn emailadres in te vullen).

Wat mij verbaast is dat anno 2017 (bijna 2018 ) er nog steeds instanties zijn waarbij het technisch mogelijk is een wachtwoord 'leesbaar' uit het systeem te halen en toe te sturen. Dit kan toch gewoon niet meer?

Bovendien betreft het een overheidsinstantie die een formele taak heeft, waaronder het examineren en uitdelen van opleidingscertificaten.

Ik zou hier wat aan willen doen door deze organisatie te wijzen op de tekortkomingen en verplichten verbeteringen door te voeren. Nu zie ik dat ze een klachtenregeling hebben, waar je nota bene per post je klacht kunt indienen.

Graag zou ik wat tips ontvangen hoe ik dit het beste kan oppakken, zonder dat de 'klager' ook moet bijdragen in het verder verduidelijken van het probleem.

[GieltjE]

Kan zo ook nog wel een groot overheidsorgaan noemen dat veel zeer persoonlijke medische gegevens verhandelt maar nog steeds met SSLv3 emailt en pertinent weigert om de vereiste upgrades door te voeren.

Het forum standaardisatie is hierin belangrijk, zij vermelden waaraan overheids en zorg instellingen moeten voldoen.

[Stoelpoot]

Het ging om je bestaande wachtwoord? Of een nieuw wachtwoord?

Ik denk dat je ter eerste via het klachtenformulier gewoon een issue moet indienen dat wachtwoorden plaintext worden verzonden, en je niet verwacht dat wachtwoorden plaintext worden verzonden, maar dat er een password-reset link wordt gestuurd die genegeerd mag worden. Het verduidelijken van het probleem is niet jouw zaak, daar moeten de behandelaars zich in verdiepen, maar jij zal wel moeten aangeven wat het probleem is, en wat volgens jou de gewenste situatie is (standaard bugreport).

Hierna kan je volgende opties aanroepen. Helaas weet ik in dit geval niet zo eentweedrie instanties om aan te kloppen.

[Droefsnoet]

Nobele zaak, maar denk niet dat er snel iets zal veranderen aan de manier van wachtwoorden verschaffen. Ongetwijfeld met een paar regeltjes code aan te passen, maar het zal niet hoog op de prio lijst staan van zo'n bedrijf.

Wachtwoorden als plain text versturen zien de meeste mensen helaas graag. Op mijn werk krijg ik dagelijks verontwaardigde reacties als ik wachtwoorden niet kan geven/toesturen. Krijg je toestanden dat ze het wachtwoord van hun e-mail niet meer weten, dus moeten ze die aanpassen, maar om dat aan te passen moeten ze inloggen op een control panel en die inloggegevens weten ze uiteraard ook niet meer en die gegevens opnieuw opvragen lukt niet, want dat is gekoppeld aan het e-mailadres waar ze het wachtwoord niet meer van weten. Half uur emmeren aan de telefoon en als bonus een negatieve review omdat je zogenaamd slechte service verleent.

Snap best dat als techniek niet je dienst is je dan lekker makkelijk plain text wachtwoorden gaat versturen. Scheelt een boel gehannes van je klanten. Heb je misschien drie mensen per jaar die zich aan die onveiligheid storen, in plaats van 3 mensen per dag die hun wachtwoord niet opnieuw kunnen instellen.

[Croga]

Droefsnoet schreef op woensdag 6 december 2017 @ 12:47:
Wachtwoorden als plain text versturen zien de meeste mensen helaas graag. Op mijn werk krijg ik dagelijks verontwaardigde reacties als ik wachtwoorden niet kan geven/toesturen. Krijg je toestanden dat ze het wachtwoord van hun e-mail niet meer weten, dus moeten ze die aanpassen, maar om dat aan te passen moeten ze inloggen op een control panel en die inloggegevens weten ze uiteraard ook niet meer en die gegevens opnieuw opvragen lukt niet, want dat is gekoppeld aan het e-mailadres waar ze het wachtwoord niet meer van weten. Half uur emmeren aan de telefoon en als bonus een negatieve review omdat je zogenaamd slechte service verleent.

Dat is natuurlijk ook een compleet belachelijk systeem.

Laat me raden: Dat control panel heb je nagenoeg nooit nodig. Resultaat gaat zijn dat mensen dat wachtwoord nooit weten omdat ze het nagenoeg nooit gebruiken. Alternatief gaat men dat wachtwoord opschrijven. Daarmee heb je dus een systeem gecreëerd wat het aloude "Security through annoyance" implementeerd; dat werkt niet.

[Johan9711]

Het ligt er ook maar net aan hoe de implementatie is hè.
Ik weet bedrijven waar ze bestaande wachtwoorden encrypted opslaan, maar beheerders zijn in staat deze te decrypten op een veilige manier. Als het vervolgens via internet mail word verstuurd waarvan ze weten dat het een encrypted email is (bijv dmv pgp) lijkt mij dit niet echt een heel groot issue.

[ongekend41]

Johan9711 schreef op vrijdag 8 december 2017 @ 07:25:
Het ligt er ook maar net aan hoe de implementatie is hè.
Ik weet bedrijven waar ze bestaande wachtwoorden encrypted opslaan, maar beheerders zijn in staat deze te decrypten op een veilige manier. Als het vervolgens via internet mail word verstuurd waarvan ze weten dat het een encrypted email is (bijv dmv pgp) lijkt mij dit niet echt een heel groot issue.

- Iemand anders (beheerder in dit geval, maak 'm niet boos) kan mijn wachtwoord kan lezen
- Het wachtwoord is te ontsleutelen.

Ik zie alleen maar alarmbellen en ben benieuwd naar die implementatie. Het lijkt me onmogelijk dit op een veilige manier te laten werken.

[RGAT]

Johan9711 schreef op vrijdag 8 december 2017 @ 07:25:
Het ligt er ook maar net aan hoe de implementatie is hè.
Ik weet bedrijven waar ze bestaande wachtwoorden encrypted opslaan, maar beheerders zijn in staat deze te decrypten op een veilige manier. Als het vervolgens via internet mail word verstuurd waarvan ze weten dat het een encrypted email is (bijv dmv pgp) lijkt mij dit niet echt een heel groot issue.

Of gewoon de normale implementatie: hashing met salt. Dan kan die beheerder er zo goed als niks mee...
Dat is de normale implementatie, die is in veel talen nog makkelijker te implementeren dan een of andere halve encryptie methode.

[DJMaze]

RGAT schreef op vrijdag 8 december 2017 @ 22:47:
...hashing met salt...
Dat is de normale implementatie

Hash is niet de juiste, je zou zomaar iemand op het slechte idee van MD5, SHA of Blake2 brengen.
KDF (Key Derivation Function) zoals Argon2i en Bcrypt zijn eigenlijk de enige juiste methoden.

[ Voor 22% gewijzigd door DJMaze op 09-12-2017 03:14 ]

[dbakker]

Als het echt een overheidsinstantie betreft zou je dit ook via het NCSC kunnen melden, mocht je geen directe reactie krijgen. Wat je zoekt heet ook wel "responsible disclosure", zie https://www.ncsc.nl/security