Just gave the App Store version a spin, and when taping the “Recommend KeePassium” entry in the settings menu I arrive at the App Store with the error message “Could not connect to App Store”.

As I have no issues with navigating anywhere else in the App Store, a wild guess is the App ID or something is wrong, or maybe Apple is a bit slow to add the reference for apps that has just been released?

With iOS 13 around the corner it’s going to be that feature that will be asked a million times over in a few months!

repro:
pre conditions:

• have google drive, enable file sharing and has it as your file storage

other notes:

• i have marked this file as available offline in gdrive
• make sure it's the file sharing system, and to open the file from gdrive, NOT THE share to system(the file location should be "Another App/Cloud Storage"

repro steps:

• (assume normal successful usage before this)
• disconnect from internet
• open app
• try to unlock the database
• get error "Cannot open database file, The plug-in returned an error."

expected result:

• the file opens normally

diag logs:

• DatabaseManager.swift:742 load()
  Failed to open database document [error:The plug-in returned an error]

I am not sure if this is fault on keepassium or google drive
probably worth investigating, and if it's google drive fault, if possible add a note that tell user to use another cloud storage app

The search bar doesn’t display when I first open a database even with “Start with Search” enabled. I try pulling down in the screen and that has no impact. If I go into a folder or open the preferences window and then go back to the previous screen, it will show up. If I drill down one folder level, it exhibits the same behavior with no search bar until I drill down one more level and then go back up one.

When you set the sort option for the database (in the app) to "Name (A..Z)" for example, this sorting is not applied in the AutoFill GUI, it just shows every entries sorted by default.

I installed iPadOS 13 PB2 this morning (up from 12.3) and I can no longer open files with Keepassium - I keep getting an error saying that I don't have permission to view it. I've tried the following:

• Open the file from Google Drive (through the iOS file picker, not the Google Drive app)
• Open the file from iCloud Driver (through the iOS file picker)
• Open the file from the new iOS 13 "On My iPad" location (through the iOS file picker)

None of these work. The only solution I've found to making it work is to open the Google Drive app, select the file, tap "Open in" and select "Copy to Keepassium". This will open the file in Keepassium but I lose the ability to sync changes automatically to the Google Drive.

Unfortunately that still results in the AutoFill feature not working. With the AutoFill database selection, no matter what I do, I can't get Keepassium to open the file. When I select "Add Database" (in AutoFill Setup) and pick a file, the file picker goes away and I'm returned back to the AutoFill Setup dialog.

Happy to provide any additional diagnostic info if you need it.

Hi,

since the last release, keepass files are not updated anymore. Even trying to reload has not effect. File is up to date in FilesApp and NextCloud app.

Any ideas?

When parsing the ISO 8601 date, the formatter locale should be set as described in Technical Q&A QA1480.

Without the locale set, the date conversion may fail for users in some regions.

dateFormatter.locale = Locale(identifier: "en_US_POSIX")

Search appears to be case sensitive, it makes difficult to find entries particularly with ios auto-caps on.

Sorry to have to break this section in, but I guess it will eventually have to be done.
I do feel humbled to get a chance to provide some feedback!

I love that you've enabled iTunes File Sharing to be able to copy some files direct to the app without having to go through the Files app, and/or any file sharing service in there.

For the regular app, this works great, and I'm able to login using a key file copied to the phone this way. However, when I tried using the Password Autofill functionality I was prompted with the descriptive note about it being handled basically as a separate or in a different context, meaning I had to select the database again.

When getting to the prompt about the master key for the database in this context however, the file copied through iTunes File Sharing was nowhere to be seen.

I've done a quick search to see if there's anything in the Apple's API documentation, but could not really find anything applicable describing the issue. The best I've found is a entry in Strongbox's FAQ, where a workaround for the same issue is presented for that app (https://strongboxsafe.com/faq/) - "My Key File is not Auto Detected in Auto Fill Mode". Basically, the suggestion is to tie the master key to a biometric authentication, to jump around the need for the file entirely.

Currently the thumbnail is blank on App Switcher regardless if the app is locked. It would be great if it shows normal thumbnail when unlocked.

