Veilig password opslaan en hashen

[ewoutw]

Hobbymatig wil ik graag met PHP/marinaDB een login systeem maken. Technisch gaat me dat wel lukken. Maar ik ben wel nieuwsgierig waar ik qua veiligheid op moeten letten. Misschien ook wel een beetje ter discussie. Open deuren als een HTTPS verbinding is natuurlijk logies. Maar ik ben wel nieuwsgierig of ik niet iets vergeet. En er zijn vast tweakers die hier al eerder over nagedacht hebben. Ik neem graag hun kennis en ervaring mee.

Zelf wilde ik password_hash() gebruiken om de wachtwoorden te hashen. Nastuurlijk in combinatie met een salt en pepper.
De salt wil ik voor iedere gebruiker aanmaken met crypt() en gewoon in de record opslaan.
De pepper wil ik eenmalig aanmaken en hardcode in de code opnemen. Hierdoor heeft een eventuele aanvaller niet alleen de databasegegevens nodig maar ook de code.
Zijn er verder nog dingen waar ik rekening mee moeten houden?

Ik weet dat veilige loginsysteem veel werk zijn en is sommige gevallen beter uit te besteden zijn aan grote techbedrijven zoals google of facebook. Maar ik wil eigenlijk alles in eigen beheer houden. Verder gaat het mij meer om het doen, dan om echt gebruik. Maar al ik het doe wil ik het zo goed mogelijk doen.
Ik hoor graag van jullie

[Room42]

ewoutw schreef op maandag 13 augustus 2018 @ 15:54:
[...] En er zijn vast tweakers die hier al eerder over nagedacht hebben. [...]

Ja, nogal: [google=php secure login]

Ik weet dat veilige loginsysteem veel werk zijn en is sommige gevallen beter uit te besteden zijn aan grote techbedrijven zoals google of facebook. Maar ik wil eigenlijk alles in eigen beheer houden.

Ook als je de authenticatie door een externe partij laat doen, moet je de autorisatie nog steeds goed regelen

Verder gaat het mij meer om het doen, dan om echt gebruik. Maar al ik het doe wil ik het zo goed mogelijk doen.

Dat is een goede reden. Daar leer je veel van.

[Stoelpoot]

Je plannen zijn in theorie goed. In PHP zijn de password_hash() serie aan functies een veilige implementatie waar je zelf weinig aan kan verpesten. Het lijkt erop dat je de theorie achter de beveiligingsmaatregelen ook goed kent.

Dus is dat hele stuk eigenlijk vrij onbelangrijk. Wat belangrijker is, is wat er om die call heen staat. Wat ga je doen met het plaintext wachtwoord uit de POST? Hoe zorg je er voor dat je geen injectie toelaat? Wat zou je doen als de database gehackt wordt en je en masse wachtwoorden moet laten resetten? Wat doe je als een gebruiker het wachtwoord niet kent? (Tip: Niet emailen!)

[DJMaze]

Stoelpoot schreef op maandag 13 augustus 2018 @ 16:01:
Wat zou je doen als de database gehackt wordt en je en masse wachtwoorden moet laten resetten?

Nah, als je netjes password_hash gebruikt (zoals je al zei) met bcrypt of de nieuwe argon2i is er niet veel aan de hand.

Je moet natuurlijk wel melden dat het is gebeurd en dat de e-mailadressen op straat liggen.

[Stoelpoot]

DJMaze schreef op maandag 13 augustus 2018 @ 17:00:
[...]

Nah, als je netjes password_hash gebruikt (zoals je al zei) met bcrypt of de nieuwe argon2i is er niet veel aan de hand.

Je moet natuurlijk wel melden dat het is gebeurd en dat de e-mailadressen op straat liggen.

Daar is inderdaad goede support voor, maar in mijn herinnering is het niet zo makkelijk en zit er wel wat extra voorwerk bij. Zeker omdat TS dit grotendeels doet voor zelfverrijking is het belangrijk om daar dus ook bewust van te zijn, vind ik, ook al is het bij PHP makkelijk uit te voeren.

Jammer dat je net de hint hebt verklapt...

[Harrie_]

Stoelpoot schreef op maandag 13 augustus 2018 @ 16:01:
Wat doe je als een gebruiker het wachtwoord niet kent? (Tip: Niet emailen!)

Sorry misschien heb ik even een memo gemist? Wat is er tegenwoordig niet goed aan een wachtwoord-reset-email?

[Stoelpoot]

Harrie_ schreef op dinsdag 14 augustus 2018 @ 09:42:
[...]


Sorry misschien heb ik even een memo gemist? Wat is er tegenwoordig niet goed aan een wachtwoord-reset-email?

Het emailen van het onbekende wachtwoord bedoelde ik Een password reset link in een email hoeft niets mis mee te zijn. Maar daar zitten ook nog haken en ogen aan: Wat doe je dan met het bestaande wachtwoord?

