Als je password om in te loggen op de website, gelijk is aan jouw privé encryptie sleutel is, kan er hoogstens lokaal wat lokaal bekend, verder onbekend maar niet geheim, zout aan worden toegevoegd om via 'afleiding' (salted , hashed) een lokale privé encryptie sleutel te krijgen. 20 tekens is overigens is te weinig om dat alles achterwege te laten. Dat zout is wel op jouw PC bekend maar niet op de website.

Of er wordt zoals bij TrueCrypt met veel moeite initieel een echte encryptie sleutel gegenereerd en die wordt met jouw privé sleutel encrypted. Ook dan heeft de website niets. Maar het blijft merkwaardig. Bij KPN (IASO) bijvoorbeeld zijn de inlog code en de prive sleutel verschillend, zoals kennelijk bij Cyphertite.

Een aardige test hoe geheim de sleutel is: wanneer moet je de sleutel intikken: bij elke backup (niet: dan staat de encryptie sleutel op de 'backup processor') of bij een restore (idem voor de resore processor). Ook aardig is: Kan je de encryptie sleutel veranderen? dan wordt een truecrypt-achtig schema gebruikt. Anders moeten alle files van alle data opnieuw encrypted worden.

akfteo, de manier waarop wachtwoorden werken is als volgt (in heel gewoon simpel Nederlands, dus het zal niet 100% accuraat zijn, maar het gaat om het idee) :

Je wachtwoord is encrypted opgeslagen op de server; wanneer je je aanmeld wordt je wachtwoord versleuteld, en wanneer JOU sleutel en de opgeslagen sleutel hetzelfde zijn krijg je toegang.
Dat betekent dus een beetje als : je ANTWOORD is opgeslagen, en alleen JIJ weet de vraag; stel je de goede vraag die bij het antwoord hoort is het een match.

Op die manier hoeft een dienst dus niet je wachtwoord op te slaan, alleen de uitkomst na versleuteling.

Hopelijk geeft dat je een beetje inzicht :)

NedFox bedankt; als ik het dan goed begrijp:

- ik maak een wachtwoord aan, bijvoorbeeld xx88tt
- op basis van het ingevoerde wachtwoord wordt dit wachtwoord versleuteld en ziet het er bijvoorbeeld zo uit: nfshvdf98735vndj*&*&h98734nrfoisfuvxh en dit is dan de zogenaamde "key"
- dit versleutelde wachtwoord (de key) kan ik zelf niet zien maar xx88tt is het enige wat hier mee "match" en dus zou je kunnen zeggen dat xx88tt ook min of meer de key is

Klopt dat een beetje zo?

En wat is dan het verschil met de Cyphertite methode waar je het versleutelde wachtwoord ook zelf beheert? Is het één veiliger dan het andere?

Gebruikersnaam/wachtwoord is de "sleutel" voor toegang, de private key is om de bestanden te coderen/decoderen.

In principe is een provider altijd in staat om bij de bestanden te komen (hey, het staat op hun harde schijven, niet?) , maar kunnen niets met de bestanden omdat jij de sleutel om te decoderen in je bezit hebt.

HOE de diverse providers precies werken weet ik niet, dat gaat mijn (gelimiteerde) kennis te boven. En of de een beter is dan een ander kunnen anderen waarschijnlijk beter beantwoorden.

Misschien helpt dit schema......

Aan jouw PC kant:
stap 1. wachtwoord xx88tt -> omzetter A -> jouw encryptie key nfshv....fuvxh -> eventueel opslaan op jouw PC
stap 2. backup file -> encryptie met jouw encryptie key -> encrypted file naar SOS

Aan de SOS website kant: als eerste aanmaken account (dit is wat edFox al aangaf)
stap 3. geef wachtwoord xx88tt-> omzetter B -> encrypted inlog wachtwoord pqrst....fklpmn -> opslag bij SOS

Aan de SOS website kant bij inloggen:
stap 4. inlog wachtwoord xx88tt -> omzetter B -> encrypted inlog wachtwoord -> vergelijk met opslag (dit is "ergens" moeten verifiëren of mijn wachtwoord klopt)"


