-
-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Password profiles should be encrypted #185
Comments
Yes AES encryption with the master password edit: LessPass does not (yet) encrypt password profiles on LessPass Database. |
Could you clarify which AES algorithm is being used? thanks ! |
Also, could you please clarify that if the master password is being used to encrypt the profile, how is it being stored in the LessPass app? Is a Hash of the master password used as the AES encryption key, or is the password itself being used? |
My first idea was to encrypt password profile with the master password after pbkdf2. |
I'm by no means an expert on security, would it be better to encrypt each string with the password after pbkdf2 and upload/download the json block with the encrypted strings instead of the plain text strings, or to encrypt the whole json block as a unit and upload that? Here is what I mean (assuming I am not making sense):
vs
note, these strings mean nothing other than how I smashed my hands on the keyboard |
If you encrypt the hole json block. The only Information you can get out of it is the length of the encrypted data. Also changes give you just a information about the length. If the values are encrypted, than you can easily find out if there was a password added, removed or probably even linked, because the other passwords are not reencrypted with another IV. On the other hand if you have decrypted data lying around, in the case of hole json encryption the hole content will be decrypted. In case of separate encryption there could be a password inserted without interfering with the other encrypted data. I would prefer the hole json file to be encrypted. |
@guillaumevincent, you mentioned encrypting the profiles with the "master password" after a pbkdf2. By "master password" do you mean the account password or the password that is added to the other attributes to create the hash? I've worked a lot with python, some with encryption. I'd love to help build this out. |
This is not an easy one because:
The password profile should be encrypted on client side, using a local encryption key. This key should be derived from your master password using pbkdf2 and at least 100k iterations. See https://security.stackexchange.com/questions/157422/store-encrypted-user-data-in-database for the workflow |
That's an issue I'd be happy to work with.
I like @guillaumevincent proposition. Nevertheless, if the whole encryption is done client side, i don't thing there is much to do server-side. I also think that the encryption can be automatically done during the next user's connection and be totally transparent to the user (so no ui changes). |
@FaustXVI on the backend we need to create an encrypted user key field. We also need to update the password update mechanism. So no there is a little work to do :) On ui side we need to update the code, to build this key after the first re connection and save it. on ui side during the login:
if key2 exists
if no key2 in database create key2:
|
@guillaumevincent yep, I think we agree. When i was say "no work on the backend" i was talking about logic code (if this then that). |
yes exactly Feel free to start this if you want, one step at a time |
I am thinking to start with the key generation, even if it's not used at first. The idea is that we can have it in production first, even if it doesn't change anything. |
sounds good to me |
I just realized that the "forgot your password ?" feature won't be usable anymore once we encrypted data. |
Yes this is the drawback of using encrypted password profiles, we lost the capability to get old password profiles when we lost our password. Because you are using your master password, we assume you always remember it. |
Ok, so what should we start with ?
I created #457 for the password change. |
#457 first yes 👍 |
I'm gonna try to take a look at this. @guillaumevincent what do you think, instead of using two keys and a random key, we can just use another model like
I don't think we need to save the encrypted_key in the database in that scenario, we can just keep a boolean flag to see if the user is using the encrypted profile. That'd probably allow us to encrypt password profiles slowly, and we can generate a random key later if we feel like migrating the old profiles. |
Hello, |
@biancarosa Thank you so much for your work ! I am so overdue ! You clearly removed a huge weight from my shoulders ! |
Hello. Thanks for this project and really useful associated tools. |
Hello @lolo120916, |
LessPass Database will be closed in March. See announcement. This issue is no longer relevant. Closing it. |
I don't see any encryption of settings, that are stored on the server. I think this is a privacy issue. Is it possible to encrypt the settings with the masterpassword?
The text was updated successfully, but these errors were encountered: