Veilige login

[Scott81]

Voor mijn web applicatie wil ik graag een veilige login inbouwen.
Nu heb ik gekozen voor 2-factor authentication waarbij een email gestuurd wordt met een code maar nu zijn er betere / veiligere oplossingen.

Na wat onderzoek gedaan te hebben ben ik tot de volgende 3 opties gekomen die ik graag wil aanbieden aan mijn gebruikers:

1. Webauthn
2. TOTP
3. E-mail

Zelf maak ik gebruik van Mac en werken alle 3 de opties perfect. Met Touch ID op de Mac, of zelfs Face ID via de iPhone, of QR via Android kan ik inloggen met Webauthn (Dit alles in Safari).

Zodra ik Chrome of Firefox gebruik werkt dit niet, ik moet namelijk gebruik maken van een hardware sleutel (USB) en daar zoekt chrome of firefox naar.
Op windows hetzelfde verhaal.

Optie 1 valt dus bij veel gebruikers wellicht al af. Het probleem is dat iemand die Mac gebruikt soms ook moet kunnen inloggen via een ander apparaat (Android tablet, windows pc). Nu kan ik een 2e mogelijkheid accepteren (TOTP of E-Mail), echter moet ik dan dus alsnog een wachtwoord opslaan.

Dit haalt naar mijn idee het "veilige" van optie 1 onderuit.

Hoe kan ik dit het beste opvangen.
Alle drie de opties heb ik gemaakt en werken, ik kan de applicatie aanpassen zodat meerdere 2-factor authenticatie methodes kunnen worden toegevoegd maar ik vraag me af of dat niet juist de extra veiligheid onderuit haalt.

Graag tips en suggesties.

[DaFeliX]

Om een gebruiker te kunnen authenticeren kun je feitelijk drie verschillende dingen gebruiken:

1. Iets wat je weet (bijv wachtwoord)
2. Iets dat je hebt (bijv een hardware sleutel)
3. Iets wat je bent (bijv een gezicht)

Twee-factor authenticatie vereist dat je twee van deze dingen gebruikt, ipv 1. Normaliter is dit dan iets wat je weet ("wachtwoord") en iets weat je hebt ("TOTP" of een hardware sleutel).

Een TOTP haalt dus niet het "veilige" onderuit, het versterkt het juist. Wat dat betreft is dit 'tzelfde als een hardware sleutel. Het grote verschil is echter wel dat een hardware sleutel extra beveiligingslagen heeft, zodat bijvoorbeeld phising vrijwel onmogelijk wordt. Wat dat betreft is TOTP gelijk aan een hardware sleutel in de zin dat het een extra factor is, maar dat een hardware sleutel een veiligere 2e factor is.

Ik zou zelf e-mail niet gebruiken als 2-factor, omdat het vaak zo is dat je met toegang tot een mailbox ook een wachtwoord kunt resetten. Dat maakt dat toegang tot e-mail beide factoren onderuit haalt. Niet ideaal dus.

Het ondersteunen van meerdere soorten factoren is overigens prima te verdedigen. Laat je gebruikers zelf kiezen of ze TOTP willen, of een YubiKey willen gebruiken, of beide. Zolang je ze maar niet dwingt beide in te stellen lijkt me dit prima verdedigbaar.

Dus: Inloggen met gebruikersnaam en wachtwoord (factor 1) en daarnaast zowel TOTP als Hardware sleutels ondersteunen (factor 2).

[Scott81]

Bedankt voor de reactie. Het idee van zonder wachtwoord kom door Webauthn. Hier heb ik geen wachtwoord voor nodig dus sla ik het ook niet op.

Dit vond ik een mooie oplossing omdat ik dus van een gebruiker niets van wachtwoorden weet / opsla dus mocht ook een lek zijn, dan staat er bij mij niets van wachtwoorden.

Uiteraard worden deze gehashed opgeslagen maar liever niets dan iets gehashed.

Ik weet helaas niet of al mijn gebruikers de kennis hebben om gebruik te maken van Webauthn of TOTP. Ben bang dat vele nog nooit van een authenticator app of Mac keychain hebben gehoord (misschien de iets oudere doelgroep)

[jammo]

Je kunt mensen een e-mail sturen met een 'magic link' om via die link in te loggen zonder wachtwoord (in plaats van een wachtwoord vergeten link waarmee het wachtwoord aangepast zou kunnen worden).

Qua veiligheid is dat niet meer of minder dan een wachtwoord reset link.
Problemen zijn wel dat gebruikers moeten wisselen tussen verschillende applicaties, het kost vrij veel tijd (je kunt niet even 'snel' inloggen) en zou een aanvaller controle hebben over de inbox van een gebruiker dan kan hij makkelijk (hetzelfde bij een wachtwoord reset) het account overnemen.
- Een manier om een gebruiker zijn account terug te laten claimen als dit zou gebeuren zou wenselijk kunnen zijn.

