LastPass 4.0 geeft familie wachtwoorden in noodsituaties
Online wachtwoordmanager LastPass heeft een nieuwe versie gelanceerd die over een feature beschikt waardoor familie en vrienden in noodsituaties toegang tot de opgeslagen wachtwoorden kunnen krijgen. LastPass is een clouddienst waar gebruikers hun wachtwoorden voor allerlei websites in een "kluis" kunnen opslaan.
De kluis is vervolgens vanaf verschillende apparaten toegankelijk, wat het inloggen vanaf pc, smartphone of tablet moet vereenvoudigen. LastPass biedt zowel gratis als betaalde versies van de software aan. Vandaag is LastPass 4.0 gelanceerd. Deze versie beschikt onder andere over een nieuwe vormgeving. Ook is er een nieuw 'sharing center' voor het op veilige wijze delen van wachtwoorden en is de kluis opnieuw ontworpen.
Een nieuwe optie die opvalt is de 'Emergency Access'. Via deze feature kunnen vrienden en familie in het geval van een noodsituatie toegang tot de wachtwoorden in de kluis krijgen. "Hoewel we niet graag voor onvoorziene situaties plannen, willen we onze geliefden niet achterlaten zonder toegang tot de wachtwoorden die ze nodig hebben, bijvoorbeeld om de hypotheek te betalen en creditcardrekeningen te beheren of de laatste wensen uit te voeren", aldus LastPass.
Via Emergency Access kan de LastPass-gebruiker familie of vrienden opgeven die in het geval van een noodsituatie toegang tot de wachtwoordkluis moeten hebben. De gebruiker kan een 'wachttijd' opgeven voordat er toegang tot de wachtwoorden wordt gegeven. Tijdens de wachtperiode kan de gebruiker het verzoek tot de wachtwoorden annuleren als het bijvoorbeeld toch niet nodig blijkt dat vrienden of familie toegang tot de wachtwoorden krijgen.
Reacties (37)
05-01-2016, 16:16 door
johanw
Dus LastPass kan zelf ook aan die wachtwoorden? De overheid van het land waar die opgeslagen zijn kan er dus ook bij. Dat is weer een veilige optie minder (en na die hack van laatst hadden ze toch al een imago issue).
"After the waiting period passes, your vault wil sync to their LastPass account automatically"
Dus als je de toegang daarna stopt staat alles al bij iemand anders tgv synchronisatie?
Dus als je de toegang daarna stopt staat alles al bij iemand anders tgv synchronisatie?
Hier ligt een keepass database op een USB stick in een dichtgeplakte envelop in de kluis. Alleen de echte belangrijke accounts staan er op die stick.
Dus als je de toegang daarna stopt staat alles al bij iemand anders tgv synchronisatie?
Ja. Niet onlogisch toch,
Als je bijvoorbeeld dood bent, en je nabestaanden toegang willen. Je configureert hetzelfde, kiest er zelf voor, en kan ook instellen hoe lang men moet wachten met toegang geven, zodat je misbruik -voordat je bijvoorbeeld dood bent- kunt voorkomen. Of je kiest ervoor geen toegang te geven op deze manier, bijvoorbeeld aan je nabestaanden.
Net zoiets als vragen "als ik een map deel met pietje, kan pietje daar dan bij". Ja natuurlijk kan pietje daar dan bij.
Dus LastPass kan zelf ook aan die wachtwoorden? De overheid van het land waar die opgeslagen zijn kan er dus ook bij.
Waarop baseer je deze uitspraak ?
Door johanw: Dus LastPass kan zelf ook aan die wachtwoorden? De overheid van het land waar die opgeslagen zijn kan er dus ook bij. Dat is weer een veilige optie minder (en na die hack van laatst hadden ze toch al een imago issue).
Lastpass hanteert een Zero Knowledge model en heeft alleen versleutelde data op hun servers staan maar geen encryptiesleutels. Er wordt alleen een hash van de encryptiesleutel gebruikt voor de authenticatie.
The user’s master password, and the keys used to encrypt and decrypt user data, are never sent to LastPass’ servers, and are never accessible by LastPass.
We hash both the username and master password on the user’s computer with 5,000 rounds of PBKDF2-SHA256, a password strengthening algorithm. That creates a key, on which we perform another round of hashing, to generate the master password authentication hash. That is sent to the LastPass server so that we can perform an authentication check as the user is logging in. We then take that value, and use a salt (a random string per user) and do another 100,000 rounds of hashing, and compare that to what is in our database.
En een imago-issue, waar baseer je dat op? Een bedrijf met een imago-issue wordt niet voor $135.000.000 gekocht.
@Redactie
Die kop had wel wat exacter kunnen zijn. Nu lijkt het alsof Lastpass op verzoek zomaar wachtwoorden uitdeelt.
05-01-2016, 17:44 door
choi
Door Anoniem: Hier ligt een keepass database op een USB stick in een dichtgeplakte envelop in de kluis. Alleen de echte belangrijke accounts staan er op die stick.
Leuk voor je, maar heb je ook een nuttige bijdrage aan de discussie?
Ze hebben dus de beschikking over mijn plain/text wachtwoord?? Om die reden moet ik niks van dit soort online password managers hebben die ik niet zelf in beheer heb. Ik heb om die reden een password manager op mijn eigen VPS staan. Ik heb het wachtwoord van mijn vrouw's account in mijn lijst staan, zij die van mij. Niet zo moeilijk om te doen.
Volgens documentatie werkt het zo: je masterkey wordt ge-encrypt met de public key van degene die je opgeeft als 'trusted'. Deze encrypted key wordt centraal opgeslagen. Als iemand toegang wil wordt de encrypted key opgestuurd naar deze persoon en daar lokaal ge-decrypt met zijn of haar private key. Deze laatste zal wel weer uit de vault komen van deze persoon, maar dat staat niet duidelijk vermeld. Oftewel; lastpass heeft _geen_ toegang tot je masterkey. Maar wel tot een encrypted masterkey. Hoe veilig dit laatste is (op de lange termijn) is weer een andere vraag...
Zie ook: https://helpdesk.lastpass.com/emergency-access/
Zie ook: https://helpdesk.lastpass.com/emergency-access/
05-01-2016, 17:51 door
choi
Door Anoniem: "After the waiting period passes, your vault wil sync to their LastPass account automatically"
Dus als je de toegang daarna stopt staat alles al bij iemand anders tgv synchronisatie?
Dus als je de toegang daarna stopt staat alles al bij iemand anders tgv synchronisatie?
Die wachtperiode is bedoeld om jezelf bedenktijd te geven tussen de aanvraag en de daadwerkelijke synchronisatie. Tijdens die wachtperiode kan je dus de aanvraag voor synchronisatie alsnog weigeren.
Your designated Emergcy Access contact(s) can request access to your account and securely receive the passwords and notes without knowing your Master Password. You decide how much time should pass before they’re given access once they request it, and you can decline access if it’s requested unnecessarily.
https://lastpass.com/support.php?cmd=showfaq&id=9972
05-01-2016, 18:35 door
johanw
Door choi:
Lastpass hanteert een Zero Knowledge model en heeft alleen versleutelde data op hun servers staan maar geen encryptiesleutels. Er wordt alleen een hash van de encryptiesleutel gebruikt voor de authenticatie.
Hoe komen die nabestaanden dan aan de gegevens? Misschien dat het goed geregeld is, maar laat ze dat dan uitleggen. Op het forum van lastpass zelf is men er ookj niet helemaal gerust op.Door johanw: Dus LastPass kan zelf ook aan die wachtwoorden? De overheid van het land waar die opgeslagen zijn kan er dus ook bij. Dat is weer een veilige optie minder (en na die hack van laatst hadden ze toch al een imago issue).
Lastpass hanteert een Zero Knowledge model en heeft alleen versleutelde data op hun servers staan maar geen encryptiesleutels. Er wordt alleen een hash van de encryptiesleutel gebruikt voor de authenticatie.
En een imago-issue, waar baseer je dat op?
http://webwereld.nl/security/86511-lastpass-gehackt-verander-hoofdwachtwoord-nu
Een bedrijf met een imago-issue wordt niet voor $135.000.000 gekocht.
Ik vraag me sowieso af waar dat soort bedragen op gebaseerd zijn, zelfs als er nooit een issue geweest zou zijn. Zoveel kunnen ze nooit verdienen aan een programma waar ook nog eens tig gratis en open source varianten van zijn.
LastPass is dan dus per definitie lek/niet veilig genoeg.
Alleen als de gegevens te decoderen zijn door de sleutel die -alleen ik- in bezit heb is het veilig.
Alle andere mogelijkheden maken backdoors.
Een oplossing is om mijn privé sleutel middels een QR-code of iets dergelijks uit te printen en deze offline op te slaan waar anderen in geval van nood toegang toe hebben.
Alleen als de gegevens te decoderen zijn door de sleutel die -alleen ik- in bezit heb is het veilig.
Alle andere mogelijkheden maken backdoors.
Een oplossing is om mijn privé sleutel middels een QR-code of iets dergelijks uit te printen en deze offline op te slaan waar anderen in geval van nood toegang toe hebben.
Door choi:
Leuk voor je, maar heb je ook een nuttige bijdrage aan de discussie?
Door Anoniem: Hier ligt een keepass database op een USB stick in een dichtgeplakte envelop in de kluis. Alleen de echte belangrijke accounts staan er op die stick.
Leuk voor je, maar heb je ook een nuttige bijdrage aan de discussie?
Als je een beetje nadenkt dan is mijn bijdrage dat er alternatieven zijn voor een dergelijk 'probleem'.
Ik snap dat je voor sommige mensen alles in b l o k l e t t e r s uit moet schrijven.
05-01-2016, 20:16 door
choi
Door Anoniem: LastPass is dan dus per definitie lek/niet veilig genoeg.
Alleen als de gegevens te decoderen zijn door de sleutel die -alleen ik- in bezit heb is het veilig.
Alle andere mogelijkheden maken backdoors.
Een oplossing is om mijn privé sleutel middels een QR-code of iets dergelijks uit te printen en deze offline op te slaan waar anderen in geval van nood toegang toe hebben.
Alleen als de gegevens te decoderen zijn door de sleutel die -alleen ik- in bezit heb is het veilig.
Alle andere mogelijkheden maken backdoors.
Een oplossing is om mijn privé sleutel middels een QR-code of iets dergelijks uit te printen en deze offline op te slaan waar anderen in geval van nood toegang toe hebben.
/zucht
Doe nou eerst wat research alvorens zomaar wat te roepen op een forum. Het staat g.v.d gewoon op hun website!
Ik herhaal:
Lastpass hanteert een Zero Knowledge model en heeft alleen versleutelde data op hun servers staan maar geen encryptiesleutels. Er wordt alleen een hash van de encryptiesleutel gebruikt voor de authenticatie.
The user’s master password, and the keys used to encrypt and decrypt user data, are never sent to LastPass’ servers, and are never accessible by LastPass.
We hash both the username and master password on the user’s computer with 5,000 rounds of PBKDF2-SHA256, a password strengthening algorithm. That creates a key, on which we perform another round of hashing, to generate the master password authentication hash. That is sent to the LastPass server so that we can perform an authentication check as the user is logging in. We then take that value, and use a salt (a random string per user) and do another 100,000 rounds of hashing, and compare that to what is in our database.
https://lastpass.com/how-it-works/
05-01-2016, 20:35 door
Dick99999
Het is toch niet verplicht om van de noodsituatie oplossing gebruik te maken? Als je dat niet doet blijft alles toch bij het oude?
05-01-2016, 20:40 door
choi
Door Anoniem:
Als je een beetje nadenkt dan is mijn bijdrage dat er alternatieven zijn voor een dergelijk 'probleem'.
Ik snap dat je voor sommige mensen alles in b l o k l e t t e r s uit moet schrijven.
Door choi:
Leuk voor je, maar heb je ook een nuttige bijdrage aan de discussie?
Door Anoniem: Hier ligt een keepass database op een USB stick in een dichtgeplakte envelop in de kluis. Alleen de echte belangrijke accounts staan er op die stick.
Leuk voor je, maar heb je ook een nuttige bijdrage aan de discussie?
Als je een beetje nadenkt dan is mijn bijdrage dat er alternatieven zijn voor een dergelijk 'probleem'.
Ik snap dat je voor sommige mensen alles in b l o k l e t t e r s uit moet schrijven.
Het 'probleem' is dat jij een van die figuren bent die op de vraag over de werking van de boordcomputer van een Toyota als antwoord geeft dat men een Nissan moet kopen. S n a p j e?
05-01-2016, 20:44 door
choi
Door Dick99999: Het is toch niet verplicht om van de noodsituatie oplossing gebruik te maken? Als je dat niet doet blijft alles toch bij het oude?
Ja, het is gewoon een extra optie waar je zelf voor kan kiezen of je er gebruik van maakt of niet.
Als je er wel voor kiest, wordt er blijkbaar een public/private key pair (2048 bits) gegenereerd per betrokken vertrouweling. Dan wordt 'iets' met de public key van de vertrouweling door mij encrypt. Alleen de vertrouweling kan dat iets decrypten met zijn private key en krijgt daarmee toegang tot de inhoud van mijn vault. De vraag voor mij is, wat is dat 'iets'?
Ik zie 3 mogelijkheden:
- een one time password,
- mijn master key (denk ik niet),
- mijn hashed master key, die normaal ook als lokale decryption key dient.
LP zou dit uitgebreider moeten vertellen, zie https://helpdesk.lastpass.com/emergency-access/
Ik zie 3 mogelijkheden:
- een one time password,
- mijn master key (denk ik niet),
- mijn hashed master key, die normaal ook als lokale decryption key dient.
LP zou dit uitgebreider moeten vertellen, zie https://helpdesk.lastpass.com/emergency-access/
Door choi:
/zucht
Doe nou eerst wat research alvorens zomaar wat te roepen op een forum. Het staat g.v.d gewoon op hun website!
Ik herhaal:
Lastpass hanteert een Zero Knowledge model en heeft alleen versleutelde data op hun servers staan maar geen encryptiesleutels. Er wordt alleen een hash van de encryptiesleutel gebruikt voor de authenticatie.
The user’s master password, and the keys used to encrypt and decrypt user data, are never sent to LastPass’ servers, and are never accessible by LastPass.
We hash both the username and master password on the user’s computer with 5,000 rounds of PBKDF2-SHA256, a password strengthening algorithm. That creates a key, on which we perform another round of hashing, to generate the master password authentication hash. That is sent to the LastPass server so that we can perform an authentication check as the user is logging in. We then take that value, and use a salt (a random string per user) and do another 100,000 rounds of hashing, and compare that to what is in our database.
https://lastpass.com/how-it-works/
Door Anoniem: LastPass is dan dus per definitie lek/niet veilig genoeg.
Alleen als de gegevens te decoderen zijn door de sleutel die -alleen ik- in bezit heb is het veilig.
Alle andere mogelijkheden maken backdoors.
Een oplossing is om mijn privé sleutel middels een QR-code of iets dergelijks uit te printen en deze offline op te slaan waar anderen in geval van nood toegang toe hebben.
Alleen als de gegevens te decoderen zijn door de sleutel die -alleen ik- in bezit heb is het veilig.
Alle andere mogelijkheden maken backdoors.
Een oplossing is om mijn privé sleutel middels een QR-code of iets dergelijks uit te printen en deze offline op te slaan waar anderen in geval van nood toegang toe hebben.
/zucht
Doe nou eerst wat research alvorens zomaar wat te roepen op een forum. Het staat g.v.d gewoon op hun website!
Ik herhaal:
Lastpass hanteert een Zero Knowledge model en heeft alleen versleutelde data op hun servers staan maar geen encryptiesleutels. Er wordt alleen een hash van de encryptiesleutel gebruikt voor de authenticatie.
The user’s master password, and the keys used to encrypt and decrypt user data, are never sent to LastPass’ servers, and are never accessible by LastPass.
We hash both the username and master password on the user’s computer with 5,000 rounds of PBKDF2-SHA256, a password strengthening algorithm. That creates a key, on which we perform another round of hashing, to generate the master password authentication hash. That is sent to the LastPass server so that we can perform an authentication check as the user is logging in. We then take that value, and use a salt (a random string per user) and do another 100,000 rounds of hashing, and compare that to what is in our database.
https://lastpass.com/how-it-works/
Ze kunnen schrijven wat ze willen op de site, dat maakt geen garantie op veiligheid.
Hoe kan een derde (nabestaanden) die gegevens benaderen, zonder mijn sleutel (wachtwoord) te weten?
Als ze er achteraf toch bij kunnen, is er per definitie een lek mogelijk. (!)
Zuchten, krachttermen en oneigenlijke research doen daar niets aan af.
Door Dick99999: Als je er wel voor kiest, wordt er blijkbaar een public/private key pair (2048 bits) gegenereerd per betrokken vertrouweling. Dan wordt 'iets' met de public key van de vertrouweling door mij encrypt. Alleen de vertrouweling kan dat iets decrypten met zijn private key en krijgt daarmee toegang tot de inhoud van mijn vault. De vraag voor mij is, wat is dat 'iets'?
Ik zie 3 mogelijkheden:
- een one time password,
- mijn master key (denk ik niet),
- mijn hashed master key, die normaal ook als lokale decryption key dient.
LP zou dit uitgebreider moeten vertellen, zie https://helpdesk.lastpass.com/emergency-access/
Ik zie 3 mogelijkheden:
- een one time password,
- mijn master key (denk ik niet),
- mijn hashed master key, die normaal ook als lokale decryption key dient.
LP zou dit uitgebreider moeten vertellen, zie https://helpdesk.lastpass.com/emergency-access/
M.i. zijn de linkjes/quotes van choi wel een redelijke aanwijzing hoe het werkt. (of in elk geval : kan werken zonder fundamentele zwakheid)
De feitelijke storage wordt gecrypt met een random sessie key.
Die storage decryption key (gemaakt en gebruikt op de computer van de eigenaar van de data) wordt gecodeerd opgeslagen . De eerste code versie is gecodeerd met een hash met veel iteraties met het password van de eigenaar.
Dat is het default model .
Ik denk niet dat de hashed master key *rechstreeks* gebruikt wordt encryptie key (jouw derde optie)- dat heeft als nadeel dat je bij het wijzigen van die master key alle opgeslagen data opnieuw moet encrypten (in plaats van alleen een sessie key) - met alle uitdagingen van halverwege powerloss - een veilige en min of meer atomic update van alleen een sessie key is veel beter te programmeren.
Verder zou je daarmee bij wijziging van de master key eerder verleende toegang voor andere keys (zoals hier met vertrouweling/erfgenaam) blokkeren of die opnieuw moeten verlenen .
Zie ook de frase in de quote van choi 17:41 'the master key and the keys used to encrypt and decrypt user data' .
Kortom - ik denk aan een totaal random sessie key voor de bulk data, en die wordt 1x of meer keren gecrypt opgeslagen .
Die gecrypte storage staat (ook) in de 'cloud' - zodat je een online/off-site backup hebt.
De feitelijke sessie key waarmee de storage gedecrypt kan worden wordt _ook_ versleuteld met de public key van vertrouweling. En ook opgeslagen.
Alleen dat stukje gecodeerde data (waar de vertrouweling een sleutel uit kan decrypten waarmee jouw data versleuteld is) krijgt de vertrouweling pas onder die bepaalde voorwaarden .
Als dit netjes geimplementeerd is kan LastPass nog steeds niet bij je data . Ze zouden natuurlijjk wel hun voorwaarden kunnen overtreden en jouw vertrouweling "direct" de versleutelde key en jouw vault kunnen geven, waarmee je vertrouweling er alsnog 'meteen' bij kan.
En natuurlijk kunnen ze fouten maken of achterdeurtjes inbouwen - een slechte RNG bij het maken van de session key, of de public key van de vertrouweling speciaal zwak genereren, of gewoon een protocol die naast de public key van je vertrouweling altijd een nsa/lastpass/hacker public key meestuurt die dezelfde toegang krijgt.
Daar kun je van alles over speculeren, maar zonder alle applicaties te reverse engineeren weinig zinnigs over zeggen.
Als je bezorgd genoeg bent over dat probleem moet je wat anders gebruiken .
In elk geval is het idee "dat kan nooit zonder dat LastPass ergens zelf bij mijn data kan" niet juist.
Door Anoniem:
Ze kunnen schrijven wat ze willen op de site, dat maakt geen garantie op veiligheid.
Inderdaad, geen garantie. Met niks. Zelfs de wiskundige garantie van het One Time Pad is alleen zo goed als hoe aan de voorwaarden voldaan wordt - _echt_ random. En _echt_ ONE time. En de bron data _echt_ niet op een andere manier laten lekken.door choi
[knip]
https://lastpass.com/how-it-works/
[knip]
https://lastpass.com/how-it-works/
Ze kunnen schrijven wat ze willen op de site, dat maakt geen garantie op veiligheid.
Sommige garanties zijn natuurlijk harder dan andere.
Maar wat ze schrijven kan wel.
Hoe kan een derde (nabestaanden) die gegevens benaderen, zonder mijn sleutel (wachtwoord) te weten?
Als ze er achteraf toch bij kunnen, is er per definitie een lek mogelijk. (!)
Zuchten, krachttermen en oneigenlijke research doen daar niets aan af.
Klein beetje meer denken over wat je met crypto kunt doen.
(of mijn vorige bijdrage lezen).
Het kan prima gebouwd worden met de beschreven kenmerken . En zonder jouw sleutel wachtwoord te weten.
En op een manier waarbij LastPass alleen er totaal niet bij kan, en de derde alleen , zonder medewerking van LastPass, ook niet.
Als LastPass en jouw derde/nabestaande samenwerken kunnen ze bij je data - dat is het hele doel tenslotte . Je moet erop vertrouwen dat die samenwerking alleen gedaan wordt, door beiden, wanneer de bedoelde omstandigheden zich voordoen.
Ieder voor zich kunnen ze dat niet.
Als zowel LastPass als jouw derde beiden totaal gehacked zijn, kan die hackende instantie ongetwijfeld bij je data.
Als ze _jou_ totaal hacken kunnen ze ook wel bij je data , zodra je LastPass gebruikt.
En als in de LastPass applicatie slechte geprogrammeerd is of achterdeurtjes ingebouwd zijn zouden ze ook bij de data kunnen - de stand alone versie is in die omstandigheid ook geen garantie - een slechte RNG kan voldoende zijn.
Maar goed - wat ze beloven is dus prima mogelijk zonder dat ze per definitie voor zichzelf altijd al toegang hebben.
06-01-2016, 00:09 door
choi
@anoniem 21:21
Had jij niet ooit een account onder de naam Dunning-Kruger?
Had jij niet ooit een account onder de naam Dunning-Kruger?
LastPass uses public-private key cryptography with RSA-2048 to allow users to share the key to their vault with trusted parties, without ever passing that information in an unencrypted format to LastPass. When Emergency Access is activated, each user has a pair of cryptographic keys – a public key to allow others to encrypt data for the user, and a private key that allows the user to decrypt the data that others have encrypted for them.
The key used to encrypt and decrypt your vault data is encrypted with the Emergency Access contact’s public key, and can be decrypted only with their corresponding private key. When setting up Emergency Access, you are using the recipient’s public key, encrypting your vault key with that public key, and then LastPass stores that RSA-2048 encrypted data until it’s released after the waiting period you specify. Only the recipient can decrypt the data, so no one else can decrypt it without access to the private key of the recipient you’re sharing it with, which is encrypted with their master password key. This process is completely automated, with no action required by the end user, and ensures that the data is inaccessible by LastPass or outside parties.
Bron:
http://tweakers.net/nieuws/107149/nieuwe-functie-lastpass-laat-dierbaren-wachtwoorden-overnemen-bij-noodgevallen.html?showReaction=8107546#r_8107546
The key used to encrypt and decrypt your vault data is encrypted with the Emergency Access contact’s public key, and can be decrypted only with their corresponding private key. When setting up Emergency Access, you are using the recipient’s public key, encrypting your vault key with that public key, and then LastPass stores that RSA-2048 encrypted data until it’s released after the waiting period you specify. Only the recipient can decrypt the data, so no one else can decrypt it without access to the private key of the recipient you’re sharing it with, which is encrypted with their master password key. This process is completely automated, with no action required by the end user, and ensures that the data is inaccessible by LastPass or outside parties.
Bron:
http://tweakers.net/nieuws/107149/nieuwe-functie-lastpass-laat-dierbaren-wachtwoorden-overnemen-bij-noodgevallen.html?showReaction=8107546#r_8107546
06-01-2016, 05:59 door
Johan d H
"Hoe kan een derde (nabestaanden) die gegevens benaderen, zonder mijn sleutel (wachtwoord) te weten?
Als ze er achteraf toch bij kunnen, is er per definitie een lek mogelijk. (!)"
Omdat je ze daar toegang toe geeft, zie bovenstaand scherm "People I Trust".
Als een van deze personen dus access wil vraagt hij toegang. Er zal jou een notificatie worden gestuurd. Als je deze notificatie niet beantwoord binnen de vooraf door jou ingestelde tijd (waiting time) dan zal de betreffende requestor read access krijgen.
Als ze er achteraf toch bij kunnen, is er per definitie een lek mogelijk. (!)"
Omdat je ze daar toegang toe geeft, zie bovenstaand scherm "People I Trust".
Als een van deze personen dus access wil vraagt hij toegang. Er zal jou een notificatie worden gestuurd. Als je deze notificatie niet beantwoord binnen de vooraf door jou ingestelde tijd (waiting time) dan zal de betreffende requestor read access krijgen.
06-01-2016, 07:58 door
johanw
Door Johan d H: "Hoe kan een derde (nabestaanden) die gegevens benaderen, zonder mijn sleutel (wachtwoord) te weten?
Als ze er achteraf toch bij kunnen, is er per definitie een lek mogelijk. (!)"
Omdat je ze daar toegang toe geeft, zie bovenstaand scherm "People I Trust".
Dat kan wel, maar hoe maken ze het uberhaupt technisch mogelijk? Stuur je je private key op en sturen zij die door, dan is het onveilig want dat zou Lastpass zelf ook bij die gegevens kunnen komen als ze willen of gedwongen worden. Stuurt die ander jouw eerst je public key, versleutel jij (een deel van) de gegevens ook daarmee en wordt de toegang daartoe door Lastpass geregeld, dan zou het veilig kunnen zijn. Punt is: er staat niet hoe ze het implementeren.Als ze er achteraf toch bij kunnen, is er per definitie een lek mogelijk. (!)"
Omdat je ze daar toegang toe geeft, zie bovenstaand scherm "People I Trust".
Ze hebben dus de beschikking over mijn plain/text wachtwoord??
Dat staat nergens, dit is slechts iets wat jij er zelf bij verzint.
@ 17:09
"Toegang hebben tot" is m.i. iets anders dan "synchroniseren met". Lezen is iets anders dan kopieeren
"Toegang hebben tot" is m.i. iets anders dan "synchroniseren met". Lezen is iets anders dan kopieeren
Door johanw:
Door Johan d H: "Hoe kan een derde (nabestaanden) die gegevens benaderen, zonder mijn sleutel (wachtwoord) te weten?
Als ze er achteraf toch bij kunnen, is er per definitie een lek mogelijk. (!)"
Omdat je ze daar toegang toe geeft, zie bovenstaand scherm "People I Trust".
Dat kan wel, maar hoe maken ze het uberhaupt technisch mogelijk? Stuur je je private key op en sturen zij die door, dan is het onveilig want dat zou Lastpass zelf ook bij die gegevens kunnen komen als ze willen of gedwongen worden. Stuurt die ander jouw eerst je public key, versleutel jij (een deel van) de gegevens ook daarmee en wordt de toegang daartoe door Lastpass geregeld, dan zou het veilig kunnen zijn. Punt is: er staat niet hoe ze het implementeren.Als ze er achteraf toch bij kunnen, is er per definitie een lek mogelijk. (!)"
Omdat je ze daar toegang toe geeft, zie bovenstaand scherm "People I Trust".
Zie mijn post van 5 jan 22:38 hoe dit gebouwd kan worden - (wat ik schrijf is consistent met de informatie in de faq) .
(Ik denk dat je goed bekend bent met pgp ?
Bedenk dan hoe PGP werkt bij het encrypten naar meerdere ontvangers [jezelf en iemand anders] - als je nu het PGP bericht naar één ontvanger door een derde partij laat achterhouden, en alleen laat doorsturen naar die ontvanger bij jouw overlijden, heb je een redelijke analogie van wat LastPass belooft - en zonder dat de derde partij zelf bij het bericht kan.)
Door Anoniem:
M.i. zijn de linkjes/quotes van choi wel een redelijke aanwijzing hoe het werkt. (of in elk geval : kan werken zonder fundamentele zwakheid)
De feitelijke storage wordt gecrypt met een random sessie key.
Die storage decryption key (gemaakt en gebruikt op de computer van de eigenaar van de data) wordt gecodeerd opgeslagen . De eerste code versie is gecodeerd met een hash met veel iteraties met het password van de eigenaar.
Dat is het default model .
Ik denk niet dat de hashed master key *rechstreeks* gebruikt wordt encryptie key (jouw derde optie)- dat heeft als nadeel dat je bij het wijzigen van die master key alle opgeslagen data opnieuw moet encrypten (in plaats van alleen een sessie key) - met alle uitdagingen van halverwege powerloss - een veilige en min of meer atomic update van alleen een sessie key is veel beter te programmeren.
Verder zou je daarmee bij wijziging van de master key eerder verleende toegang voor andere keys (zoals hier met vertrouweling/erfgenaam) blokkeren of die opnieuw moeten verlenen .
Zie ook de frase in de quote van choi 17:41 'the master key and the keys used to encrypt and decrypt user data' .
Kortom - ik denk aan een totaal random sessie key voor de bulk data, en die wordt 1x of meer keren gecrypt opgeslagen .
Die gecrypte storage staat (ook) in de 'cloud' - zodat je een online/off-site backup hebt.
De feitelijke sessie key waarmee de storage gedecrypt kan worden wordt _ook_ versleuteld met de public key van vertrouweling. En ook opgeslagen.
Alleen dat stukje gecodeerde data (waar de vertrouweling een sleutel uit kan decrypten waarmee jouw data versleuteld is) krijgt de vertrouweling pas onder die bepaalde voorwaarden .
Als dit netjes geimplementeerd is kan LastPass nog steeds niet bij je data . Ze zouden natuurlijjk wel hun voorwaarden kunnen overtreden en jouw vertrouweling "direct" de versleutelde key en jouw vault kunnen geven, waarmee je vertrouweling er alsnog 'meteen' bij kan.
En natuurlijk kunnen ze fouten maken of achterdeurtjes inbouwen - een slechte RNG bij het maken van de session key, of de public key van de vertrouweling speciaal zwak genereren, of gewoon een protocol die naast de public key van je vertrouweling altijd een nsa/lastpass/hacker public key meestuurt die dezelfde toegang krijgt.
Daar kun je van alles over speculeren, maar zonder alle applicaties te reverse engineeren weinig zinnigs over zeggen.
Als je bezorgd genoeg bent over dat probleem moet je wat anders gebruiken .
In elk geval is het idee "dat kan nooit zonder dat LastPass ergens zelf bij mijn data kan" niet juist.
M.i. zijn de linkjes/quotes van choi wel een redelijke aanwijzing hoe het werkt. (of in elk geval : kan werken zonder fundamentele zwakheid)
De feitelijke storage wordt gecrypt met een random sessie key.
Die storage decryption key (gemaakt en gebruikt op de computer van de eigenaar van de data) wordt gecodeerd opgeslagen . De eerste code versie is gecodeerd met een hash met veel iteraties met het password van de eigenaar.
Dat is het default model .
Ik denk niet dat de hashed master key *rechstreeks* gebruikt wordt encryptie key (jouw derde optie)- dat heeft als nadeel dat je bij het wijzigen van die master key alle opgeslagen data opnieuw moet encrypten (in plaats van alleen een sessie key) - met alle uitdagingen van halverwege powerloss - een veilige en min of meer atomic update van alleen een sessie key is veel beter te programmeren.
Verder zou je daarmee bij wijziging van de master key eerder verleende toegang voor andere keys (zoals hier met vertrouweling/erfgenaam) blokkeren of die opnieuw moeten verlenen .
Zie ook de frase in de quote van choi 17:41 'the master key and the keys used to encrypt and decrypt user data' .
Kortom - ik denk aan een totaal random sessie key voor de bulk data, en die wordt 1x of meer keren gecrypt opgeslagen .
Die gecrypte storage staat (ook) in de 'cloud' - zodat je een online/off-site backup hebt.
De feitelijke sessie key waarmee de storage gedecrypt kan worden wordt _ook_ versleuteld met de public key van vertrouweling. En ook opgeslagen.
Alleen dat stukje gecodeerde data (waar de vertrouweling een sleutel uit kan decrypten waarmee jouw data versleuteld is) krijgt de vertrouweling pas onder die bepaalde voorwaarden .
Als dit netjes geimplementeerd is kan LastPass nog steeds niet bij je data . Ze zouden natuurlijjk wel hun voorwaarden kunnen overtreden en jouw vertrouweling "direct" de versleutelde key en jouw vault kunnen geven, waarmee je vertrouweling er alsnog 'meteen' bij kan.
En natuurlijk kunnen ze fouten maken of achterdeurtjes inbouwen - een slechte RNG bij het maken van de session key, of de public key van de vertrouweling speciaal zwak genereren, of gewoon een protocol die naast de public key van je vertrouweling altijd een nsa/lastpass/hacker public key meestuurt die dezelfde toegang krijgt.
Daar kun je van alles over speculeren, maar zonder alle applicaties te reverse engineeren weinig zinnigs over zeggen.
Als je bezorgd genoeg bent over dat probleem moet je wat anders gebruiken .
In elk geval is het idee "dat kan nooit zonder dat LastPass ergens zelf bij mijn data kan" niet juist.
Het blijft gissen als LP niet exact aangeeft hoe het geïmplementeerd is. Toch een paar opmerkingen. Wat choi beschreef is de athetication hash die naar en naar LP wordt gezonden, nog eens bij LP gehashed en bewaard wordt.
Lokaal op je PC wordt de enige echte encryption key afgeleid van je master password, ook via hashing maar anders dan bij de authetication (Choi). Als je alleen die encryption key lokaal encrypyt met de public key van de ontvanger, krijgt de ontvanger in feite een key via 'pass the hash'. Je hoeft dus niet de vault opnieuw te encrypten. Een nieuwe master key hoeft dan alleen gehashed te worden en de hash moet encrypted en verzonden te worden.
Voor een 'garantie' dat LP of de vertrouweling niet over de master paswword beschikt, moet alles alleen op de juiste PC (die an mij en die van mij vertrouweling) worden encrypted, decrypted en gegenereerd. Bij LP 'op de site' mag helemaal niets gebeuren, behalve de login authetication.
LP mag dus ook geen keys genereren. Of LP opzettelijk of door een fout lokaal een zwakke key genereert, kan nagegaan worden, de code is toegankelijk, zonder echte reverse engeneering (het is javascript in je browser).
Hopelijk gaat LP vertellen hoe dit is geimplementeerd.
Door Dick99999:
Het blijft gissen als LP niet exact aangeeft hoe het geïmplementeerd is. Toch een paar opmerkingen. Wat choi beschreef is de athetication hash die naar en naar LP wordt gezonden, nog eens bij LP gehashed en bewaard wordt.
Lokaal op je PC wordt de enige echte encryption key afgeleid van je master password, ook via hashing maar anders dan bij de authetication (Choi). Als je alleen die encryption key lokaal encrypyt met de public key van de ontvanger, krijgt de ontvanger in feite een key via 'pass the hash'. Je hoeft dus niet de vault opnieuw te encrypten. Een nieuwe master key hoeft dan alleen gehashed te worden en de hash moet encrypted en verzonden te worden.
Door Anoniem:
Het blijft gissen als LP niet exact aangeeft hoe het geïmplementeerd is. Toch een paar opmerkingen. Wat choi beschreef is de athetication hash die naar en naar LP wordt gezonden, nog eens bij LP gehashed en bewaard wordt.
Lokaal op je PC wordt de enige echte encryption key afgeleid van je master password, ook via hashing maar anders dan bij de authetication (Choi). Als je alleen die encryption key lokaal encrypyt met de public key van de ontvanger, krijgt de ontvanger in feite een key via 'pass the hash'. Je hoeft dus niet de vault opnieuw te encrypten. Een nieuwe master key hoeft dan alleen gehashed te worden en de hash moet encrypted en verzonden te worden.
Als de feitelijke encryptie key direct afgeleid wordt uit het master password (via welke hashing dan ook), hoe zou je dan je master password kunnen wijzigen zonder alle data opnieuw te encrypten ?
Zelfs bij lokaal gebruik is dat een beetje onwenselijk - als programmeur wil je zorgen dat je de data onder ging beding verliest , ook niet als halverwege de re-encryptie de applicatie crashed/stroom wegvalt etc.
Dat is makkelijker te bereiken als het stukje data vrij kort is en een vaste lengte heeft dan wanneer je het hele volume op zo'n manier moet behandelen.
Verder moet je in dat model dan ook die gewijzigde key opnieuw encrypten met de pubkey van de derde die er (onder voorwaarden) bij moet kunnen - en die gewijzigde key moet ook weer geupload worden , samen met je opnieuw gecrypte vault.
Als je op dat moment offline bent, is de vault op je lokale computer op dat moment door de derde niet meer te recoveren -
(ietwat gezocht voorbeeld, maar : je slaat een hoop data op, wijzigt je master password tijdens je Amazone trekking (geen sync) - en alleen je laptop wordt teruggevonden - de derde die de gecrypte vorige hash krijgt kan dan alleen de oude versie die bij LastPass in de cloud stond recoveren. - niet de meest recente versie die op je laptop staat )
Anyway : een design met een totaal random sessie key waarmee de data gecrypt wordt, en die sessie key crypten met een hash afgeleid van het masterpassword heeft dat soort nadelen niet.
Uit deze veel betere eigenschappen en het los gebruik van de term 'master password and the keys used to encrypt data' meen ik af te leiden dat deze constructie gebruikt wordt .
Voor een 'garantie' dat LP of de vertrouweling niet over de master paswword beschikt, moet alles alleen op de juiste PC (die an mij en die van mij vertrouweling) worden encrypted, decrypted en gegenereerd. Bij LP 'op de site' mag helemaal niets gebeuren, behalve de login authetication.
LP mag dus ook geen keys genereren. Of LP opzettelijk of door een fout lokaal een zwakke key genereert, kan nagegaan worden, de code is toegankelijk, zonder echte reverse engeneering (het is javascript in je browser).
Hopelijk gaat LP vertellen hoe dit is geimplementeerd.
Als je voorzichtig/paranoide genoeg wilt zijn om in de code te kijken of ze alles goed doen, zie je ook meteen welke encryptie stappen ze doen qua keymanagement.
Het zou wat makkelijker zijn als ze een high level design van hun proces/product gaven, maar voor degenen die nu eenmaal graag alles wantrouwen zegt dat natuurlijk niks.
Bij gewoon gebruik wordt de vault inderdaad opnieuw encrypt als een gebruiker een nieuw master password genereert. Mijn opmerking ging daar niet over, maar over emergency gebruik. Als het master password verandert, moet het 'normale' gebeuren (dus opnieuw encrypten) en bovendien moet mijn vault key met de public key van de vertrouweling encrypt worden en verzonden worden..
Er is nu een onderwerp op het LP forum dat veel details geeft:
https://forums.lastpass.com/viewtopic.php?f=12&t=194685
Er is nu een onderwerp op het LP forum dat veel details geeft:
https://forums.lastpass.com/viewtopic.php?f=12&t=194685
Door Dick99999: Bij gewoon gebruik wordt de vault inderdaad opnieuw encrypt als een gebruiker een nieuw master password genereert. Mijn opmerking ging daar niet over, maar over emergency gebruik. Als het master password verandert, moet het 'normale' gebeuren (dus opnieuw encrypten) en bovendien moet mijn vault key met de public key van de vertrouweling encrypt worden en verzonden worden..
Er is nu een onderwerp op het LP forum dat veel details geeft:
https://forums.lastpass.com/viewtopic.php?f=12&t=194685
Er is nu een onderwerp op het LP forum dat veel details geeft:
https://forums.lastpass.com/viewtopic.php?f=12&t=194685
Thx. Dus (volgens een support man van LP ) is het inderdaad direct een hash van het masterpassword waarmee de vault gecrypt wordt.
Dan heb ik LP blijkbaar overschat - hoewel ik er geen security impact voor zie, denk ik dat een design met nog een laagje indirectie (random sessie key) wel enkele voordelen geboden zou hebben.
De reden zal wel historisch gegroeid zijn, en daarna de noodzaak van backwards compatibility zonder "type 2015 vaults kunnen niet met oude clients geopend worden" issues.
07-01-2016, 11:26 door
Dick99999
Door Anoniem:
Thx. Dus (volgens een support man van LP ) is het inderdaad direct een hash van het masterpassword waarmee de vault gecrypt wordt.
Nee, de (mijn) encryption key is een afleiding (salted, hashed, derived funtion,iteration) van mijn master password. Die key wordt met de public key van de vertrouweling encrypted op mijn PC. En dat resultaat wordt uiteindelijk, wanneer de wachtperiode over is, door de vertrouweling ontvangen met mijn encrypted vault.Thx. Dus (volgens een support man van LP ) is het inderdaad direct een hash van het masterpassword waarmee de vault gecrypt wordt.
Dan heb ik LP blijkbaar overschat - hoewel ik er geen security impact voor zie, denk ik dat een design met nog een laagje indirectie (random sessie key) wel enkele voordelen geboden zou hebben.
De reden zal wel historisch gegroeid zijn, en daarna de noodzaak van backwards compatibility zonder "type 2015 vaults kunnen niet met oude clients geopend worden" issues.
Door Dick99999:
Door Anoniem:
[..]
Dan heb ik LP blijkbaar overschat - hoewel ik er geen security impact voor zie, denk ik dat een design met nog een laagje indirectie (random sessie key) wel enkele voordelen geboden zou hebben.
De reden zal wel historisch gegroeid zijn, en daarna de noodzaak van backwards compatibility zonder "type 2015 vaults kunnen niet met oude clients geopend worden" issues.
Dat overschatten vind ik flauw. Het wordt een off-topic, maar ik denk dat er weinig voordelen te behalen zijn met een andere key. Als de key gekraakt wordt, maak het weinig uit of een random session key of mijn vault key is. En je moet voor elke sessie en elke vertrouweling een nieuwe encrypted vault maken en ergens buiten mijn PC opslaan.[..]
Dan heb ik LP blijkbaar overschat - hoewel ik er geen security impact voor zie, denk ik dat een design met nog een laagje indirectie (random sessie key) wel enkele voordelen geboden zou hebben.
De reden zal wel historisch gegroeid zijn, en daarna de noodzaak van backwards compatibility zonder "type 2015 vaults kunnen niet met oude clients geopend worden" issues.
Ik heb al twee berichten beschreven wat ik als voordelen zie om als encryptie key een random sessie key te gebruiken, en _die_ te encrypten met afgeleiden van master passwords.
Niet direct impacting op security, wel op meer gemak en betrouwbaarheid (reliablity).
Ah - misverstand bij je : ik bedoel met 'sessie key' niet dat deze key regelmatig verandert , maar random door het systeem gegenereerd wordt bij het initialiseren van een vault.
Ik heb de terminologie van (oa) pgp geleend - de random key die gebruikt wordt om een bericht te encrypten, en _die_ key is wat met public keys gecrypt wordt.
Voor het volume van lastpass vaults valt het blijkbaar voldoende mee, maar voor encrypted filesystems is zo'n constructie totaal noodzakelijk.
De truecrypt term is 'volume key' , en dat gebruikt precies die constructie die ik ook voor lastpass vaults verwachtte.
http://crypto.stackexchange.com/questions/18479/how-does-truecrypt-change-password-without-the-need-for-a-complete-re-encryption
08-01-2016, 10:01 door
Dick99999
Die session key heeft mij inderdaad op het verkeerde been gezet. Zo'n (permanente) random encryption/decryption key (die zelf weer encrypted wordt met een afgeleid wachtwoord) wordt ook door backup programma's gebruikt. Maar bijvoorbeeld Ocster en KPN (IASO) doen dat niet. En dus kan de sleutel van de backup daarbij nooit veranderd worden!
Het enige nadeel dat ik ken van zo'n permanente key is dat die (random) key moet worden opgeslagen en er dus ook een reserve kopie van gemaakt moet worden. Dat lees je ook bij truecrypt: als je sleutel beschadigd raakt, moet je een reserve kopie hebben.
Terug naar LP, ik vond 1 deel van antwoord op het LastPass forum gisteren opvallend (en de rest zeer geruststellend):
"Since this is the same technological solution as with our existing shared folders, except with the addition of the delay, ....
Er is dus 'altijd' al een private/public key pair geweest met een distributie mechanisme!
Het enige nadeel dat ik ken van zo'n permanente key is dat die (random) key moet worden opgeslagen en er dus ook een reserve kopie van gemaakt moet worden. Dat lees je ook bij truecrypt: als je sleutel beschadigd raakt, moet je een reserve kopie hebben.
Terug naar LP, ik vond 1 deel van antwoord op het LastPass forum gisteren opvallend (en de rest zeer geruststellend):
"Since this is the same technological solution as with our existing shared folders, except with the addition of the delay, ....
Er is dus 'altijd' al een private/public key pair geweest met een distributie mechanisme!
Door Dick99999:
[..]
Terug naar LP, ik vond 1 deel van antwoord op het LastPass forum gisteren opvallend (en de rest zeer geruststellend):
"Since this is the same technological solution as with our existing shared folders, except with the addition of the delay, ....
Er is dus 'altijd' al een private/public key pair geweest met een distributie mechanisme!
[..]
Terug naar LP, ik vond 1 deel van antwoord op het LastPass forum gisteren opvallend (en de rest zeer geruststellend):
"Since this is the same technological solution as with our existing shared folders, except with the addition of the delay, ....
Er is dus 'altijd' al een private/public key pair geweest met een distributie mechanisme!
Ik gebruik geen LP, dus ik wist niet dat ze al een shared folder model hadden.
Als ik aanneem dat de discussie en de vragen vooral van LP gebruikers zijn snap ik wat minder dat ze niet dezelfde vragen en zorgen al hadden bij shared folders .
Want een stukje tijdvertraging met voorwaarden in het vrijgeven van een toegangssleutel (+kopie folder) is het enige verschil tussen een shared folder en een nabestaanden-optie.
Sinds LP 4.0 werkt auto fill-in niet meer, niet meer onder IE en al helemaal niet met W10. Kom dit euvel -nog- nergens tegen duw ligt waarschijnlijk aan eigen comp.
Ik zou dat op het LP support forum melden, lijkt mij beter. Bij mij werkt LP 4.0/4.1 met Firefox en Win 10 gewoon wat invullen betreft. De nieuwe features werken gedeeltelijk bij mij. De bugs lijken bug voor bug opgelost te worden.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
