[PHP] Login hash, beveiligingsopmerkingen

[? ?]

Ik wil een eenvoudige login procedure voorzien voor een website voor een privé groep van 150 mensen. Op die site kunnen ze dan bv. opties aanpassen.
Het is niet het geval, maar zou best kunnen: op de site kunnen ze kiezen welke soep ze morgen willen.
De site is via internet vrij toegankelijk, mits juiste URL.

Ik wil geen wachtwoord gedoe, dus ga ik de mensen gewoon allemaal een login (=hun emailadres) en een link geven in de vorm van https://site/login/random hash/

Als ze hun link kwijt zijn, kunnen ze eenvoudig een hun emailadres invullen en krijgen ze de link toegestuurd.

Is dit een goed idee Het enige dat ik kan bedenken dat tegen zo'n login systeem spreekt, is dat eens de URL gekend is, je deze niet zelf kan veranderen, terwijl je een wachtwoord wel zelf kan veranderen.

Als dit het enige punt van kritiek zou zijn, zou ik ook bij aanvragen van de link, een nieuwe kunnen genereren en die toesturen.

Ik wil geen wachtwoorden, omdat mensen ofwel belachelijk eenvoudige wachtwoorden gebruiken, ofwel het te veel moeite gaan vinden en de website niet gaan gebruiken wegens te-veel-gedoe.

[DutchKel]

Les 1: Security through obscurity is nooit een goed idee

In het kort (de engelse versie heeft een uitgebreidere uitleg): Wikipedia: Security through obscurity

[analogue]

Je kan ook denken aan een token (JWT bijvoorbeeld) die je laat refreshen gedurende een periode zodat mensen zich slechts eenmaal, of alleen na lange perioden van afwezigheid hoeven te authenticeren.

One time password kan ook nog een leuke optie zijn, dat is wel iets meer gedoe, iedere sessie vraag je via je email een tijdelijk ww aan. Na einde sessie verloopt het ww.
Maar als de content belangrijk of gevoelig genoeg is dat het beveiligd moeten worden zou ik me niet zo druk maken over de gebruikers en er sowieso een degelijk systeem opzetten. Raad mensen een pw manager aan, simpeler en sneller kan het niet denk ik.

[? ?]

kfaessen schreef op dinsdag 6 december 2016 @ 21:22:
Security through obscurity is nooit een goed idee

Er is geen obscurity? Je hebt een "wachtwoord" dat je krijgt in de vorm van een link. Geen obscure zaken.

[ Voor 58% gewijzigd door ? ? op 06-12-2016 22:08 ]

[? ?]

analogue schreef op dinsdag 6 december 2016 @ 21:30:
One time password kan ook nog een leuke optie zijn, dat is wel iets meer gedoe, iedere sessie vraag je via je email een tijdelijk ww aan. Na einde sessie verloopt het ww.

Zo gevoelig is het niet. De enige leak die ik zie, is als het toestel van de gebruiker gecompromitteerd wordt en er lokale toegang is, maar dan kan een keylogger om het even wat doen. De URL met passcode (HTTP request) wordt sowieso versleuteld door HTTPS.
Op publieke computers blijft de URL wel in de geschiedenis zitten, maar ik kan daar wel een waarschuwing voor geven.

[ Voor 9% gewijzigd door ? ? op 06-12-2016 22:11 ]

[Verwijderd]

Ik heb dit zelf ook meer dan eens gedaan. Als het gaat om welke soep je middags wel hebben op het werk en er geen loonstroken of BSN nummers op komen te staan en je bijv. een kleine beveiliging inbouwt dat alleen je eigen domein gebruikt kan worden (*@bedrijfsnaam.ext) dan is het naar mijn idee best veilig. Veiliger in ieder geval dan mensen die qwerty als password gebruiken.

Alles valt en staat een beetje met de veiligheid van het mailaccount, maja als dat compromised is dan ben je toch de sjaak want passwords reset werken ook via daar. Los van de hele security through obscurity discussie en pro's/con's is dat hier sowieso niet echt aan de orde. Je kan je source code publiceren en mensen worden niets wijzer dan daarvoor, mits je de hash in de URL maar veilig maakt (misschien tijdsgebonden ofz)

[Koenvh]

Kun je niet iedereen alleen laten inloggen met een e-mailadres, maar wel bij elke wijziging een e-mail sturen om de wijzigingen te bevestigen? (Of e-mail + postcode oid) Als het alleen om de soep 's middags gaat zou dat geen groot probleem moeten zijn, als er persoonlijke gegevens bij staan is een wachtwoordvrij oplossing sowieso riskant.

[Verwijderd]

Inloggen middels een "geheime" URL is onveilig, omdat:
- men niet kan uitloggen (geschiedenis openbare computer / telefoon van vriend )
- je er niet zeker van kunt zijn dat URL's geheim blijven, denk aan malafide toolbars/plugins in een browser die de URL waarnaar je kijkt "lekken"
- je het wachtwoord/hash nooit kunt wijzigen als deze alleen op de gebruikersnaam gebasseerd is

[mithras]

Gebruik passwordless login. Werkt ook via email, alleen met een degelijke beveiliging zonder obscurity.

1. Vul emailadres in
2. Stuur email met one-time token geldig voor x minuten
3. Login met link inclusief token
4. Authenticeer in sessie voor een y periode