Je opmerking "zal SOS toch ergens moeten weten wat mijn wachtwoord is" is zowel waar als niet waar.
Niet waar omdat zij het wachtwoord niet opslaan, zie 3 en dat is wat NedFox ook aangaf.
Wel waar omdat in het begin van 3 en 4 jouw wachtwoord eventjes bekend is bij SOS (maar het wordt niet opgeslagen).

Veel problematischer is dat tegenwoordig inbrekers hele data bases met encrypted (hashed) wachtwoorden stelen. Daarna proberen zij die te decoderen. Het hangt dan van de lengte van jouw wachtwoord en de omzetter B (hash functie) af of zij daarin makkelijk kunnen slagen.

Kortom, zoals je al aangaf het was veel beter geweest als SOS inderdaad een apart inlog wachtwoord had en jij zelf een aparte privé sleutel. Het is dus niet hetzelfde als het schema dat je voor Cyphertite aangeeft.


Nog 3 opmerkingen:
De omzetters A en B zijn z.g. hash functies die zelf geen key nodig hebben om van jouw wachtwoord een 'encrypted' (beter: hashed) wachtwoord te maken. Dus xx88tt wordt omgezet (hashed) naar nfshv....fuvxh. Alleen xx88tt 'past' daarop. xx88tt is alleen te achterhalen door van alle mogelijke wachtwoorden te proberen of ze nfshv....fuvxh opleveren.

Er is een kans dat SOS in stap 3 hetzelfde doet als LastPass. Dan wordt bij inloggen een hashcode opgegeven. Bij een website login via de browser is dat nauwelijks haalbaar, bij een app login wel.

In mijn eerste anwoord gaf ik nog een alternatief voor stap 1 op jow PC:
stap 1Alt: SOS PC-app genereert encryption key jklm....stuv-> encrypt die key met jouw wachwoord xx88tt -> sla encrypted key lokaal op jouw PC op
Stap 2 verandert dan ook iets

Bedankt voor de uitleg allemaal. Het is mij hopelijk een stuk duidelijker nu:

- ik maak een wachtwoord aan en op basis van dat wachtwoord wordt een encrypted key gegenereerd
- het wachtwoord en de encrypted key zijn voor altijd aan elkaar verbonden
- het wachtwoord is nodig om de encrypted key zeg maar "te activeren"

Een backup service kan hier op verschillende manieren mee omgaan:

1- wachtwoord en encrypted key worden opgeslagen bij de backup dienst (niet veilig)
2- encrypted key wordt opgeslagen bij de backupdienst maar wachtwoord is alleen bekend bij gebruiker (veilig)
3- wachtwoord wordt opgeslagen bij backup dienst maar encrypted key is alleen bekend bij gebruiker (meest veilig)

Methode 1 dus n iet aan te raden. Methode 2 is in principe heel veilig maar het is theoretisch mogelijk om aan de hand van de encrypted key het wachtwoord te decoderen. Methode 3 is het meest veilig omdat het zo goed als onmogelijk is om aan de hand van het wachtwoord de encrypted key te achterhalen.

Klopt bovenstaande nu allemaal een beetje??

Ik heb na lang zoeken 4 backup diensten gevonden die aan methode 2 of 3 voldoen:

1- SOS Backup Online (wachtwoord alleen bij gebruiker bekend)
2- Wuala (wachtwoord alleen bij gebruiker bekend)
3- Cyperhtite (encrypted key alleen bij gebruiker bekend)
4- Crashplan (encryptedf key alleen bij gebruiker bekend)

Cyperhtite en Crashplan lijken dus echt superveilige backup diensten. Cyperhtite heeft dan wellicht nog als voordeel dat het open source betreft, Crashplan heeft als voordeel dat het als enige werkt met 448 bits versleuteling (tegen 256 bij de rest).

