[PHP] Encryptie, is dit veilig genoeg?

[DennusB]

Hoi Tweakers,

Ik ben een projectje voor een website begonnen die extreem privacy gevoelige data op moet gaan slaan, dit gaat om plain-text data. Om er voor te zorgen dat dit zeer veilig wordt opgeslagen heb ik een manier bedacht. Ik wil bij jullie graag peilen of dit veilig genoeg is en of er nog dingen beter kunnen!

Het hele encryptie model bestaat uit 3-factor-authentication.

1. Een user specifieke hash, gegenereerd tijdens registratie, 20 tekens lang, random
2. De SHA256 hash van het user-wachtwoord (wordt gehashed tijdens het inloggen, wachtwoord is dus nergens plain-text te vinden, logisch)
3. Laravel's App-Key (20 tekens random)

Vervolgens maken we een MD5 hash van bovenstaande factors op de volgende manier :

code:

$userwachtwoord.$usersalt.$appkey

Bovenstaande MD5 hash is vervolgens de ecnryptie key die we Mcrypt voeren. De IV voor Mcrypt wordt ook per user tijdens registratie random gegenereerd met de functie :

code:

mcrypt_create_iv($iv_size, MCRYPT_RAND);

Alles wordt vervolgens encrypted met de key (MD5 hash) en de IV sleutel, de encrypted sleutel gaat de database in en kan pas weer encrypted worden met exact de zelfde MD5 hash.

Mijn denkwijze is als volgt : Als iemand de gehele website zou hacken en de code + database zou dumpen, dan NOG is het onmogelijk de data te decrypten omdat de hacker niet beschikt over het plain-text wachtwoord van de user.

Is deze denkwijze een beetje accuraat en wat kan er volgens jullie beter/anders?

[Hydra]

Wat is volgens jou het nut van meerdere hashing functies?

Voor one-way hashingmoet je gewoon geen hashes gebruiken die bedoeld zijn om snel te zijn. Dit sluit dus MD5 en SHA uit. Beter kun je voor iets als bcrypt gaan.

Daarnaast, belangrijker: je geeft niet aan welke data er precies ook weer gedecrypt moet kunnen en wie precies bij die data moet kunnen.

