Hoe sla je niet- gehashte wachtwoorden het veiligst op

[Pater91]

Sinds een aantal jaar ben ik bezig met een klein projectje ( symfony 4, php ) voor mezelf om het een en ander te automatiseren op websites. Stilletjes aan werd het groter, slimmer, en gebruiksvriendelijker.
Een aantal weken terug ben ik op het punt beland dat het project klaar is voor het publiek, maar er zijn wat zaken waar ik me nog over moet buigen, en advies nodig heb.

Voor mijn project is het namelijk noodzakelijk om inloggegevens op te slaan voor een externe website. Deze gegevens heb ik in plaintext nodig... en het is zo simpel dat wanneer het project de gegevens kan decrypten, ik dat ook kan, en dus ook een eventuele hacker met meer security kennis dan ik.
Hoe kan ik dit het beste aanpakken?

Huidige situatie:
- Al het verkeer loopt over https, dus mitm aanvallen zijn uitgesloten.
- Gebruiker voert zijn gegevens in op de daarvoor bestemde pagina.
- De server ontvangt deze gegevens, en stuurt deze door naar een api op een andere server die enkel intern toegankelijk is. Hier staat enkel poort 443 open naar de andere server.
- De api slaat deze gegevens in plaintext op ( voor prive gebruik was dit prima, don't judge me here ) in combinatie met het gebruikers ID.
- Een ander script op de api server maakt verbinding met een database ( alleen intern te bereiken en op een andere machine ) en haalt dan de queue op. De queue bevat enkel data over de opdracht ( niet gevoelig ) en een lokaal gebruikers ID. Het script voert de opdracht uit, en iedereen is gelukkig.


Nu ben ik misschien wat paranoia, maar is dit een degelijk begin? Ik weet dat de wachtwoorden eigenlijk encrypted moeten worden, maar de key om te decrypten zal hoe dan ook ergens beschikbaar moeten zijn...dus hoeveel zin heeft dat feitelijk gezien? En welke encryptie is hiervoor het best geschikt?

Alle servers draaien overigens op debian, met apache2 als webserver.

Leesvoer is uiteraard altijd welkom! Ik verwacht geen voorgekauwde oplossingen, enkel suggesties met argumenten om van te leren. Zelf lijkt het me een vrij solide constructie namelijk, dus ik ben erg benieuwd naar jullie ervaringen en visie hierin

[pottink]

Als je wachtwoorden plaintext nodig hebt moet je eens gaan nadenken waar je applicatie misschien ergens fout zit. Wachtwoorden moet je m.i. ALTIJD encrypteren, hoe dan ook.
Beste is dan dat je de 2 hashes vergelijkt.

https://secure.php.net/manual/en/function.password-hash.php

code:

password_hash($raw, PASSWORD_BCRYPT, $options);

Als je echt moet gaan decrypten zou ik me gaan afvragen of je het niet op een andere manier kan aanpakken.

[Voor 20% gewijzigd door pottink op 10-10-2018 16:11]

[mstx]

Niet.
De enige goede optie is dat die externe website oauth of iets vergelijkbaars implementeert.

[McKaamos]

Passwords moet je altijd hashen idd. En salten, en in een sterk hashingalgoritme (dus geen MD5!).

Ik vraag me ook sterk af waarom je wachtwoorden in plaintext nodig hebt. Als jouw applicatie inlogt op een remote service, dan zou je eens moeten gaan kijken naar Oauth tokens oid.

Verder: HTTPS is géén garantie dat er geen MITM gedaan wordt. Hell, er zijn letterlijk virusscanners die MITM uitvoeren om data onderweg van server naar browser te controleren.
Alleen TLS 1.3 bied daar mitigations voor, niet HTTPS an-sich, en TLS1.3 is nog lang niet overal doorgevoerd, dus je moet wel 1.2 en eventueel lager ondersteunen.

[Stoelpoot]

Niet. Klaar.

Encrypten is wel veiliger, omdat je dan met enkel een database-kwetsbaarheid niet direct de wachtwoorden kan zien.

Dat gezegd hebbende, is het gewoon *niet* veilig. Klaar.

Wat ik begrijp wil je de inlogsessie over meerdere servers gebruiken. Hiervoor kan je bijvoorbeeld een OAuth2-implementatie gebruiken. Hiermee logt de gebruiker in, krijgt een token wat bewijst dat de login-sessie geldig is, en met dit token kunnen andere servers binnen het domein ook valideren dat de aanvragen die ze krijgen authenticated en authorized zijn. Zo te zien zijn al je verbindingen in je eigen beheer, dus dit is niet lastig te implementeren.

@pottink, je zoekt overigens naar de term hashing, niet encrypting. Hashing is het one-way scramblen van een wachtwoord, encrypten is hetgeen wat de Duitsers gebruikten zodat hun verkeer niet afgeluisterd werd (en door de Turingmachine gekraakt werd).

[mithe]

Een wachtwoord moet je niet willen kunnen decrypten. Als je een wachtwoord kwijt bent kan je beter gewoon een nieuwe mailen. En het liefst de gebruiker forceren om het wachtwoord te vervangen.

[McKaamos]

Leuke video, neem het ter harte:

[mithras]

Het is lastig te bepalen uit je verhaal omdat de use case nog niet helemaal duidelijk is, maar je dit waarschijnlijk afschermt omdat je je eigen idee wil beschermen.

Als ik er vanuit ga dat jij vanuit jouw systeem andere sites moet benaderen om in te kunnen loggen, heb je inderdaad de passwords nodig (als er geen API keys e.d. zijn, maar die moet je hetzelfde bewaken als passwords). Een password manager lost dat technisch goed op: je kan de password van externen encrypten met een password van de gebruiker. Daarmee heb je op jouw systeem geen toegang tot de wachtwoorden, zolang je design goed is. Let dus goed op je opslag, hoe je in php werkt met caching en dat de decryptie/encryptie enkel in memory gebeurt. Een beter design is om de actie niet eens op je eigen server te laten plaatsvinden, maar op het device van de gebruiker.

Als je wachtwoorden enkel nodig hebt voor eigen authenticatie (zoals iedereen boven mij aanneemt volgens mij), moet je inderdaad niet naar encryptie kijken maar gewoon netjes hashen. Maar omdat je zegt:

Voor mijn project is het namelijk noodzakelijk om inloggegevens op te slaan voor een externe website.

Ga ik uit van mijn eerste aanname en acteer je meer zoals password managers ook wachtwoorden in oorspronkelijke staat moeten terughalen.

[Voor 3% gewijzigd door mithras op 10-10-2018 16:34]

[Not Pingu]

Jammer dat iedereen hier het standaardantwoord geeft ipv mee te denken met de TS. Dat je wachtwoorden moet hashen weten we nou wel. Maar dat is een softwareoplossing voor een ops-probleem. Bovendien: door passwords te hashen is de rest van je data nog steeds geen klap veiliger.

De sleutel hiertoe zit 'm dus niet in de programmeerhoek maar in je netwerkarchitectuur. Je geeft aan dat de verbinding intern in je netwerk redelijk afgeschermd zijn, dat is een begin. Het doel is dus om (tot een redelijk niveau) te voorkomen dat iemand uberhaupt bij je netwerk kan om je DB te stelen. Je kunt bijv bij PCI-DSS kijken voor inspiratie, hoewel dat wel enorm overwhelming kan zijn.

Om een paar dingen op een rijtje te zetten die imho nog in het redelijke vallen:

• Verdeel je netwerk dmv VLANs in een DMZ (publiek bereikbaar gedeelte) en een intern gedeelte
• Zorg voor een goede wachtwoord policy op je servers
• Geef alles in je netwerk alleen de toegang die het nodig heeft
• Installeer een IDS/IPS zoals Splunk of OSSEC, inclusief agents op je servers voor file integrity monitoring
• Installeer een WAF (bijv. ModSecurity) tussen je publieke en je private netwerk
• Run een scanning tool zoals HackerGuardian om een beeld te krijgen van hoe veilig je omgeving is

Ben het wel eens met @McKaamos dat die andere partij beter een token-systeem aanbiedt, maar die keuze heb je gewoon niet altijd.

[Voor 11% gewijzigd door Not Pingu op 10-10-2018 16:45]

[hellum]

@Not Pingu En dan blijkt date TS toch een klein foutje heeft gemaakt in de applicatie, waardoor SQL inject mogelijk is. Lekt toch de hele database uit. Het hoeft maar iets heel kleins te zijn in een hoek die je niet verwacht en de plain passwords van mensen lekken toch uit.

[dcm360]

@hellum De veiligste oplossing is inderdaad om geen wachtwoorden nodig te hebben vanuit de applicatie. Dat neemt nog niet weg dat er een goede oplossing te ontwerpen valt waarmee de risico's van het wel gebruiken van wachtwoorden geminimaliseerd worden.

Een vergelijkbare vraag zou zijn hoe je een webmail-client schrijft die via imap en smpt een mailserver benadert. Ook in dat geval gebruik je de inloggegevens van de gebruiker, en wil je voorkomen dat die per ongeluk uitlekken. Dan is het antwoord 'Je moet deze software niet maken' vrij nutteloos.

[Nvidiot]

Pater91 schreef op woensdag 10 oktober 2018 @ 16:05:
...
- Al het verkeer loopt over https, dus mitm aanvallen zijn uitgesloten.
...

Hier wil ik toch even op inhaken. MITM aanvallen kunnen prima ook met HTTPS gedaan worden, tenzij je de certificates controleert. Zoek even op 'certificate pinning' als je hier meer over wil lezen

[hellum]

@dcm360 Tja, als het echt zou moeten.

Ik zou beginnen met de passwords van mensen te scheiden van de normale applicatiedatabase (op deze manier, als je database uitlekt, hebben ze niet direct de passwords te pakken). De passwords zou ik daarna encrypten, (dus per wachtwoord en gebruiker een andere cipher). Het cipher zou ik laten afhangen van het wachtwoord van de gebruiker in je eigen applicatie (die je wel gewoon goed moet hashen en daardoor alleen de gebruiker weet).

Dit AUB niet letterlijk opvolgen, ik heb er maar 10 minuten over nagedacht en er zijn vast betere oplossingen.

[mcDavid]

Er zijn wel projecten om dit soort secrets te managen, bijvoorbeeld: https://www.vaultproject.io/

Maar dit is vooral van toepassing als je op grote schaal secrets moet managen (denk bijv database credentials van meerdere applicaties e.d.). Als je het gebruikt om één wachtwoord op te slaan, is het voornamelijk het verplaatsen van het probleem. Want uiteindelijk is er nog steeds ergens een repository waar dat wachtwoord herleidbaar in staat.

Overigens snap ik de hele paniek in dit topic niet zo. Vrijwel ieder PHP-project heeft wel ergens een config bestand waar plain-text credentials in staan van op zijn minst een database of iets dergelijks. Je ontkomt er gewoon niet aan.

Het enige wat te zeggen valt, is dat voor een api natuurlijk geen username/password, maar een token of iets dergelijks gebruikt zou moeten worden. Liefst gekoppeld aan het IP waar de requests vandaan mogen komen. Maar als je de api in kwestie niet zelf onderhoud, wordt dat natuurlijk een moeilijk verhaal.

Edit: Zoals Hellum zegt, heb de vraag niet helemaal goed gelezen.

[Voor 6% gewijzigd door mcDavid op 11-10-2018 10:12]

[Rob]

Betreffende deze 2 punten:
- De api slaat deze gegevens in plaintext op ( voor prive gebruik was dit prima, don't judge me here ) in combinatie met het gebruikers ID.
- Een ander script op de api server maakt verbinding met een database

Waarom is het wachtwoord hier nodig in plaintext?

[hellum]

mcDavid schreef op woensdag 10 oktober 2018 @ 17:15:

Overigens snap ik de hele paniek in dit topic niet zo. Vrijwel ieder PHP-project heeft wel ergens een config bestand waar plain-text credentials in staan van op zijn minst een database of iets dergelijks. Je ontkomt er gewoon niet aan.

Het gaat om de plain credentials van meerdere gebruikers om in een extern systeem in te loggen. Als dat uitlekt ben je de sjaak.

[Pater91]

Rob schreef op woensdag 10 oktober 2018 @ 17:22:
Betreffende deze 2 punten:
- De api slaat deze gegevens in plaintext op ( voor prive gebruik was dit prima, don't judge me here ) in combinatie met het gebruikers ID.
- Een ander script op de api server maakt verbinding met een database

Waarom is het wachtwoord hier nodig in plaintext?

@Nvidiot Thanks voor de tip over https mitm... ik ga het gelijk uitzoeken want dit kende ik nog niet, lijkt me erg interessant om meer over te leren. In mijn ervaring is het namelijk niet mogelijk zonder dat de eindgebruiker iets merkt, maar het zou me niet verbazen als er alweer iets op gevonden is.

Ik merk dat er wat verwarring is omtrent het project.. ik zal even proberen het beter te verwoorden, want ik merk dat ik nogal cryptisch ben.
(Overigens, @mithras, jij had de insteek wel goed begrepen )

Mijn project logt in, namens de eindgebruiker, op diverse websites om daar acties uit te voeren.
Erg simpel, maar zodra je er een module bovenop knalt ga je immens veel tijd besparen. Ik heb momenteel modules draaien voor marktplaats en enkele game webshops, zodat ik o.a. automatisch mijn enorm overschot van producten kan aanbieden op marktplaats. De modules voor de game webshops geeft me een notificatie zodra een product ineens in de aanbieding is, en kan het tevens bestellen voor me als ik dat wil.
Ik heb inmiddels al 2 jaar geen enkele pre-order meer gemist op deze manier Alles zit zo in elkaar dat ik binnen een half uurtje een nieuwe module heb gemaakt voor eender welke site dan ook, best praktisch als je weinig tijd hebt.

Wat het punt dus is: de server heeft hoe dan ook de gegevens in plaintext nodig op een bepaald punt, hashen is dus geen optie. Het wachtwoord waarmee je inlogt op het systeem is uiteraard wel hashed
Aangezien ik vaker zaken als deze voorbij zie komen ( hell, je hebt online bitcoin managers.. ) dacht ik dat er vast wel een verantwoorde manier is om dit te bekokstoven zonder grote risico's. Begrijp me niet verkeerd, de servers zitten dichtgetimmerd voor zover ik weet met mijn ~8 jaar ervaring. Maar als er een optie is om dit echt helemaal op slot te gooien dan zou dat erg mooi zijn.


TLDR:
Mijn systeem automatiseert zaken op andere websites, en daarvoor moet hij kunnen inloggen met gegevens van de 'klant'. Die gegevens moeten ergens zo veilig mogelijk opgeslagen worden, waar het risico vrijwel niet aanwezig is dat een derde partij hier ooit in komt. Ik ben zelf een persoon die online wachtwoordmanagers niet vertrouwt, en dat zie je terug in mijn zorgen hierover. Maar, er moet toch een optie zijn om dit fatsoenlijk op te slaan? Het moet anno 2018 toch mogelijk zijn om veilig een wachtwoord encrypted op te slaan, en later terug te halen? De server waar de data op staat hangt niet eens aan het internet, deze dient enkel als database voor de servers eromheen, welke enkel kunnen zeggen "stuur opdracht X naar website Y met inloggegevens Z".

Nogmaals; mocht er geen fatsoenlijke oplossing zijn om dit voor elkaar te krijgen dan zal ik maar een client applicatie moeten bouwen. Veiligheid gaat boven alles, zeker als het om andermans gegevens gaat.

[Voor 5% gewijzigd door Pater91 op 10-10-2018 21:31]

[EddoH]

Er is simpelweg geen ultiem veilige methode voor wat je wilt doen.
Waar je nog aan kunt denken is:

- de user elke actie/sessie vragen om een (master)password in te voeren om daarmee zijn keys te decrypten en te gebruiken. Hierdoor hoef je niet de decryptie keys op te slaan.

- gespecialiseerde hardware (HSM) gebruiken om daarmee de key storage en eventuele decryptie te doen.

[Voor 3% gewijzigd door EddoH op 10-10-2018 22:12]

[ajakkes]

Zijn website heeft daarmee een vergelijkbare functie als de websites die hij niet vertrouwd. Namelijk password manager websites. Naast de overige functies.

Behalve dan dat Lastpass de wachtwoorden pas nodig heeft nadat de gebruiker is ingelogd en deze website de wachtwoorden continue nodig heeft om acties uit te voeren op andere websites.

Mogelijk kan je iets doen met ingelogd blijven op die websites middels cookies?

Waarbij die cookies overigens ook veilig opgeslagen dienen te worden.

Ik zou eens kijken hoe bijvoorbeeld KeePass zoiets oplost.

[emnich]

De enige normale optie is om de wachtwoorden encrypted op te slaan met de key ergens buiten je webroot. De key kan je ook nog samenstellen met een vaste key in een config (buiten de root) en iets van de gebruiker in de database.

Ook zou je de encryption key op een andere server op kunnen slaan en deze telkens ophalen maar uiteindelijk ontkom je er niet aan om op de webserver alles neer te zetten om die wachtwoorden plaintext te maken. Het enige wat je kan doen is het risico beperken.

Als iemand alleen de database in handen krijgt (grootste risico) dan heeft ie niets aan de wachtwoorden. Lekt ook nog je key uit dan kan de hacker er nog steeds niets mee (mits je dus de key aanvult met iets van de gebruiker). Als de hacker echter toegang krijgt tot het hele systeem dan ben je hoe dan ook de l*l.

[Voor 6% gewijzigd door emnich op 11-10-2018 07:38]

[BCC]

Ik heb ooit zoiets gemaakt waarbij je de plaintext wachtwoorden van de gebruiker encrypt met een pub/private key combinatie, waarbij het private stuk symmetrisch geencrypt is met het wachtwoord van de gebruiker. Let wel - je kan dus pas bij dr iets als de gebruiker inlogt. Wachtwoorden resetten is er dus ook niet meer bij. Password managers doen iets vergelijkbaars.

[Voor 14% gewijzigd door BCC op 11-10-2018 07:50]

[emnich]

BCC schreef op donderdag 11 oktober 2018 @ 07:47:
Ik heb ooit zoiets gemaakt waarbij je de plaintext wachtwoorden van de gebruiker encrypt met een pub/private key combinatie, waarbij het private stuk symmetrisch geencrypt is met het wachtwoord van de gebruiker. Let wel - je kan dus pas bij dr iets als de gebruiker inlogt. Password managers doen iets vergelijkbaars.

Maar het idee is volgens mij dat de server zelfstandig aan het werk gaat, bijvoorbeeld 's nachts zonder dat de gebruiker is ingelogd.

[Luchtbakker]

Ik roep maar wat. Maar als je de website draait op een public server, en je password middels vm op een 2e server die niet public benaderbaar is maar alleen lokaal?

[Kalentum]

Volgens mij ontkom je er niet aan om die wachtwoorden encrypted op te slaan. Belangrijk is wat je als key voor de encryptie gebruikt. Want voor de duur van die user sessie moet je die key ergens hebben staan, wat op zich natuurlijk een risico is. Dus ik zou (wat anderen hier ook al aangeven) het wachtwoord van de user gebruiken om een key te decrypten (waarna je het wachtwoord van de user niet meer nodig hebt). Die unencrypted key gebruik je dan om de third party wachtwoorden te unencrypten

Hoe het dan werkt:
- User logt in met behulp van username/ password en het password unlockt een master key die voor elke gebruiker anders is.
- Deze master key sla je server side op, niet in je database, voor de duur van een user session.
- Deze master key gooi je weg als je user uitlogt en / of na een paar uur
- De master key gebruik je om de wachtwoorden van de third parties te encrypten en decrypten
- De master key wordt niet permanent opgeslagen. Als je 'm niet meer hebt moet de user opnieuw inloggen
- De encrypted credentials (pak ook username mee!) van de gebruiker staan niet in je database maar in kleine, aparte bestanden, voor elke user apart (bv als JSON, sqlite, whatever). Dus als je main database lekt (bv omdat jij een kopie op je development machine laat rondslingeren) heb je nog altijd geen kritische user data gelekt.

Grootste risico is toch dat iemand toegang krijgt tot je service en voldoende informatie kan vergaren om er met de derde partij username/passwords vandoor te gaan. Zorg dus ook dat je procedures hebt als dat gebeurt. Informeer je users direct dat ze hun wachtwoorden moeten wijzigen. Stel gebruiksvoorwaarden op die je vrijwaren van eventuele schade en zorg ervoor dat mensen zich bewust zijn dat je ze hun credentials bij jou achterlaten.

[EvH]

Pater91 schreef op woensdag 10 oktober 2018 @ 21:20:
[...]

Mijn project logt in, namens de eindgebruiker, op diverse websites om daar acties uit te voeren.
Erg simpel, maar zodra je er een module bovenop knalt ga je immens veel tijd besparen. Ik heb momenteel modules draaien voor marktplaats en enkele game webshops, zodat ik o.a. automatisch mijn enorm overschot van producten kan aanbieden op marktplaats.

[...]

Wellicht offtopic; maar dit werkt de indruk als een soort adplacer, waarbij je inlogt dmv bijvoorbeeld CURL.

Zodra het enigszins bekend word; treed Marktplaats actief op met als gevolg een ban op het betreffende account & IPadres

Wees hier bewust van

Algemene voorwaarden van Marktplaats:

Tenzij Marktplaats daarvoor toestemming heeft gegeven (bijvoorbeeld in het geval van API partners), is het niet toegestaan om Advertenties op de Website te plaatsen via een geautomatiseerd systeem, of op enige andere wijze dan via de ‘Plaats Advertentie’ knop.

Het is niet toegestaan om Advertenties namens of in opdracht van derden te plaatsen, tenzij Marktplaats daarvoor toestemming heeft gegeven (bijvoorbeeld in het geval van API partners).

[Freeaqingme]

Waarom @mcDavid zijn nagenoeg volledige antwoord heeft gestriked weet ik niet, maar dat is wel wat ik ook zou voorstellen. Ik zou sowieso de opslag van de wachtwoorden in een aparte applicatie opslaan die zoveel als mogelijk gescheiden is van je 'main' applicatie.

Voor de daadwerkelijke opslag is iets als Vault specifiek gemaakt. Lijkt me wat dat betreft ook een goede oplossing om op z'n minst naar te kijken.

[Oid]

Gebruik een password management tool zoals bijv. https://thycotic.com/solu...tools/secret-server-free/
en haal vervolgens via een api de juiste gegevens op.

[eric.1]

Pater91 schreef op woensdag 10 oktober 2018 @ 21:20:
Mijn project logt in, namens de eindgebruiker, op diverse websites om daar acties uit te voeren.

Volgens mij moet je hier toch nog even vanuit de ogen van de consument, derde partijen (waar je dus voor de gebruiker inlogt) en de avg (toegang tot account, betekent al snel dat je (persoons-)gegevens in kan zien waar je geen ... mee te maken hebt) naar kijken.

[Pater91]

eric.1 schreef op donderdag 11 oktober 2018 @ 16:28:
[...]

Volgens mij moet je hier toch nog even vanuit de ogen van de consument, derde partijen (waar je dus voor de gebruiker inlogt) en de avg (toegang tot account, betekent al snel dat je (persoons-)gegevens in kan zien waar je geen ... mee te maken hebt) naar kijken.

Heb ik gedaan, vandaar deze vraag
Ik heb intussen besloten maar een client variant te maken waarmee de gebruiker lokaal inlogt, om mezelf een hoop kopzorgen te besparen.

Encryptie en wat not is leuk, maar aan het einde van de rit staan de gegevens nog steeds gewoon op 1 machine. Nu kan ik wel alles op netwerkniveau dichttimmeren, maar ik besef me nu eigenlijk pas dat ik deze verantwoordelijkheid helemaal niet wil dragen.

[Hydra]

Hoe dit soort zaken normaal geregeld worden is dat ze 2 keer encrypted worden. 1 keer met een geheime key die server-wide is, en 1 keer met een per-user key die je nergens opslaat. Dat betekent dat als iemand de database heeft, hij nog niks heeft, want de data is encrypted. Als iemand de database + server key heeft, heeft 'ie nog steeds niks: je hebt ook de user key nodig. Als iemand de db key + server key heeft, en een user-key, heeft 'ie alleen nog maar toegang tot die user.

Natuurlijk wil je dit soort dingen als 't even kan helemaal niet doen, maar voor sommige applicaties is het nodig. Ga niet lopen hannesen met aparte processen enzo; die extra complexiteit is security by obscurity op z'n best, en de kans dat je daar een fuck-up maakt en zo iets naar buiten openstelt is aanwezig.

Dit is hoe dit soort oplossingen meestal werken; je zult dus gebruikers iedere keer om een master password vragen dat je nooit en te nimmer aan jouw kant opslaat.

[EddoH]

Hydra schreef op vrijdag 12 oktober 2018 @ 12:03:
Hoe dit soort zaken normaal geregeld worden is dat ze 2 keer encrypted worden. 1 keer met een geheime key die server-wide is, en 1 keer met een per-user key die je nergens opslaat. Dat betekent dat als iemand de database heeft, hij nog niks heeft, want de data is encrypted. Als iemand de database + server key heeft, heeft 'ie nog steeds niks: je hebt ook de user key nodig. Als iemand de db key + server key heeft, en een user-key, heeft 'ie alleen nog maar toegang tot die user.

Natuurlijk wil je dit soort dingen als 't even kan helemaal niet doen, maar voor sommige applicaties is het nodig. Ga niet lopen hannesen met aparte processen enzo; die extra complexiteit is security by obscurity op z'n best, en de kans dat je daar een fuck-up maakt en zo iets naar buiten openstelt is aanwezig.

Dit is hoe dit soort oplossingen meestal werken; je zult dus gebruikers iedere keer om een master password vragen dat je nooit en te nimmer aan jouw kant opslaat.

Wat is het nut van die server-wide key behalve wat extra obscurity?

[Hydra]

EddoH schreef op vrijdag 12 oktober 2018 @ 12:39:
Wat is het nut van die server-wide key behalve wat extra obscurity?

Dat je met alleen de user key intercepten (doormiddel van een keylogger ofzo) nog steeds niet al de passwords van een user hebt, tenzij je naast de data ook de server key hebt.

[Voor 7% gewijzigd door Hydra op 12-10-2018 13:03]

[EddoH]

Da's waar, maar je zult ook al toegang tot de DB moeten hebben, dan is die server key ook niet heel ver weg meer. Maar soit, ik snap het punt, mochten alleen de data records uitlekken is het een extra hurdle.

[Hydra]

EddoH schreef op vrijdag 12 oktober 2018 @ 13:06:
Da's waar, maar je zult ook al toegang tot de DB moeten hebben, dan is die server key ook niet heel ver weg meer. Maar soit, ik snap het punt, mochten alleen de data records uitlekken is het een extra hurdle.

Precies. Defence in depth, da's eigenlijk alles.

[Freeaqingme]

Hydra schreef op vrijdag 12 oktober 2018 @ 12:03:
Ga niet lopen hannesen met aparte processen enzo; die extra complexiteit is security by obscurity op z'n best, en de kans dat je daar een fuck-up maakt en zo iets naar buiten openstelt is aanwezig.

Sinds wanneer is Layered Security hetzelfde als Security by Obscurity? Doorgaans wordt Layered Security juist toegepast omdat mensen fouten maken. En als er dan een fout in de buitenste laag zit terwilj je maar 1 laag hebt, dan ben je gepwnd. Terwijl juist door meerdere lagen te gebruiken 1 gecompromiteerde applicatie of server niet direct betekent dat al je gegevens op straat liggen.