Om bovenstaande nog iets verder te beveiligen zou je de gebruiker ook nog om zijn TOTP token kunnen vragen na de klik op de link.

[DaFeliX]

Dan heb je het over passkeys, dat is niet 'tzelfde als 2FA.

Met passkey gebruik je alleen iets wat je hebt, en gebruik je dus 1 factor. Dat is weliswaar veiliger dan iets wat je weet, omdat het moeilijker is voor een aanvaller om 't in 't bezit te krijgen, maar is geen 2FA.
Webauthn kun je overigens ook gebruiken om hardware sleutels te gebruiken als tweede factor.

Overigens moet je wachtwoorden sowieso gehashed opslaan, zodat er bij een eventueel lek de schade te beperken is. Uiteraard moeten je gebruikers dan wel hun wachtwoorden aanpassen, maar geeft ze in elk geval de tijd dit te doen.

De publieke sleutels die je met passkeys krijgt niet - een aanvaller kan immers niet zoveel met zo'n publieke sleutel.

Als jouw gebruikers nog nooit eerder iets met TOTP gedaan hebben, kan dat inderdaad lastig zijn. In dat geval 'moet' je gebruikers meenemen hoe zij zelf dit kunnen instellen. Druk ze dan aub ook op 't hart om een backup te maken, zodat ze zichzelf niet buitensluiten mochten ze hun telefoon kwijtraken.

Overigens, om wat voor soort applicatie gaat het?

[Scott81]

Wachtwoorden worden uiteraard gehashed opgeslagen maar als ik het kon vermeiden zou ik he liever niet opslaan.

Ik heb zelf volledige rechten over deze applicatie dus kan het altijd "resetten" voor een gebruiker (mochten ze de telefoon ofzo kwijtraken).

Het is een HRM systeem waarbij personeel van klanten elk een login heeft

[Gerco]

Scott81 schreef op woensdag 28 juni 2023 @ 15:11:
Het is een HRM systeem waarbij personeel van klanten elk een login heeft

Zulke systemen haken vaak in op de SSO provider van de klant zelf zodat er helemaal geen aparte logins voor gebruikers zijn die je moet opslaan. Je ziet vaak dingen als een subdomain per klant wat direct doorlinkt naar hun Azure Active Directory, Ping, Okta of Google Workspace login, bijvoorbeeld.

Wat Microsoft doet is om je login domain vragen en je dan doorverbinden met de SSO provider voor dat domain (mits dat domain Microsoft klant is, natuurlijk). Op die manier hoef je zelf helemaal geen gebruikersaccounts te beheren, geen accounts te resetten, etc. Dat gebeurt allemaal bij de klant zelf zonder dat ze jou daarvoor nodig hebben.

[Scott81]

Voor sommige klanten kan dat inderdaad de juiste oplossing zijn, maar we hebben ook klanten die niet op dit niveau werken.
Dit zou een mooie toevoeging zijn maar dan nog moeten klanten de mogelijkheid hebben alles bij ons toe te voegen

[Orion84]

Scott81 schreef op woensdag 28 juni 2023 @ 15:11:
Wachtwoorden worden uiteraard gehashed opgeslagen maar als ik het kon vermeiden zou ik he liever niet opslaan.

Ik heb zelf volledige rechten over deze applicatie dus kan het altijd "resetten" voor een gebruiker (mochten ze de telefoon ofzo kwijtraken).

Denk ook even na over hoe dat proces er uit moet zien. 2FA toevoegen is goed, maar als je dat vervolgens alsnog met 1 mailtje kan laten resetten voegt het alsnog weinig toe (een e-mail is immers vrij eenvoudig te spoofen).

[Scott81]

Dat is juist de onduidelijkheid bij mij.
Ik kan het volgens mij vrij veilig maken maar als er een "fallback" moet zijn zodat ze óf hun inlog manier moeten kunnen resetten óf op een ander apparaat moeten kunnen inloggen waar deze optie niet beschikbaar is, dan is een groot deel van de veiligheid weg.

Want hoe kan ik iemand veilig op een windows pc laten inloggen als ze via webauhtn op mac inloggen.
Via totp kan dat nog wel (als de mac of iphone beschikbaar is), maar vaak is dat niet zo, anders loggen ze daar wel op in.

Welke optie is er dan nog behalve mail en sms (waarbij ik sms liever niet aanbied)

[Anoniem: 80910]