Opnieuw inloggen? Begin bij stap 1 en vul je emailadres in. Bij meerdere projecten gebruikt, werkt fantastisch. Leesvoer:

* Signing in to Medium by email
* Passwords are Obsolete

[DJMaze]

mithras schreef op dinsdag 6 december 2016 @ 22:40:
Gebruik passwordless login. Werkt ook via email, alleen met een degelijke beveiliging zonder obscurity.

1. Vul emailadres in
2. Stuur email met one-time token geldig voor x minuten
3. Login met link inclusief token
4. Authenticeer in sessie voor een y periode

Opnieuw inloggen? Begin bij stap 1 en vul je emailadres in. Bij meerdere projecten gebruikt, werkt fantastisch. Leesvoer:

* Signing in to Medium by email
* Passwords are Obsolete

Werkt dat ook voor iemand die Chrome gebruikt maar zijn e-mail links nog steeds opent in Internet Explorer?

Gebruik dan gewoon TOTP:
1. e-mailadres invullen
2. kijk op je telefoon voor pincode
3. Geen TOTP? Stuur QR code via e-mail

[ Voor 6% gewijzigd door DJMaze op 06-12-2016 23:47 ]

[NMe]

DJMaze schreef op dinsdag 6 december 2016 @ 23:46:
3. Geen TOTP? Stuur QR code via e-mail

Want een QR-code is handiger dan een linkje dat daadwerkelijk opent op het systeem waarmee je op dat linkje klikt?

Als je dit soort dingen wil doen dan wil je inderdaad in elk geval de URL timebomben zodat die slechts een zeer korte tijd werkt. Dat betekent inderdaad dat je user zelf om die login-URL zou moeten vragen. Linksom of rechtsom is dat juist meer gezeik voor de user dan domweg een wachtwoordje invullen...

[DJMaze]

NMe schreef op dinsdag 6 december 2016 @ 23:52:
Linksom of rechtsom is dat juist meer gezeik voor de user dan domweg een wachtwoordje invullen...

True, maar even in je (Google) Authenticator je random "pincode" opvragen is sneller dan 1-15 minuten wachten op een e-mailtje (afhankelijk van je imap/pop instellingen).
Of gebruik een code via SMS.

Oftewel gebruik de 2FA als 1FA

[ Voor 7% gewijzigd door DJMaze op 06-12-2016 23:59 ]

[Barryvdh]

NMe schreef op dinsdag 6 december 2016 @ 23:52:
[...]

Want een QR-code is handiger dan een linkje dat daadwerkelijk opent op het systeem waarmee je op dat linkje klikt?

Als je dit soort dingen wil doen dan wil je inderdaad in elk geval de URL timebomben zodat die slechts een zeer korte tijd werkt. Dat betekent inderdaad dat je user zelf om die login-URL zou moeten vragen. Linksom of rechtsom is dat juist meer gezeik voor de user dan domweg een wachtwoordje invullen...

Natuurlijk kan je dat ook combineren. Een TOTP is geen QR code (alleen de registratie van de TOTP code is meestal wel QR code), maar 6 cijfers vaak (in geval van Google Authenticator).

In dat geval kan je natuurlijk ervoor kiezen om je code via App te genereren of via sms/email te versturen, eventueel als directe link (login.php?totp=123456), al is een TOTP code normaal maar kort (3x30 sec ofzo) geldig. Dan heb je maar 1 methode nodig, maar kan de gebruiker kiezen wat hij wil doen.


Daarnast kan je natuurlijk wel veranderen, alleen moet je ze dan een nieuwe link sturen. De 'hash' is dan gewoon een random string van 32 tekens, die je opnieuw kan laten genereren + emailen, waardoor oude links niet meer werken.

[Ventieldopje]

Bij mega.nz (dropbox alternatief) kun je ook links naar je bestanden delen en daarbij heb je twee opties.

1. link naar het bestand (bijv. index.php?file=<hash>), encryptie key (wachtwoord) zit daar niet bij en moet je los doorgeven/mailen naar de gene die het wil bezoeken. Die key dien je daar dan in te voeren.
2. link naar bestand mét encryptie key (wachtwoord) (bijv. index.php?file=<hash>&key=<key>)

Sommige andere diensten werken zonder aparte key maar dan is de hash gewoon veel langer.

Kortom, ga even goed na wat je precies beveiligd en maak daarin een afweging tussen gebruiksgemak en veiligheid, beide samen gaat helaas niet echt en moet je altijd compromissen sluiten.

[Hydra]

kfaessen schreef op dinsdag 6 december 2016 @ 21:22:
Les 1: Security through obscurity is nooit een goed idee

Dit is wel erg kort door de bocht. Er is niks obscuur aan; je secret is gewoon een link in je mailbox in plaats van een wachtwoord in je hoofd. Minder 'secure' dan een wachtwoord; tuurlijk. Maar dit werkt voor low-impact sites als datumprikker.nl of lootjestrekker.nl prima.

Het is een kwestie van afwegingen maken. Als het niet zo'n ramp is als iemand zo'n e-mail in handen krijgt en je wil dat mensen alleen maar een link opnieuw hoeven aan te klikken die hen identificeert dan is dit een prima oplossing.