keepass2android
keepass2android copied to clipboard
PhilippC
Android 12 can't decrypt existing database
Pixel 4A, fresh new Android 12. Database with key says "invalid composite key or password" (doesn't matter local or remote db) although both keyfile and password are correct. KeePassDroid opens that db successfully.
Getting the same issue on a Pixel 5 after upgrading to Android 12. Before the OS update everything worked as usual.
Same here. Pixel 5, upgraded to Android 12, and now I cannot open the database.
I can't reproduce this on Android 12. Can you give details about which kdbx version and which Encryption/KDF settings you are using?
Maybe you can even produce a sample database file which you can share here for testing?
If I create a new db everything works fine, the issue is reproducible on old db. I don't actually know which version of db can't be decrypted. I see this logs in logcat:
2021-10-26 10:17:42.426 28962-32557/? D/KP2A: status submessage: Decoding database…
2021-10-26 10:17:42.433 28962-28962/? D/KP2A: OnFinish message: Invalid composite key! Please try again.
can you open the database wtih another port (e.g. Keepassdroid) or on a PC with KeepassXC/KeePass2?
I had the same problem and while testing I discovered keys created by keepassXC are working, while other files are not working i.e. jpg. When I want to change the derivative function the error message "not a whole file" is shown. I think it depends if the key file is padded to a correct size or not.
@daniel8192 thanks for the input! @vitalymak @hallmichael868 @dvdfrd can you confirm you are using similar key files?
@PhilippC yep, the issue is definitely in key processing because I've changed key using keepassx and now I can open the db.
I created a new DB and a new key with KeePass 2.49 to check and the same error occurred. The error I'm getting is: "Invalid composite key! Please try again"
Files are attached. Password is: checkthisout keynotworkingandroid.zip
Greetings, my Samsung S20 just updated to Android12 and now I got the same Invalid composite key as well. The master DB is on Windows, created with KeePass, I use in addition of the master password a jpg file as key file.
I made some research with a test DB and figured out, the error only comes up, when the key file is on the local filesystem of my Samsung. When I put this to Dropbox or Google Drive, everything is working again. For me it looks like, the answer of the filesystem access has changed form Android 11 to 12 and therefor the key has changed. It doesn't matter, if its a fresh DB or the old one.
I'm not so happy with a key file in the cloud and would like to switch back to a local one.
regards Jan
I've run another test. And I think this issue might be specifically for key files which aren't created with Keepass but are binary files. What created the "invalid composite key" error in keepass2android: Create a new database and use an image file as key and a normal password Try to open it in in keepass2android
What works in keepass2android: Use the database from above and change the masterkey to use an key file created by Keepass. Open the database again in keepass2android. Observe that it opens correctly without error
@hallmichael868 I tried to reproduce this but on a Pixel 4a with Android 12 I can open the attached files (master password is test). Can you try with those as well, please?
binary-keyfile.zip
@PhilippC I used your files and was able to unlock the database without problem.
Now that puzzled me of course. Why does it work with your test files and not mine. So I ran some more tests. And after a few hours and like 20 test or so and eventually narrowed it down.
It seems like the EXIF meta data is the issue. If the key file has a lot of EXIF meta data, as is usual for smartphones or modern digital cameras, it works as a key file for Keepass in windows but doesn't unlock in Keepass2Android. I tried using the same image, once with meta data and once without (removed it with Irfanview). With the EXIF meta data it doesn't work and after removing the meta data the image can be used as a key file successfully even though the content of the image is exactly the same. Why that is I don't know, but it might have something to do with how jpg files and their headers are formatted? I also wonder if other binary files are affected.
I've found an image created with a Pixel6 from a phone review with a lot of meta data, changed the master key of your database to use it, and attached both files. Please find both files attached. Those should allow you to recreate the issue.
I just can confirm what @hallmichael868 wrote. There seems to happen something different on android 12 if you select an image/media than opening a non media file. My keyfile is a .jpg file and I had the same issues. As soon as I renamed the file to .key, with the exact same content, I was able to open the DB. The used function to load the keyfile needs to be configured to raw mode and not taking care of media types.
@hallmichael868 that's an interesting observation, thanks for taking the time to investigate! Are you saying the file you attached can not be opened from KP2A? Because on my device it does work. If it doesn't work for you, can you tell me which app version you are using (please see settings - about)?
@hallmichael868 that's an interesting observation, thanks for taking the time to investigate! Are you saying the file you attached can not be opened from KP2A? Because on my device it does work. If it doesn't work for you, can you tell me which app version you are using (please see settings - about)?
@PhilippC @hallmichael868 sorry for joining so late, but I was some kind of busy during the last days.
I was able to open both of your test databases with the local stored key files. I took the hint with the EXIF data in key files and voilá after removing the EXIF data from my picture I was able to used it as key file stored local on my Galaxy S20 for KP2A again.
I've no clue what Android 12 is doing during a file open of a image/jpeg in opposite of previous versions, but for me the workaround is good enough. I also do not see EXIF data in the key file as security measure and suggest to put a hint in the documentation to remove the EXIF data completely from a key file, if there are errors. BTW. if someone ask how to do this quickly:
exiftool -all= filename.jpg
Thank you for your time to figure the solution out. I really appreciated this.
@PhilippC , please keep KP2A running, for me it's the best password safe, that can sync with windows
br Jan
that's an interesting observation, thanks for taking the time to investigate! Are you saying the file you attached can not be opened from KP2A? Because on my device it does work. If it doesn't work for you, can you tell me which app version you are using (please see settings - about)?
@PhilippC Indeed. Those files don't work for me. Just retested it to make sure. I'm using KP2A Offline latest version (1.08d-r5) on stock Android 12.
I found this Issue when I was trying to figure out why I cant open database on both phone and desktop. It seems to be happening somehow due to the length of the password.
- Create database in KeepassXC with short password like "pass". Copy to the phone - everything works.
- Same if database is created in phone app vice versa
- Fails if password length is 30 or more. Don't know exact number, 20 - is ok.
I'm using Xiaomi with Android 11 though.
I have upgraded my phone to android 12 and a keepass database can't be open after even that is possible on desktop. I store the database outside a default location and use a jpg file as a key. But when a new database is created by the app with the non-default location too it is possible top open it. However I get then an error message something like that 'com.android.externalstorage has no access to content: .....' but the application is functional.
I haven't found out what exactly is causing this, but there is a problem with jpg files as key files. Can you change this to a new key file (on PC)?
@PtrToObject have you tried my advise from Feb. 3rd?
I've no clue what Android 12 is doing during a file open of a image/jpeg in opposite of previous versions, but for me the workaround is good enough. I also do not see EXIF data in the key file as security measure and suggest to put a hint in the documentation to remove the EXIF data completely from a key file, if there are errors. BTW. if someone ask how to do this quickly: exiftool -all= filename.jpg
Since I've removed all EXIF data from the jpg, everything is workimg again. cheers Jan
I haven't found out what exactly is causing this, but there is a problem with jpg files as key files. Can you change this to a new key file (on PC)?
Yes if text based file types, like a .key file are used it works. But the issue might exist for other media files like audio or video as well. Or even other non text based file types. But since it's only happened after upgrading to Android 12, I suppose it also has something to do with how Android handles these files and/or how they are handled/parsed in KP2A. Manually removing the EXIF data is something that a (quite tech savvy) user can do as a desperate workaround, but not something that the user should have to do at all.
Similar issue after updating a pixel4a. I was able to fix the issue by simply using a file browser and changing the extension of the key file to something other than .jpg (no changes to exif or database), and the database opened as-is.
Similar issue after updating a pixel4a. I was able to fix the issue by simply using a file browser and changing the extension of the key file to something other than .jpg (no changes to exif or database), and the database opened as-is.
So it seems it's really about how these non text based file types are handled by Android 12 and KP2A
@PhilippC I saw another user having this issue in the duplicate report. You replied you have no way to reproduce this and test this. How could I be of assistance (as someone who was able to reproduce it)? What would you need to be able to fix this?
FWIW, I am no longer having this issue. Running 1.09d-r0 on Android 13. When I got my new phone (Pixel 5), I installed the app and had the same problem as on my previous phone. But at some point, it started working again, and I haven't seen the issue since.
@dvdfrd you're completely right. I didn't retest after upgrading to Android 13. But I did just now and it seems the databases I had can be opened again with combined keys which use binary files. I assume it was some way how Android 12 file system interacted with KP2A.
I can't retest on an Android 12 device though. I would assume the issue still happens for those devices.
Hi, i have the same issue, DB created and used since long time, last phone using it isOneplus 8T , Android 12, and still working fine on it. Now i am migrating on a Oneplus ACE 2 Pro with Android 13 and i get the message "invalid composite key" What can i do ? Was there a fix for this issue ? Nota : i don't use a key file, only password Maybe if i export and recreat th DB on the Android 13 it could work ? How to export / import safely ?
I would suggest you do something similar to what I did - change the file extension to something that isn't an image - that way the android API doesn't affect the data that keepass receives. I just renamed the file with the File app to key_image.kpg (from key_image.jpg), and it worked. As the file data isn't modified from what it originally was, it works without needing to export/modify/etc.