[PHP] Gevoelige data opslaan

[xilent_xage]

Hoi,

Even een korte situatieschets. Ik wil gevoelige data heel veilig opslaan. Daarbij zijn drie zaken belangrijk:

1. Integriteit: De data mag niet verloren gaan of worden gewijzigd. het is de bedoeling dat de data jarenlang wordt bewaard.
2. Vertrouwelijkheid: De data mag niet uitleesbaar zijn door anderen zonder toestemming.
3. Reproduceerbaarheid: De data moet uiteindelijk weer terug te halen zijn door (dezelfde of een andere gebruiker.

Nou snap ik dat 100% veilig niet bestaat. En dat je eigenljik dit soort data beter niet online kunt opslaan. Toch is dit in mijn situatie nodig.

Voor dit plan had ik het volgende model in gedachten:

Webserver met inlogsysteem over https waarmee gebruikers de data kunnen uploaden en downloaden. De webserver genereert een random key waarmee de data wordt versleuteld. Deze key wordt naar alle gebruikers gemaild/smsd, en daarna niet meer op de server opgeslagen.

Het versleutelde bestand wordt in stukjes van 100kb oid gehakt, en verdeeld over een aantal FTP-servers op verschillende lokaties. De inloggegevens van de andere server moeten bekend zijn bij de webserver helaas, hier heb ik nog geen mooie oplossing voor gevonden. De gegevens worden redundant opgeslagen. De gegevens over welk stukje waar staat + een checksum/hash staan in de database op de webserver. Ik check na de file transfers uiteraard de checksums om er zeker van te zijn dat ze overeenkomen.

Middels een cron check ik de versleutelde data periodiek met de checksum. Indien die afwijkt dan haal ik een van de 2 (3?) backupversies terug om de fout te repareren.

Als gebruikers bij hun data willen komen dan moeten ze de key invoeren waarna het bestand wordt gerecompiled (uiteraard na checken met checksum) en gedecrypt. Vervolgens wordt het onversleutelde bestand via https teruggestuurd naar de gebruiker.

Vragen so far:

• Graag jullie mening over dit ontwerp (qua veiligheid).
• Jammer dat als mensen hun code kwijtraken de data verloren gaat. Is hier nog wat op te bedenken? Bijv een cc naar mijn eigen email? of opslaan op een aparte server?
• Jammer dat de FTP gegevens op een of andere manier ook bij de webserver bekend moeten zijn. Is daar nog een truuk op te bedenken?

Alvast bedankt!

[chuxiej]

Ik kan niet veel zeggen over je concept maar ik wilde even reageren op het volgende:

Het versleutelde bestand wordt in stukjes van 100kb oid gehakt, en verdeeld over een aantal FTP-servers op verschillende lokaties. De inloggegevens van de andere server moeten bekend zijn bij de webserver helaas, hier heb ik nog geen mooie oplossing voor gevonden. De gegevens worden redundant opgeslagen. De gegevens over welk stukje waar staat + een checksum/hash staan in de database op de webserver. Ik check na de file transfers uiteraard de checksums om er zeker van te zijn dat ze overeenkomen.

Ik raad je hiervoor heel erg aan om naar Hadoop te kijken.
Hier heb ik zeer goede ervaringen mee over het redundant opslaan van "blocks" van grote files.
Het is zeer goed te configureren en ik denk perfect voor dit doeleinde.

[Ventieldopje]

Leuk, maar als je de keys via sms/email gaat versturen is je beveiliging al naar de knoppen lijkt me. Mobieltjes kunnen gejat/vergeten worden en een email server binnen het bedrijf is ook niet de veiligste plek (hoort wel veilig te zijn maar is het vaak niet). Bovendien heb je dan kans dat kwaadwillenden fishing mails gaan sturen om zo achter de keys te komen

[xilent_xage]

Ventieldopje schreef op vrijdag 06 mei 2011 @ 18:58:
Leuk, maar als je de keys via sms/email gaat versturen is je beveiliging al naar de knoppen lijkt me. Mobieltjes kunnen gejat/vergeten worden en een email server binnen het bedrijf is ook niet de veiligste plek (hoort wel veilig te zijn maar is het vaak niet). Bovendien heb je dan kans dat kwaadwillenden fishing mails gaan sturen om zo achter de keys te komen

klopt, maar mijn systeem gaat er juist vanuit dat geen enkel systeem an sich veilig is. Het idee is om de alle puzzelstukjes los op te slaan. Met een puzzelstukje heb je nog niks: Pas als je toegang hebt tot iemands mobiel/email EN de webserver EN meerdere ftp-servers dan heb je de data te pakken.

[Precision]

xilent_xage schreef op vrijdag 06 mei 2011 @ 19:20:
klopt, maar mijn systeem gaat er juist vanuit dat geen enkel systeem an sich veilig is. Het idee is om de alle puzzelstukjes los op te slaan. Met een puzzelstukje heb je nog niks: Pas als je toegang hebt tot iemands mobiel/email EN de webserver EN meerdere ftp-servers dan heb je de data te pakken.

Spreek je jezelf hier nu niet tegen? Zoals ik het lees kan je met die code de gegevens gaan downloaden. De gebruiker is sowieso een zwakke schakel in het geheel, maw als het zo veilig moet zijn zou ik ze niet mailen.
Tenzij je zelf afdwingt dat ze bvb via vpn moeten verbonden zijn en dat ze na 5 minuten inactiviteit automatisch uitgelogd worden. Hoe veiliger je het wilt maken hoe minder gebruiksvriendelijker het is, des te meer kans je maakt dat de gebruiker het gewoon op een post-it'tje schrijft en op zijn scherm/onder zijn toetsenbord hangt. Hoe meer stappen de gebruiker moet doorlopen, hoe zwakker de schakel de gebruiker wordt.

xilent_xage schreef op vrijdag 06 mei 2011 @ 18:11:
Als gebruikers bij hun data willen komen dan moeten ze de key invoeren waarna het bestand wordt gerecompiled (uiteraard na checken met checksum) en gedecrypt. Vervolgens wordt het onversleutelde bestand via https teruggestuurd naar de gebruiker.

Het verspreiden van de gegevens heeft toch weinig zin aangezien je in een databank opslaat waar welke gegevens staan en die moeten toch op een manier gelinkt zijn aan een gebruiker/bestand + je gebruikt encryptie op het bestand, dus met het puzzelstuk "het bestand" raken ze nog altijd niet veel verder. Ik zou een gebruiker eerder over https laten inloggen dan met usernaampje en een passwoordje die met salt en pepper is opgeslagen. Sla bijvoorbeeld het wachtwoord van het versleutelde bestand op (nog eens versleuteld, met opnieuw een salt en pepper via mcrypt zodat het terug te halen is) op. Als een gebruiker een bestand wil downloaden zou ik hem een eenmalige link sturen naar het bestand via e-mail en eventueel het wachtwoord nog eens via sms. Laat ze zeker het bestand downloaden met een wachtwoord op, als gebruikers het gaan doormailen naar elkaar dat het toch nog enigszins veilig is.

[ Voor 16% gewijzigd door Precision op 06-05-2011 19:41 ]

[T-MOB]

Wat een ingewikkeld gedoe met FTP-servers enzo. Dat gedeelte zou ik lekker weglaten, als je een degelijk encryptie-algoritme gebruikt dan kun je de bestanden gewoon in een database kwijt. Dan heb je "gratis" allerhande tools voor het behouden van integriteit, het maken van backups en het verzorgen van redundantie.

Het (unencrypyted) rondmailen van keys zou ik achterwege laten. Beter zet je dan iets van PGP in zodat alleen de ontvanger van het bericht het kan ontcijferen en niet iedereen die netwerkverkeer kan afluisteren...

Verder vraag ik me heel erg sterk af wat het nut is van het systeem. Iemand die het boeiend vind om belangrijke data veilig op te slaan kan gewoon een truecrypt-volume opslaan in zijn gMail-box om maar iets geks te noemen.

[Staatslot]

de zwakke schakel zit inderdaad in het versturen van die code naar de gebruiker.. met die code ben je al waar je wilt zijn. Je zou er nog een extra laag bij kunnen maken, door een unieke code per sms te versturen. Dan heeft iemand de gemailde code nodig en de unieke code per sms.. Helaas is het wel zo dat smartphones toegang hebben tot beide, dus heb je de smartphone heb je het bestand..

[FragFrog]

Staatslot schreef op vrijdag 06 mei 2011 @ 20:56:
de zwakke schakel zit inderdaad in het versturen van die code naar de gebruiker.. met die code ben je al waar je wilt zijn.

Niet helemaal natuurlijk: met die code ben je waar je wilt zijn voor die ene gebruiker. Als iemand je netwerk hacked en toegang krijgt tot de server voorkom je zo wel dat iemand alle data kan inzien *kuch*PSN*kuch*.

Totdat je natuurlijk weer een ander single-point-of-failure introduceert door bijvoorbeeld een kopie van alle gegenereerde codes naar jezelf te mailen

Overigens zie ik ook het extra nut van meerdere FTP servers niet in. Versleuteld is versleuteld, daar kan een hacker toch niet bij, en als dat wel kan is het net zo simpel om de webserver aan te vallen aangezien die toch hoe dan ook ervoor moet kunnen zorgen dat alle stukjes gecombineerd worden tot 1 (versleuteld) bestand.

Terzijde, gebruikers zijn altijd de zwakste schakel, ik lees niets in je plannen om te voorkomen dat iemand anders simpelweg het mailtje van iemands PC grijpt en een keylogger installeert en daarna overal bij kan. Juist daar zou ik me op concentreren: vereis een tokengenerator of ga bijvoorbeeld downloadcodes genereren die elke keer dat een bestand opgevraagd wordt verzonden worden via SMS.

[BeefHazard]

Modbreak:

Trollen wordt hier niet gewaardeerd.

[ Voor 67% gewijzigd door NMe op 06-05-2011 22:04 ]

[Emmeau]

waarom geen fileserver benaderbaar via VPN (met Radius)?

Ben je alle php/apache etc vulnerables al kwijt en qua beveiliging al een eind.

[xilent_xage]

Ok, aanvullende eis: het moet gebruiksvriendelijk zijn en volledig webbased. PGP en VPN zijn dus geen optie. En uiteraard zit er op de webserver ook nog eenuser/pass login systeempje met salting.

[Archiebald]

Je kunt de gebruikers hun 06 nummer van te voren laten invoeren (en laten bevestigen d.m.v. een smsje).
Bij het inloggen moet men dan een wachtwoord + code invullen (die ze op dat moment ontvangen op hun mobiel).

En dat versleutelen van bestanden dan. Maar je zou ook de bestanden in een directory zetten die niet in de web directory staan. En via een php script checken of iemand de rechten heeft voor dat bestand. Je kunt dat makkelijk doen met mod_rewrite.

[NMe]

Waar hoort mijn topic?

PRG>>SEA

[xilent_xage]

NMe schreef op vrijdag 06 mei 2011 @ 22:06:
Waar hoort mijn topic?

PRG>>SEA

excuus, helemaal gelijk

[xilent_xage]

Archiebald schreef op vrijdag 06 mei 2011 @ 22:05:
Je kunt de gebruikers hun 06 nummer van te voren laten invoeren (en laten bevestigen d.m.v. een smsje).
Bij het inloggen moet men dan een wachtwoord + code invullen (die ze op dat moment ontvangen op hun mobiel).

En dat versleutelen van bestanden dan. Maar je zou ook de bestanden in een directory zetten die niet in de web directory staan. En via een php script checken of iemand de rechten heeft voor dat bestand. Je kunt dat makkelijk doen met mod_rewrite.

"Bezwaar" tegen SMSen is dat het de bedoeling is dat de data 10,20,30 jaar bewaard blijft. Vriuj grote kans dat gebruikers tegen die tijd een ander 06-nummer hebben. En bovendien moet je dan het mobiele nummer van de gebruiker in je DB opslaan. Als iemand toegang krijgt tot je server ben je alsnog de pineut.

[Blorgg]

xilent_xage schreef op vrijdag 06 mei 2011 @ 22:05:
Ok, aanvullende eis: het moet gebruiksvriendelijk zijn en volledig webbased. PGP en VPN zijn dus geen optie. En uiteraard zit er op de webserver ook nog eenuser/pass login systeempje met salting.

Fortigate, en ook anderen als Juniper, hebben appliances waarmee je een VPN tunnel kunt opzetten via je browser. Je gaat dan naar de website van dat apparaat, logt in met username/password, installeert(eenmalig) de plug-in voor je browser en kunt verbinding maken.

Daarna kun je via de VPN tunnel bij de webserver met alle gevoelige data waar je met een ander username/password in moet loggen. Ik zou overigens wel overwegen om met een IP whitelist te werken voor de VPN server.

[Staatslot]

Nu toch wel erg nieuwsgierig, mag ik vragen om wat voor soort informatie het gaat?
Hoef geen details, uit je TS begrijp ik dat je die niet wilt geven, maar een indicatie kan misschien geen kwaad?

Wat je wilt wordt wel erg lastig, zeker omdat het 10, 20 of 30 jaar moet worden bewaard..
Dat lijkt me toch wel lastig met veel verschillende ftp-servers, dan moet je ook nog eens redundantie gaan inbouwen voor het uitvallen van meerdere ftp-servers. Sms'en mag ook niet, want na zoveel jaar veranderen mensen inderdaad van mobiele nummer. Maar de kans dat iemand na 30 jaar een code uit een mailtje weet te halen is ook niet bijster groot natuurlijk. Tenzij personen het op meerdere plekken gaan noteren, en dan heb je weer een zwakke plek in het systeem te pakken. Lastig...

[CAPSLOCK2000]

Data 30 jaar bewaren? Ik geloof dat je niet helemaal beseft wat je daar zegt, en hoop dat je een paar miljoen euro aan budget hebt....
Zet alles in pure ASCII tekst op een hardeschijf en leg dat ding in een brandkast. Dat is de enige betaalbare manier om data 30 jaar veilig te bewaren.
Zelf iets ingewikkelds in elkaar knutselen met meerdere internetservers en een eigen encryptie-systeem gaat het niet worden. Ik denk dat je nog eens goed moet nadenken over wat je precies nodig hebt (en hoeveel dat mag kosten). Als het echt veilig moet zijn moet je het gewoon niet zelf doen maar een expert inhuren.

[xilent_xage]

Blorgg schreef op vrijdag 06 mei 2011 @ 22:14:
[...]

Fortigate, en ook anderen als Juniper, hebben appliances waarmee je een VPN tunnel kunt opzetten via je browser. Je gaat dan naar de website van dat apparaat, logt in met username/password, installeert(eenmalig) de plug-in voor je browser en kunt verbinding maken.

Daarna kun je via de VPN tunnel bij de webserver met alle gevoelige data waar je met een ander username/password in moet loggen. Ik zou overigens wel overwegen om met een IP whitelist te werken voor de VPN server.

Plugin voor browser is al te gebruiks-onvriendelijk, om maar even de grenzen te bewaken
En een IP whitelist...tsjah... zie jij maar eens 30 jaar hetzelfde IP te houden...

[xilent_xage]

CAPSLOCK2000 schreef op vrijdag 06 mei 2011 @ 22:22:
Data 30 jaar bewaren? Ik geloof dat je niet helemaal beseft wat je daar zegt, en hoop dat je een paar miljoen euro aan budget hebt....
Zet alles in pure ASCII tekst op een hardeschijf en leg dat ding in een brandkast. Dat is de enige betaalbare manier om data 30 jaar veilig te bewaren.

Erm dat lijkt me helemaal niet zo veilig. Goeie kans dat na 30 jaar zo'n schijf gaar is.

[b][message=35989366,noline]
Zelf iets ingewikkelds in elkaar knutselen met meerdere internetservers en een eigen encryptie-systeem gaat het niet worden. Ik denk dat je nog eens goed moet nadenken over wat je precies nodig hebt (en hoeveel dat mag kosten).

Geen eigen encryptie systeem, gewoon een bestaand systeem, AES256 oid

[b][message=35989366,noline]
Als het echt veilig moet zijn moet je het gewoon niet zelf doen maar een expert inhuren.

Tsja zat er al op te wachten. Bij ieder topic over beveiliging is dit meestal het advies. Waarmee ik geenzins wil zeggen dat het onterecht is natuurlijk. De vraag is of wat ik wil zo ingewikkeld is. Eigenlijk leek mijn probleem me redelijk standaard (gevoelige data online opslaan), maar met googlen vond ik geen off-the-shelf-produkten...

[Blorgg]

En daar is een hele goede reden voor. Weet jij nog hoe je 15 jaar geleden op Internet bezig was? Hoe websites en webservices er toen uit zagen?

Mocht je het niet mee hebben gemaakt: het was een primitieve bende in vergelijking met tegenwoordig.

Als een whitelist bijhouden al te moeilijk is, dan hoef je hier niet eens over na te denken en moet je er gewoon niet aan beginnen. Je zult immers van tijd tot tijd je systeem moeten aanpassen op nieuwe ontwikkelingen. Denk bijvoorbeeld aan nieuwe browsers en besturingssystemen. Wellicht dat overheden in de toekomst gaan eisen dat dergelijke informatie voorzien moeten worden van nog zwaardere beveiliging, of dat de gekozen beveiliging te licht blijkt te zijn, of dat er beveiligingslekken naar voren komen.

Al met al zul je met een dergelijk systeem 30 jaar lang bezig blijven. Daar is helaas niets aan te doen. Tenzij je, zoals vermeld, het in een kluis legt.

[Voutloos]

Zelfs met een kluis heb je een grote kans dat je een keertje onderhoud moet plegen, al was het maar omdat je wellicht over 30 jaar geen ene fuck kan met een schijf met huidige connectoren. Maar dan nog zie ik dit als een kansrijkere aanpak dan de gemiddelde persoon/klein bedrijf die even wat slims wilt bedenken.
[/skeptisch]

Je bent er nog niet aan toe om het over 30 jaar in de toekomst te hebben, richt je maar eerst op het heden. Is een stuk concreter ook, want zover vooruit voorspellen gaat niemand lukken. Mocht je dat wel kunnen kan je daar schandalig veel meer mee verdienen dan met je huidige idee.

Verklaar eens waarom je het over meedere locaties wilt delen? Is dat ivm redundantie? Wil je niet dat 1 partij alle blokjes heeft? Wat geeft de master server het recht om wel alle delen op te halen? Hoe redundant is die master server dan? Hoe snel moet data beschikbaar zijn? Heb je een leuke SLA voor je klanten? Wil je een verzekering bieden tegen data theft? Etc. etc.

[YopY]

Ik zou zeker niet beginnen met een eigen 'distributed filesystem' via een vage FTP-server constructie, dan mag je zelf al die redundantie, synchronisatie en consistentiezooi bouwen, en dan is het nog maar zeer de vraag of het ook maar iets toevoegt aan je beveiliging. Gebruik dan, zoals anderen suggereerden, een bestaand systeem zoals Hadoop of welk virtueel filesystem er maar is (ook al garandeer je daarmee niet dat de zaak in stukjes gehakt en 'verspreid' wordt, maar dat lijkt me geen goeie manier om zoiets te doen).

En ook zoals anderen opgemerkt hebben: 30 jaar redundantie en zulke (blijkbaar) hoge veiligheidseisen lijkt me sterk dat zoiets aan 1 persoon overgelaten wordt die, blijkens uit dit topic, ook geen ervaring met zulke eisen heeft. Als het écht zo belangrijk is voor je opdrachtgever, dan zou hij wel een bedrijf ingehuurd hebben, of tenminste een beveiligingsconsultant.

30 jaar redundantie moet je kijken naar backupsystemen en/of redundante disk arrays (en ook natuurlijk redundantie op een of meerdere externe locaties, backupstrategieën, etc). Daarbovenop mag je vervolgens de rest van je systeem bouwen.

Hoe dan ook, niet iets waar je zomaar één persoon de opdracht voor geeft, aangezien je alleen al voor het opslagverhaal een IT-expert annex ervaren systeembeheerder nodig hebt, voor het 30-jaar-redundantieverhaal ook een menneke, en voor het beveiligingsverhaal een beveiligingsexpert die (bijvoorbeeld) militaire gegevens of bedrijfsgeheimen van grote bedrijven heeft beveiligd (uitgaande van de hoogste beveiligingsgraad).

In de praktijk zal HTTPS en encryptie voor de meeste gevallen afdoende zijn. Ik bedoel, een bestand met 256 of voor hetzelfde 1024-bits versleuteling zul je, tenzij je het wachtwoord hebt, niet snel kraken.

Je zou er op zich van uit moeten gaan dat iemand volledige toegang heeft tot je server en zijn bestanden. Daar zou je je beveiliging op moeten baseren. Ook met dat 'distributed' verhaal van je - immers, er is één frontend die in jouw idee de gegevens van al die FTP-servers afhaalt, dus dat is je zwakke punt bij dat verhaal.

[xilent_xage]

Akkoord, ben er wel van overtuigd dat een eigen distriibutiesysteem op de lange termijn onhandig is. Dat betekent: Bestanden op de server zelf encrypten en opslaan. Ik heb daarbij een lichte voorkeur voor losse bestanden omdat dat iets makkelijker is qua backup en evt losse file transfers. Maar dat terzijde.

Wil overigens ook geenszins beweren dat ik dit helemaal in mijn eentje ga oppakken, maar ik probeer wel vooraf een overzicht te krijgen van de mogelijkheden die er zijn en de problemen die ik kan verwachten.

Eentje waar ik vannacht na lang piekeren over uit was: Het naar de gebruiker toesturen van de encryption key is niet the way to go. Niet alleen vanwege het gevaar van diefstal, maar ook is de kans dat een gebruiker in die 30 jaar zijn key kwijtraakt gewoon veel te groot. De key moet dus ook ergens online worden bewaard. Maar waar?

Overigens is bij nader inzien die genoemde 30 jaar misschien ook wat overdreven. Laten we even uitgaan van een termijn van 5 jaar.

[FragFrog]

xilent_xage schreef op zaterdag 07 mei 2011 @ 13:05:
De key moet dus ook ergens online worden bewaard. Maar waar?

Je zou de encryption key kunnen salten met het wachtwoord van de gebruiker. Deze mag bekend worden geacht (anders kan de gebruiker ook niet inloggen), vervolgens kun je de rest van de seed gewoon opslaan. Eventueel een aparte authenticatieservice voor opzetten op een losse server die verder potdicht zit.

Een nadeel is uiteraard dat iemand niet zomaar zijn wachtwoord kan veranderen zonder zijn keys te invalidaten, niet helemaal ideaal. Daarnaast kan iemand met volledige controle over de webserver alsnog de requests onderscheppen, maar daar ontkom je hoe dan ook niet aan. Met alleen de database zelf begint een aanvaller in elk geval weinig.

Periodiek een hardcopy lijst met keys opsturen naar je users is geen optie? Beetje degelijk papier en het gaat zo tien jaar mee Dan leg je uiteraard wel een deel van de beveiliging in handen van je gebruikers (als ze de keylist laten rondslingeren kan een hacker met een keylogger alsnog bij je data) maar bij een worst-case scenario is dan hooguit de data van 1 gebruiker openbaar. Plus je moet fysiek toegang hebben tot de locatie van de gebruiker, ook niet altijd even simpel

[ Voor 22% gewijzigd door FragFrog op 07-05-2011 14:09 ]

[xos]

Het beste zou zijn om de key niet op te hoeven slaan. Je kunt deze afleiden van een stukje data wat alleen een gebruiker weet, bijvoorbeeld een wachtwoord. Er zijn hier diverse algoritmes voor zoals PBKDF2. Dat betekent wel dat als een gebruiker dit stukje data wil veranderen alle data eerst ontsleuteld moet worden en opnieuw versleuteld moet worden met de nieuwe key. Of je moet een soort van keychain opbouwen waarbij de vorige key wordt versleuteld met de nieuwe key die afgeleid is van het laatst gekozen wachtwoord. Eventueel kan je de afgeleide key met een asymetrisch algoritme versleuteld opslaan waarbij je zelf het private deel in beheer hebt. Hierdoor kan je als een gebruiker haar wachtwoord vergeten is de data alsnog terughalen. Of je kunt een upgrade doen naar een ander encryptie algoritme omdat je zelf in staat bent de originele data altijd weer terug te halen. Op deze manier hoef je maar 1 sleutel veilig te stellen wat makkelijker is dan voor iedere gebruiker een losse sleutel.

Omdat je van plan bent om data versleuteld op te slaan is storage as a service misschien een optie. Zolang je data alleen in versleutelde vorm die kant op stuurt en het ontsleutelen ook weer lokaal doet zijn veel security gerelareerde problemen van een cloud niet of minder van toepassing.

Verder is de implementatie erg belangrijk en niet te onderschatten moeilijk. Je noemt bijvoorbeeld AES256, waarschijnlijk omdat dit een bekend algoritme is. AES is een tradeoff tussen snelheid en sterkte. Als je doel is om data voor langere tijd op te slaan en deze niet al te vaak weer wilt ontsleutelen dan is een algoritme als serpent ook interessant. Dit is een wat conservatiever algoritme met een grotere "security margin" dan AES maar vergt ook meer hardware resources. Of je verhoogd het aantal rounds van AES natuurlijk. Al met al zijn er veel keuzes te maken, niet alleen op conceptueel niveau maar ook op implementatie niveau. Zeker dit laatste gaat nog vaak fout zoals blackbarry recent nog heeft gedemonstreerd.

Periodiek een hardcopy lijst met keys opsturen naar je users is geen optie? Beetje degelijk papier en het gaat zo tien jaar mee Dan leg je uiteraard wel een deel van de beveiliging in handen van je gebruikers (als ze de keylist laten rondslingeren kan een hacker met een keylogger alsnog bij je data) maar bij een worst-case scenario is dan hooguit de data van 1 gebruiker openbaar. Plus je moet fysiek toegang hebben tot de locatie van de gebruiker, ook niet altijd even simpel

Als een hacker het lukt om een keylogger te installeren dan kan aangenomen worden dat deze hacker ook bij het lokale filesysteem kan. Dan kan gedownloade informatie ook ingezien worden, of opnieuw versleuteld te worden als een vorm van digitale kipnapping...

[FragFrog]

xos schreef op zaterdag 07 mei 2011 @ 23:06:
Als een hacker het lukt om een keylogger te installeren dan kan aangenomen worden dat deze hacker ook bij het lokale filesysteem kan. Dan kan gedownloade informatie ook ingezien worden, of opnieuw versleuteld te worden als een vorm van digitale kipnapping...

Digitale kidnapping zal geen groot probleem zijn aangezien de data altijd nog opnieuw van de server gehaald kan worden in onversleutelde vorm. Juist daarom zijn individuele keys per bestand nuttig: als een hacker dit inderdaad voor elkaar krijgt en je komt erachter kun je je PC weer opschonen. Vervolgens kan de hacker enkel bij die bestanden die je gedurende de periode dat je PC geinfecteerd was hebt opgevraagd. Een alternatief hiervoor is een systeem van TAN codes zoals bijvoorbeeld de Postbank / ING gebruikt, maar dan moet je wel de sleutel ook online bewaren.

Ik denk dat in geval van een virus / trojan de schade beperken realistischer is dan voorkomen, of je moet al een complete PC scan bij inloggen forceren zoals bijvoorbeeld MS doet bij zijn digitale werkplekken.

[Remus]

YopY schreef op vrijdag 06 mei 2011 @ 23:40:
In de praktijk zal HTTPS en encryptie voor de meeste gevallen afdoende zijn. Ik bedoel, een bestand met 256 of voor hetzelfde 1024-bits versleuteling zul je, tenzij je het wachtwoord hebt, niet snel kraken.

Nu misschien, maar over 30 jaar? 15 a 20 jaar geleden werd nog gedacht dat single-DES met een 56 bits key voldoende veilig was. Nu is dat niet sterk genoeg meer. Als je data over een periode van 30 jaar wilt opslaan dan moet je bijvoorbeeld met enige regelmaat de encryptie versterken, maar daarmee ondervang je echter niet iemand die voor die tijd de handen op jouw data legt en wel een paar jaar de tijd heeft om het te kraken, of kan wachten op techniek/capaciteit om de data sneller te kraken. Of je moet nu een zeer sterke encryptie kiezen en hopen dat dat over een periode van 30 jaar niet kraakbaar is (wat niet goed te voorspellen valt).

[xilent_xage]

FragFrog schreef op zaterdag 07 mei 2011 @ 14:06:
[...]

Je zou de encryption key kunnen salten met het wachtwoord van de gebruiker. Deze mag bekend worden geacht (anders kan de gebruiker ook niet inloggen), vervolgens kun je de rest van de seed gewoon opslaan. Eventueel een aparte authenticatieservice voor opzetten op een losse server die verder potdicht zit.

Een nadeel is uiteraard dat iemand niet zomaar zijn wachtwoord kan veranderen zonder zijn keys te invalidaten, niet helemaal ideaal. Daarnaast kan iemand met volledige controle over de webserver alsnog de requests onderscheppen, maar daar ontkom je hoe dan ook niet aan. Met alleen de database zelf begint een aanvaller in elk geval weinig.

Het is de bedoeling dat andere geautoriseerde gebruikers ook toegang krijgen tot het bestand.

[YopY]

Remus schreef op zondag 08 mei 2011 @ 09:31:
[...]


Nu misschien, maar over 30 jaar? 15 a 20 jaar geleden werd nog gedacht dat single-DES met een 56 bits key voldoende veilig was. Nu is dat niet sterk genoeg meer. Als je data over een periode van 30 jaar wilt opslaan dan moet je bijvoorbeeld met enige regelmaat de encryptie versterken, maar daarmee ondervang je echter niet iemand die voor die tijd de handen op jouw data legt en wel een paar jaar de tijd heeft om het te kraken, of kan wachten op techniek/capaciteit om de data sneller te kraken. Of je moet nu een zeer sterke encryptie kiezen en hopen dat dat over een periode van 30 jaar niet kraakbaar is (wat niet goed te voorspellen valt).

Goed punt. SHA is een encryptiealgoritme dat door de Amerikaanse NSA gebruikt wordt. Daar hebben ze ook door dat computers met de tijd sneller worden. Daar stappen ze over naar SHA-2 en 3 nog voordat de voorgaande gekraakt begint te worden.

Het systeem moet dus ook om de paar jaar voorzien kunnen worden van een nieuwe encryptietechniek. Dat kan lastig worden - je kunt moeilijk alle bestaande bestanden decrypten (sterker nog, dat kan helemaal niet als je beveiliging goed is), danwel bestaande bestanden opnieuw encrypten met een nieuwer algoritme. Ik vraag me af hoe andere partijen hiermee omgaan.

Het is de bedoeling dat andere geautoriseerde gebruikers ook toegang krijgen tot het bestand.

Interresant. Een wachtwoord delen is dus geen optie. Je zou dan kunnen gaan werken met een 'box' met bestanden waar mensen op in kunnen loggen, die op zijn beurt de encryptiesleutel (of een deel daarvan) bevat. Ik zou zo niet weten of er uberhaupt een encryptiesysteem bestaat dat meerdere passkeys ondersteunt.

Misschien kun je het volgende doen. Door middel van een lokaal encryptieprogramma of -apparaat (denk Random Reader van de Rabo) kan de gebruiker een eenmalige toegangssleutel genereren voor de bestanden. De gebruiker logt eerst in op de web-interface, en krijgt daar een code voorgeschoteld die ingevuld moet worden op het lokale apparaat / stukje software. Die genereert vervolgens een 'response' code, die ingevuld kan worden op de site om toegang te krijgen tot de uiteindelijke bestanden.

Dat is natuurlijk wel gebaseerd op een algoritme dat aan beide kanten werkt, danwel gegevens die alleen in de software aan beide kanten bekend zijn.

Hoe dan ook, beveiliging op basis van alleen een username en password is niet afdoende in dit geval.

[Voutloos]

xilent_xage schreef op zondag 08 mei 2011 @ 10:42:
[...]
Het is de bedoeling dat andere geautoriseerde gebruikers ook toegang krijgen tot het bestand.

Hopakee, nog een extra eis erbij. En meteen een voorspelbare (aka: mag je ook zelf direct toelichten hoor... ) vraag: Mogen derden dan diezelfde secrets te zien krijgen?

Al met al noem je een hoop eisen, waarvan een aantal met elkaar botst. Alle requirements halen gaat je niet lukken, dus tijd om te bepalen welke eisen het belangrijkste zijn en een trade-off te kiezen. Daarvoor mag je alleen even zelf de moeite doen om de diverse eisen/wensen die nu in het topic zijn op te sommen.

[Verwijderd]

YopY schreef op zondag 08 mei 2011 @ 10:58:
[...]
Goed punt. SHA is een encryptiealgoritme dat door de Amerikaanse NSA gebruikt wordt.

offtopic:
SHA is overigens geen encryptie algoritme maar een cryptografische hashing algoritme. Encryptie is omkeerbaar als je de juiste sleutels kent terwijl hashing per definitie onomkeerbaar is (of dat dient te zijn).

[xilent_xage]

Voutloos schreef op zondag 08 mei 2011 @ 11:08:
[...]
Hopakee, nog een extra eis erbij. En meteen een voorspelbare (aka: mag je ook zelf direct toelichten hoor... ) vraag: Mogen derden dan diezelfde secrets te zien krijgen?

Al met al noem je een hoop eisen, waarvan een aantal met elkaar botst. Alle requirements halen gaat je niet lukken, dus tijd om te bepalen welke eisen het belangrijkste zijn en een trade-off te kiezen. Daarvoor mag je alleen even zelf de moeite doen om de diverse eisen/wensen die nu in het topic zijn op te sommen.

Neehoor, stond ook al vermeld in de opening (eis nr 3). Maar misschien maak ik het iedereen incl mezelf makkelijker als ik het achterliggende idee iets meer uit de doeken doe. Het gaat hier om een soort 'digitale kluis' waarin geheime info (denk aan testament, verzekeringspapieren maar wellicht ook persoonlijke boodschappen aan anderen) gelegd kan worden die na een bepaalde tijd of bepaalde gebeurtenissen (bijv overlijden) wordt opengesteld voor derden. Tot die tijd is de inhoud van de kluis alleen toegankelijk voor de eigenaar van de data. De eigenaar kan zelf bepalen na hoeveel tijd (of bij welke gebeurtenissen) de inhoud van de kluis wordt vrijgegeven en aan wie.

[xilent_xage]

Overigens veel dank voor alle feedback - ben het model al danig aan het bijschaven. Ik hink nu op het volgende been:

Via https kunnen gebruikers inloggen (username/password). Het wachtwoord van een gebruiker wordt als MD5 in de database bewaard. Voor elk bestand wordt een random key gegenereerd, waarmee het bestand versleuteld wordt opgeslagen. Een key wordt per bestand, per gebruiker die daar toegang toe heeft versleuteld opgeslagen. Als key voor het versleutelen van de key wordt het wachtwoord van de betreffende gebruiker gebruikt. Deze key is nergens opgeslagen, alleen een MD5 hash ervan.

Misschien om rainbow tables tegen te gaan moet het wachtwoord verlengd worden. Of ik gebruik idd iets PBKDF-erigs.

Schiet maar

[johnkeates]

Er zijn met deze situatie sowieso al dingen waar je ook niet omheen kan... bijvoorbeeld het probleem met closed source software; als je over 30 jaar een programma wil gebruiken kan je er de donder op zeggen dat het niet gaat werken. Als je dan over de broncode beschikt kan je tenminste zelf nog een oplossing regelen, met een closed source programma niet. Servicecontracten zijn leuk, maar probeer bijvoorbeeld vandaag maar eens iets te regelen voor een programma van 30 jaar oud

Dan heb je voor lokale beveiliging iets nodig als LUKS, niet LUKS per se, maar een systeem waarbij de encryptie en de keys en de user keys dus los van elkaar staan. Dan kan je veilige encryptie toepassen met meerdere keys. Een master key bewaar je dan in stukjes op meerdere locaties (en die key maak je voor het gemak bijvoorbeeld ook iets van 128MB lang (JA, LANG dus! ) zodat er over 30 jaar ook nog geen computer is die hem instant kan kraken. Gebruik bijvoorbeeld RSA met die sleutel (of nog beter: Elliptic curve cryptography), dan wordt brute-forcen ook een zeer trage taak.

Ga bijvoorbeeld ook na tot welke garantie de informatie veilig moet blijven en hoe lang. Stel dat je het met een paar miljoen klaar moet hebben, dan kunnen de opdrachtgevers niet verwachten dat het over 15 jaar nog even veilig is als vandaag Maar kijk ook naar de impact, als de data over 15 jaar naar buiten komt, is de informatie dan nog relevant?

Maar om nog verder te gaan met lokale cryptografie; ga niet binnen een software pakket zitten, maar gebruik gewoon wat je normaal gebruikt, maar dan in een compleet beveiligde omgeving. Stel dat je geen windows gebruikt, dan kan je dus het hele OS in complete encryptie draaien. Daarmee bedoel ik dan dat het hele systeem (muv CPU cache en RAM) dus allen maar scrabled data bevat. Om dan te zorgen dat een cold attack de keys niet beschikbaar maakt zou je op grote fysieke afstand twee servers kunnen gebruiken, een met alleen een iSCSI target en de ander met alleen een key om te booten. Mocht de iSCSI server genaaid worden, dan heeft de inbreker er niks aan. Mocht de keyserver genaaid worden, dan kan je gewoon de iSCSI server uitzetten. Dan is het natuurlijk van belang dat de fysieke beveiliging goed is, om dat je wel moet weten dat er ingebroken wordt.

Mocht het voorkomen dat de keyserver dood gaat, dan invalidate je z'n key en kan die key niet meer gebruikt worden om de iSCSI target de decrypten.

Ik neem als voorbeeld LUKS om dat je dan de data op de schijf met een stevige symmetrische key encrypt, maar die key zelf niet gebruikt, maar weer asymmetrisch encrypt met een ander algoritme. Dat kan je dan meer meerdere malen doen zodat je meerdere asymmetrische sleutels hebt om dezelfde symmetrische key te krijgen om daarmee het bestandssysteem te kunnen lezen/schrijven. Je kan ook een boot disk nemen met een key die dus door de server met de publieke interface gebruikt wordt, en dan meerdere iSCSI targets of disk images on file met weer losse keys. Dan kan je op elke image een master key, een backup key en een user key zetten bijvoorbeeld. Dan kan je user keys zonder verlies van data intrekken, de master key vernietigen als iemand een van de locaties waar een deel van de master key opgeslagen is (fysiek) benaderd heeft, en een backup key bijvoorbeeld verdelen over 15 personen die ze altijd bij zich moeten hebben.

Dit is allemaal natuurlijk niet erg snel, want iSCSI zal je dan via internet moeten laten lopen, wat niet erg snel is (als je niet te veel geld wil uitgeven).

Edit:

Je kan beter gewoon helemaal geen MD5 gebruiken. Dat hashing algoritme wordt constant aangevallen en het is gewoon een kwestie van tijd tot het irrelevant is. SHA265 is wat beter, maar je zou ook met mcrypt gewoon alles met triple-DES en een hele lange key kunnen scrambelen. Nu is DES ook niet een van de sterkste, maar wel erg snel in vergelijking met RSA. Plus, DES (net als RSA) zijn niet one-way, dus dat is misschien ook een factor. Je zou kunnen kijken naar certificate-based authentication. Dan zorg je er voor dat de certificaat data ruw op een USB stick staat en een applet die uitleest. Dat is natuurlijk niet waterdicht (cert komt altijd langs 't RAM en anders ook wel in een cache terecht), maar beter dan keyloggable gebruikers invoer.

[ Voor 9% gewijzigd door johnkeates op 08-05-2011 14:01 . Reden: MD5 toevoeging ]

[xilent_xage]

johnkeates schreef op zondag 08 mei 2011 @ 13:41:
...veel leerzame info....

Je kan beter gewoon helemaal geen MD5 gebruiken. Dat hashing algoritme wordt constant aangevallen en het is gewoon een kwestie van tijd tot het irrelevant is. SHA265 is wat beter, maar je zou ook met mcrypt gewoon alles met triple-DES en een hele lange key kunnen scrambelen. Nu is DES ook niet een van de sterkste, maar wel erg snel in vergelijking met RSA. Plus, DES (net als RSA) zijn niet one-way, dus dat is misschien ook een factor. Je zou kunnen kijken naar certificate-based authentication. Dan zorg je er voor dat de certificaat data ruw op een USB stick staat en een applet die uitleest. Dat is natuurlijk niet waterdicht (cert komt altijd langs 't RAM en anders ook wel in een cache terecht), maar beter dan keyloggable gebruikers invoer.

In mijn opzet zou een one-way hash wel een voordeel hebben, nl dat de key voor de data niet op de server aanwezig is en ook niet reproduceerbaar is. Zelfs als je met MD5 een collision zou vinden heb je goeie kans dat dit niet de juiste key voor decryptie oplevert.

[Equator]

johnkeates schreef op zondag 08 mei 2011 @ 13:41:
Je kan beter gewoon helemaal geen MD5 gebruiken. Dat hashing algoritme wordt constant aangevallen en het is gewoon een kwestie van tijd tot het irrelevant is. SHA265 is wat beter, maar je zou ook met mcrypt gewoon alles met triple-DES en een hele lange key kunnen scrambelen. Nu is DES ook niet een van de sterkste, maar wel erg snel in vergelijking met RSA. Plus, DES (net als RSA) zijn niet one-way, dus dat is misschien ook een factor.

Ho, stop. Jij vergelijkt hier een symmetrisch encryption algoritme met een assymmetrisch algoritme.

RSA/DSA/DH zijn assymetrische algoritmes (een sleutelpaar waarvan de eerste sleutel gebruikt wordt voor versleuteling en de andere voor ontsleuteling) welke in principe gebruikt worden voor één doel: Het veilig uitwisselen van sleutelmateriaal.
ECC (Eliptic Curve Crypto.) doet hetzelfde als bovenstaande en is dus ook een assymetrisch algoritme. Echter biedt ECC met een veel kleinere sleutellengte vergelijkbaar veel veiligheid als RSA met een langere sleutellengte.
ECC-128 vs. RSA-3072 (bron: Wikipedia: Elliptic curve cryptography )
En hoe kleiner de sleutellengte, hoe sneller het algoritme

DES/3-DES/AES/CAST/BlowFish/RC4/RC5 zijn symmetrische algoritmes (1 sleutel wordt gebruikt voor versleutelen en ontsleutelen) welke gebruikt worden voor het versleutelen van datablokken. (Oke, de laatste 2 zijn streamingcyphers en geen blockcyphers).

Een symmetrisch algoritme is zo maar een factor 1000 sneller met het versleutelen van een stukje data, dan een assymmetrisch algoritme. RSA/DSA/Diffie-Helman gebruik je dus niet voor het versleutelen van grote hoeveelheden text/data.

Voor het veilig opslaan van wachtwoorden gebruik je geen MD5 meer. Dat hashing-algoritme is bewezen dat er zoveel hashing collisions optreden (of zelfs zijn te forceren) dat het niet meer veilig is voor wachtwoord opslag (of opslag van wat dan ook). Ook SHA-1 (SHA-160) zou ik niet meer gebruiken, al zegt NIST dat het nog 'veilig' zou zijn. Gebruik SHA-256 of SHA-384 inclusief een salt (geheime toevoeging aan het te hashen wachtwoord waardoor een rainbow-tabel geen waarde meer heeft) voor het opslaan van een wachtwoord. SHA-512 heeft geen toegevoegde waarde ten opzichte van SHA-384. RIPE-MD kan ook, maar wordt weinig gebruikt, en staat ook niet op de lijst met veilige hashing algoritmes van NIST.

[ Voor 9% gewijzigd door Equator op 09-05-2011 13:49 ]

[mace]

xilent_xage schreef op vrijdag 06 mei 2011 @ 18:11:
• Jammer dat als mensen hun code kwijtraken de data verloren gaat. Is hier nog wat op te bedenken? Bijv een cc naar mijn eigen email? of opslaan op een aparte server?

CC naar je eigen mail is onveilig, alle keys op 1 plek? Nee slecht idee. Opslaan op een aparte server is ook niet handig.

Beter encrypt je alles met een ADK en die sla je dan ergens heel veilig op (op papier in een kluis bijv). Je kan hem ook nog in 3 stukken hakken en aan 3 verschillende mensen geven zodat nooit 1 persoon in z'n uppie iets kan decrypten. Maar dat hangt af van hoe ver je wilt gaan.

edit: Dan moet je er wel voor zorgen dat je een public/private keypair gebruikt want als je gewoon een plain decryption key gebruikt dan ben je de sjaak als ze de server hacken en de key achterhalen. Als je alleen de public key hebt op de server kunnen ze niks. De private key ligt dan veilig in de kluis.

Dit is te realiseren met gnupg.


( EnJa ik heb deze ideeën van PGP )

[ Voor 21% gewijzigd door mace op 09-05-2011 13:54 ]

[xilent_xage]

mace schreef op maandag 09 mei 2011 @ 13:51:
[...]
De private key ligt dan veilig in de kluis.

maar dat betekent wel dat er een fysieke actie nodig is om de boel te decrypten. Dat is hier geen optie. De bewaarde data moet ten alle tijden via web door de eigenaar van de kluis in te zien zijn. En bij vrijgeven na bijv overlijden aan de nabestaanden. Zonder dat ik daarvoor een papiertje uit een kluis moet halen.

[alwinuzz]

xilent_xage schreef op zondag 08 mei 2011 @ 13:16:
[...]
Maar misschien maak ik het iedereen incl mezelf makkelijker als ik het achterliggende idee iets meer uit de doeken doe. Het gaat hier om een soort 'digitale kluis' waarin geheime info (denk aan testament, verzekeringspapieren maar wellicht ook persoonlijke boodschappen aan anderen) gelegd kan worden die na een bepaalde tijd of bepaalde gebeurtenissen (bijv overlijden) wordt opengesteld voor derden. Tot die tijd is de inhoud van de kluis alleen toegankelijk voor de eigenaar van de data. De eigenaar kan zelf bepalen na hoeveel tijd (of bij welke gebeurtenissen) de inhoud van de kluis wordt vrijgegeven en aan wie.

Je moet denk ik een afweging maken tussen veiligheid en flexibiliteit.

Het veiligst lijkt me om alles op papier te hebben en dan af te geven bij een kluis gehuurd bij de bank. Maar dit is ook het minst flexibel.

Bij digitale bestanden kan je ook een met TrueCrypt beveiligd bestand op USB stick en harde schijf zetten, en dat samen met de passphrase naar de kluis brengen.

Als je een 'digitale kluis' probeert te maken, zou je heel veel moeite moeten steken in adequate beveiliging. Dit is een specialisme op zich en vandaar ook het advies 'zoek een expert'. Een idee als "Jammer dat als mensen hun code kwijtraken de data verloren gaat. Is hier nog wat op te bedenken? Bijv een cc naar mijn eigen email?" getuigt niet echt van expertise. Wat doe je als jouw email wordt gehackt?

Maar hoe goed je systeem ook is beveiligd, je kan niet om de gebruiker heen. Er kan een virus/trojan/keylogger op de computer van de gebruiker zitten. De gebruiker kan draadloos wifi gebruiken dat gehackt is. Of de gebruiker wil een backup van z'n bestanden en kopieert even alles naar een mapje 'Mijn documenten/backup digitale notaris/'. Bij een perfect beveiligd systeem is de gebruiker de zwakste schakel.

[Rinzler]

xilent_xage schreef op zaterdag 07 mei 2011 @ 13:05:
Overigens is bij nader inzien die genoemde 30 jaar misschien ook wat overdreven. Laten we even uitgaan van een termijn van 5 jaar.

5 jaar is al wat realistisch Ik kan me moeilijk inbeelden wat voor data na 30 jaar nog iets van nut/bruikbaarheid heeft (behalve mss statische data van over de jaren heen). De kans is groot dat je zelfs na 10 jaar al zegt: "Aah juist, datte"

Als je het echt veilig wil houden, zul je de software ook regelmatig moeten onderhouden. (updaten/upgraden naar nieuwe versie..). Onderschat dat niet

Gebruikers zullen altijd op de een of andere manier hun passwoord verliezen, voorzie een optie waarmee ze een nieuw passwoord kunnen krijgen. Desnoods enkel via jou of iets dergelijk. In ieder geval, het maakt ni echt veel uit hoe hard je je beveiling gaat uitdokteren als 1 van de gebruikers hun computers waarmee ze op jou webapp zitten niet goed beveiligen (iedereen kent wel de typische leek-computer vol met trojans e.d.)...

De grootste secuirity-tip: laat niet eender welke gebruiker toe

[mace]

xilent_xage schreef op maandag 09 mei 2011 @ 14:17:
[...]


maar dat betekent wel dat er een fysieke actie nodig is om de boel te decrypten. Dat is hier geen optie. De bewaarde data moet ten alle tijden via web door de eigenaar van de kluis in te zien zijn. En bij vrijgeven na bijv overlijden aan de nabestaanden. Zonder dat ik daarvoor een papiertje uit een kluis moet halen.

Ja maar die ADK wordt dus alleen gebruikt in noodgevallen. Hoe vaak zal het voorkomen?

Tevens raad ik je sowieso aan om met PGP/GPG te werken met public/private keys, aangezien je dan dingen specifiek voor bepaalde mensen kan encrypten, en dan hoeven de gebruikers maar één key te bewaren. En als je server gehackt wordt kunnen de hackers niks decrypten omdat je de private keys niet op de server bewaart.

[Remus]

Equator schreef op maandag 09 mei 2011 @ 13:41:
Gebruik SHA-256 of SHA-384 inclusief een salt (geheime toevoeging aan het te hashen wachtwoord waardoor een rainbow-tabel geen waarde meer heeft) voor het opslaan van een wachtwoord.

offtopic:
Een salt hoeft helemaal niet geheim te zijn, zo lang hij maar per gebruiker anders is.

[NMe]

Remus schreef op maandag 09 mei 2011 @ 18:01:
[...]

offtopic:
Een salt hoeft helemaal niet geheim te zijn, zo lang hij maar per gebruiker anders is.

Als je salt bekend is bij de would-be hacker kan hij anders gewoon een nieuwe rainbow table genereren voor die specifieke gebruiker en die vervolgens tegen het gehashte wachtwoord aan houden. Dat is nog steeds tijdrovend maar maakt een hack wel een stuk makkelijker. Natuurlijk is het enige moment waarop zowel de hash als de salt bij de hacker bekend worden doorgaans het moment waarop hij de hele database in handen heeft, maar alsnog zou ik de salt gewoon niet weergeven en dus effectief "geheim" houden.

[mace]

NMe schreef op maandag 09 mei 2011 @ 18:13:
[...]

Als je salt bekend is bij de would-be hacker kan hij anders gewoon een nieuwe rainbow table genereren voor die specifieke gebruiker en die vervolgens tegen het gehashte wachtwoord aan houden. Dat is nog steeds tijdrovend maar maakt een hack wel een stuk makkelijker. Natuurlijk is het enige moment waarop zowel de hash als de salt bij de hacker bekend worden doorgaans het moment waarop hij de hele database in handen heeft, maar alsnog zou ik de salt gewoon niet weergeven en dus effectief "geheim" houden.

Rainbow table genereren?

Kan je net zo goed meteen bruteforcen want je doet hetzelfde.....

[KopjeThee]

Kan je voor een digitale kluis de kunst niet afkijken van banken, en hoe die met telebankieren omgaan? Daar spelen precies dezelfde problemen, lijkt me.

[ReenL]

Vergeet alsjeblieft je idee om keys te hashen en alles wat daarbij in de buurt komt, dit gaat simpelweg niet werken.

Met RSA ben je op de goede weg en de gedachtegang van het niet hebben van een sleutel is opzich niet verkeerd, maar als je de sleutel zelf niet hebt, moet de gebruiker hem zelf hebben. Deze moet je natuurlijk dan niet distribueren over een onveilig netwerk (lees mail en sms), maar gewoon over HTTPS.

Over beveiliging in de toekomst kun je trouwens nog weinig zeggen, behalve dat je applicatie om de 2/3 jaar een forse upgrade/migratie zou moeten krijgen. Punt is dat je alleen gefaseerd kan migreren als je de sleutels alleen aan de gebruiker zelf geeft. Ook een wachtwoord vergeten functie valt niet onder de mogeljikheden.

Wat je echter wel kan doen is je applicatie opdelen in een DMZ en een MZ. Hierbij zet je bijvoorbeeld de keys op een server op het interne netwerk. Een derde (virtuele dan wel fysieke) server verzorgt vervolgens de firewall functionaliteit en zorgt ervoor dat de "key"-server alleen verkeer kan ontvangen (en dus niet kan zenden) op een bepaalde poort van de "data" server. De voorkeur is ook dat niet beide servers apache als "publieke" service draait. Als een hacker immers in staat is apache te hacken, dan kan hij dit ook 2 keer.

De "key"- server kun je vervolgens een acl geven. Zo kan je alleen een key opvragen als je rechten hebt op een bepaalde file. Een key opvragen van een andere gebruiker resulteert in een complete stop van de service, waardoor de hacker maar 1 (mislukte) poging zou kunnen doen mocht hij zich in de DMZ bevinden.

Vergeet alleen een ding niet, wat veel belangrijker is. Je hebt een verdraait goede hoster nodig. Je kunt dit niet zomaar even op webhosting draaien of op een vps er zijn dan namelijk altijd onbetrouwbare mensen die fysiek toegang hebben.

[EDIT]
Nog eens even gelezen, kan begrijpen als het wat onduidelijk is, het is ook veel, ik kan hier minstens een uur over volpraten, maar een hele paper in mijn reply schrijven vond ik ook weer wat

Zo bedoel ik met "publieke"-service bijvoorbeeld dat een ander apparaat kan communiceren met de service. De server hoeft daarvoor dus niet aan het internet te hangen en een apparaat in de MZ zal er dus ook minstens (en liefst) 1 hebben.

[ Voor 10% gewijzigd door ReenL op 09-05-2011 20:02 ]

[NMe]

mace schreef op maandag 09 mei 2011 @ 18:48:
[...]

Rainbow table genereren?

Kan je net zo goed meteen bruteforcen want je doet hetzelfde.....

Dat hangt ervanaf of je als hacker direct in de database kan of niet. Als je geen databasetoegang hebt blijf je langer onder de radar als je dit voorwerk offline doet aangezien meerdere mislukte inlogpogingen vast gethrottled en gelogd worden in een goed systeem.

[ReenL]

Ik denk dat mace bedoelt dat een rainbow tabel genereren en brute-forcen (beide offline) met de GPU's van tegenwoordig beide in een reële tijd uitgevoerd kunnen worden. Een rainbow table "gebruiken" zou misschien sneller zijn, maar kost onwijs veel opslag.

[mace]

ReenL schreef op maandag 09 mei 2011 @ 23:08:
Ik denk dat mace bedoelt dat een rainbow tabel genereren en brute-forcen (beide offline) met de GPU's van tegenwoordig beide in een reële tijd uitgevoerd kunnen worden. Een rainbow table "gebruiken" zou misschien sneller zijn, maar kost onwijs veel opslag.

Nee, wat ik bedoel is dat er geen enkel verschil is tussen het bruteforcen van iets en een rainbow table maken. Je itereert in beide gevallen door alle mogelijke combinaties. Alleen in het ene geval vergelijk je het steeds met een hash en in het andere geval sla je het op om hem later te vergelijken.

Dus een rainbow table genereren duurt net zo lang als het bruteforcen van een database.

Dit gegeven dat je de database in je bezit hebt uiteraard, want als dat niet zo is heb je alsnog niks aan een rainbow table.

[Verwijderd]

Als ik de TS goed begrijp dan moet het een gebruiksvriendelijke kluis worden met data die mogelijk pas over 10+ jaar wordt opgevraagd.

Wanneer het inderdaad gaat om authentieke aktes (zoals testamenten), dan zou ik, naast het volledig beveiligen van de server en de documenten, gebruik maken van een duo-login systeem.

Hierbij moeten 2 mensen tegelijk (bv binnen 10 minuten) een authenticatie code opgeven, voordat de documenten ingezien kunnen worden. Denk hierbij dan aan de client (en/of nabestaanden) en een notaris.
De logingegevens en authenticatie code van de client staan vast (deze moeten immers in het bezit van de client zijn), terwijl de notaris (en/of het kantoor) elke x tijd een nieuwe code toegestuurd krijgt.

Een client kan dan nooit bij zijn/haar documenten zonder dat dit onder het toeziend oog van een notaris gebeurd, en een notaris kan nooit bij de documenten van een client zonder zijn/haar toestemming. En voor derden wordt het vrijwel onmogelijk gemaakt, omdat zij dan 2 verschillende logins en authenticatie codes moeten zien te krijgen.


Voor het opslaan van de data zou je kunnen kijken naar Hardware security modules, waarmee je de data zeer goed kunt beveiligen, maar toch toegankelijk blijft over het internet.

[NMe]

mace schreef op maandag 09 mei 2011 @ 23:33:
[...]

Dit gegeven dat je de database in je bezit hebt uiteraard, want als dat niet zo is heb je alsnog niks aan een rainbow table.

Dus als je door een bug de hash en salt van één user hebt weten bemachtigen (bijvoorbeelde de user met id 1 ) dan is een rainbow table baseren op die salt en dan eenmalig inloggen op dat account geen optie? Ik zou het zelf in elk geval wel zo doen om zo lang mogelijk verborgen te kunnen blijven.

[mace]

NMe schreef op dinsdag 10 mei 2011 @ 00:07:
[...]

Dus als je door een bug de hash en salt van één user hebt weten bemachtigen (bijvoorbeelde de user met id 1 ) dan is een rainbow table baseren op die salt en dan eenmalig inloggen op dat account geen optie? Ik zou het zelf in elk geval wel zo doen om zo lang mogelijk verborgen te kunnen blijven.

Mijn punt is dat het gelijk is aan bruteforcen. Je moet nog steeds dezelfde berekeningen maken als je een rainbow table maakt als dat je de hash kraakt.

We hebben het hier in beide gevallen over een offline hack waarbij je een hash + salt bemachtigd hebt, en je gebruikt dat om een geldig password te vinden, die je later op de desbetreffende applicatie invult, toch?

Wat heeft het voor een nut om een hele rainbow table te bouwen die alleen te gebruiken is voor één bepaalde user? Dan zoek je toch gewoon één keer een geldige plaintext op en gebruik je die?

Nogmaals, er is GEEN verschil rekentechnisch gezien. Het duurt allebei lang om de hashes te berekenen, alleen in het geval van rainbow tables sla je alles op en zoek je later de geldige plaintext, en bij een (offline)bruteforce zoek je gewoon meteen een geldige plaintext en gebruik je die.

De rainbow table die je aanmaakt zal ook maar alleen voor die gebruiker op die website geldig zijn dus waarom in vredesnaam alles opslaan als je het toch maar één keer gebruikt?

PS: Misschien is het een idee om deze discussie af te splitsen?

[Voutloos]

NMe hoopt gewoon dat je het hashen zo kan doen dat men het niet offline kan testen, maar zegt puur om het verwarrend te maken dingen over database connecties.

Salt per user is in ieder geval een goed idee, salt geheim houden valt echter vaak in het security through obscurity hokje.

[ZpAz]

Voutloos schreef op dinsdag 10 mei 2011 @ 09:40:
Salt per user is in ieder geval een goed idee, salt geheim houden valt echter vaak in het security through obscurity hokje.

Je kan toch ook gewoon beiden combineren? Een per user salt en een 'prive' unieke salt?

[NMe]

Voutloos schreef op dinsdag 10 mei 2011 @ 09:40:
NMe hoopt gewoon dat je het hashen zo kan doen dat men het niet offline kan testen, maar zegt puur om het verwarrend te maken dingen over database connecties.

Nee, NMe had gewoon poep in zijn hoofd en moet ook als 'ie het druk heeft even nadenken voor 'ie bijdehand gaat lopen doen. De prutser.

Salt per user is in ieder geval een goed idee, salt geheim houden valt echter vaak in het security through obscurity hokje.

De salt geheim houden is geen beveiliging an sich. Valt wél in het hokje "need to know". De gebruiker heeft niks aan die salt en behalve je eigen systeem heeft alleen een hacker er wat aan om die salt te kennen. Geheim houden is het niet echt, maar als ik geen reden heb om hem wél te laten zien, dan laat ik hem niet zien.

[johnkeates]

nogmaals.. dat salten is leuk maar gaat je niet helpen met de huidige stand van technologie. Het gaat hier dacht ik niet om een leuk fotoboekje met een login voor mensen die wat willen uploaden. Even wat salt in je php-soep gooien is niet de oplossing in dit geval. Je kan het helaas ook niet puur in PHP oplossen.

Als je zoals ik eerder postte en zoals anderen eerder posten een combinatie neemt, kom je er wel, maar er is extreem veel te doen voor 1 persoon.

Gebruik symmetrische encryptie met een lange key (gebruik dan ook een crypto processor), en die lange key, die versleutel je dan weer met een asymmetrisch algoritme, bijvoorbeeld RSA om dat het goed te implementeren is. In dit geval doet LUKS maar TrueCrypt vast ook wel, beide dingen. Je moet niet denken dat een SSL certificaatje plus een leuk MySQL tabelletje met wat zout in je hashes de oplossing is. MD5 is makkelijk te berekenen, en kan steeds sneller. Het duurt echt niet lang meer tot er iemand met een ASIC komt en daar 100+ van in een doosje stoppen om alle mogelijke strings te berekenen.

Dan heb je DMZ + MZ: Je DMZ is een frontend zonder data, die met je MZ verbind om informatie op te halen. Als je alles, inclusief compleet systeem encrypt kan niemand het aanvallen. Zorg ook dat er meerdere boot keys zijn, dan kan je de aanwezige key vernietigen op het moment dat er een aanval is, plus het maakt een coldboot attack onmogelijk, om dat de key die mogelijk uit het ingevroren RAM gehaald wordt niet meer bruikbaar is.


Note: het valt me op dat er nu 3 pagina's lang herhaald wordt en herkauwd e.d. Is het niet handiger als er even een overzichtje is met wat er al gesuggereerd is?

[xilent_xage]

johnkeates schreef op dinsdag 10 mei 2011 @ 11:31:

Note: het valt me op dat er nu 3 pagina's lang herhaald wordt en herkauwd e.d. Is het niet handiger als er even een overzichtje is met wat er al gesuggereerd is?

Dat lijkt me een taak voor de TS Okay, hoop dat ik niemand tekort doe met de onderstaande samenvattingen:

Suggesties met betrekking tot de reproduceerbaarheid/backups

• Ga niet zelf data distribueren en checken maar gebruik een out-of-the-box oplossing.
• Stap af van het idee om een systeem te ontwikkelen wat 30 jaar meegaat, ga uit van 5 jaar oid.
• Gebruik open source software
• Huur een expert in

Suggesties met betrekking tot de veiligheid/encryptie

• Laat users inloggen met een user/pass + salt
• Gebruik een encrypted filesystem
• Denk na over 'fysieke' opslag van keys (per post versturen / in kluis opslaan)
• Als je de bestanden voldoende versleuteld ben je in principe veilig zoalng de key niet in handen valt van anderen.
• Gebruik een unieke key per bestand
• Onderzoek off-the-shelf-produkten (USB keys etc)
• Hou rekening met fysieke opslag
• Huur een expert in
• Zorg voor meerdere keys die in staat zijn de key te genereren om het bestand te decrypten. Dit kan met verschillende technieken.
• Maak een fysieke scheiding tussen de webserver en de opslag. Voor de verbinding tussen beide systemen zijn verschillende beveiligingen mogelijk (ip whitelisting, iSCSI, VPN enz)

Ik ga me dit weekend wat meer in LUKS verdiepen, klinkt interessant. Toch alvast een vraag: Kunnen jullie nog even schieten op mijn laatste idee:

xilent_xage schreef op zondag 08 mei 2011 @ 13:26:
Via https kunnen gebruikers inloggen (username/password+salt). Het wachtwoord van een gebruiker wordt als MD5 in de database bewaard. Voor elk bestand wordt een random key gegenereerd, waarmee het bestand versleuteld wordt opgeslagen. Een key wordt per bestand, per gebruiker die daar toegang toe heeft versleuteld opgeslagen. Als key voor het versleutelen van de key wordt het wachtwoord van de betreffende gebruiker gebruikt. Deze key is nergens opgeslagen, alleen een MD5 hash ervan.

Misschien om rainbow tables tegen te gaan moet het wachtwoord verlengd worden. Of ik gebruik idd iets PBKDF-erigs.

Er is al commentaar gegeven op het gebruik van MD5, maar m.i. is dat niet terecht, omdat het 'kraken' van MD5 nog altijd geen valide key oplevert. Een aanvaller kan dan inloggen en allicht bestanden downloaden, maar verkeerd gedecode. Maar corrigeer me gerust als ik het misheb

Deze opzet zou eventueel op systeemniveau kunnen worden uitgebreid met een DMZ/MZ zoals al door enkelen geopperd.

[Equator]

Er is al commentaar gegeven op het gebruik van MD5, maar m.i. is dat niet terecht, omdat het 'kraken' van MD5 nog altijd geen valide key oplevert. Een aanvaller kan dan inloggen en allicht bestanden downloaden, maar verkeerd gedecode. Maar corrigeer me gerust als ik het misheb

Dat ligt eraan wat je dus wilt hashen met MD5. Voor wachtwoord opslag in een database is een hash een goede optie.
Er zijn echter wat problemen met MD5. Er zijn rainbow tables waarin de meeste hashes staan , en dus terug te vinden zijn.. Daarnaast is het algoritme gewoon erg vatbaar voor collisions. Een verkeerd wachtwoord wat dezelfde hash oplevert als een valide wachtwoord is een zeer denkbaar risico. De controle op validiteit van het wachtwoord levert namelijk een positief resultaat op.
Een oplossing voor de rainbow tabel kan zijn om een hash toe te voegen, maar dat veranderd niets aan de kwetsbaarheid van het MD algoritme.
Ik raad je aan om MD5 gewoon links te laten liggen, en gebruik te maken van een SHA-256 of SHA-384 algoritme gecombineerd met een salt. (En dan laten we de discussie over een generieke salt en of dat de salt geheim moet zijn maar even achterwege)

Wat je bedoeld met "verkeerd gedecode" is mij een raadsel. Tenzij jij denkt dat het wachtwoord ook daadwerkelijk de encryptie-sleutel is voor de data. Dat ligt natuurlijk maar aan de implementatie. Een verkeerde / ontbrekende encryptie-sleutel levert gewoon een error op, geen verkeerd ontsleutelde data.

Een voorbeeld als EFS (Microsoft Encrypted FileSystem) Hierin is de data versleuteld met een sleutel X. De sleutel X is versleuteld met de publieke sleutel van de gebruiker.
De private sleutel is versleuteld met het wachtwoord van de gebruiker.
Wordt het wachtwoord van de gebruiker nou gereset, dan kan hij niet meer bij zijn private sleutel, en kan dus de decryptie-sleutel X niet meer ontsleutelen. Gevolg: Een dikke error bij het benaderen van een versleuteld bestand.

[xilent_xage]

In mijn opzet wordt het ww van de user gebruikt voor het versleutelen van de key. op die manier kun je dus per file de key opslaan voor elke gebruiker die er toegang toe heeft. Mocht een user zn wachtwoord kwijtraken is dat geen probleem, want er zijn nog een aantal andere users die via hun ww bij het bestand komen, waaronder ik.

Als een verkeerde key tot een foutmelding leidt ipv mijn veronderstelde verkeerd gedecode data - prima.

[Janoz]

Ik zie 2 problemen:

1- Bij het wijzigen van een wachtwoord moeten alle ge-encodeerde sleutels weer gehergenereerd worden (maar dat is overkomelijk)
2- Je eigen wachtwoord wordt op deze manier wel heel erg waardevol.

[xilent_xage]

Janoz schreef op donderdag 12 mei 2011 @ 13:00:
Ik zie 2 problemen:

1- Bij het wijzigen van een wachtwoord moeten alle ge-encodeerde sleutels weer gehergenereerd worden (maar dat is overkomelijk)
2- Je eigen wachtwoord wordt op deze manier wel heel erg waardevol.

Eens met beiden. Met de toevoeging dat probleem 2 volgens mij ook wel overkomelijk is. Dit wachtwoord wordt immers nergens op de server opgeslagen. En ik kan natuurlijk een mooi sterk ww gebruiken

[Janoz]

Dat is technisch, maar wat dacht je bijvoorbeeld van het ethische aspect? Je maakt blijkbaar een dienst waarbij data 30 jaar uber prive, maar toch beschikbaar kan blijven. Zou jij het acceptabel vinden dat, naast enkel de mensen die jij vindt dat er bij mogen, ineens ook de site admin erbij kan?

[xilent_xage]

Janoz schreef op donderdag 12 mei 2011 @ 13:08:
Dat is technisch, maar wat dacht je bijvoorbeeld van het ethische aspect? Je maakt blijkbaar een dienst waarbij data 30 jaar uber prive, maar toch beschikbaar kan blijven. Zou jij het acceptabel vinden dat, naast enkel de mensen die jij vindt dat er bij mogen, ineens ook de site admin erbij kan?

kort gezegd: ja. net zoals mijn ISP mijn mail kan lezen enz. Ik denk dat een dergelijke borging nodig is. Het is immers veel belangrijker dat de 'begunstigden' niet voor een bepaalde tijd of gebeurtenis bij de data kunnen. En dat betekent dat de admin de enige is die je kan redden als je je wachtwoord kwijtraakt. Daar lijkt me, welke implementatie je ook kiest, geen weg omheen - tenzij je de key op de server gaat opslaan met alle gevolgen van dien.

[ Voor 8% gewijzigd door xilent_xage op 12-05-2011 13:41 ]

[Janoz]

Je kunt ook accepteren dat de data voor eeuwig verloren is wanneer alle gebruikers hun wacthwoorden kwijt raken. Zo vanzelfsprekend vind ik het niet dat een serveradmin overal bij zou mogen komen hoor.

[xilent_xage]

Janoz schreef op donderdag 12 mei 2011 @ 14:01:
Je kunt ook accepteren dat de data voor eeuwig verloren is wanneer alle gebruikers hun wacthwoorden kwijt raken. Zo vanzelfsprekend vind ik het niet dat een serveradmin overal bij zou mogen komen hoor.

nou vooruit, dan geven we gebruikers de keus.

[Freeaqingme]

Wat dat md5'en betreft, wou je het wachtwoord md5'en, of ook de salt? En waarom zou je in vredesnaam anno 2011 nog voor md5 kiezen?

[mace]

Freeaqingme schreef op zondag 15 mei 2011 @ 00:35:
Wat dat md5'en betreft, wou je het wachtwoord md5'en, of ook de salt? En waarom zou je in vredesnaam anno 2011 nog voor md5 kiezen?

Snap je het concept van salten wel? Je moet het allebei hashen anders heeft het geen nut.

md5 heeft zijn beste tijd wel gehad idd.

[johnkeates]

Ik zou het gebruikerswachtwoord alleen voor authenticatie van de gebruiker gebruiken. Dan kan je per gebruiker een lange key gebruiken voor symmetrische encryptie van een lange sleutel die weer gebruikt kan worden op een filesystem of image.

Ik heb een vergelijkbare setup meerdere malen in productie omgevingen opgezet en tot nu toe geen onvoorziene omstandigheden tegen gekomen.

Hier is een wat duidelijkere visuele opzet van wat ik eerder postte:



Detail / ruwe schets van LUKS:


Er is ook een extra voordeel:

Plausible deniability
plausible deniability involves the possession of encrypted data which cannot be proven to exist. This is often done by using steganography. Keys hidden in this way are currently not supported by the init script.
To implement this, check out StegFS and Scubed.

Dat is misschien totaal irrelevant in jouw situatie, maar het kan dus zijn dat dat ook geimplementeerd moet worden. Ik heb keys op random plekken op een groot stuk flash in blokjes staan die afhankelijk van het systeem wel of niet in de juiste volgorde bij elkaar gevonden worden om zo een boot key te verkrijgen. Als je er naar kijkt, zie je gewoon alleen maar een paar GB aan random data. Daar kan een inbreker moeilijk de key uit terugvinden En stel dat ie je met een moersleutel op je hoofd aan het timmeren is (http://xkcd.com/538/) dan kan je de sleutel niet geven, al zou je het willen. Dat is allemaal weer sterk afhankelijk van de waarde van de informatie (jouw bloed/zweet/tranen/pijn/dood vs de data).

[ Voor 5% gewijzigd door johnkeates op 15-05-2011 01:46 . Reden: Plaatjes deden stom. ]

[Freeaqingme]

mace schreef op zondag 15 mei 2011 @ 01:03:
[...]

Snap je het concept van salten wel?

Jazeker. Ben me er van bewust dat de vraagstelling enigzins misleidend was

[xos]

johnkeates schreef op zondag 15 mei 2011 @ 01:44:
Ik zou het gebruikerswachtwoord alleen voor authenticatie van de gebruiker gebruiken. Dan kan je per gebruiker een lange key gebruiken voor symmetrische encryptie van een lange sleutel die weer gebruikt kan worden op een filesystem of image.

Als ik vragen mag, welke cipher (mode) gebruik je hiervoor? Je noemt namelijk lange keys, ergens in het topic noem je al een key lengte 128MB. Ik ben benieuwd welke ciphers met dergelijke lange keys overweg kunnen en ook nog eens snelgenoeg dat ze praktisch inzetbaar zijn.

[alt-92]

Ligt aan waar je ze voor wil gebruiken.
De daadwerkelijke data encryptie (dus niet het transport of de user authentication) mag rustig wat langer duren, daar kun je wel grotere keylengths voor inzetten.

Evengoed: scheiden van toegangsbeveiliging en databeveiliging is sowieso wel verstandig omdat je dan ook nog de mogelijkheid openhoudt van upgrades aan ciphersuites of zelfs zoiets banaals als hardwarevervanging.

[johnkeates]

Precies. Ik bedoel trouwens niet dat je een lange key gebruikt van 128MB voor alles wat maar een key nodig heeft (dat zou ook je keuze qua ciphers flink limiteren), maar bijvoorbeeld om een master keyfile te maken en die bijvoorbeeld met RSA coderen. Als je RSA berekeningen met ziek lange keys doet, ben je wel even bezig. Dan heb je dus een tijdslot om het zo te zeggen. Dus stel dat alle keys weg zijn en je echt aan je laatste redmiddel toe bent, kan je die lange RSA key assembleren vannuit verschillende fysieke locaties, om daarna een flinke computer even een paar weken te laten rekenen.

Authenticatie kan je natuurlijk 1 factor en dan username/password met salt en md5 hash doen, maar hoe graag wil je je data beveiligen? Ik verzin nu terplekke dat je ook multifactor authenticatie kan doen, en dan bijvoorbeeld eerst een username, en twee passwords moet invoeren, dan kan je als 2e factor email auth erbij doen, dat je een code krijgt om verder te gaan, dan misschien nog sms daarna om nog een extra auth the doen, misschien digitaal certificaat voor two-way SSL ofzo, *zuigt nog even aan z'n duim* en dan, een applet die een paar address ranges van een flash drive scant op bepaalde bits. Om maar wat te noemen.

Verder zou je encryptie natuurlijk meerlaags moeten doen;

Op FS niveau een snelle met sterke (lange/complexe) key (LUKS met aes-cbc-essiv:sha256 en een keysize van 256 bit ofzo) en dan een master keyfile maken om het filesystem altijd te kunnen unlocken. Die master keyfile (of admin keyfile of 1337 keyfile of sjakie keyfile - naam is irrelevant) ga je dan met RSA even flink encrypten met een lange key, 4096 bit ofzo (dan zit je tot na 2030 nog wel goed qua kraakbaarheid). Om de berekeningen lang/traag te maken kan je ook een extreem lange key gebruiken van meerdere MB's. (128MB RSA anyone?) Dan heb je een 'laatste redmiddel' maar wel altijd een manier om data terug te krijgen in een worst case scenario. key en keyfile deel je allebei in een paar stukjes op en dan natuurlijk wel zo dat je ze kan reconstrueren als je ze allemaal bezit. Daarna verspreid je die over meerdere fysieke locaties.

Die dingen kan je allemaal een voor een vervangen zonder probleem. Behalve als je van ciphersuite wil veranderen, dan moet je de ene drive unlocken, en de data naar een nieuwe kopieren, en die weer locken, en de oude vernietigen.

Dan heb je je IPC via VPN of iSCSI via VPN of ander leuk systeem (verzin eens wat), die ook even sterk gecodeerd moet zijn, maar daar zijn zo veel oplossingen (off-the-shelf) voor, dat hoeft niet moelijk te zijn.

Op je outside-facing server zorg je er voor dat ie wel kan starten, maar de webinterface ook weer flink op slot zit en je die handmatig moet starten met een lange key die moeilijk te bemachtigen is (of je zet het op een partitie en gebruikt LUKS) waarna mensen pas kunnen inloggen. Dan gebruik je multifactor auth, en misschien SSL/TLS (toch wel handig he) en dan is het daarna verantwoordelijkheid van de gebruikers.

[alt-92]

Het probleem wat ik heb met een dergelijke aanpak is dat je er vanuit gaat dat je media en infrastructuur ook daadwerkelijk voor diezelfde levensduur beschikbaar is.

Wat dat betreft is 128MB cipherblocks natuurlijk vette overkill als je gaat kijken hoe longterm encrypted datastorage bij archiveringsinstanties ingezet wordt - het daadwerkelijk kunnen benaderen/converteren van die data na 5-10 jaar *denk maar eens aan fileformats of appcompat* is ook belangrijk voor Compliance.