Het kan wel als ze dus een random gegenereerde AES key in je gebruikersprofiel opslaan, apart van je wachwoord voor inloggen. Maar de claim dat ze zelf nergens bij kunnen is natuurlijk torokaka want als de applicatie erbij kan (en dat kan hij, want jij kunt die gegevens via internet opvragen) dan kunnen zij dat ook. Wel kunnen ze organisatorische maatregelen hebben getroffen, zodat de DBA's niet bij de gebruikersprofiles en/of de AES keys kunnen komen. Dan is de claim wat ongelukkig geformuleerd, maar wel waar.

With ^^

Ik zou de data versleutelen met een lange random sleutel en deze sleutel weer versleutelen met zowel het wachtwoord van de gebruiker als met een masterkey. Mocht de gebruiker zijn/haar wachtwoord kwijtraken, dan middels de masterkey de sleutel waarmee de data versleuteld is recoveren en opnieuw versleutelen met het nieuwe wachtwoord. Vervolgens op applicatieniveau voorkomen dat je medewerkers bij de masterkey en de database kunnen.

Technisch is het dan natuurlijk nog wel mogelijk dat de ontwikkelaar(s) de data kunnen onsleutelen, maar dat heb je alijd als je wilt voorkomen dat de gebruiker de data kwijt is bij een wachtwoordverlies. Persoonlijk zou ik toch gaan voor 'permanent verloren data bij vergeten wachtwoord' als het echt gevoelige data is. In dit geval zou ik dat waarschijnlijk niet doen, omdat de gebruiker echt niet alles opnieuw gaat invoeren bij een vergeten wachtwoord.

Wel een leuke dienst btw.

Ik zou er zeker voor kiezen om security ver bij de DBA's weg te houden zodat je optimaal kunt monitoren wat er op de database's gebeurt en snel kan ingrijpen wanneer daar zaken naar boven komen die niet kloppen.

Security begint bij het vaststellen van een goed beleid, pas daarna gaan bekijken hoe je dit technisch kunt gaan invullen.

Het is uitermate naïef om te veronderstellen dat data die worden opgeslagen bij derden veilig zijn. Elk systeem hoe ook versleuteld is uiteindelijk voor iemand toegankelijk en dus kwetsbaar. Er moet natuurlijk iemand toegang hebben tot de applicatie in het geval van calamiteiten - stel dat Yunoo ( of Trueserver BV resp. True B.V.) ter ziele gaat, wat dan ?

Wat doet je overigens veronderstellen dat AES de veiligiste encryptie-standaard is ?

Dit soort projecten zijn maar voor één ding goed, veel informatie verzamelen over nog veel meer mensen.
Deze gegevens zullen geanonimiseerd worden en verkocht worden voor een hoop poen.

Helaas zijn deze 'anonieme' gegevens vaak vrij eenvoudig te herleiden op specifieke personen.

Er is 0,0 reden voor een applicatie als deze om op het web op een externe database te draaien, dit hoort op je eigen pc thuis achter slot en grendel. Hier zijn ook programma's genoeg voor.

Ik vind dit wel een mooie oplossing, mede omdat er een recoverfunctionaliteit bijzit. Wellicht nog mooier is het om de recovery los te koppelen van de authenticatie (password). De vercijfersleutel wordt gemaakt door een userkey te combineren met een hash van het wachtwoord. Ditzelfde doe je met een recoverykey met het recovery wachtwoord. Beide systemen moeten toegang geven tot de encryptiesleutel.
Je zou ook kunnen denken aan een een asymmetrisch systeem met een public en een private key. Maar dan komt er ineens een hele lading keymanagement bij.

Heeft er iemand al gewoon geprobeerd ze eens op te bellen om te vragen hoe het zit?

Grt,
Joep

AES kan heel veilig zijn. Is wel afhankelijk van de implementatie.

