steps needed to re-encrypt a Keepass database

 ©2025 ALL RIGHTS RESERVED, Consumer Reporting Business

The following is the steps needed to re-encrypt a Keepass database for whatever need such as a compromised master key. This is what I do to re-crypt into a crypt with a new master key.

recrypt TASK

First make new DB files from template

 a. another for offline recovery which will not be used with android keystore

2. make on FAT ( non-journaling )

3.. initialize with mind generated passphrase typed in securely with incognito keyboard

 -a. add junk

4. change master passphrase to a zero-knowledge entry from another DB

 a. add junk

5. copy in to phone storage (journaling filesystem) only if needed

6. input master passphrase into Android keystore for active use (no need to retype passphrase)

When I remove the screen lock pin does it automatically erase the stored credentials?

The answer is no it does not erase credentials because when reinitialising a screen lock those credentials set under a prior pin have been found to have been remembered by android.

I changed a database key using a long string off all available characters and then later after having opened it with such long password suddenly it does not open. What do you guess may be the cause of this? Would you guess that of the many special characters UTF-8 codepoints changed the value of some character thus making the password unvalid? Would you guess something actually corrupted the encrypted header thus making the database not respond to the proper password? Why would it open and then suddenly no longer accept the password?

The following is a paste of the KeepassDX magikeyboard output of the password in question.

