Generating cryptographic keys

[Stefan Arentz]

Hey all,

My application that lets people sign in with BrowserID. I am now exploring ways to encrypt user data in my app.

What I would do if I were not using BrowserID is encrypt the data with user specific keys that are derived from the password. In a user record I would store a 'wrapped' key. The wrapped key simply is a random generated key that is encrypted (wrapped) with some hash of the user's password. (This is very much like what Firefox Sync does)

So I specifically have two cases that I know how to implement with a traditional username/password login but not with BrowserID.

1) When the user logs in, i can decrypt a wrapped key using the user's password. I then keep this key around for the session and use it to use/encrypt/decrypt the user's data.

2) When the user changes his password I re-wrap the key

With BrowserID there is no password, so I am not sure what to do here. I don't see anything usable in the verification receipt either that I could use.

I'm interested in discussing solutions or alternatives.

S.

[Ben Adida]

Hi Stefan,

Thanks for your comment here.

> What I would do if I were not using BrowserID is encrypt the data
> with user specific keys that are derived from the password.

This approach is a bit problematic: you don't want to use the same
password both for authentication and key-generation.

> random generated key that is encrypted (wrapped) with some hash of
> the user's password. (This is very much like what Firefox Sync does)

You mean something like PBKDF2, I think:
https://secure.wikimedia.org/wikipedia/en/wiki/PBKDF2

(just mentioning this because it's not a good idea to just hash a
password before using that as an encryption key.)

> With BrowserID there is no password, so I am not sure what to do
> here. I don't see anything usable in the verification receipt either
> that I could use.

Indeed, there is no good way to do what you're trying to do now. You
could prompt for an extra passphrase, which is what you would want to do
anyways to separate auth from encryption. We may want to think about how
to support this kind of functionality in BrowserID.

To help think through this, can you lay out a bit more of your use case?
This is all for localStorage encryption?

-Ben

[David Dahl]

Stefan:

You may be interested in the DOMCrypt API, which is going to be included in a W3C working group later this year.

https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

Cheers,

David

----- Original Message -----
From: "Stefan Arentz" <sar...@mozilla.com>
To: dev-id...@lists.mozilla.org
Sent: Thursday, September 15, 2011 9:05:02 AM
Subject: Generating cryptographic keys

Hey all,

My application that lets people sign in with BrowserID. I am now exploring ways to encrypt user data in my app.

What I would do if I were not using BrowserID is encrypt the data with user specific keys that are derived from the password. In a user record I would store a 'wrapped' key. The wrapped key simply is a random generated key that is encrypted (wrapped) with some hash of the user's password. (This is very much like what Firefox Sync does)

So I specifically have two cases that I know how to implement with a traditional username/password login but not with BrowserID.

1) When the user logs in, i can decrypt a wrapped key using the user's password. I then keep this key around for the session and use it to use/encrypt/decrypt the user's data.

2) When the user changes his password I re-wrap the key

With BrowserID there is no password, so I am not sure what to do here. I don't see anything usable in the verification receipt either that I could use.

I'm interested in discussing solutions or alternatives.

S.

_______________________________________________
dev-identity mailing list
dev-id...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-identity

[Stefan Arentz]

On 2011-09-15, at 3:03 PM, David Dahl wrote:

> Stefan:
>
> You may be interested in the DOMCrypt API, which is going to be included in a W3C working group later this year.
>
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

Sorry I should have been more clear about this: I'm talking all server-side. No JS involved.

S.

[Peter]

Let's say u lose my laptop. It's password is typically broken easily (given human nature). This means encrypted data stored locally is compromised, and you can be spoofed online.

Of course the same is true for digitalids built into browsers for nearly 2 decades.

How does browserid enable the compromised party to recover (from a pretty common event -losing a laptop or other portable device)?

[Dan Mills]

Hi Peter,

This is an unrelated question to what Stefan was asking about--but the answer is that BrowserID uses short-term keys on each client to limit this threat. So there is still a threat window, but it is limited. Eventually the device needs to re-authenticate to get new certificates.

Dan

[Stefan Arentz]

On 2011-09-15, at 5:56 PM, Ben Adida wrote:

>
> Hi Stefan,
>
> Thanks for your comment here.
>

>> What I would do if I were not using BrowserID is encrypt the data
>> with user specific keys that are derived from the password.
>

> This approach is a bit problematic: you don't want to use the same password both for authentication and key-generation.

Sorry for the confusion. I understand that 'app' now means 'client side web app' in our world :- However, I am talking about a case where everything happens server-side.

So wether this is good practice not, I think it totally depends on the type of app. And the security constraints of your project. (FWIW, my question was not about the Mozilla project that I work)

For the app that I am looking at it actually makes a lot of sense to encrypt some items attached to user's profiles with a key derived from the same password that is used to login to the web app:

1) Users will not be bothered with multiple passwords. Which is a *major* thing when it comes to usability. Less things to remember is better. This is a major advantage of BrowserID obviously.

2) Whenever my database or a user record leaks for some reason, people cannot see any of the sensitive data that is stored in a user record since it is encrypted with a unique key per user. They would have to brute force each and every key or know specific keys. For me that is an acceptable risk. And much better than no encryption at all.

I think this is a pretty common case for many web apps. So I'm a bit stuck here. It seems that the only way to go forward with BrowserID is, as you suggested, to introduce a password in my app again :-/

S.

[Ben Adida]

Hi Stefan,

> So wether this is good practice not, I think it totally depends on the type of app.

I probably didn't explain my point very well. What I mean to say is that
it's tricky to do the crypto right if you want to derive a key from a
passphrase whose hash (bcrypt) you're also storing. This does not depend
on the type of app, it's just a fact of crypto.

And one has to consider that, if there is a false sense of security that
might exist if you think "oh, well this data is encrypted, it's all
good" if there is a weakness in the correlation between the key and the
bcrypted password.

(Mind you, I'm not telling you there's a clear attack, I'm just saying
"danger, you're in a very grey area.")

I do understand the point you're making though, and so to understand it
more thoroughly, I have one question for you: how do you handle a
password change?

> I think this is a pretty common case for many web apps.

I'm not sure it's quite that common, but of course it's nice to
encourage more secure practices.

Another question: are you decrypting in the browser or on the server?

-Ben