I’m unsure if this is a case of KeePassium doing the AutoFill methods in a different way than the iCloud Keychain, or if it simply is that Apple is not using their own API for their AutoFill. As I’m using the iCloud Keychain as the ground truth here, it may all be null and void based on the assumption that it should behave the same.

In Safari it seems the behavior is as expected, but when entering credentials inside Apps there is some odd behavior in the UI.

In a gist; When using AutoFill and selecting the entry I’m returned to the App, with the focus on one of the fields, and sometimes also outside the fields, with a blinking caret indicating the field is active. If I tap on any of the fields related to the login they stay blank, and also if I push outside, the fields now losing focus. As soon as I tap one of the user or pass fields again, after their focus has been lost, the credentials simply pop in.

In the cases where the fields are not filled this pattern can be repeated over and over without the credentials showing in the fields, invoking AutoFill multiple times. As soon as you tap outside and then in one of the fields again they “automagically” appear.

With iCloud Keychain I’ve tried this about 20 times, never seeing the same behavior. When using KeePassium it is roughly 50/50 on a run of 20 tests, with the longest streak without being able to reproduce the issue being 5 times.

Not done a proper profile how this differs between apps, but I’ve had the same behavior in multiple apps. From my memory I recall a handful of them, sadly local apps only on the Swedish App Store. Will hunt for a international one that can be used to reproduce.

I’ve captured the behavior in one App using iOS screen capture. Can’t manage to attach them through my iPhone, but I’m linking the clips on dropbox. Good to know:
Användarnamn = User name
Lösenord = Password

As the iOS Screen Capture does not indicate where taps happen the best way is to look where the caret (text entry marker) is placed, as that is the clearest indication of what field is in focus.

Also, the whole on-screen keyboard goes away whenever the user or pass field is not in focus.

The following link should go to a Dropbox folder where you can find 5 clips:
https://www.dropbox.com/sh/gr0840td25sdl0x/AAA3ZvWvcUPRWgiFRDGidqGpa?dl=0

Clips 1-3 are different variations on altering field in focus before taping outside of formed and then back in the login form.

Clip 4 is a case where returning to the app none of the fields are focused.

Clip 5 is when doing multiple AutoFills after each other without the fields getting filled until “onblur” and then focusing on the username again.

Summary

The app locks up when going to the "thumb reachability" mode (which moves the app to the lower part of the screen).

Steps to reproduce

• Set AppLock timeout to "Immediately"
• Perform the reachability gesture (on device without a Home button)

Expected result

• The app moves to the lower part of the screen, still unlocked.

Observed result

• The app moves to the lower part of the screen, but shows the AppLock screen/Face ID request

Thanks to J.B. for reporting this.

After navigating to a sub menu in the settings section, upon return to the main settings section the menu is slightly “squished”. The descriptive text under the ”Start” entry creeps up into the field itself.

Attaching screenshot to easier understand.

Steps to replicate (approximate):

• Create an entry for KeePassium in Apple Keychain
• Enable Keychain in system's AutoFill settings
• Open KeePassium, choose a database
• Use AutoFill/Keychain to fill the master key form

Expected result: only the password field is filled.

Observed result: the key file field is filled with the user name from the Keychain.

[Thanks, /u/Silunare]

Describe the bug
Saving a database in KeePassium will remove custom Auto-Type sequences.

To Reproduce
Steps to reproduce the behavior:

1. Take database from the desktop KeePass client that is filled with entries that have custom Auto-Type sequences, eg to include {totp} codes.
2. Have said database on a cloud, in my case OwnCloud
3. Open database in KeePassium from the file provider.
4. Change something - in my case I only changed the name of one key by a couple letters.
5. Wait till the sync does it's thing, then open database in Desktop again.

Expected behavior
Only the name of the changed entry should change, everything else should stay the same.

Actual behavior
All custom Auto-Type sequences in my database have been set to standard, in the process removing the custom patterns I put in there. For anybody else who stumbles across this issue, I was able to get my sequences back by syncing with a backup.