Wat i me tenslotte dan nog afvraag: wanneer een backup dienst zo'n hoge graad van beveiliging aanbiedt als de 4 hierboven genoemd, maakt het dan nog wat uit of het om een Europese of een Amerikaanse dienst gaat? De bestanden zijn (helemaal al in het geval van Crashplan en Cyperhtite) zo goed als onmogelijk door derden in te zien.

Daarnaast lijkt de opslag bij deze genoemde diensten mij ook veiliger dan het neerzetten van een eigen NAS bij vrienden/familie in huis. De hoge mate van encryptie en het feit dat er gebruik wordt gemaakt van goed beveiligde datacenters maakt een online backup (mits de dienst dus voldoet aan genoemde beveiligings eisen) mijn inziens de meest veilige keuze.

En natuurlijk, ook altijd eigen onsite backups blijven gebruiken (dit maar even gezegd voor de zekerheid) de online backup is alleen maar bedoeld om ook één EXTRA backup buiten de deur te kunnen bewaren.

Nee, het klopt helaas niet. Als we encrypted key (of bedoel je encryptie key?) nu eens door het woord sleutel vervangen, dan geldt:
1- wachtwoord en sleutel worden opgeslagen bij de backup dienst (niet veilig)
2- sleutel wordt opgeslagen bij de backupdienst maar wachtwoord is alleen bekend bij gebruiker (onveilig, je geeft de sleutel van je voordeur toch ook niet weg, dus waarom wel de sleutel tot de backup data?)
3- wachtwoord wordt opgeslagen bij backup dienst maar sleutel is alleen bekend bij gebruiker (komt bijna niet voor, onveilig)
4- wachtwoord is alleen bekend bij gebruiker (niet opgeslagen) en sleutel alleen op mijn PC opgeslagen (veilig)
5- wachtwoord is alleen bekend bij gebruiker (niet opgeslagen) en sleutel wordt elke keer opnieuw gemaakt (maar wel dezelfde!) (zeer veilig, wel onhandig bij elke backup je wachtwoord intikken)

Een 5-de dienst is: KPN backup online: wachtwoord en sleutel gescheiden, wachtwoord bij gebruiker, sleutel alleen op PC, niets bij KPN.

"Wat i me tenslotte dan nog afvraag: wanneer een backup dienst zo'n hoge graad van beveiliging aanbiedt als de 4 hierboven genoemd, maakt het dan nog wat uit of het om een Europese of een Amerikaanse dienst gaat? De bestanden zijn (helemaal al in het geval van Crashplan en Cyperhtite) zo goed als onmogelijk door derden in te zien."

De meningen verschillen volgens mij: ik zou zeggen US is net zo goed als EU (aannemende dat de sleutel niet bekend is buiten de PC, maar ik ken die backup diensten niet exact). En ik ga uit van een sterke sleutel, maar ook dat zou onderzocht moeten worden bij die 5 voorbeelden.
Maar in theorie zouden organisaties als NSA bij hele belangrijke gegevens de sleutel kunnen proberen te achterhalen.

Bij beveiliging is het altijd het afwegen van risico's. Ik zou ook zeggen dat een sterke encryptie in de cloud, veiliger is dan opslag ergens buitenshuis. Maar ik dacht dat crashplan encryptie en familie combineert!

Uiteindelijk blijft het een kwestie van vertrouwen, wanneer er vanuit een wachtwoord een "HASH" wordt berekend door middel van een onbekend niet te controleren proces. Je moet er dan maar op vertrouwen dat dit onbekende niet controleerbare proces niet reversibel is. En dat de backupsoftware achter je rug om niet van allerlei dingen met je password doet die jij niet wilt.

Een veiliger oplossing is om op je eigen PC een Private- Public-key paar te genereren met een opensource-tool en een opensource-algoritme.

Maar dan nog blijft het een kwestie van vertrouwen. Want op jouw PC draait hoogstwaarschijnlijk een stukje software van de leverancier dat de backup verzorgt en dus de versleuteling. En, je voelt hem vast wel aankomen:

- Deze software kan bij je private-key
- Wordt deze private-key wel gebruikt
- Wordt deze private-key niet stiekem meegestuurd

