[BUG] - Enter wrong password shows the encrypted folders (name)

[ricassiocosta]

Describe the bug
If a create a folder using a legitimate password, store some files there, close the vault and tries to open the vault using a wrong password, although the files encrypted are not accessible, the name of folders and their location are displayed. This can potentially expose sensitive information, like if the user uses folders category naming.

To Reproduce
Steps to reproduce the behavior:

1. Go to Valv login page and login using some password (lets call this password1)
2. Click on add folder and create a new folder
3. Click on Import files and select some file to import
4. Click on the lock icon
5. Login again using a different password (password2)
6. Note that the folder previously created are displayed, although the files encrypted are not accessible.

Expected behavior
Neither the files encrypted or the folders created should be visible if I login different passwords.

Smartphone (please complete the following information):

• Device: Samsung Galaxy S23
• OS: Android 13 - One UI 6
• Version 1.6.1 (22)

[ricassiocosta]

An additional comment regarding this issue, is that the encrypted files shows in their names the extension of the original file... This seems to be a security issue for me. This could potentially lead to extortion.

[hej2010]

The problem with hiding the folders that contain files encrypted using a different key is that you need to store a relation between the encryption key and those folders (e.g. the hash of the password/key together with the folder path). If you move around files or move files between devices the app won't know that and it can e.g. hide folders that should not be hidden and the other way around.

The encrypted file extension is added automatically by Android but I can try to make an update that removes it

[ricassiocosta]

The problem with hiding the folders that contain files encrypted using a different key is that you need to store a relation between the encryption key and those folders (e.g. the hash of the password/key together with the folder path). If you move around files or move files between devices the app won't know that and it can e.g. hide folders that should not be hidden and the other way around.

The encrypted file extension is added automatically by Android but I can try to make an update that removes it

I think this could be solved by showing only the files that the informed key can decrypt. If a folder has no file that can be decrypted by using the informed key, the folder should be hidden from the viewer. This would avoid someone to add different files using different keys in a same folder for example.
Another issue that I have noticed, is that in this same scenario that someone adds different files using different keys in a same folder, is that the file counter shows that total amount of files inside that folder...

• Imagine user using a key A encrypt 2 files.
• This user logout and login using key B (here is the issue that using key B the user will still be able to see the folder and the amount of files inside that folder encrypted using key A)
• The user than, adds 2 more files using key B.
• Now the counter shows 4 files in that folder.
• A third person - potentially a threat actor - logins using key C. Now the threat actor knows that the user has 4 files encrypted, and extort the user to give the legimate key.
• The user gives the key B - He thought to create a fake-hidden storage to store less important files to mock the actual ones.
• But this key only decrypt 2 files, and the counter shows 4. So, now the user has a big problem.

[hej2010]

Yes, but that would require trying to decrypt every file in the folder, it will be very slow if you have a lot of files

[ricassiocosta]

Maybe you can create kinda of a "header file" in each folder. A file that would be used to verify if a given key can decrypt that folder. Yes, this would be a new "business requirement", that would enforce each folder to have a specific key to encrypt/decrypt the whole content. If I'm not wrong, TrueCrypt use a similar strategy to verify if a given key is valid to decrypt a container or not.

[xxxserxxx]

If a create a folder using a legitimate password, store some files there, close the vault and tries to open the vault using a wrong password, although the files encrypted are not accessible, the name of folders and their location are displayed.

I have been creating folders with the app, but the folder names are never encrypted. File names are, but never folder names.

I was going to file a feature request, but I must be using Valv wrong - what's necessary to have Valv encrypt the folder names?

[hej2010]

I have been creating folders with the app, but the folder names are never encrypted. File names are, but never folder names.

I was going to file a feature request, but I must be using Valv wrong - what's necessary to have Valv encrypt the folder names?

You can't encrypt/hide the folder names, all files are stored in a regular file hierarchy on your phone.

If you create a folder "A" in the app it simply creates a folder named "A" on your device and stores all the files inside.

[ricassiocosta]

I have been creating folders with the app, but the folder names are never encrypted. File names are, but never folder names.
I was going to file a feature request, but I must be using Valv wrong - what's necessary to have Valv encrypt the folder names?

You can't encrypt/hide the folder names, all files are stored in a regular file hierarchy on your phone.

If you create a folder "A" in the app it simply creates a folder named "A" on your device and stores all the files inside.

What about hashing the folder name? The encrypt suggestion using the same algo that encrypt the file names would be enough

[xxxserxxx]

@ricassiocosta the point to hashing is that it's not reversible. You can regenerate the hash if you know the original data, but you can't unhash a hash. You could leave the directory names hashed, but that's not an optimal user experience. You could encrypt the name, but you'd need to store the salt, IV, and iteration count for each directory somewhere, which means metadata for each directory. You could embed the salt, IV, and iteration count in the encrypted direcory name, but that adds 32 bytes to each directory name, and it completely ignores the check step. Or, you create one metadata file with the salt and IV, but then you greatly weaken your security, as you're giving an aattacker a lot of test data to brute force break your key.

I see what @hej2010's issue is here. It's possible, obviously, but it's less simple than it appears.