20 reacties

  1. Dag Arnoud, Uiteraard helemaal eens dat je die optie MOET aanbieden, om de redenen die je noemt. Wat wel interessant is, is om te snappen wat je eigenlijk verwacht van zo’n functie. Want een wachtwoord is bedoeld om de toegang tot je gegevens te beveiligen. Maar als je je wachtwoord reset en als je daarna vervolgens inlogt bij de dienst, en je kunt weer bij al je informatie, berichten en bestanden, dan kan dat alleen maar betekenen dat je informatie of niet versleutelt was of dat de dienst minimaal een kopie van je sleutel heeft bewaard. Want hoe anders had je toegang kunnen krijgen tot je informatie terwijl jij je wachtwoord, oftewel de sleutel, was kwijtgeraakt :). Op die manier kom je er achter dat vrijwel alle diensten in ieder geval niet voldoen aan de recente aanbevelingen van het NCSC dat je alleen maar aan de Cloud Act kunt ontkomen als je zorgt dat leveranciers niet over je sleutels beschikken…. #eyeopener 🙂

    1. De Unix-login werkt niet zoals je beschrijft. Een CGI of iets dergelijk met het setuid-bit gezet, kan een nieuw wachtwoord plaatsen, d.w.z. de one-way hash ervan opslaan (met seed, natuurlijk), zonder het oude wachtwoord te hoeven kennen. Als alleen de houder van e-mailadres de lange moeilijke code krijgt op bij die CGI te kunnen komen, dan is het veilig en mogelijk, en toch wist de serverbeheerder het wachtwoord niet.

  2. Een enigzins gerelateerde vraag: De website chess.com heeft voor accounts wel een email-gebaseerde wachtwoord-reset optie, maar die doet het alleen als je ook marketing e-mails toestaat. Als je op “unsubscribe all” klikt komt er de volgende melding te staan bij je account-settings:

    Your email address has been permanently unsubscribed and will receive no email from us, including password resets. Contact Support at https://support.chess.com if you wish to remove this block.

    Hoe zit dit? Dit voelt ook als een vorm van dwang; sta ons toe je te spammen met aanbiedingen, want anders is je account in gevaar als je je wachtwoord vergeten bent.

    1. Wat een vreemde implementatie van unsubscribe. Ik zou toch (op basis van gezond verstand) zeggen dat opt-out alleen geldt waarvoor een opt-in is verkregen. Voor dit soort transactionele mails (je vraagt een password reset actief aan) is geen toestemming nodig. Kennelijk werken ze met een blokkadelijst; bij elke uitgaande mail wordt gecheckt of je (e-mailadres) op die lijst staat.

      1. Het feit dat deze melding er zo expliciet staat doet mij vermoeden dat het een slinkse poging is om mensen er toe aan te zetten om toestemming te geven voor het gebruik van hun mailadres voor marketing-doeleinden. Want inderdaad, om een password-reset mail te ontvangen is geen expliciete toestemming nodig, dat kan gewoon. Maar goed, het is mijn vermoeden, ik heb er geen hard bewijs voor. Het zou ook gewoon incompetentie kunnen zijn.

    2. Ik vind het geen gekke gedachte.

      Om 100% zeker te zijn dat we niemand (per ongeluk) mailen die unsubscribe heeft gekozen (en die dan misschien een boete gaat vragen) halen we het e-mail adres weg uit de actieve database. Alleen op deze manier kunnen we 100% garanderen dat de klant geen onterechte mails krijgt.
      Ik zie het ook niet echt als dwang als je het niet makkelijk weer kunt aanzetten. Hoewel mensen zouden dan echt contact opnemen met de helpdesk?

      1. Ik vind van wel. Die twee dingen staan los van elkaar; je accountnaam is je email-adres; je logt in met je emailg. Ze kunnen dat emailadres niet volledig verwijderen zonder je account te verwijderen. Het emailadres staat ook nog steeds gewoon bij je instellingen. En daarnaast, dit is voor zover mij bekend de enige website die dit zo doet. Bij alle andere websites waar ik een account heb staan het ontvangen van marketing-emails en password-resets los van elkaar. In die zin is het dus wel gek; ze zijn de enige.

        1. Een email-adres als accountnaam is strikt genomen al een potentieel AVG lek. Er is namelijk niets dat garandeert dat een email-adres niet hergebruikt wordt voor een andere persoon, bijvoorbeeld nadat een email account is opgezegd of nadat de houder van het maildomein is opgehouden te bestaan en de domeinnaam vrijgevallen is. Vergelijk dit met een telefoonnummer: een telefoonnummer kan nadat een abonnement beëindigt is (na een eventuele afkoelingsperiode) toegedeeld worden aan een andere persoon.

          Email-adressen en telefoonnummers zijn derhalve niet geschikt ter identificatie van een persoon.

      2. Overweging 42 van de AVG:

        Toestemming mag niet worden geacht vrijelijk te zijn verleend indien de betrokkene geen echte of vrije keuze heeft of zijn toestemming niet kan weigeren of intrekken zonder nadelige gevolgen.
        Het intrekken van toestemming leidt i.c. tot het uitsluiten van een wachtwoord reset-functionaliteit. Dát lijkt me een nadelig gevolg.

  3. Interessant… Voor een project waar ik nu aan werk voeren gebruikers een gebruikersnaam en wachtwoord in. Deze worden samengevoegd in een hash en ik bewaar alleen de hash in de database. Door de hash op te zoeken krijg ik een authenticate-ID maar kan dus nooit de gebruikersnaam of wachtwoord terughalen. En dat betekent dus dat een password reset in principe niet mogelijk is.

    De truc is alleen dat ik een identiteit-tabel heb die gekoppeld kan zijn aan meerdere authenticate-ID’s. Dat betekent dat je vanuit de identiteit een andere authenticatie toe kunt voegen. Zo kan b.v. authenticatie via Google of Facebook of een security token aan een gebruiker worden toegevoegd. Maar heb je geen andere authenticaties ingesteld dan heb je in dit systeem gewoon pech.

    De logica hierachter is eenvoudig, want ik wil geen gevoelige login-informatie bewaren in mijn systeem dus het enige wat ik heb is een hash. Ik kan een gebruikersnaam ook niet koppelen aan een hash in de tabel. Want dat is weer een extra risico. (En de software werkt met financiële transacties en zeer gevoelige data.) Een password reset is dus nooit mogelijk en gebruikers moeten dan met de helpdesk bellen om een nieuwe authenticatie te krijgen voor hun account.

    En ja, dit wordt uitgelegd in de documentatie! Gebruikers weten dat wij wel een identiteit onthouden, maar geen gebruikersnaam en wachtwoord.

      1. Nee, niet als salt. Het is nog best relatief complex hoe ik deze data vermangel tot een unieke hash… 1) Ik neem het wachtwoord en bereken een SHA-hash. 2) Ik converteer de gebruikersnaam naar kleine letters. 3) De SHA hash wordt vervolgens als een AES key gebruikt om de gebruikersnaam te encrypten. 4) Het systeem haalt een RSA sleutel op uit een interne resource. 5) De resulterende waarde wordt met de RSA sleutel weer verder gehashed. 6) De uiteindelijke hash wordt opgeslagen in het systeem.

        Het zijn best veel stappen en dat is bewust gedaan om het gehele proces traag te houden, Een SHA hash, AES encryptie en dan nog een RSA hash is een beetje overkill maar maakt het erg lastig om een brute-force aanval uit te voeren wegens de meerdere stappen die nodig zijn.

        Ja, het kan vast eenvoudiger. 😀 Maar uit deze database is het eigenlijk onmogelijk om een gebruikersnaam te herleiden. Dus als je je wachtwoord bent vergeten dan kunnen we deze authenticatie nooit meer herstellen. Maar in een tweede database wordt de authenticatie ID (dus niet de hash!) gekoppelt aan een Identiteit-record en er kunnen meerdere vormen van authenticatie worden toegepast. Via de identiteit kunnen we van een gebruiker de authenticaties herstellen. We sturen dan een link naar hen toe waarmee een nieuwe authenticatie toegevoegd kan worden, maar dat systeem moeten we eigenlijk nog uitwerken. (Want moet ook erg goed beveiligd worden.)

        1. Als iemand zijn wachtwoord dus compromised is dan kan je deze nooit verwijderen, je kan alleen “een nieuwe authenticatie” toevoegen.

          [rant] Ik vind het denk ik nog het meest opzienbarend dat je hier serieus trots op lijkt te zijn. Stel je voor dat je iets zou bouwen wat standaard en onderhoudbaar is?? Als het traag moet zijn dan had je gewoon bcrypt kunnen gebruiken. Uitspraken als “dan heb je in dit systeem gewoon pech.” doen me denken aan die oude BOFH verhaaltjes uit de jaren ’90. [/rant]

          1. Als een gebruikersnaam en wachtwoord zijn gejat dan is de hash gewoon uit het systeem te verwijderen. Sterker nog, er wordt bijgehouden met welke authenticaties er bepaalde acties worden uitgevoerd en deze kunnen geblokkeerd worden als er verdachte activiteiten plaats vinden. Dan is de authenticatie weg en moet de gebruiker een nieuwe gebruikersnaam en wachtwoord kiezen.

            Is het standaard? Nee, want standaard is ook standaard te hacken.

            Is het onderhoudbaar? De authenticatie bestaat uit 1 tabel in een aparte database met twee belangrijke velden. (En een geldigheidsduur van begindatum tot einddatum.) Hoe het verder beheerd wordt hangt af van de projecten die ervan gebruik maken. Die andere projecten bepalen verder ook of ze functionaliteit willen hebben om een wachtwoord te herstellen. Waar het hier om gaat is dat in dit deel van het project niets over gebruikersnamen en wachtwoorden terug te herleiden is.

            Ben ik er trots op. Meh. Waar het mij om gaat is dat een hacker zijn tanden kapot bijt om deze boel te ontcijferen. De gehele database kan in verkeerde handen vallen en dan kan de hacker er nog steeds vrijwel niets mee. Ja, een brute attack kan wel, als ze de tijd hebben om alle variaties van gebruikersnamen en wachtwoorden uit te proberen. Zijn ze wel even mee bezig.

            Weet jij dan een betere optie om gebruikers te laten inloggen met gebruikersnaam en wachtwoord, waarbij hackers nog steeds niet veel kunnen doen ook als ze de database in handen krijgen?

              1. De betreffende module mag geen beperkingen opleggen aan gebruikersnaam en wachtwoord. En mag geen gebruikersnaam opslaan. Er ligt een laag boven die in een andere database de gebruikersdata bewaart en eventuele beperkingen oplegt. Deze module is meer een index waar je op basis van gebruikersnaam en wachtwoord een UserID opzoekt. Dus dit is een complete database met maar 1 tabel met 2 velden erin. (Die van belang zijn.) Verder zit er niets in deze database en is dit een interne service die ook nog eens op een aparte server draait.

                Het idee is dat andere projecten allemaal op hun eigen server draaien. Deze hebben allemaal een Identity onderdeel maar deze zal nooit de wachtwoorden opslaan. Er zijn diverse redenen om het zo strict te maken.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.