User Information (please complete the following information):
KeePassium iPhone SE@iOS 12.3.1, KeePass on Windows 10, OwnCloud

Currently, the Database Lock timeout closes any opened database and clears any remembered master keys from the keychain. A full lock down, so to say.

In some cases, however, it makes more sense to close the database, but keep the master keys. This way, the decrypted database does not hang around in the memory, but can be quickly loaded when needed.

[Thanks, @cnvxer]

A self destruct passcode that deletes all app db, app data, app settings TLDR
since clearing masterkey can already be done via protect database
but it would still be nice to have a separate self-destruct password with options of what to clear/keep

Not sure if possible due to secure enclave limitations, but also duress fingerprint to look even more legit?(from what i see, apple only tells your app if the authentication is successful or not)

steps to replicate
1: crate a new database
2: add it to the auto fill
3: delete the database (including the bin)
4: check auto fill

(The option to copy diagnostic data doesn't seem to allow me to copy and paste so maybe display it as a text to allow users to manually copy and paste for future issues)

i added a couple entries...
1 x email
3 x general

when i login or try to on a website only the email one is displayed, maybe offer an option to display all saved passwords despite condition's etc

Sorry for slacking off for a while, but switching jobs and transitioning to a new phone took its time! :)

The good thing is that this meant that I went through the process of setting the app up from scratch again, where I found a slight hickup in the UX.

On the welcome page you get a good description of what you need to do, but when going through the "Add Existing Database" process and selecting the database file, you end up on the same Welcome page, without any indication of success or failure, or suggestion on the way forward. I performed the same procedure twice, and was just about to do it a third, before realizing I was stuck in a loop.

I guess before proper release the onboarding process will be polished a bit, so this may not be applicable for the long term, but a small suggestion meanwhile could be instead of going back to the welcome screen make the user go to the database selection screen, maybe with a "overlay" pointing to the top right plus sign for adding more databases to the app?

TrayTOTP for KeePass (.NET) on desktop systems might sometimes store formats such as 30;6;https://www.google.com/ in TOTP Settings, with the intent to use the Date header from a HTTP query as a source for a time delta. Currently, in KeePassium, these entries seem to be skipped entirely, and treated as if there's no TOTP.

Keepass2Android, for example, does not implement this, but shows a warning instead when viewing one of these entries notifying the user that, indeed, time correction is not implemented:

https://github.com/PhilippC/keepass2android/blob/ee6b7c4fe0257af35eed0eed09c83721db72e94c/src/keepass2android/Totp/TrayTotpPluginAdapter.cs#L147-L148

Describe a feature you'd like

• the ability to add multiple urls to an entry (some websites have multiple login places)
• the ability to move or clone an entry

Additional context
most websites either have multiple login pages or Keepassium does not recognise the login page but does recognise other pages

it would be useful to clone an entry if you have multiple logins on a service or you need to move them into folders

I am looking forward to KeePassium's release but in my opinion the development is not public.

The commits are not atomic and a huge combination of different changes so it is hard to follow and track. This setup also does make it harder for others to contribute to the project.

Not to mention that KeePassium is a security sensitive open-source software but you seem to have a private repo or separate development infrastructure and only commit the final stages in this repo.

Why are you not using this repository for the every day development if you really want KeePassium to be open-source?

YubiKey support is a frequently requested feature, especially since both desktop and Android apps have it. I am opening this feature request to collect relevant info on the topic and to keep track of updates.

YubiKey support in KeePass ecosystem is a wild zoo of formats and methods.

KeePass itself supports YubiKey in static mode (YK simulates a keyboard and types your master password), as well as HOTP and challenge-response modes (with the OtpKeyProv and KeeChallenge plugin, respectively).

KeePassXC, in turn, also supports YubiKey in challenge-response mode. In contrast to KeePass plugins, KeePassXC's implementation does not need any additional files (that would need to be synced), keeping the database self-sufficient. Well, with a YubiKey :)

Since KeePassXC is available on more platforms and needs only the database itself, their approach seems the best candidate for implementation.

like for example keepassxc can do

i used the old master key password and it worked still?

(would also be nice to have a feature that allows you to select multiple databases to either delete or export)