Wat redelijk gangbaar is, is een dubbele encryptie met 2 sleutels. Eentje die alleen bekend is bij de gebruiker (z'n WW) en eentje die alleen bekend is bij de beheerder (jij). Meer laagjes hashing stapelen heeft echt nul zien; dat is gewoon lagen obscurity toevoegen en als je niet uitkijkt maak je je oplossing alleen maar zwakker.

[Juup]

DennusB schreef op maandag 04 januari 2016 @ 15:36:
... extreem privacy gevoelige data ...

Ga absoluut niet zelf proberen om encryptie te doen.
Gebruik liever een bestaand mechanisme als PGP.

[DennusB]

Hydra schreef op maandag 04 januari 2016 @ 15:42:
Wat is volgens jou het nut van meerdere hashing functies?

Voor one-way hashingmoet je gewoon geen hashes gebruiken die bedoeld zijn om snel te zijn. Dit sluit dus MD5 en SHA uit. Beter kun je voor iets als bcrypt gaan.

Daarnaast, belangrijker: je geeft niet aan welke data er precies ook weer gedecrypt moet kunnen en wie precies bij die data moet kunnen.

Wat redelijk gangbaar is, is een dubbele encryptie met 2 sleutels. Eentje die alleen bekend is bij de gebruiker (z'n WW) en eentje die alleen bekend is bij de beheerder (jij). Meer laagjes hashing stapelen heeft echt nul zien; dat is gewoon lagen obscurity toevoegen en als je niet uitkijkt maak je je oplossing alleen maar zwakker.

Bcrypt is afhankelijk van tijd, dat werkt dus niet. De tekst zelf moet door de gebruiker (en alleen de gebruiker) ook weer gedecrypt kunnen worden.

Dat 2 sleutel principe zit er nu dus in, die laagjes heb je inderdaad misschien wel gelijk in. Maar het voegt wel wat extra moeilijkheid toe

Juup schreef op maandag 04 januari 2016 @ 15:45:
[...]

Ga absoluut niet zelf proberen om encryptie te doen.
Gebruik liever een bestaand mechanisme als PGP.

Als je iets verder leest zie je dat Mcrypt wordt gebruikt, dat is al bestaand

[ Voor 12% gewijzigd door DennusB op 04-01-2016 15:50 ]

[Hydra]

DennusB schreef op maandag 04 januari 2016 @ 15:50:
Bcrypt is afhankelijk van tijd, dat werkt dus niet. De tekst zelf moet door de gebruiker (en alleen de gebruiker) ook weer gedecrypt kunnen worden.

Ik bedoelde als natuurlijk vervanging voor de hash-functies (MD5 en SHA).

Dat 2 sleutel principe zit er nu dus in, die laagjes heb je inderdaad misschien wel gelijk in. Maar het voegt wel wat extra moeilijkheid toe

Nee. Je concatenate 2 stuks informatie naar 1 sleutel. Dat is wat anders dan 2 keer encrypted met 2 sleutels.

Als je iets verder leest zie je dat Mcrypt wordt gebruikt, dat is al bestaand

Ah sorry. Je bent overduidelijk prima zelf instaat dit op te lossen. Mijn excuses.

[CyBeR]

PBKDF2, graag.

[Juup]

DennusB schreef op maandag 04 januari 2016 @ 15:50:
Als je iets verder leest zie je dat Mcrypt wordt gebruikt, dat is al bestaand

Het idee is dat bijna niemand foutloos een eigen encryptie systeem kan implementeren, zelfs niet als je bestaande hashing algoritmes gebruikt.
Gebruik daarom een library van een sterk encryptie systeem dat zo min mogelijk fouten toelaat.

[DennusB]

Hydra schreef op maandag 04 januari 2016 @ 15:52:
[...]


Ik bedoelde als natuurlijk vervanging voor de hash-functies (MD5 en SHA).


[...]


Nee. Je concatenate 2 stuks informatie naar 1 sleutel. Dat is wat anders dan 2 keer encrypted met 2 sleutels.


[...]


Ah sorry. Je bent overduidelijk prima zelf instaat dit op te lossen. Mijn excuses.

toon volledige bericht

Ja das waar, je maakt 1 sleutel van 3 delen informatie, ik ga daar even naar kijken.
Verder : Die quote ging niet over jou

[Hydra]

Oh en je app key gebruiken als sleutel is niet zo snugger. Als die key moet veranderen kun je je gegevens niet meer decrypted. Je moet daar gewoon een losstaande key voor gebruiken, in een configfile, buiten de root.

DennusB schreef op maandag 04 januari 2016 @ 15:53:
Ja das waar, je maakt 1 sleutel van 3 delen informatie, ik ga daar even naar kijken.
Verder : Die quote ging niet over jou

I know. Maar als mensen je proberen te helpen werkt het niet echt letterlijk als je betweterig gaat doen.

[ Voor 45% gewijzigd door Hydra op 04-01-2016 15:55 ]

[DennusB]

Hydra schreef op maandag 04 januari 2016 @ 15:54:
Oh en je app key gebruiken als sleutel is niet zo snugger. Als die key moet veranderen kun je je gegevens niet meer decrypted. Je moet daar gewoon een losstaande key voor gebruiken, in een configfile, buiten de root.

Goed plan inderdaad Dat zal ik aanpassen, thanks!

Edit : Ik bedoelde het totaal niet betweterig, maar het leek alsof de poster het stuk over Mcrypt had gemist.

[ Voor 12% gewijzigd door DennusB op 04-01-2016 15:56 ]

[CyBeR]

Hydra schreef op maandag 04 januari 2016 @ 15:54:
Oh en je app key gebruiken als sleutel is niet zo snugger. Als die key moet veranderen kun je je gegevens niet meer decrypted. Je moet daar gewoon een losstaande key voor gebruiken, in een configfile, buiten de root.

Iemand die op je server zit kan dat ook lezen, dat biedt nagenoeg nul extra beveiliging.

Het is meer dan voldoende om het wachtwoord van de gebruiker om te toveren in een key (bijvoorbeeld middels PBKDF2) en die key vervolgens te gebruiken voor je crypto. Enige wat je eventueel ergens los moet opslaan dan is een IV als je crypto-algoritme dat vereist.

Een IV is overigens geen "sleutel".

[johnkeates]

Gebruik PBKDF2 / RFC2898, probeer niet je eigen onzin te implementeren, gaat nooit goed. Als je nog extra methodes wil aanbieden voor losse apps kan je OAuth gebruiken boven op PBKDF2.

[Hydra]

CyBeR schreef op maandag 04 januari 2016 @ 15:57:
Iemand die op je server zit kan dat ook lezen, dat biedt nagenoeg nul extra beveiliging.

Iemand die op je server zit kan daar ook prima wachtwoorden afvangen. Dat is een worst-case scenario. Er zijn scenario's (zoals dat alleen de data op straat ligt) waarin dit wel voor je werkt. Daarnaast is die server key ook iets wat je at startup in zou kunnen voeren natuurlijk; die hoeft niet perse ergens opgeslagen te zijn.

Het is meer dan voldoende om het wachtwoord van de gebruiker om te toveren in een key (bijvoorbeeld middels PBKDF2) en die key vervolgens te gebruiken voor je crypto. Enige wat je eventueel ergens los moet opslaan dan is een IV als je crypto-algoritme dat vereist.

Als je zowel de key van de gebruiker (iets wat hij alleen weet) als een eigen key (iets wat jij alleen weet) betekent dit dat een aanvaller 3 zaken nodig heeft: de user keys, de server key en de data. Gebruikers zijn over het algemeen te onvoorzichtig met hun keys en dit is dan een extra laagje beveiliging.

[CyBeR]

Hydra schreef op maandag 04 januari 2016 @ 16:02:
[...]


Iemand die op je server zit kan daar ook prima wachtwoorden afvangen. Dat is een worst-case scenario. Er zijn scenario's (zoals dat alleen de data op straat ligt) waarin dit wel voor je werkt. Daarnaast is die server key ook iets wat je at startup in zou kunnen voeren natuurlijk; die hoeft niet perse ergens opgeslagen te zijn.


[...]


Als je zowel de key van de gebruiker (iets wat hij alleen weet) als een eigen key (iets wat jij alleen weet) betekent dit dat een aanvaller 3 zaken nodig heeft: de user keys, de server key en de data. Gebruikers zijn over het algemeen te onvoorzichtig met hun keys en dit is dan een extra laagje beveiliging.

Dat is onzin. Als de attacker het plaintext wachtwoord weet kan 'ie gewoon inloggen. Als 'ie op de server zit (en daar wachtwoorden kan afvangen) kan 'ie ook al die extra keys lezen. Desnoods uit het geheugen, of door de server te rebooten en te wachten tot de admin de server key invoert.

Je maakt 't jezelf hiermee wel moeilijk maar je verbetert de security van je systeem op geen enkele manier.

[ Voor 4% gewijzigd door CyBeR op 04-01-2016 16:05 ]

[Hydra]

CyBeR schreef op maandag 04 januari 2016 @ 16:04:
Dat is onzin. Als de attacker het plaintext wachtwoord weet kan 'ie gewoon inloggen. Als 'ie op de server zit (en daar wachtwoorden kan afvangen) kan 'ie ook al die extra keys lezen.

Als hij op de server alle wachtwoorden af kan vangen wat maakt het user password dan nog uit? Ik snap niet helemaal waarom je relaas opgaat voor de server key maar niet voor de client key.

Daarnaast ga je uit van alleen het worst case scenario. Er zijn genoeg scenario's waarbij de server niet compromised is maar er wel data op straat ligt en dan is het hebben van die extra laag gewoon nuttig.

[CH4OS]

Aangezien er keys gebruikt worden, ga ik er ook vanuit dat er gebruik gemaakt wordt van een framework. Wellicht heeft dat framework al iets voor encryptie ingebouwd zitten of zijn er wellicht packages beschikbaar om op een makkelijke manier PBKDF2 te implementeren? Voor bijvoorbeeld Laravel zie ik op packalyst al diverse packes (al dan niet forks) staan.

[CyBeR]

Hydra schreef op maandag 04 januari 2016 @ 16:21:
[...]


Als hij op de server alle wachtwoorden af kan vangen wat maakt het user password dan nog uit? Ik snap niet helemaal waarom je relaas opgaat voor de server key maar niet voor de client key.

De "client key" is het wachtwoord. Als dat op straat ligt ben je (als bijbehorende gebruiker) sowieso fucked en daar is niet echt een manier omheen zonder échte two-factor authenticatie te gebruiken. Dwz, een extra out-of-band authenticatiemethode en niet wat TS denkt dat een factor is.

Daarnaast ga je uit van alleen het worst case scenario. Er zijn genoeg scenario's waarbij de server niet compromised is maar er wel data op straat ligt en dan is het hebben van die extra laag gewoon nuttig.

Nee, nogmaals die extra laag haalt geen drol uit. Een derivated key uit een salted hash-functie met een groot aantal rounds zoals PBKDF2 of bcrypt is veilig en al die "extra lagen" voegen alleen maar moeilijkheid voor jezelf toe.

Als je hele db op straat ligt en je code niet kun je als je doet wat ik voorstel nog steeds 100% niks met die data. Een app-key die overal identiek is voegt welhaast letterlijk niks toe aan een hashfunctie.

CptChaos schreef op maandag 04 januari 2016 @ 16:23:
Aangezien er keys gebruikt worden, ga ik er ook vanuit dat er gebruik gemaakt wordt van een framework. Wellicht heeft dat framework al iets voor encryptie ingebouwd zitten of zijn er wellicht packages beschikbaar om op een makkelijke manier PBKDF2 te implementeren? Voor bijvoorbeeld Laravel zie ik op packalyst al diverse packes (al dan niet forks) staan.

PHP 5.5+ heeft PBKDF2 zelf ingebouwd zitten: http://php.net/manual/en/function.hash-pbkdf2.php

[ Voor 23% gewijzigd door CyBeR op 04-01-2016 16:27 ]

[Hydra]

CyBeR schreef op maandag 04 januari 2016 @ 16:24:
Nee, nogmaals die extra laag haalt geen drol uit. Een derivated key uit een salted hash-functie met een groot aantal rounds zoals PBKDF2 of bcrypt is veilig en al die "extra lagen" voegen alleen maar moeilijkheid voor jezelf toe.

Als je hele db op straat ligt en je code niet kun je als je doet wat ik voorstel nog steeds 100% niks met die data. Een app-key die overal identiek is voegt welhaast letterlijk niks toe aan een hashfunctie.

Dat is gewoon niet waar. Je gaat er hier vanuit dat een kraker niet aan user keys kan komen. Je wil niet weten hoeveel hits hij gaat krijgen met een password list. Als hij de DB heeft die niet geencrypt is met een server key kan hij met "123456" alleen al een zooi hits hebben. Met een DB die zowel met de user als met een DB key is geincrypt kan dat gewoon niet.

De extra complexiteit is een extra encryptiestap met een andere key. Big fucking deal.

[ Voor 4% gewijzigd door Hydra op 04-01-2016 16:32 ]

[CH4OS]

CyBeR schreef op maandag 04 januari 2016 @ 16:24:
PHP 5.5+ heeft PBKDF2 zelf ingebouwd zitten: http://php.net/manual/en/function.hash-pbkdf2.php

Ah, dat wist ik dan weer niet, maar middels een package wordt de functionaliteit dan ook (in elk geval eleganter) naar het framework naar keuze gebracht.

[We Are Borg]

CyBeR schreef op maandag 04 januari 2016 @ 16:24:


PHP 5.5+ heeft PBKDF2 zelf ingebouwd zitten: http://php.net/manual/en/function.hash-pbkdf2.php

Caution
The PBKDF2 method can be used for hashing passwords for storage. However, it should be noted that password_hash() or crypt() with CRYPT_BLOWFISH are better suited for password storage.

Maar ze geven zelf aan geen PBKDF2 te gebruiken in de situatie van de TS ?

[SKiLLa]

Kijk anders ook ff op: https://www.owasp.org/ind...aphic_Storage_Cheat_Sheet
En verder inderdaad een user-/record-based unieke sleutel gebruiken, zodat data van een gebruiker alleen ontsleuteld kan worden door de combinatie van een gebruikersgeheim + serverside-systeemgeheim. Voor de symmetrische versleuteling zou ik b.v. AES-GCM gebruiken, AEAD en supersnel op moderne hardware (en patenten-issues vrij); of anders AES-CTR.

Of gebruik gewoon TDE. En gebruik een crypto-verantwoorde random generator (CSPRNG) niet de default PRNG. En behandel keys als byte-arrays en niet als strings.

[CyBeR]

Hydra schreef op maandag 04 januari 2016 @ 16:29:
[...]


Dat is gewoon niet waar. Je gaat er hier vanuit dat een kraker niet aan user keys kan komen. Je wil niet weten hoeveel hits hij gaat krijgen met een password list. Als hij de DB heeft die niet geencrypt is met een server key kan hij met "123456" alleen al een zooi hits hebben. Met een DB die zowel met de user als met een DB key is geincrypt kan dat gewoon niet.

Een aanvaller die wachtwoorden weet kan om te beginnen gewoon op de applicatie inloggen.

Goed in het specifieke geval van een aanvaller die alléén de db heeft (maar geen app toegang of wat dan ook) maak je 't inderdaad moeilijker om een lijst van veel voorkomende slechte wachtwoorden te gebruiken. Maar dat is wel een heel niche toepassing imo.

We Are Borg schreef op maandag 04 januari 2016 @ 16:36:
[...]


[...]

Maar ze geven zelf aan geen PBKDF2 te gebruiken in de situatie van de TS ?

PBKDF2 is een key-derivation functie. TS wil data encrypten met een key en daar is een key-derivation functie nou net heel geschikt voor.

Overigens is de reden daarvoor dat password_hash() en crypt() specifiek voor dit doel zijn (waar PBKDF2 éigenlijk een ander doel heeft) en één waarde opleveren die alles bevat: salt, rounds, hash algo, hash zelf. PBKDF2 geeft je losse waarden waardoor je die zelf moet opslaan. En de resulterende hashes (van password_hash()/crypt()) zijn compatibel met meerdere systemen zoals linux PAM. Cryptografisch gezien is PBKDF2 niet slechter.

[Evianon]

Het ziet er redelijk uit. De key van je app zelf gebruiken is inderdaad niet zo handig voor als die ooit een keer verandert, maar zoals al aangegeven is het juist belangrijk dat een deel van je key van de server komt en een deel van de key van de user (het password), zodat je niet (direct) op 1 punt kwetsbaar bent. Let er nog op dat je initialization vector goed klopt met de blocksize enz.

Verder is een trager hashing algoritme gebruiken inderdaad verstandig. Als zoiets niet beschikbaar is en niet makkelijk / handig te installeren, kun je dat ook zelf doen door middel van stretching: simpelweg een arbitrair aantal keer (bijv. 1337) een "snelle" hash als SHA toepassen, eigenlijk wat andere algoritmes ook gewoon doen. Het gaat er uiteindelijk om om brute-forcen te vertragen.

Ik zou je aanraden een aparte random salt per versleuteling te gebruiken, en niet één die je bij registratie genereert en voor ieder stukje data hergebruikt. Met de salt wil je juist (o.a.) voorkomen dat hetzelfde wachtwoord telkens dezelfde key oplevert, zodat het maken van een dictionary niet mogelijk is, wat je door het hergebruiken van de salt weer teniet doet. Je kunt de salt telkens gewoon plain achter de resulterende ciphertext plakken, dat maakt niet uit en daardoor hoef je ze niet apart in een database veld met iedere string bij te houden.

Verder ben je inderdaad niet bezig met je eigen encyption, maar gewoon met het veilig implementeren van een bestaand algoritme, en daar is helemaal niets mis mee.

[deadinspace]

DennusB schreef op maandag 04 januari 2016 @ 15:36:
Het hele encryptie model bestaat uit 3-factor-authentication.

Andere posters hintte er ook al naar, maar dit is geen 3-factor authentication. De "factors" zijn:

• Iets dat je weet. (typisch een wachtwoord)
• Iets dat je bent. (biometrische zaken zoals een vingerafdruk bv)
• Iets dat je hebt. (bv een pas of een token-generator zoals je telefoon)

Bij two-factor authentication heb je twee van deze drie zaken. Zoals bijvoorbeeld gebruikelijk is voor bank-transacties: je pas en je pincode.

Jouw constructie is slechts gebaseerd op iets dat de gebruiker weet (namelijk het wachtwoord), en is dus one-factor authentication.

1. Een user specifieke hash, gegenereerd tijdens registratie, 20 tekens lang, random

Een hash is niet random. Ik kan je aanraden je te beter te verdiepen in de terminologie als je dit tot een goed einde wil brengen

2. De SHA256 hash van het user-wachtwoord (wordt gehashed tijdens het inloggen, wachtwoord is dus nergens plain-text te vinden, logisch)

Zoals andere posters al aanhaalden, gebruik nooit SHA-256 om wachtwoorden te hashen, maar een hash die daar specifiek voor ontworpen is (zoals PBKDF2, bcrypt, of scrypt) met een geschikte iteration count.

Vervolgens maken we een MD5 hash van bovenstaande factors op de volgende manier

Waarom MD5? Je hebt een paar redelijke bronnen van entropie, en vervolgens reduceer je dat tot 128 bits. Hoewel dat waarschijnlijk genoeg is kan het geen kwaad om wat meer te behouden (bv 256 bits dmv SHA-256).

Bovendien zou ik gebruik van MD5 afraden voor alles tegenwoordig. Hoewel MD5 voor deze specifieke situatie waarschijnlijk nog acceptabel is geeft het aantal gaten in MD5 teveel zorgen voor de toekomst imho.

Bovenstaande MD5 hash is vervolgens de ecnryptie key die we Mcrypt voeren. De IV voor Mcrypt wordt ook per user tijdens registratie random gegenereerd met de functie :

Een waarschuwing: ik heb me laten vertellen dat mcrypt een slechte API is die fouten maken in de hand werkt. En dat is dodelijk in encryptie.

Mijn denkwijze is als volgt : Als iemand de gehele website zou hacken en de code + database zou dumpen, dan NOG is het onmogelijk de data te decrypten omdat de hacker niet beschikt over het plain-text wachtwoord van de user.

De aanvaller heeft het plain-text wachtwoord van de user niet nodig. De aanvaller heeft de SHA-256 hash nodig. En die staat gewoon in de database (toch?). Uiteindelijk staan alle secrets dus in je DB en code.

Hydra schreef op maandag 04 januari 2016 @ 15:42:
Voor one-way hashingmoet je gewoon geen hashes gebruiken die bedoeld zijn om snel te zijn. Dit sluit dus MD5 en SHA uit.

Alle hashing is one-way. Dat is de hele definitie van een hash.

Je moet geen snelle hashes gebruiken om wachtwoorden te hashen. In vrijwel elke andere situatie wil je juist dat een hash zo snel mogelijk is

[DennusB]

deadinspace schreef op maandag 04 januari 2016 @ 18:35:
[...]

Een hash is niet random. Ik kan je aanraden je te beter te verdiepen in de terminologie als je dit tot een goed einde wil brengen

Sorry, ik bedoelde uiteraard salt.

De aanvaller heeft het plain-text wachtwoord van de user niet nodig. De aanvaller heeft de SHA-256 hash nodig. En die staat gewoon in de database (toch?). Uiteindelijk staan alle secrets dus in je DB en code.

Nee natuurlijk staat die niet in de database. De sha256 van het user wachtwoord wordt alleen bij t inloggen gemaakt en in een sessie gestopt en de uiteindelijke decryptie sleutel wordt pas gemaakt zodra het echt nodig Is..

[Anoniem: 111703]

Grappig dat er nog bijna niemand met het juiste (edoch simpele) antwoord gekomen is. Namelijk: password_hash(). Geeft wel te denken, aangezien de functie al een hele tijd gewoon beschikbaar is in PHP (sinds 5.5, of zelfs vanaf 5.3.7 als je een forward compatible package gebruikt).

Het advies is overigens om niet zelf te gaan lopen hannesen met het genereren van salts, maar dit aan de functie zelf over te laten (met PHP 7 is de optie om zelf een salt mee te geven als optie zelfs deprecated). Je kan met een cost (integer in het bereik [4,31]) ook invloed hebben op de zwaarte van de encryptie. Het onderliggende algoritme (bcrypt) is meer dan zwaar en veilig genoeg. Let er wel op dat je de hash in een varchar(255) opslaat.

Ten slotte: staar je niet dood op het helemaal dicht timmeren van slechts 1 facet van je beveiliging (encryptie van wachtwoorden), aangezien een ketting slechts zo sterk is als de zwakste schakel.

[ Voor 6% gewijzigd door Anoniem: 111703 op 04-01-2016 19:20 ]

[CyBeR]

Anoniem: 111703 schreef op maandag 04 januari 2016 @ 19:18:
Grappig dat er nog bijna niemand met het juiste (edoch simpele) antwoord gekomen is. Namelijk: password_hash().

Lees eens terug?

[Anoniem: 111703]

CyBeR schreef op maandag 04 januari 2016 @ 19:19:
[...]


Lees eens terug?

Vandaar dat er stond: bijna niemand.

[deadinspace]

DennusB schreef op maandag 04 januari 2016 @ 18:53:
Nee natuurlijk staat die niet in de database. De sha256 van het user wachtwoord wordt alleen bij t inloggen gemaakt en in een sessie gestopt en de uiteindelijke decryptie sleutel wordt pas gemaakt zodra het echt nodig Is..

En waar staat die session data?

[Gomez12]

Anoniem: 111703 schreef op maandag 04 januari 2016 @ 19:18:
Grappig dat er nog bijna niemand met het juiste (edoch simpele) antwoord gekomen is.

Wat ik dan wel weer grappig vind is wat jij dan als vraagstelling leest als dat het juiste edoch simpele antwoord is.

Er staat een voorbeeld van een huidige "encyptie" en de vraag is imho : Is dit veilig genoeg en/of wat kan verbeteren?
Dan is enkel password_hash() een antwoord op een hele andere vraag die wel eraan gelieerd is, maar die niet gesteld is.

Plus dat het een beetje overbodig is om meerdere keren het goede antwoord te plaatsen (oftewel 1x volstaat) een antwoord wordt nou niet echt juister als iedereen het maar blijft herhalen. Dus ik vind het niet zo verwonderlijk dat er mensen zijn die denken : het juiste antwoord staat er al, ik hoef niet meer te reageren.

[DennusB]

deadinspace schreef op maandag 04 januari 2016 @ 22:14:
[...]

En waar staat die session data?

PHP session, dus niet in de database

Wat betreft de discussie om de hashing van het wachtwoord te veranderen, dat ben ik met jullie eens en ga ik dus aanpassen Thanks voor de waardevolle input hierover.

[Gomez12]

DennusB schreef op dinsdag 05 januari 2016 @ 00:03:
[...]

PHP session, dus niet in de database

Wat betreft de discussie om de hashing van het wachtwoord te veranderen, dat ben ik met jullie eens en ga ik dus aanpassen Thanks voor de waardevolle input hierover.

Maar skip je dan ook gelijk de MD5 hash?

Want in principe heeft het in de praktijk (behalve als je echt alle gevolgen begrijpt) alleen maar negatieve effecten als je hashing methodes gaat mixen (want je gaat vrijwel altijd enkel maar je entropie verlagen)

Plus dat je even moet opletten wat de gevolgen zijn van het gebruiken van een password (of elk user te wijzigen gegeven) in je encryptie / hashing zelf. In wezen moet je dan handmatig expliciet gaan opvangen dat alles wat ge-encrypt is ge-decrypt en opnieuw ge-encrypt moet worden bij een password change, anders is het niet meer benaderbaar.
En nou weet ik niet over wat voor hoeveelheden data je praat, maar ik zit liever niet na 1 jaar gebruik te hebben gemaakt van jouw site een half uur te wachten totdat mijn password wel/niet doorgevoerd is.

[CyBeR]

Gomez12 schreef op dinsdag 05 januari 2016 @ 00:40:
[...]
Plus dat je even moet opletten wat de gevolgen zijn van het gebruiken van een password (of elk user te wijzigen gegeven) in je encryptie / hashing zelf. In wezen moet je dan handmatig expliciet gaan opvangen dat alles wat ge-encrypt is ge-decrypt en opnieuw ge-encrypt moet worden bij een password change, anders is het niet meer benaderbaar.

Klopt ja, de geëigende manier daarvoor is het genereren van een random key, waarna die key geencrypt wordt met een key gebaseerd op het wachtwoord en opgeslagen. Daarna hoef je bij een wijziging alleen maar die key te her-encrypten.

Zo werkt het gemiddelde full-disk-encryptionproduct (waaronder LUKS en Apple Filevault).

[ Voor 7% gewijzigd door CyBeR op 05-01-2016 01:42 ]

[DJMaze]

Wat ik nog mis is de optie: Client Certificaten
De hell voor een juiste implementatie en de kosten voor ondersteuning (mensen snappen het niet) daar gelaten, is het wel een prima extra optie als dingen echt veilig moeten zijn.

De grootste fout blijft gewoon PEBCAK

[xleeuwx]

DJMaze schreef op dinsdag 05 januari 2016 @ 01:56:
Wat ik nog mis is de optie: Client Certificaten
De hell voor een juiste implementatie en de kosten voor ondersteuning (mensen snappen het niet) daar gelaten, is het wel een prima extra optie als dingen echt veilig moeten zijn.

De grootste fout uitdaging blijft gewoon PEBCAK

FTFY

Is een optie als Oauth van google / MS / eigen server / FB / ga zo maar door geen optie ?

[Gomez12]

DJMaze schreef op dinsdag 05 januari 2016 @ 01:56:
Wat ik nog mis is de optie: Client Certificaten
De hell voor een juiste implementatie en de kosten voor ondersteuning (mensen snappen het niet) daar gelaten, is het wel een prima extra optie als dingen echt veilig moeten zijn.

De grootste fout blijft gewoon PEBCAK

Ach, het grootste wat ik mis is gewoon uitbesteden aan een expert die wel weet hoe het werkt.

Als het echt om extreem privacy gevoelige data gaat wil je gewoon niet zelf gaan lopen klooien.

Goede encryptie / beveiliging is gewoon moeilijk en een foutje is heel heel snel gemaakt.

De grootste PEBCAK's bij beveiliging zitten bij de programmeurs die het zelf wel even denken te kunnen doen met een paar standaard functie's en dat is het dan wel.

Als het echt om extreem privacy gevoelige data gaat (wat meestal gelijkstaat aan veel geld waard). Wat mij altijd is : Als het echt extreem privacy gevoelige data is, ga er dan vanuit dat de hacker je complete server uit het rack trekt en mee naar huis neemt, daar een jaar lang naar alle broncode en "secret codes" etc die je gebruikt hebt gaat zitten turen en 100.000 investeert bij een Amazon / MS cloud voor wat computing power. Ben jij er dan zeker van dat jouw oplossing blijft staan. Of breekt hij dan?

Want de gemiddelde hack gebeurt niet meer in 1 avondje, dat is tegenwoordig meer dat het gewoon via laagjes gebeurt en dat mensen bijv al 2 maanden overal toegang toe hebben zonder dat jij het weet maar ze doen simpelweg niets, want ze zijn alleen maar aan het zoeken / kijken naar de secret codes.

xleeuwx schreef op dinsdag 05 januari 2016 @ 02:04:
[...]
Is een optie als Oauth van google / MS / eigen server / FB / ga zo maar door geen optie ?

Grootste twijfelpunt bij OAuth vind ik altijd dat je het zelf kan draaien zonder enige centrale certificering oid, waardoor als je het zelf draait je het probleem alleen maar verplaatst hebt. Joeperdepoepie, mijn site maakt nu gebruik van een industriestandaard veilige OAuth-methode, alleen de OAuth server zal dan over het algemeen weer volgens de oude gedachten opgezet zijn en dezelfde beveiligingsgaten bevatten als het originele idee zonder OAuth.

OAuth vind ik altijd alleen maar leuk als je daarmee het probleem kan verplaatsen naar een betrouwbare partij die voor de rest niets met de info wenst te doen. Wat bij een Google / MS / FB nog wel eens twijfelachtig wil zijn als jouw domeinnaam al genoeg zegt voor het deels opbouwen van een profiel.

[xleeuwx]

En andere optie is om gewoon de hasing fascade van Laravel te gebruiken (indien je al aangaf dat je Laravel Gebruikte), eventueel in combinatie met de secret key encrypted met het wachtwoord of dergelijke.


Hash:
https://laravel.com/api/5...racts/Hashing/Hasher.html

Encrypt:
https://laravel.com/api/5...Encryption/Encrypter.html

[ajakkes]

Als ik het goed begrijp staat de hashfunctie in javascript. Met het uitgangspunt dat het wachtwoord 1% van gevallen Welkom01 is.

Hoe veilig is dan je implementatie?

Jshash(Welkom01) gaat naar de server.
Server slaat jshash(Welkom01) op in de sessie. Maakt hash(jshash(Welkom01).usersalt.globalsalt)

De globalsalt staat in je filesystem. De usersalt in je database. En de gebruikte hash in je filesystem.

De key van je key is hash(jshash(Welkom01).usersalt.globalsalt).

Wanneer je de globalsalt weg laat heb je genoeg aan de database en het raden van de hash en encrypt functie om een deel van de data te decrypten. Immers jshash(Welkom01).usersalt kan je bruteforcen op de encrypted keys.

Bij het weglaten van de usersalt is de globalsalt nodig. Maar wanneer deze geraden is, is een lijst met veel gebruikte wachtwoorden het enige om een deel van de data te lekken, bij toegang tot de database.

Volgens mij voegt een jshash, oftewel een hash functie zichtbaar in de clientside code, over alleen het wachtwoord niet zoveel toe. Behalve dat het wachtwoord niet direct bij andere sites van de gebruiker hergebruikt kan worden. Immers of de hacker nu het wachtwoord heeft of de hash van het wachtwoord maakt voor jouw site niks uit. De hash van het wachtwoord is wat je wil horen en altijd hetgeen de hacker zal zien of kunnen creëren.

[deadinspace]

DennusB schreef op dinsdag 05 januari 2016 @ 00:03:
PHP session, dus niet in de database

Maar wel op je filesystem (waarschijnlijk, er zijn andere mogelijkheden). In een van mijn vorige posts schreef ik dat dat alle ingrediënten te vinden zijn in je code of in je DB. Als ik dat aanpas naar "op je filesystem of in je DB", dan blijft dat punt wel staan. Je Laravel app key staat in je code, de wachtwoord-hash in de session files, en je user salt in de DB.

Als een aanvaller toegang heeft tot je server, heeft hij toegang tot alledrie. Hoe vaak worden session files opgeruimd? Gebeurt dat überhaupt? Anders kan het zijn dat deze gegevens beschikbaar zijn voor veel langer dan je zou verwachten.

Overigens: PHP native sessions, of Laravel sessions? Laravel sessions kunnen wel degelijk in de DB staan (al is file storage de default volgensmij).

Oh, en nog wat: hoe sla je user-wachtwoorden (voor het inloggen van gebruikers) op? Als dit SHA-256-hashed is zonder salt, dan is dat hetzelfde als voor je key derivation hash in je session, en in dat geval staat diezelfde hash dus wel in je DB

[DennusB]

deadinspace schreef op dinsdag 05 januari 2016 @ 14:12:
[...]

Maar wel op je filesystem (waarschijnlijk, er zijn andere mogelijkheden). In een van mijn vorige posts schreef ik dat dat alle ingrediënten te vinden zijn in je code of in je DB. Als ik dat aanpas naar "op je filesystem of in je DB", dan blijft dat punt wel staan. Je Laravel app key staat in je code, de wachtwoord-hash in de session files, en je user salt in de DB.

Als een aanvaller toegang heeft tot je server, heeft hij toegang tot alledrie. Hoe vaak worden session files opgeruimd? Gebeurt dat überhaupt? Anders kan het zijn dat deze gegevens beschikbaar zijn voor veel langer dan je zou verwachten.

Overigens: PHP native sessions, of Laravel sessions? Laravel sessions kunnen wel degelijk in de DB staan (al is file storage de default volgensmij).

Oh, en nog wat: hoe sla je user-wachtwoorden (voor het inloggen van gebruikers) op? Als dit SHA-256-hashed is zonder salt, dan is dat hetzelfde als voor je key derivation hash in je session, en in dat geval staat diezelfde hash dus wel in je DB

Laravel sessions, maar ze staan inderdaad niet in database. Het is de bedoeling om dat op een losse server (zonder internet toegang vooral) op te gaan slaan. Is dat een goed plan?

Edit : User-wachtwoord is gewoon Laravel native, dat is bcrypt voor zover ik weet!

[ Voor 3% gewijzigd door DennusB op 06-01-2016 08:15 ]

[Barryvdh]

Je kan het beter omdraaien toch? Niet een hash maken en die opslaan als encryptie sleutel, maar een goede random encryptie key genereren en die versleuteld opslaan, met behulp van het wachtwoord.

Bij invoeren van het wachtwoord kan je dan de encryptiesleutel ontcijferen. Als je wachtwoord wil wijzigen hoef je alleen encryptiesleutel te ontcijferen met oude wachtwoord, en opnieuw te versleutelen met het nieuwe. Alle data blijft ongewijzigd. En je slaat nergens een hash op van je wachtwoord zelf.

En ik zou niet de Laravel app key gebruiken, maar inderdaad een losse key, in het geval dat dat nog ooit wijzigt (is al paar keer van default algoritme enzo veranderd).

Als je er voor zorgt dat je sessies kort opgeslagen worden of in geheugen met memcached, dan valt de impact mee toch? In het slechtste geval zouden ze bij de sessies van actieve gebruikers op dat moment kunnen, maar waarschijnlijk niet het grootste deel. Als ze eenmaal file access hebben op je systeem, kunnen ze natuurlijk ook gewoon een script toevoegen wat wel de wachtwoord plain-text afvangt..

Of zou je bijv. het user-deel van de encryptiesleutel op kunnen slaan in een (secure, http-only) cookie, op het moment dat je inlogt? Laravel encrypt standaard zijn cookies met de app key, dus aan alleen dat deel van de key heb je niks, tenzij je ook de database + app encryptie keys hebt.