Scott81 schreef op woensdag 28 juni 2023 @ 16:32:
Dat is juist de onduidelijkheid bij mij.
Ik kan het volgens mij vrij veilig maken maar als er een "fallback" moet zijn zodat ze óf hun inlog manier moeten kunnen resetten óf op een ander apparaat moeten kunnen inloggen waar deze optie niet beschikbaar is, dan is een groot deel van de veiligheid weg.

Want hoe kan ik iemand veilig op een windows pc laten inloggen als ze via webauhtn op mac inloggen.
Via totp kan dat nog wel (als de mac of iphone beschikbaar is), maar vaak is dat niet zo, anders loggen ze daar wel op in.

Welke optie is er dan nog behalve mail en sms (waarbij ik sms liever niet aanbied)

ik weet niet hoe het heet, maar github.com heeft dat mooi uitgewerkt en dan kan je met je windows pincode inloggen als 2e factor. ik weet niet of het opensource is, edge only o.i.d.

[Scott81]

Anoniem: 80910 schreef op woensdag 28 juni 2023 @ 16:39:
[...]


ik weet niet hoe het heet, maar github.com heeft dat mooi uitgewerkt en dan kan je met je windows pincode inloggen als 2e factor. ik weet niet of het opensource is, edge only o.i.d.

Bedankt, ik zal eens zoeken of ik hier iets van vind.


Wat ik dus niet zo goed snap, hieronder een artikel met uitleg over passkeys:
https://www.keepersecurit...ossary/what-is-a-passkey/

Hierin wordt aangegeven dat de eerste keer inloggen via wachtwoord gebeurt en daarna een passkey ingesteld kan worden.

Hartstikke prima, maar daarna wordt uitgelegd dat dit veiliger is omdat er geen wachtwoorden opgeslagen hoeven te worden op de server. Dat klopt dan toch niet, het wachtwoord is toch immers al opgeslagen om de eerste keer in te kunnen loggen? En daarnaast moet het wachtwoord later gebruikt kunnen worden om via een apparaat wat geen passkeys ondersteund in te kunnen loggen, dus het wachtwoord verwijderen zodra een passkey is ingesteld kan ook neit

[Orion84]

Scott81 schreef op woensdag 28 juni 2023 @ 16:32:
Dat is juist de onduidelijkheid bij mij.
Ik kan het volgens mij vrij veilig maken maar als er een "fallback" moet zijn zodat ze óf hun inlog manier moeten kunnen resetten óf op een ander apparaat moeten kunnen inloggen waar deze optie niet beschikbaar is, dan is een groot deel van de veiligheid weg.

Want hoe kan ik iemand veilig op een windows pc laten inloggen als ze via webauhtn op mac inloggen.
Via totp kan dat nog wel (als de mac of iphone beschikbaar is), maar vaak is dat niet zo, anders loggen ze daar wel op in.

Welke optie is er dan nog behalve mail en sms (waarbij ik sms liever niet aanbied)

Je zal daar op een of andere manier dan moeten vaststellen dat degene die de reset aanvraagt ook de eigenaar van het account is. Herstelcodes zijn daarvoor een gebruikelijke optie, maar die willen mensen ook nogal eens vergeten (veilig) te bewaren. "Geheime vragen" is ook een optie, maar ook gevoelig voor social engineering / raden en effectief eigenlijk gewoon een soort van wachtwoord. Een vertrouwd communicatie kanaal kan ook een optie zijn. Bijvoorbeeld de betreffende klant opbellen of er inderdaad een 2FA reset is aangevraagd. Bij grotere klanten kan je ook iemand binnen die organisatie verantwoordelijk maken hiervoor. Die kan dan via interne (veilige) communicatiemiddelen aanvragen afhandelen. etc. etc.

Scott81 schreef op woensdag 28 juni 2023 @ 16:46:
[...]


Bedankt, ik zal eens zoeken of ik hier iets van vind.


Wat ik dus niet zo goed snap, hieronder een artikel met uitleg over passkeys:
https://www.keepersecurit...ossary/what-is-a-passkey/

Hierin wordt aangegeven dat de eerste keer inloggen via wachtwoord gebeurt en daarna een passkey ingesteld kan worden.

Hartstikke prima, maar daarna wordt uitgelegd dat dit veiliger is omdat er geen wachtwoorden opgeslagen hoeven te worden op de server. Dat klopt dan toch niet, het wachtwoord is toch immers al opgeslagen om de eerste keer in te kunnen loggen? En daarnaast moet het wachtwoord later gebruikt kunnen worden om via een apparaat wat geen passkeys ondersteund in te kunnen loggen, dus het wachtwoord verwijderen zodra een passkey is ingesteld kan ook neit

