3

I want to store a file encrypted on the user's device for offline access. Since they don't have an internet connection, they can't sign in with their username/password and receive a secret key, so my thought is that I could derive a key directly from their password. They are using a non-windows device, so cannot use something like DPAPI.

The scheme is essentially: User's password is run through some key derivation function like pbkdf2 to get an acceptable strength key. This key is used to encrypt the file locally and can be generated on the fly when offline by having the user input their password.

Questions:

1) You can run a billion iterations of pbkdf2, but if their password is a single character it won't help much. Does this change if there is a mandatory password policy that ensures at least relatively sane passwords?

2) Alternative key generation techniques?

3) Overall thoughts/suggestions?

4) This gives an offline attack method to get their password for the service which has access to a whole lot more than just this file. Seems like this adds substantial risk. Thoughts?

Gerald Oswald
  • 31
  • 1

1 Answers1

1

Sounds alright to me. I'll answer your questions and add some thoughts:

1) You can run a billion iterations of pbkdf2, but if their password is a single character it won't help much. Does this change if there is a mandatory password policy that ensures at least relatively sane passwords?

I personally hate password policies, but I'm not your average user. You could consider warning them (saying 8 characters non-dictionary is a reasonable password) but otherwise leave them free to do what they want. Maybe when they try to use a 3-character password or less, give a pop up going "that one sucks, do you maybe want to leave the file unencrypted instead? [y/n]" ;)

2) Alternative key generation techniques?

See How to securely hash passwords? for some ideas. They are not strictly key-derivation functions, but I think you can use things like scrypt and bcrypt the same way.

4) This gives an offline attack method to get their password for the service which has access to a whole lot more than just this file. Seems like this adds substantial risk. Thoughts?

Good point! It does give away offline cracking, but only for one user. In the case that password file gets stolen, the attacker could probably modify the device to include a keylogger anyway.

3) Overall thoughts/suggestions?

  • Besides a key-derivation function, also look at how you encrypt the file. You'll want to use authenticated encryption, or at the very least, a block cipher mode of operation (i.e. don't use ECB).

  • You could also encrypt the file with a randomly generated key (using a CSPRNG) and then encrypt that key with the user's password. If the user wants to change the password, they can do that without re-encrypting all the data. You only have to re-encrypt the key.

  • Users don't like it when there is no "I forgot my password" option. I am in favor of saying "this is how every file storage service should work anyway so stop complaining" but that's simply not acceptable for many companies. You could encrypt the key (see my previous point) not just with the user's password, but separately also with your public key. Then the password reset feature can use the private key (stored on the server only) to decrypt the key and allow for a password reset. This also means you have access to user's data, though.

Community
  • 1
Luc
  • 31,973
  • 8
  • 71
  • 135