ik ga er eens een mail aan wagen. Kijken wat ze terug te melden hebben :)

Als je een password kan vergeten en dan toch nog bij de versleutelde data kan komen, dan is er een mens of een samenwerkingsverband van mensen die het vergeten password kan achterhalen.
En jij hoort dan duidelijk niet bij het samenwerkingsverband, want jij was degene die het password vergat.
Passwords zijn verouderd als authenticatie techniek en er zijn superieure technieken beschikbaar.

Met AES is niets mis, daar hoef je niet bang voor te zijn.
Het gaat hier om de toegang tot de sleutel die wordt gebruikt, en die beschermt je privacy in dit geval slechts beperkt.

Ik heb antwoorden terug met betrekking tot de beveiliging:

Het gebruik van AES:
Zoals inderdaad beschreven op de site gebruiken we AES-encryptie voor het beveiligen van de gebruikersdata binnen Yunoo. Bij het kiezen voor gebruikerspecifieke versleuteling en zogenoemde masterversleuteling hebben we een aantal zaken overwogen. Het mag duidelijk zijn dat versleuteling op gebruikersniveau een betere versleuteling is, maar er kleven een aantal nadelen aan. Het eerste is dat de gebruiker bij verlies van het wachtwoord niet meer in staat is de gegevens te herstellen. Immers, de data is met het oude wachtwoord versleuteld. Ten tweede willen wij in de 'vergelijk'-optie de mogelijkheid aan onze gebruikers bieden om te vergelijken met de uitgavepatronen van gebruikers in een soortgelijke situatie. Bij een versleuteling op gebruikersniveau is dit simpelweg onmogelijk.

We hebben uiteindelijk gekozen om de gebruikersdata daarom op masterniveau te versleutelen. Daarbij is het dan ook zeker waar dat 1 van onze medewerkers, met veel terugrekenwerk (de connecties van transacties naar rekeningen en emailadressen zijn immers ook versleuteld) in staat zou kunnen zijn om de transactie-data van de gebruikers in te zien. Echter heeft beveiliging niet alleen te maken met de technische implementatie, maar zeker ook met het beleid dat binnen het bedrijf wordt gehanteerd (wie heeft beschikking over welke wachtwoorden, wie heeft toegang tot welke code, etc.), iets waar bij ons enorm veel waarde aan wordt gehecht. Overigens spelen we wel met het idee om de versleuteling op gebruikersniveau optioneel instelbaar te maken. Op deze manier leggen we de verantwoordlijkheid bij de gebruiker zelf.

Betreffende het verwijderen van je data:
Wanneer je je data verwijderd (op dit moment doe je dit door je rekening te verwijderen), wordt dit gesynchroniseerd verwijderd. Dit houdt inderdaad in dat het direct van de servers verwijderd wordt. Ik neem aan dat je technisch bent, dan zegt onze hosting partij (True) je waarschijnlijk genoeg.

De audit en het rapport:
De audit die hier wordt genoemd is er gekeken naar de technische beveiliging in meerdere lagen van de applicatie. Zo is er gekeken naar de software die op de servers is geinstalleerd, de configuratie hiervan, de versies en mogelijke veiligheidslekken. Daarnaast is er ook op code-niveau ge-audit. Zo is er gekeken naar het voorkomen van bekende veiligheidslekken en de verschillende veiligheidslagen die deze veiligheidslekken tegengaan. De audit is uitgevoerd door iBuildings, een zeer gerenomeerde partij op het gebied van PHP, de taal waarin Yunoo ontwikkeld is. Op deze pagina is meer informatie te vinden over deze audit:

http://www.ibuildings.nl/technology/tcs/security-audit

Het uitgebrachte rapport is zeer positief, mede daarom wordt er voor het eind van deze maand een klant-case gepubliceerd vanuit iBuildings, waarin de security-audit verder wordt uitgediept. Als je dit aangeeft kan ik je hierover op de hoogte houden.