Dus om dit te voorkomen zou het versleutelingsproces door een van de backup-software onafhankelijk stukje software moeten gebeuren. Het liefst natuurlijk weer door een opensource stuk software.

Ook altijd onthouden dat alles wat je op het internet zet, ook bekend gaat worden, omdat encryptie ook ooit eens gekraakt wordt, en als iemand alles van je opgeslagen heeft, dus dan alles kan gaan bekijken.
Ook worden pc steeds sneller, dus indien wachtwoord te klein is(of een slechte wachtwoord gekozen), dan kan dit ook gekraakt worden door brute force, dus in de toekomst.

Een website mag bijv nooit je wachtwoord geven, als jij die verloren hebt, want dan is je wachtwoord niet goed opgeslagen.
(encrypted, hashed en salted heet dit, security now op youtube legt dit uit).

Dus als je opslag op internet zelf de encryptie voor jouw doet, met jouw sleutel/wachtwoord, dan is het niet veilig.
Indien jij dit wel zelf doet, dus op je pc, dan is het een stuk veiliger.

@ 22:35 Euro10000
Bij online backup ligt dat iets anders. Het staat niet op Internet: je moet via een account bij de opslag komen. Maar in geval van diefstal van de backup data zou de dienstenaanbieder daarom inzicht moeten verschaffen in hoe lang het gemiddeld duurt voordat de sleutel gekraakt kan worden. Vooral voor backup is een lange bewaartijd van groot belang.
En eventueel erbij vertellen dat de encryptie methode misschien onveilig wordt bevonden indien de toekomst fouten worden gevonden.

"Your password is stored in a database, encrypted -no one can see it. When you log in, the username and password will authenticate and allow for access. When you authenticate, it is authenticated over SSL, so you can be sure that it's also encrypted. The Server knows how to decrypt both, securely and ensure that you are who you say you are."

The digital key is stored within the password.

FOUT FOUT FOUT!! Er zitten hier tenminste 3 grote fouten in dit antwoord.

Of deze medewerker weet echt niet waar hij het over heeft, of hij maakt er Sesamstraattaal van zodat de leek het begrijpt. Dat laatste lijkt me niet waarschijnlijk, er wordt tenslotte een technische vraag gesteld dus verwacht je een technisch antwoord.

Als ik jou was zou ik de technische specs opvragen HOE het exact werkt zodat je het kunt auditten. Want met dit antwoord kan je dienst direct naar de prullenbak verwijzen.

Nou jongens, lekkere ingewikkelde materie dit. Hoe dan ook, de conclusie voor mij is dat de door mij gebruikte backup dienst SOS Backup Online behoorlijk veilig is (ik heb als enige het wachtwoord) maar dat ik voor meer veiligheid beter gebruik zou kunnen maken van Cyperhtite (open source en ik heb de encrypted key) of Crashplan (zelfde als Cyperhtite maar geen open source).

Ik heb een proef account bij SOS aangemaakt. Het blijkt dat SOS (naast de zakelijke accounts) 2 soorten consumenten accounts heeft.

Type 1 (standaard) doet vermoedelijk lokale encryptie met een sleutel die SOS wel kent. Type 2 (Ultra Safe) doet lokale encryptie met een sleutel die SOS niet kent. Ultra Safe kan alleen aangezet worden bij het aanmaken van een nieuwe account.

Tijdens transport wordt SSL gebruikt, maar deze optie staat standaard af. Opgeslagen data in het datacentrum (data at rest) word encrypted met een sleutel die alleen SOS kent. Decryptie in het datatcentrum levert voor UtraSafe accounts dus de lokaal op de PC encryted data op.

Grote vraag blijft: hoe wordt de ultra safe encryptie sleutel gemaakt? Want AES is is zekere zin net zo veilig als de sterkte van de sleutel: zwakke sleutel, zwak AES. En maximaal 20 niet random tekens voor een wachtwoord dat direct als sleutel gebruikt zou worden (ik heb daarover geen informatie gevonden) is zwak in dit soort toepassingen.