view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    Recycle all entries with the string "too old" appearing in the Notes
    string.

 Remove empty groups

        $kdbx->groups(algorithm => 'dfs')
            ->where(-true => 'is_empty')
            ->each('remove');

    With the search/iteration algorithm set to "dfs", groups will be
    ordered deepest first and the root group will be last. This allows
    removing groups that only contain empty groups.

    This can also be done with one call to "remove_empty_groups".

SECURITY

    One of the biggest threats to your database security is how easily the
    encryption key can be brute-forced. Strong brute-force protection
    depends on:

      * Using unguessable passwords, passphrases and key files.

      * Using a brute-force resistent key derivation function.

    The first factor is up to you. This module does not enforce strong
    master keys. It is up to you to pick or generate strong keys.

    The KDBX format allows for the key derivation function to be tuned. The
    idea is that you want each single brute-force attempt to be expensive
    (in terms of time, CPU usage or memory usage), so that making a lot of
    attempts (which would be required if you have a strong master key) gets
    really expensive.

    How expensive you want to make each attempt is up to you and can depend
    on the application.

    This and other KDBX-related security issues are covered here more in
    depth: https://keepass.info/help/base/security.html

    Here are other security risks you should be thinking about:

 Cryptography

    This distribution uses the excellent CryptX and Crypt::Argon2 packages
    to handle all crypto-related functions. As such, a lot of the security
    depends on the quality of these dependencies. Fortunately these modules
    are maintained and appear to have good track records.

    The KDBX format has evolved over time to incorporate improved security
    practices and cryptographic functions. This package uses the following
    functions for authentication, hashing, encryption and random number
    generation:

      * AES-128 (legacy)

      * AES-256

      * Argon2d & Argon2id

      * CBC block mode

      * HMAC-SHA256

      * SHA256

      * SHA512

      * Salsa20 & ChaCha20

      * Twofish

    At the time of this writing, I am not aware of any successful attacks
    against any of these functions. These are among the most-analyzed and
    widely-adopted crypto functions available.

    The KDBX format allows the body cipher and key derivation function to
    be configured. If a flaw is discovered in one of these functions, you
    can hopefully just switch to a better function without needing to
    update this software. A later software release may phase out the use of
    any functions which are no longer secure.

 Memory Protection

    It is not a good idea to keep secret information unencrypted in system
    memory for longer than is needed. The address space of your program can
    generally be read by a user with elevated privileges on the system. If
    your system is memory-constrained or goes into a hibernation mode, the
    contents of your address space could be written to a disk where it
    might be persisted for long time.

    There might be system-level things you can do to reduce your risk, like
    using swap encryption and limiting system access to your program's
    address space while your program is running.

    File::KDBX helps minimize (but not eliminate) risk by keeping secrets
    encrypted in memory until accessed and zeroing out memory that holds
    secrets after they're no longer needed, but it's not a silver bullet.

    For one thing, the encryption key is stored in the same address space.
    If core is dumped, the encryption key is available to be found out. But
    at least there is the chance that the encryption key and the encrypted
    secrets won't both be paged out together while memory-constrained.

    Another problem is that some perls (somewhat notoriously) copy around
    memory behind the scenes willy nilly, and it's difficult know when perl
    makes a copy of a secret in order to be able to zero it out later. It
    might be impossible. The good news is that perls with SvPV
    copy-on-write (enabled by default beginning with perl 5.20) are much
    better in this regard. With COW, it's mostly possible to know what
    operations will cause perl to copy the memory of a scalar string, and
    the number of copies will be significantly reduced. There is a unit
    test named t/memory-protection.t in this distribution that can be run
    on POSIX systems to determine how well File::KDBX memory protection is
    working.

    Memory protection also depends on how your application handles secrets.
    If your app code is handling scalar strings with secret information,
    it's up to you to make sure its memory is zeroed out when no longer
    needed. "erase" in File::KDBX::Util et al. provide some tools to help
    accomplish this. Or if you're not too concerned about the risks memory