Een manier waarop dat veiliger is, is wanneer het dus na inschakelen van passkey authenticatie niet meer mogelijk is om via wachtwoord in te loggen, waarbij het wachtwoord dan dus ook niet meer opgeslagen hoeft te worden.

Anderzijds als de server het wel bewaart: hoe minder je je wachtwoord hoeft in te typen, hoe kleiner de kans dat het onderschept wordt op een of andere manier. Het kan dan evt. nog steeds uitlekken als de server gehackt wordt, maar malware op een apparaat van de gebruiker die toetsenbord aanslagen registreert bijvoorbeeld is dan geen bedreiging meer of iemand die over je schouder meekijkt.

[Oon]

Scott81 schreef op woensdag 28 juni 2023 @ 15:11:
Wachtwoorden worden uiteraard gehashed opgeslagen maar als ik het kon vermeiden zou ik he liever niet

Waarom niet? Als je dat met een sterke hash obv industriestandaard libraries/functies doet is daar niks mis mee. Dan gebruik je gewoon Blowfish met 12 iteraties of hoger, heeft iedere hash een eigen salt, en is het op het moment zo goed als niet te kraken.

Het is een HRM systeem waarbij personeel van klanten elk een login heeft

Als je dit soort absolute basisvragen moet stellen lijkt het me niet handig om met dergelijke persoonsgegevens te gaan werken. Als je echt denkt dat het opslaan van wachtwoorden TOTP minder veilig maakt en dat een stukje technologie dat maar op een heel klein groepje apparaten werkt om de een of andere reden veiliger zou zijn, dan ga je ook echt niet correct kunnen inschatten welke andere gegevens je dan alsnog (omkeerbaar) moet versleutelen en hoe je dat veilig kunt doen..

In een HRM systeem lijken wachtwoorden me niet eens het belangrijkste om veilig op te slaan, want hoe die worden opgeslagen is pas relevant als iemand toegang krijgt tot je database. Als alle persoonsgegevens dan volledig in te zien zijn dan heeft het niet opslaan van een wachtwoord ook weinig toegevoegde waarde

[Oon]

Scott81 schreef op woensdag 28 juni 2023 @ 16:32:
Welke optie is er dan nog behalve mail en sms (waarbij ik sms liever niet aanbied)

Mail en SMS zijn allebei per definitie onveilig. Mail omdat je niet kunt garanderen dat de ontvangende partij een veilige mailserver gebruikt (die heeft misschien wel unencrypted IMAP aan staan of gebruikt een HTTP webmail client). Over SMS is vaak genoeg in het nieuws dat simkaarten worden overgenomen en daarmee TOTP-beveiligde accounts worden gehackt.

Allebei gewoon niet aan beginnen, bevestigen of een mailaccount bestaat met een activatiemailtje is prima, maar verder nooit gebruiken voor iets dat met veiligheid te maken heeft.

[Scott81]

Altijd fijn als mensen direct zeggen dat ik er niet aan moet beginnen als ik een vraag stel. Alle gegevens in de database staan encrypted opgeslagen. Uiteraard alle wachtwoorden gehashed (zoals ook al vaker aangegeven) en ja, hoe minder gegevens ik op sla, hoe veiliger ik het vind. Ongeacht of het uberhaupt terug te zetten is naar wachtwoord of niet.

En uiteraard doe ik er alles aan dat niemand toegang krijgt tot de database, maar ik vind het pas dom als ik er gewoon van uit ga dat daar nooit iemand in kan…

[Anoniem: 80910]

Er wordt gezegd dat email per definitie fout is als 2e factor. Daar ben ik het niet mee eens. Dat een gebruiker webmail met alleen http gebruikt kun je ook over de webapplicatie zeggen. Tenzij je een redirect hebt naar https afkomstig van http. Is gewoon een fout van de gebruiker. Imap unencrypted zal waarschijnlijk niet meer voorkomen bij een gerenommeerde partij, dus dat kun je ook uitsluiten. Dan de inhoud van de email. Daar moet dan een redelijke key inzitten die je dan niet als $_Get maar als $_Post op de betreffende pagina laat invoeren met een csrf token erbij (weet je zeker dat je van je applicatie komt)

Volgens mij is hedendaagse email uitermate geschikt voor 2 factor authenticatie. Kun je nog een eis stellen ook. Namelijk een ander email adres voor 2e factor, dit zou bij een bedrijf dan 2 dingen kunnen betekenen. De een logt in. De ander accodeert dat en vult de code in. En de inloggende persoon komt in het systeem. (Niet de accoderende). Dit kan ook met aliassen, het enige nadeel, dus naar dezelfde inbox ipv 2 verschillende. Maar iso technisch wel controleerbaar ook omdat dit bij de klant ligt en niet bij het gebruikte systeem.