Allow blank password when creating a database

[RokeJulianLockhart]

Have you searched for an existing feature request?

• Yes, I tried searching

  /issues?q=is%3Aissue%20disable%20master%20password&page=2 returned 0 relevant results at +2024-01-06T12:45:53+00:00.

Brief Summary

The undermentioned screenshot list chronologically demonstrates how the current vault-password application process does not permit null as the value without an alternative provided:

1. 
2. 
3. 

I believe that it should.

Example

As sourceforge.net/p/keepass/discussion/329220/thread/6d703ada/#5cb5/506f and the corroborative thread it references explain, I want to disable password authentication when creating vault files whose sole purpose is to be deliberately unrestrictedly distributed for:

1. Communal investigation of functionality present within KeePass and its derivatives (XC):

   Currently, I must add a password that is known to both parties to vault files created for this purpose, despite the data contained not being usable to authenticate anywhere – it's randomly generated.

2. Communal distribution of evaluation credentials for local software:

   I could use a text file for this, or a mere database file. I frequently do. However, it'd be quicker and more consistent for all involved to utilize XC in their stead.

Context

Please note that the aforementioned "corroborative reference" refers (ultimately) to reddit.com/r/KeePass/comments/dzjt5w, which requests this functionality for unsubstantiated rationale:

Is it possible to make KeePass not ask for password when opening a database

It has been upvoted 3 times, including mine.

[droidmonkey]

No. Just use 'a' like I do.

[RokeJulianLockhart]

#11631 (comment)

@droidmonkey, that's actually exactly what I've been doing:

However, why is that desirable in the stead of merely not necessitating a password? I don't understand the rationale.

[droidmonkey]

What's the rationale of allowing it? Your examples aren't rationale. You still need to say "don't use a password" so people know how to open it. Just as easy to say "use a".

We support null password on open for legacy purposes only. Blank password is actually different from null password. We support both for opening only.

When creating credentials, you must have at least one type specified and password cannot be blank. We warn if password is weak. We also have a new enterprise setting that disallow weak passwords.

[RokeJulianLockhart]

We support null password on open for legacy purposes only. Blank password is actually different from null password. We support both for opening only.

@droidmonkey, thanks. I wasn't aware, and was indeed referring to a blank password, but didn't consider phrasing it in that manner.

Considering that accessing an existent vault with a blank password is supported, should I reduce the scope of this FR to merely exposing that option via the vault creation GUI?

What's the rationale of allowing it? Your examples aren't rationale. You still need to say "don't use a password" so people know how to open it. Just as easy to say "use a".

Hopefully the undermentioned, including more examples (and being more verbose), is more actionable:

1. When a directory is encrypted (via VeraCrypt, as an example) and can be decrypted with a password, having the same set on a vault stored within that directory is redundant.

2. Additionally, for the aforementioned, significantly more niche use cases, it increases the overhead whenever such a file is distributed to another.

   That person must inform the recipient that the password is "a", via:

   1. Message

      Difficult, if you don't know who it's going to be sent to.

   2. Inside the filename

      Means that the purpose of the vault is obscured in the same situation.

   3. Inside an XDG Extended Attribute

      Allows the file to retain its original filename, but isn't discoverable, and definitely isn't portable.

[droidmonkey]

I could be open to this when creating a database after being subjected to a stern warning.