First of all, thanks for your incredible work. You’re doing god’s work.

I would love to contribute and maintain a translation into the German language, but it seems that all strings are static and distributed over the whole source code. Maybe think about moving them into separate and translatable resource files.

Official references and documentation provided by Apple:

• About Internationalization and Localization
• Internationalization and Localization for iOS

Please display the current app version somewhere, perhaps in the About section.

It should be possible to move or copy an entry to another group.

(Initially requested by @Dragonblitz10 in #47.)

First of all KeePassium looks great, I appreciate your work!

Perhaps you could refine the workflow of the Autofill in Safari.
Currently you have to press the “password” Button, enter the Keychain or use Touch/Face-ID, tap the button of the suggested account and press Login.

Most Password-Manager show Accountdetails like the URL and the username for the Website instead of the “Password” Button. In addition to that you only need to tap this button, use Touch-ID/ Face-ID (if enabled) and for Websites with mobile view it automatically locks in.
For this process the Apple Keychain only saves the Information about the URL respectively the username, not the password.

This would simplify the log in and save some time for people who log in very often.

Option to copy the TOTP into clipboard(if present) after invoking native password autofill...
Seems to be the best way to make TOTP as "streamline" as possible waiting for iOS to add TOTP auto filling support

Describe Bug:
Then I click on „file sorting“ settings there is no title/caption and „Done“ Button visible.
This happens only on my iPad (Userinformation below), not on my personal iPhone 6s (same OS and App Version like the iPad).

Steps to reproduce the behavior:

1. Open KeePassium on the iPad 10.5.
2. Click on ‘file sorting’ settings.
3. See no caption/title and no „Done“ Button.

Expected behavior:
Caption/title and “Done” Button is visible.

User Information:

• Device: iPad Pro 10.5
• OS: iOS 12.4.1
• App Version: 1.01.32

Currently, KeePassium is not well recognized by other password managers' AutoFill (see #41). Associating the app with its web domain should fix this.

Currently, a database can be opened in two ways:

• By entering a full master password.
• Completely automatically, using the saved master key.

It might be useful to add a middle-ground solution between these extremes. Specifically, before unlocking the database with the saved master key, ask the user to enter a few first (or last) symbols of the master password. After one failed attempt, fallback to full master password.

[Thanks, u/deviltrombone]

KeeTop stores OTP parameters in a protected field named "otp". The value is formatted as follows:
key={base32Key}&step=30&size=8&type=TOTP&otpHashMode=SHA256

Defaults:

• step = 30
• size = 6
• type = "TOTP" (can be "HOTP")
• otpHashMode = SHA1 (others are not supported yet)

Initially, the app was intended to follow the classical freemium route: a few days of free trial, then some features were to be disabled. The countdown visible in the Settings is a bug/leftover from that time.

Later on, KeePassium evolved to use a more liberal free tier. Instead of a trial period, the app would count the time it spends on the screen and gently nudge more active users towards the premium. However, in the first few days everybody is an active user: they would need to explore the app, add a database, change the settings...

So, I've repurposed the "Free trial" timer into an "Initial setup grace period": during the first two days the app usage counter is disabled. This is an internal timer and it should not be visible in the app.

Unfortunately, I forgot to remove it from displaying in the settings, and now it sends a very wrong message to people...

Just to be clear: once the countdown finishes, all the features will remain active (unless I messed up there, too...) The only difference is that the app will start taking into account its daily usage, to distinguish casual and active users.

When the app is sent to background, any protected fields that were visible (passwords, memory-protected custom fields) should reset to "Hidden" state.

[Thanks, V.M.]

Setting the AppLock timeout to the same duration as the iOS display/auto-lock timeout makes the app wake up the phone for one additional period.

I believe this is combined with FaceID, as it seems to attempt an authentication attempt straight away, and when failing it tries to notify the user which in itself makes the device wake up.

If left alone after that, it manages to go to sleep/lock the device on the second attempt.

I've run across another issue when using the Autofill integration within an app (CheapCharts in this case).

I'll start with steps for reproduction:

1. Start app and go to login screen/dialog
2. Start the entry, and push the iOS Passwords bar that shows up
3. Select KeePassium and unlock database (everything so far works as expected)
4. Lock screen
5. Unlock screen, now back at the login dialog of the app
6. Push the Passwords bar again (this is where things starts looking odd)
7. Instead of being prompted for source of password, KeePassium now seems preselected and prompts me for my Touch ID (assuming this is because I've got it enabled as App Lock, with a very short timeout of 15 seconds). As soon as I provide my TouchID login, now I'm prompted whether to use iCloud Keychain or KeePassium.
8. Selecting KeePassium I now arrive at the database unlock screen. Enter master key and unlock.
9. Instead of getting a list in KeePassium I'm now returned to the login dialog inside the app again.

At this stage, everything seems to have "reset", so if you repeat steps 1-3 you will be back in a good state. KeePassium does consider this an unexpected shutdown, and erroneously points its fingers to the encryption algorithm, which I do not really think had any involvement in the shutdown.

Per the feature list and #7, #8 KeePassium supports TOTP.

I have a KDBX file created in https://app.keeweb.info/ that has been imported into KeePassium. Entries have records labeled "otp" with data in the standard URI format "otpauth://totp/{label}?secret=...". This shows the rotating TOTP code correctly in KeeWeb but in KeePassium all I see is the protected URI text.

Additionally I cannot see how to create a new TOTP record in KeePassium. Am I supposed to enter the URI manually - no support for QR codes?

How is TOTP supposed to be setup and used?

Calling this an issue might be a stretch, but I don't know any better way to report minor nitpicks. :)

Deployed Beta 23 today, and encountered a few "upgrade related" (just an assumption, will see if they happen again in some context) error message, both in App mode and Autofill mode.

I then noticed that the way the error messages are presented differs slightly in Autofill and in standalone versions of the UI.

It may be by design, or it may be a work in progress not fully deployed across the code base, or simply not even something that's been reflected upon. It won't cause any problems for any users, but possibly reduce the "uniformity" of the UX. Attaching images of the two variants.

Standalone:

Autofill:

I'd love to have an overview over all saved OTP Tokens in a file. (Maybe an option to add favorite OTPs to this overview.)

Just like a standard Tool Like "Google Authenticator" does.

My use-case is, having to login to a VPN each day, which requires OTP. It would be much easier for me, having the tokens in an easy accessible overview.

The "Copy to clipboard" button does not work in AutoFill's diagnostic log.

Steps to reproduce

• Open AutoFill
• Try to unlock a database with a wrong password
• Press the "diagnostic info" button in the error message
• Press the "Copy to clipboard" button

Expected result

• The content of the diagnostic log is copied to the clipboard.

Observed result

• Clipboard content does not change.

Originally reported in #15.

It should be possible to add TOTP codes to entries (manually or by scanning a QR code).

(Related to #23)

would be useful if it's possible to transfer all passwords of the internal keychain to KeePassium saving time and effort in transferring large amounts of data.

Another great option would be able to select multiple databases on the menu to either delete or export all databases at once

I am not sure, i am thinking of for TOTP 1 click copy/view
maybe a account list: view/copy for a folder inside a db??
need more ideas to refine this suggestion

gist of it is to do something with widgets
practicality wise though: i see some problems like, how the db would probably be always locked thus, needing masterkey making it as good as just opening the app
account list might just be pointless as ios has built in password filling to begin with
TOTP might be less useless since one can argue they wanted to use that for another device like pc

anyone have any idea if a totp widget would be helpful?

Describe a feature you'd like
Currently, local databases and all key files can be accessed from the Files app. It would be useful to add an option to make them accessible only from the app. (For example, move to a private directory in the app sandbox.)

Would this be useful?

[Thanks, T.]

With "Backup Database Files" enabled, a database copy is created for every minor edit.

There should be a section in settings to control/limit the number of backup files (by age or number), and a possibility to delete them all.

Some keyboards do not appear as IME when editing entry's custom field value. Seems to be limited to Chinese and Japanese (Russian and Arabic appear ok).

[Thanks, Regulus]