KeePass Help Center KeePass Home | Downloads | Translations | Plugins | Donate 
Help Center Home | Forums | Awards | Links 







KeePass 2.57.1 Release Notes

Information related to KeePass version 2.57.1.

Many thanks to the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) and mgm security partners for sponsoring and performing a code analysis of KeePass 2.x (project CAOS 3.0 German, press report German).

No security vulnerabilities classified as medium, high or critical were found. However, two minor potential security vulnerabilities and some improvable code parts were identified. As a result, various improvements have been implemented; see the KeePass 2.57.1 changelog.

Notes on the code analysis report:

  • D. Findings with the classification 'Bad practice', by line number in 'keepass-sast.xlsx':

    • 97-99. For these three links, HTTP has now been replaced by HTTPS.
    • 100. Unfortunately, this website does not support HTTPS (no connection possible). Therefore, the link has now been replaced by a link to Regex101 (similar website, but supports HTTPS).
    • 101-103 and 105. These problems have now been fixed. All streams/readers/writers mentioned are now closed immediately, even when an exception occurs.
    • 104. Fixed.
  • E1.1. For details about the security of auto-type's window/sequence matching, see the section 'Auto-Type Window/Sequence Matching'.

    In the report, it is suggested that for a global auto-type operation, an entry should match only if the title of the target window matches the title of the KeePass entry exactly. This is not an improvement in our opinion, for the following two reasons:

    1. Security is not really increased. If a malicious website uses exactly the same title as a legitimate website, the window title is also identical for both websites, and thus the two websites are indistinguishable for auto-type. If an exact match would be necessary, a malicious website could not specify multiple service names, but such an attack is probably rather rare. An attacker who wants to phish usually tries to create a website that looks as real as possible (including the title); multiple service names in the title would increase the likelihood that a user would recognize the website as malicious (especially when KeePass shows a selection dialog due to multiple matching entries).
    2. The suggestion is not practical, because window titles often contain additional text that you do not want in an entry title. In the example in the report (website with the URL 'https://wiki.mgm-tp.com/confluence/dologin.action'), the window title is 'Log In - mgm Confluence - Mozilla Firefox', and this is exactly what a user would have to enter as entry title if an exact match would be required. Prefixes such as 'Log In -' and suffixes such as '- Mozilla Firefox' in the entry title would make it much more difficult for users to find and manage entries. Furthermore, a reasonable sorting of entries by title would no longer be possible (as sorting would primarily be done by prefixes).

    Note that it is already possible to enforce exact matches. The user can turn off the option 'An entry matches if its title is contained in the target window title' (in the menu 'Tools' → 'Options' → tab 'Advanced'; thus the entry title becomes irrelevant for auto-type and can be chosen freely) and add the target window for each entry in the entry dialog on the 'Auto-Type' tab page (button 'Add'). If no wildcard and no regular expression is specified in the target window field, an exact match is required for the entry to match. This approach means additional effort for the user, and even minor changes to the window title mean that an entry no longer matches (and for example, all auto-type target windows have to be changed when the web browser is changed). So, there are several disadvantages and no real security benefit, but anyone who wants to can proceed in this way.

  • E1.2. The default values for key derivation functions (KDFs) in KeePass are based on the current OWASP recommendations (2024).

    • In the case of Argon2, KeePass uses 2 as the degree of parallelism (instead of 1), because almost every device nowadays has at least 2 CPU cores and in the case of KeePass, multiple KDFs are not usually computed in parallel (in contrast to servers). Furthermore, the memory parameter has been increased to 64 MB (with 2 iterations). The default values for Argon2 in KeePass are therefore a little higher than the current OWASP recommendation.
    • AES-KDF is somewhat similar to PBKDF2-HMAC-SHA256, for which OWASP currently recommends 600000 iterations. This is exactly the default value that KeePass uses for AES-KDF.

    For computing AES-KDF, KeePass uses an AES implementation that uses the AES-NI instruction set, if the current processor supports it. With AES-NI, AES (and therefore AES-KDF) is computed significantly faster. The processor used in the test (Intel Core i7-6820HQ) supports AES-NI. However, there are many applications (for other devices such as smartphones) that can open KDBX files, but where AES-NI is not available (as it is not supported by the processor or cannot be accessed by the programming language used). In this case, AES-KDF is slower and is therefore closer in time to Argon2 with the default values (same order of magnitude).

    The KDF parameters should of course ensure good security, but it should also be possible to open a KDBX file with most applications on reasonably up-to-date devices in a reasonable amount of time. In our opinion, the current default values are currently a good compromise. We will continue to monitor developments and adjust the default values in due time (as it has already been done several times in previous KeePass versions).

  • E2. This is not a security issue, as explained in the section 'Malicious Data' (to which the report also refers).

    However, we like the suggestion to show a confirmation dialog. Therefore, two options have now been added:

    • Show confirmation dialog when running/opening a 'cmd://' URI.
    • Show confirmation dialog when evaluating/replacing a '{CMD:...}' placeholder.

    Both options can be found in the menu 'Tools' → 'Options' → tab 'Interface (1)', and both are turned on by default.

  • E3. Cf. E2. The following option has now been added (in the menu 'Tools' → 'Options' → tab 'Interface (1)', turned on by default):

    • Show confirmation dialog when evaluating/replacing a '{REF:P@...}' placeholder.
  • E4. The Spamex.com import module has now been removed.

  • E5. KeePass uses the 'HttpWebRequest' class of .NET here, which can follow redirects automatically/transparently. We are not aware of any way to show a confirmation dialog before following a redirect (after the first request). However, it is possible to prohibit following redirects.

    An option 'Follow redirects' has now been added in the 'Open From URL' dialog on the 'Advanced' tab page. 'Yes'/'No' turns following redirects on/off; the default is 'Automatic', which means that KeePass leaves the decision to .NET (which is usually 'Yes'). As legitimate servers also use redirects, they are not prohibited by default.

  • F. File 'keepass_cpd.txt':

    • The files with the extension '.Designer.cs' contain only code that was generated by the Windows Forms Designer (Visual Studio) for the dialogs. There was no copy&paste here. Some of the dialogs or parts of them are similar, which is intentional (consistent user interface). Similar code cannot be combined here (refactoring), because otherwise the Windows Forms Designer cannot be used anymore.
    • The file 'XmlSerializerEx.Gen.cs' contains only automatically generated code for XML serialization (similar to Microsoft's SGen). There was no copy&paste here. The first few lines to deserialize an object are indeed often the same, as the procedure is the same at the beginning (skipping an empty element, reading the start tag and jumping to the content) and then a loop begins to read the contained elements. As only very few of the lines are independent of the type, it is not particularly useful to move parts into separate functions here. Furthermore, the code parts exist only once in the generator (see 'XmlSerializerEx.cs'). In order to make it clearer that 'XmlSerializerEx.Gen.cs' contains only automatically generated code, the file has now been renamed to 'XmlSerializerEx.Generated.cs'.
    • Files in 'KeePass/UI/ToolStripRendering': a base class for the color tables has now been added and most of the methods for drawing the background of menu items have been combined in the 'ProExtTsr' class.
    • Files in 'KeePass/DataExchange/Formats': most of these findings have now been revised.
    • File 'CsvStreamReader.cs': the code has now been combined.
    • For various reasons, we do not want to change the few remaining findings.






Get KeePass