pº&ut/Îk¯ÿ¸÷nØ]Ä~Ãí=í¬ûp§<S×sÞêN2¯ª¼Ä]¯¤ìs¿¿jË5¾h®âÝìÿnPåP«pi%û2æÆnä&´gJ0ا@Ðþ=p¤[;ÅJhãoF2Õneß\ÁÙKN7Ü×êìG¸<¼*FÐj¯ø`Ì×"Æq¥vôB5EzWÖLtUêjvsbzèYÑ+w¿ä`©ì¼³w'2Ñ}çJ©?n`vÿçÛ`«iLfH\t³Ìzó:ëR´¡bRªßó3Û=éívLB:k£ þ[p«(®mGNÆs»ìñÀ´åD³Á-wYy/Orß&²)$N]j¹ÿc1l³Æ"bòPLw ³ÑANéõ£7¿¢ÍÑÄÒPÙqg6« òÅdÐvÌŸêófð¹xë)© V6uq|±Ïq`Ñ'¡oð§!«ºÉÀøDËÀ@DK¬N²ëôve=nÏh¸ &£+N~$cCûI|WÛáäNÜ4jûØzÇ®Ð1Åï¡r$â"£ZÐF.¿ç>³ö\WûÃEܼ÷¼çÈÑþrBÿµÛLp¯¡cÓS¢R4-<"©;§ú2ß[«¾¥9ÁÐ2UT´3S-¿8]h¢`e´ÞRDò-;àÜùnu¡`ªÝ%ë¯Pãg#GÜKqÍEmkW7¥Gbg7údæJÄ>[C0/sL=ÖK1R_UGÉBÝ¢0aÎ5ùº®h¢Ðÿ³Ä±dR¬$Ã/CÌ,NÔtÀÏÑ5ÞøNlúøôÚú¸S0ìn§å¤]fw¨ñ\¦m(:ùMV§¸:¢ñ?¬³oÇÿ·!cFâÇêϾI ñ.è~&g9Oã~%ÀÝZ»äs¾xªúÓ«Îâ}2fåPéÜI:Fq)RBüSy8ZvÞp4þI´c9"KØ0pbü¦Ä²·Fq%§}ÝE%Û÷Û¬ïjIÃEá%¨J)}Úè\·d&1îÍ:¤H£y=]`¾ðôØü¸&Ô1X¾¾¤~PÐR*þAiÐú¢4¡vÝáIîx³xYP;õ#æ9ìËöî C5ÝH ¥sIó×upG×þMüü¯4>RÀcÇtø9ùwêX¶OC'h¥#Û¼EJÖ¿0ÞPja¢ü*ä4ªÂ&ùåÏ6¶4kgÌøOí÷J&:Ýs¸?{Ú/U{Z¼5-×sÛ)00m~F%³F^A¬B~çoL*mrPañtâyêj`yi]ÄsÿWâPsüE5"éHà*±WµKqBÈÁÆ0_?äî,7ñh^½]*-ó/µIÓ{w¥t¡<Ä"Ð@´ðë|Db1î ¾¿)u>ú§ShhÇT(¸ÎÓâ±cEá4'c{UÃBJÏïÆãNCºFÔ¨³RÓoïÞ1:ÞÝpÕ;)ü´æ.Ì´5,n8ãEk?,ç]g2¯îÒYïnϯ±~±Wøÿu

The many lines seem to be linebreaks inserted by terminal emulator.

“UTF-8 IS A PROBLEM” quote me on this.

UTF-8 is a problem because because of UTF-8 when you look at this blog entry with the password string there is no guarantee what you see is actually what the password is [was]. See UTF-8 IS a problem.

Is it better to use android credentials storage or not? pros and cons

pro. only type master passphrase once

con. it is unknown how secure the android keystore is. Malware could expose the passphrase. Prusamablè with root the master pass stored in android keystore could be exposed. More research needed into if android keystore on device is exposable by android root.

Android Keystore Con: Root Exposure (Partial)

​A fundamental concern with any on-device security measure, including the Keystore, is what happens if an attacker achieves root access (full control, or root) over the device. ( chat )

​Key Material Protection: If the Keystore key is hardware-backed (stored in a Trusted Execution Environment or StrongBox), the raw key material itself is highly protected and cannot be extracted by a root user. This prevents the key from being stolen and used to decrypt your master passphrase on a different, unrooted device. ( chat )

​Data Use Exposure: Despite the key being non-extractable, a rooted device or an attacker with full control (root) can still use the key to decrypt data on the device. By impersonating the legitimate application and intercepting the cryptographic operation system calls, the attacker can force the Keystore to decrypt the master passphrase and then intercept the decrypted passphrase from the application's memory as it is being used. Therefore, while the key is safe from extraction, the decrypted secret is still vulnerable to a sophisticated attacker with root privileges. ( chat ) –Therefore using the android keystore for pin, pass, or fingerprint does add an amount of vulnerability in the case of a root user. The fingerprint scanner is neat but the software underlaying it is iffy. And there [is] are concerns about biometrics handling.

“AVOID ANDROID KEYSTORE.” quote me on this.

An Android Keystore Pro. is that [because] the user will have to type in the password manually instead of automatic by pin or fingerprint: for actively used databases like those used for online accounts it is more practical to use android keystore. The recovery email may be stored outside in a separate database without inputting the master password into android keystore.

A further consideration about KeepassDX is the use of AES for database storage and Argon for the master header. This suggests the database is actually encrypted by an AES key and not the Argon key derived from the password.

     Q. How does this all work? Isn't there a way to simplify this and encrypt the database with the same security as the user access master password? A. No that is how the app works.

The problem I see with actual database header encryption keys derived from another key which is derived from the user's password is that the user doesn't really know how the actual encryption key is handled and further with udpating software the actual encryption key may be handled wrong or broken or exposed by an update. It essentially boils down to trust in the application's implementation.

NOTE: Gemini says when changing the master pass it does change the underlaying database key however because it does so when a master key is changed it is export to plaintext in memory and then re-crypted with the new key. As such only change the master key when airgapped offline, and the same goes for Merge databases.

“AVOID MEMORY EXPOSURE” quote me on this.

Open source offers the potential for perfect scrutiny, but that potential is only realized if the user actually does the auditing. You don't have to trust the developer's promises; you can verify the implementation of the security mechanisms yourself.( chat )

Even if the code is perfect, the security of the derived key still depends on the runtime environment (the operating system, the hardware, and the compiler). Flaws in the Android OS's memory management or a malicious compiler could still compromise a perfectly implemented open-source application.( chat ) –Therefore I will be going full-circle twice through the OSI layers from hardware to application and back again. This involves KeepassDX, android™, Linux®, and compiler GCC and Clang, and open hardware– Chinese industry. In lieu of all of this my favorite game is Laptop Tycoon.

The app dev and the user may work closely to produce a finished product of secure and practicle use of the password manager. Yes the product is like that MasterCard commercial priceless. Priceless events. Contact on GitHub and move the source project to a private GIT because the OAuth guy has unfettered access to all GitHub accounts, this I know because I tested it and found no way to de-auth OAuth logins.