Secure Account Management

[Olaf van der Spek]

Account management lijkt simpel, wie heeft vroeger niet zelf register en login functies geïmplementeerd. Maar wil je dit echt goed doen dan blijkt het alles behalve simpel. Het helemaal zelf doen is eigenlijk geen optie.
Zijn hier reference guides voor? Hoe pakken jullie dit aan?

Sign-in via email (https://blog.medium.com/s...ium-by-email-aacc21134fcd) lijkt mij handig, zeker voor mobile devices, maar hoe je dat veilig implementeerd durf ik niet te zeggen.

Zelfs Tweakers lekt (volgens mij) of er een account bestaat met een bepaald email adres.

Ik ken https://www.owasp.org maar dat is geen complete guide.

[Hydra]

"Hoe" ik het aanpak is compleet afhankelijk van wat ik aan het doen ben. Sign in by e-mail is prima voor iets als Datumprikker bijvoorbeeld. Maar aan de andere kant van het spectrum, noem een EPD of een Banking App, moet je (dat ben je verplicht) daadwerkelijk de identiteit van een persoon vaststellen.

Wat je dus moet doen is vast stellen wel niveau van trust je nodig hebt. Is toegang hebben tot een e-mail account genoeg of moet jij 100% zeker weten dat je met een bepaalde persoon te maken hebt? Daar begin je mee.

Kwa techniek zijn er genoeg methoden. Oauth, signin by e-mail, JSON web tokens, noem ze maar op. Maar elk van deze mechanismen hebben voors en tegens. Het zijn tools en voor je weet welke je pakt moet je weten wat je gaat bouwen.

[DexterDee]

Het een en ander hangt sterk af van wat je probeert te beveiligen. Een bankomgeving moet veel beter beveiligd worden dan een forum account. Het is in alle gevallen in ieder geval veiliger om in te loggen met 2FA (two factor authentication), dan met één factor (of het nu een wachtwoord, email link, pincode, etc... is).

Ik heb zelf goede ervaringen met Duo, met dit platform (er is een gratis account mogelijkheid) kun je relatief eenvoudig users "onboarden" en een pushbericht uitsturen. De gebruikers krijgen dan een popup met een groene "allow" en rode "deny" button. Druk op de juiste button en je logt automatisch door.

Google authenticator werkt ook prima, alleen moet de gebruiker dan een cijferreeks overtypen. Hetzelfde voor tokens via SMS. Veiligheid en gebruiksvriendelijkheid moet je altijd tegen elkaar afwegen. Een beveiliging met twee fysieke sleutels en een 128 cijferige nucleaire lanceercode is natuurlijk veiliger dan een pincode van 4 cijfers, maar ook nogal "invasive" voor de eindgebruiker.

Mocht je (hashes van) wachtwoorden opslaan van eindgebruikers, zorg dan dat je een modified key algoritme gebruikt zoals bcrypt of PBKDF2. Anders ben je (zelfs met SHA256 en een flinke salt) kwetsbaar voor brute force aanvallen mochten de hashes ooit op straat liggen.

Finally, mocht je écht willen weten of een persoon ook echt een persoon is, dan zijn er natuurlijk nog identity services als iDIN. Hiermee kun je iemand via zijn eigen bankomgeving laten authenticeren. Dat kost dan wel weer een bedragje per authenticatie.

[Olaf van der Spek]

Hydra schreef op maandag 3 juli 2017 @ 11:01:
"Hoe" ik het aanpak is compleet afhankelijk van wat ik aan het doen ben. Sign in by e-mail is prima voor iets als Datumprikker bijvoorbeeld. Maar aan de andere kant van het spectrum, noem een EPD of een Banking App, moet je (dat ben je verplicht) daadwerkelijk de identiteit van een persoon vaststellen.

Ik ben (gelukkig, helaas?) niet bezig met EPD of banking apps, het gaat eigenlijk om 'standaard' websites / fora (neem t.net).
Neem bijvoorbeeld sign-in, melden dat het email adres fout is of het wachtwoord fout is is not-done. Neem dan password reset, al iets lastiger. Dan sign-up, meldt je dan wel of ook niet dat een email adres al in gebruik is? En waarom dan wel en bij sign-in niet?