[Harrie_]

@Stoelpoot als je het onbekende wachtwoord mailt heb je 'm kennelijk plaintext ergens staan

En de oude hash kun je toch overschrijven door de nieuwe?

[Barryvdh]

ewoutw schreef op maandag 13 augustus 2018 @ 15:54:

Zelf wilde ik password_hash() gebruiken om de wachtwoorden te hashen. Nastuurlijk in combinatie met een salt en pepper.
De salt wil ik voor iedere gebruiker aanmaken met crypt() en gewoon in de record opslaan.
De pepper wil ik eenmalig aanmaken en hardcode in de code opnemen. Hierdoor heeft een eventuele aanvaller niet alleen de databasegegevens nodig maar ook de code.
Zijn er verder nog dingen waar ik rekening mee moeten houden?

Niet je eigen salt/pepper gaan implementeren, gewoon `password_hash($password);` gebruiken. Daar zit al een unieke salt in per wachtwoord. Ook al zou je de salt + hash hebben, je kan er alsnog niet zomaar een wachtwoord van maken. Zie ook https://www.phptherightway.com/#password_hashing

[PressPlayOnTape]

Waarom überhaupt nog een wachtwoord opslaan? Je zou ook kunnen overwegen een inlog zonder wachtwoord te maken, waarmee je de beveiliging eigenlijk verlegt naar de e-mailprovider. Zie ook het artikel Login without password most secure | Wait.. What?

[Jory]

Zorg ervoor dat je tijdens het inloggen ook password_needs_rehash() gebruikt om te controleren of de hash die in de database staat nog voldoet aan de instellingen waarmee je op dat moment hashes genereert.

[Not Pingu]

@ewoutw je focust op het opslaan wachtwoorden, maar waarschijnlijk heb je veel meer gevoelige informatie over je gebruikers en hun toegang. In elk geval heb je hun e-mailadres, dat is ook persoonlijke informatie.

Hashen van wachtwoorden doe je omdat je verwacht dat je database gestolen gaat worden. Focus dus liever op de vraag waarom je database kennelijk steelbaar is. Want wat voor hashing algoritme ga je gebruiken om e-mailadressen en andere persoonsgegevens op te slaan?

spoiler:

Dat is een strikvraag

En hoe ga je voorkomen dat toegangsrechten van je gebruikers door kwaadwillenden gebruikt kunnen worden? Je loginsysteem geeft nl. toegang tot andere systemen. Kunnen die systemen de toegang terugtrekken als blijkt dat een kwaadwillende via jouw loginsysteem ongewenst toegang krijgt?

[Barryvdh]

Encryptie van persoonlijke data kan inderdaad handig zijn, indien van toepassing, al is dat buiten de scope van zijn originele vraag

Het hangt ook af van het type applicatie/data dat je hebt. Als je puur het inloggen veiliger wil maken, kan je (naast dus password_hash gebruiken) er voor kiezen om 2-factor authenticatie te gebruiken. Hierbij is e-mail dus geen 2de factor, sms ook niet erg veilig, maar je kan er voor kiezen om One Time Passwords te generen, bijvoorbeeld met https://github.com/antonioribeiro/google2fa
Dat kan je met een Google Authenticator/Authy app gebruiken, zodat je altijd een vertrouwd device nodig hebt. Natuurlijk wel een stukje ingewikkelder dan alleen wachtwoord maar wel stuk veiliger.

Daarnaast, zoals al gezegd, zorg dat je het veilig opslaat. Dus prepared statements gebruiken in PHP; zie https://www.phptherightway.com/#databases weer.

Je kan er ook voor kiezen om een ORM te gebruiken voor je databases, of juist een heel framework (Laravel, Symfony) die ook een deel van je authenticatie, encryptie, databases etc uit handen nemen.

[Not Pingu]

Barryvdh schreef op dinsdag 14 augustus 2018 @ 11:13:
Encryptie van persoonlijke data kan inderdaad handig zijn, indien van toepassing, al is dat buiten de scope van zijn originele vraag

Ik lees in de OP:

Maar ik ben wel nieuwsgierig waar ik qua veiligheid op moeten letten.

Dat is dus algemener dan wachtwoorden.
Overigens zou encryptie van data nog niet eens mijn voorstel zijn. Zowel encryptie als hashing zijn een programmeursantwoord op een systeembeheersprobleem.

[ewoutw]

WoW hoop nuttig reacties. Waarvoor allemaal dank. Volgens mij had ik qua code die ik moet schrijven de boel wel goed zitten dus. Maar er staan zeker nog nuttige dingen in om over na te denken. Maar dat is vooral procedure wijs.

Ik ga er nog eens over nadenken hoe ik extra hindernissen inbouw voor hackers.
Persoonlijk ga ik van uit van uit dat elk systeem te kraken is zolang er geld, tijd en middelen voor handen zijn. Dus zo onrendabel mogelijk maken.