Managing encryption keys with database
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I'm stuck at the design level of implementing end-to-end encryption with Firebase Firestore.
Let's say that I store user's private key on his device, what should i do when user decides to uninstall the app and install it later, or when he loses his device?
Given that his encryption key is stored only on his device, everything gets lost, do i just create new private key and "mark" his previous data as inaccessible?
The simple solution that i can think of is storing the user's private key in the database, but that's not really the goal.
firebase encryption google-cloud-firestore
asked Nov 15 '18 at 15:48
WiktorWiktor
13611
add a comment |
I'm stuck at the design level of implementing end-to-end encryption with Firebase Firestore.
Let's say that I store user's private key on his device, what should i do when user decides to uninstall the app and install it later, or when he loses his device?
Given that his encryption key is stored only on his device, everything gets lost, do i just create new private key and "mark" his previous data as inaccessible?
The simple solution that i can think of is storing the user's private key in the database, but that's not really the goal.
firebase encryption google-cloud-firestore
asked Nov 15 '18 at 15:48
WiktorWiktor
13611
add a comment |
I'm stuck at the design level of implementing end-to-end encryption with Firebase Firestore.
Let's say that I store user's private key on his device, what should i do when user decides to uninstall the app and install it later, or when he loses his device?
Given that his encryption key is stored only on his device, everything gets lost, do i just create new private key and "mark" his previous data as inaccessible?
The simple solution that i can think of is storing the user's private key in the database, but that's not really the goal.
firebase encryption google-cloud-firestore
asked Nov 15 '18 at 15:48
WiktorWiktor
13611
I'm stuck at the design level of implementing end-to-end encryption with Firebase Firestore.
Let's say that I store user's private key on his device, what should i do when user decides to uninstall the app and install it later, or when he loses his device?
Given that his encryption key is stored only on his device, everything gets lost, do i just create new private key and "mark" his previous data as inaccessible?
The simple solution that i can think of is storing the user's private key in the database, but that's not really the goal.
firebase encryption google-cloud-firestore
firebase encryption google-cloud-firestore
asked Nov 15 '18 at 15:48
WiktorWiktor
13611
asked Nov 15 '18 at 15:48
WiktorWiktor
13611
asked Nov 15 '18 at 15:48
WiktorWiktor
13611
asked Nov 15 '18 at 15:48
WiktorWiktor
13611
asked Nov 15 '18 at 15:48
WiktorWiktor
13611
13611
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
If the user loses their private key, you have two options:
- You declare their data lost
- You give them a way to recover their key
Both are valid options, but #2 seems to be by far the most common with Cloud-based data storage services.
If you'd store the recovery key and private in the same database, anyone with physical access to the database also has access to the keys that are needed to decrypt the data. So that's a bad practice.
The most important thing with a recovery service is that you don't store the private and recovery keys in the same place as the user's data. You could use a complete separate database (I'd recommend thinking of a different provider altogether), or any other physically separated mechanism.
answered Nov 15 '18 at 16:00
Frank van PuffelenFrank van Puffelen
247k31394423
What if i also made an option without end-to-end encryption? Is the data that flows to firestore documents encrypted by them, or it's just like easy to get plain text data? I know that they encrypt the data once it gets to the server but what about the sending process?
– Wiktor
Nov 15 '18 at 16:33
All traffic goes over SSL, so is encrypted end-to-end already. All disks are also encrypted, so data is encrypted at rest too.
– Frank van Puffelen
Nov 15 '18 at 18:14
add a comment |
Here is the keybase.io solution you might want to refer to.
In short,
- User is recommended to register multiple devices where each device has a separate pair of keys
- User needs an already registered device to be able to register a new device
- If user loses a device, he/she should be able to access the account with another registered device and delete the stolen device from the system
answered Nov 15 '18 at 16:06
Saptarshi BasuSaptarshi Basu
2,22721927
I had a slight idea of how to make it if the user has another device, but actually registering those devices in this way looks interesting, i'll definitely look into it, thanks
– Wiktor
Nov 15 '18 at 18:33
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53323103%2fmanaging-encryption-keys-with-database%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
If the user loses their private key, you have two options:
- You declare their data lost
- You give them a way to recover their key
Both are valid options, but #2 seems to be by far the most common with Cloud-based data storage services.
If you'd store the recovery key and private in the same database, anyone with physical access to the database also has access to the keys that are needed to decrypt the data. So that's a bad practice.
The most important thing with a recovery service is that you don't store the private and recovery keys in the same place as the user's data. You could use a complete separate database (I'd recommend thinking of a different provider altogether), or any other physically separated mechanism.
answered Nov 15 '18 at 16:00
Frank van PuffelenFrank van Puffelen
247k31394423
What if i also made an option without end-to-end encryption? Is the data that flows to firestore documents encrypted by them, or it's just like easy to get plain text data? I know that they encrypt the data once it gets to the server but what about the sending process?
– Wiktor
Nov 15 '18 at 16:33
All traffic goes over SSL, so is encrypted end-to-end already. All disks are also encrypted, so data is encrypted at rest too.
– Frank van Puffelen
Nov 15 '18 at 18:14
add a comment |
If the user loses their private key, you have two options:
- You declare their data lost
- You give them a way to recover their key
Both are valid options, but #2 seems to be by far the most common with Cloud-based data storage services.
If you'd store the recovery key and private in the same database, anyone with physical access to the database also has access to the keys that are needed to decrypt the data. So that's a bad practice.
The most important thing with a recovery service is that you don't store the private and recovery keys in the same place as the user's data. You could use a complete separate database (I'd recommend thinking of a different provider altogether), or any other physically separated mechanism.
answered Nov 15 '18 at 16:00
Frank van PuffelenFrank van Puffelen
247k31394423
What if i also made an option without end-to-end encryption? Is the data that flows to firestore documents encrypted by them, or it's just like easy to get plain text data? I know that they encrypt the data once it gets to the server but what about the sending process?
– Wiktor
Nov 15 '18 at 16:33
All traffic goes over SSL, so is encrypted end-to-end already. All disks are also encrypted, so data is encrypted at rest too.
– Frank van Puffelen
Nov 15 '18 at 18:14
add a comment |
If the user loses their private key, you have two options:
- You declare their data lost
- You give them a way to recover their key
Both are valid options, but #2 seems to be by far the most common with Cloud-based data storage services.
If you'd store the recovery key and private in the same database, anyone with physical access to the database also has access to the keys that are needed to decrypt the data. So that's a bad practice.
The most important thing with a recovery service is that you don't store the private and recovery keys in the same place as the user's data. You could use a complete separate database (I'd recommend thinking of a different provider altogether), or any other physically separated mechanism.
answered Nov 15 '18 at 16:00
Frank van PuffelenFrank van Puffelen
247k31394423
If the user loses their private key, you have two options:
- You declare their data lost
- You give them a way to recover their key
Both are valid options, but #2 seems to be by far the most common with Cloud-based data storage services.
If you'd store the recovery key and private in the same database, anyone with physical access to the database also has access to the keys that are needed to decrypt the data. So that's a bad practice.
The most important thing with a recovery service is that you don't store the private and recovery keys in the same place as the user's data. You could use a complete separate database (I'd recommend thinking of a different provider altogether), or any other physically separated mechanism.
answered Nov 15 '18 at 16:00
Frank van PuffelenFrank van Puffelen
247k31394423
answered Nov 15 '18 at 16:00
Frank van PuffelenFrank van Puffelen
247k31394423
answered Nov 15 '18 at 16:00
Frank van PuffelenFrank van Puffelen
247k31394423
answered Nov 15 '18 at 16:00
Frank van PuffelenFrank van Puffelen
247k31394423
247k31394423
What if i also made an option without end-to-end encryption? Is the data that flows to firestore documents encrypted by them, or it's just like easy to get plain text data? I know that they encrypt the data once it gets to the server but what about the sending process?
– Wiktor
Nov 15 '18 at 16:33
All traffic goes over SSL, so is encrypted end-to-end already. All disks are also encrypted, so data is encrypted at rest too.
– Frank van Puffelen
Nov 15 '18 at 18:14
add a comment |
What if i also made an option without end-to-end encryption? Is the data that flows to firestore documents encrypted by them, or it's just like easy to get plain text data? I know that they encrypt the data once it gets to the server but what about the sending process?
– Wiktor
Nov 15 '18 at 16:33
All traffic goes over SSL, so is encrypted end-to-end already. All disks are also encrypted, so data is encrypted at rest too.
– Frank van Puffelen
Nov 15 '18 at 18:14
What if i also made an option without end-to-end encryption? Is the data that flows to firestore documents encrypted by them, or it's just like easy to get plain text data? I know that they encrypt the data once it gets to the server but what about the sending process?
– Wiktor
Nov 15 '18 at 16:33
What if i also made an option without end-to-end encryption? Is the data that flows to firestore documents encrypted by them, or it's just like easy to get plain text data? I know that they encrypt the data once it gets to the server but what about the sending process?
– Wiktor
Nov 15 '18 at 16:33
All traffic goes over SSL, so is encrypted end-to-end already. All disks are also encrypted, so data is encrypted at rest too.
– Frank van Puffelen
Nov 15 '18 at 18:14
All traffic goes over SSL, so is encrypted end-to-end already. All disks are also encrypted, so data is encrypted at rest too.
– Frank van Puffelen
Nov 15 '18 at 18:14
add a comment |
Here is the keybase.io solution you might want to refer to.
In short,
- User is recommended to register multiple devices where each device has a separate pair of keys
- User needs an already registered device to be able to register a new device
- If user loses a device, he/she should be able to access the account with another registered device and delete the stolen device from the system
answered Nov 15 '18 at 16:06
Saptarshi BasuSaptarshi Basu
2,22721927
I had a slight idea of how to make it if the user has another device, but actually registering those devices in this way looks interesting, i'll definitely look into it, thanks
– Wiktor
Nov 15 '18 at 18:33
add a comment |
Here is the keybase.io solution you might want to refer to.
In short,
- User is recommended to register multiple devices where each device has a separate pair of keys
- User needs an already registered device to be able to register a new device
- If user loses a device, he/she should be able to access the account with another registered device and delete the stolen device from the system
answered Nov 15 '18 at 16:06
Saptarshi BasuSaptarshi Basu
2,22721927
I had a slight idea of how to make it if the user has another device, but actually registering those devices in this way looks interesting, i'll definitely look into it, thanks
– Wiktor
Nov 15 '18 at 18:33
add a comment |
Here is the keybase.io solution you might want to refer to.
In short,
- User is recommended to register multiple devices where each device has a separate pair of keys
- User needs an already registered device to be able to register a new device
- If user loses a device, he/she should be able to access the account with another registered device and delete the stolen device from the system
answered Nov 15 '18 at 16:06
Saptarshi BasuSaptarshi Basu
2,22721927
Here is the keybase.io solution you might want to refer to.
In short,
- User is recommended to register multiple devices where each device has a separate pair of keys
- User needs an already registered device to be able to register a new device
- If user loses a device, he/she should be able to access the account with another registered device and delete the stolen device from the system
answered Nov 15 '18 at 16:06
Saptarshi BasuSaptarshi Basu
2,22721927
answered Nov 15 '18 at 16:06
Saptarshi BasuSaptarshi Basu
2,22721927
answered Nov 15 '18 at 16:06
Saptarshi BasuSaptarshi Basu
2,22721927
answered Nov 15 '18 at 16:06
Saptarshi BasuSaptarshi Basu
2,22721927
2,22721927
I had a slight idea of how to make it if the user has another device, but actually registering those devices in this way looks interesting, i'll definitely look into it, thanks
– Wiktor
Nov 15 '18 at 18:33
add a comment |
I had a slight idea of how to make it if the user has another device, but actually registering those devices in this way looks interesting, i'll definitely look into it, thanks
– Wiktor
Nov 15 '18 at 18:33
I had a slight idea of how to make it if the user has another device, but actually registering those devices in this way looks interesting, i'll definitely look into it, thanks
– Wiktor
Nov 15 '18 at 18:33
I had a slight idea of how to make it if the user has another device, but actually registering those devices in this way looks interesting, i'll definitely look into it, thanks
– Wiktor
Nov 15 '18 at 18:33
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53323103%2fmanaging-encryption-keys-with-database%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
