[HN Gopher] KeePassXC Audit Report
       ___________________________________________________________________
        
       KeePassXC Audit Report
        
       Author : crecker
       Score  : 123 points
       Date   : 2023-04-15 15:43 UTC (7 hours ago)
        
 (HTM) web link (keepassxc.org)
 (TXT) w3m dump (keepassxc.org)
        
       | sdfghswe wrote:
       | I have found that I develop emotional loyalty to good software.
       | Most software is shit, but KeePassXC has been really good.
        
         | paulryanrogers wrote:
         | I feel similarly, and would also say KeePass 2 is also good and
         | well written. (If a bit DI heavy for my taste.)
        
           | sdfghswe wrote:
           | What's DI?
        
             | paulryanrogers wrote:
             | Dependency Injection
        
       | mdaniel wrote:
       | Based on the dates in the audit, I would have expected references
       | to existing issues, e.g.
       | 
       | > The memory deallocation could be improved to not to contain
       | secrets after the database is locked though. See
       | https://github.com/keepassxreboot/keepassxc/issues/7335 for
       | progress on this issue
       | 
       | Then again, the PDF mysteriously doesn't indicate which words are
       | hyperlinked and so maybe I just didn't wave my cursor over enough
       | words to find those references
       | 
       | Also, because the outer blogpost didn't mention it (although it
       | is in the actual PDF) the auditor is https://molotnikov.de/cv and
       | it says they work for AWS as a Senior Security Architect. I
       | didn't see anything especially C++ focused, but I guess any
       | independent audit is better than none
        
         | spansoa wrote:
         | > The memory deallocation could be improved to not to contain
         | secrets
         | 
         | Attacks against RAM are as old as time. The beauty of RAM is
         | everything gets wiped when you power off, so secrets don't
         | persist.
        
           | hyperman1 wrote:
           | No, unfortunately. When they swap out, they end up on disk.
           | Sector remapping can then keep them there, even if swap space
           | is reused.
           | 
           | I think there is an API in windows to mark a small part of
           | memory as unswappable, but it can't be very big.
        
             | bionade24 wrote:
             | Even if you don't encrypt your Linux' filesystem
             | partitions, you definately should encrypt the swap / the
             | partition the swapfile is on. A new encryption key for the
             | swap can be created at every boot, removing the need of an
             | encryption password. This behaviour does make hibernation
             | impossible, so swap encryption isn't the default on Linux
             | distros that have opt-in encryption.
             | 
             | https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption
             | 
             | Does someone know how it's handled on Windows and macOS?
        
           | whoopdedo wrote:
           | RAM does not get wiped when you power off[1] and cold boot
           | attacks[2] are possible.
           | 
           | [1] https://github.com/arekbulski/Cameleonica/blob/master/doc
           | ume...
           | 
           | [2] https://www.usenix.org/legacy/event/sec08/tech/full_paper
           | s/h...
        
           | snvzz wrote:
           | Modern AMD CPUs support memory encryption.
           | 
           | Unfortunately, it isn't enabled by default but needs kernel
           | parameters.
           | 
           | I understand firmware vendors are to blame, and in many
           | machines the system will freeze when you attempt to actually
           | use this feature. This is unfortunate.
        
       | mywacaday wrote:
       | How do people mange passwords themselves across
       | laptop/tablet/mobile? I have been meaning to leave lastpass but
       | always seems like too much hassle.
        
         | jordibc wrote:
         | I encrypt with gpg and upload the .xkdb file (itself already
         | encrypted) to a server I have access to with scp.
         | 
         | Not manually, and not only for this file: this is a system I
         | have to sync the files I want in different machines, by running
         | a little program I wrote (https://gitlab.com/jordibc/csync just
         | in case). I would use syncthing otherwise, but this system has
         | several advantages for me.
         | 
         | If I hadn't access to an online server, I'd use some cloud
         | storage for the same thing.
        
         | ducknalddon wrote:
         | I keep my database in a git repo.
        
           | remram wrote:
           | And then how do you sync the Git repo?
        
             | executesorder66 wrote:
             | Device A -> git push to remote repo
             | 
             | Device B -> git pull from remote repo
             | 
             | -\\_(tsu)_/-
        
               | remram wrote:
               | Where do you host that remote repo? How do you push/pull
               | from mobile?
        
         | Macha wrote:
         | I self host vaultwarden (formerly bitwarden_rs) and use the
         | bitwarden clients. This is more of a lastpass-esque experience
         | than KeePass in a sync program, which was my previous solution
         | from about 10 years ago to about 3 years ago when I switched to
         | bitwarden.
        
           | RussianCow wrote:
           | How do they compare? I've been eyeing Bitwarden for a while
           | only because there's an iPhone in my household and it doesn't
           | support Syncthing, so we end up manually syncing the DB on
           | that device occasionally. It would be great to avoid that
           | manual sync.
        
             | Macha wrote:
             | For me the big advantage was just never having to think
             | about sync conflicts ever again, which happened to me often
             | enough to be annoying. There's also things like the browser
             | integration is more streamlined, using the bitwarden CLI is
             | convenient in some of my automation, and while android
             | supports syncthing, android has always been a bit less
             | reliable in desktop platforms in allowing syncthing to run
             | in the background or in allowing other apps to know that
             | syncthing has updated a file.
        
               | elp wrote:
               | I use Dropbox for my mobile devices and keypassxc had
               | been great. I had the same issues as you with syncyhing
               | on mobile.
        
               | Macha wrote:
               | I actually moved from Dropbox to Syncthing as I found
               | Syncthing more reliable, as Dropbox would sometimes
               | generate spurious conflicts even between my desktop
               | devices.
        
         | gabrielgio wrote:
         | I use a third party app to sync the database file, in my case
         | Nextcloud.
        
         | mdaniel wrote:
         | > I have been meaning to leave lastpass but always seems like
         | too much hassle
         | 
         | I mean this in all seriousness: how have you stayed on Lastpass
         | after the innumerable breaches? There's "my weekends are not
         | best spent exporting and importing csvs" and then there's
         | borderline criminal negligence of credentials one _pays_ a
         | company to keep safe
         | 
         | I mean, it's your life, I'm just genuinely curious how that
         | calculus plays out
        
         | theSage wrote:
         | I use KeepassXC + Syncthing.
         | 
         | On a few devices that never connect to the same wifi i use
         | tailscale to connect Syncthing.
        
           | rglullis wrote:
           | Syncthing (the most recent versions, at least) also allows
           | for password-encrypted sharing. So even if you are syncing
           | across a relay, no data is in clear.
        
         | _dain_ wrote:
         | The password database is literally just A File On Your
         | Computer. So any file synchronization tool will work. I use
         | Syncthing.
        
         | sigio wrote:
         | Vaultwarden self-hosted bitwarden and passwordstore.org
        
         | Fire-Dragon-DoL wrote:
         | I'll answer this for you since people circles around it:
         | 
         | For people without need for sharing, use cloud storage. Make
         | sure to use an app that protects from writes from different
         | clients though.
         | 
         | For people with need for sharing, you are doomed. (e. g. Family
         | sharing)
        
           | omnicognate wrote:
           | Not doomed in the least. I self-host vaultwarden (and many
           | other services) on my home network and access them from
           | mobile devices (web and/or bitwarden app) using wireguard.
        
             | Fire-Dragon-DoL wrote:
             | That requires a whole more competency than pasting a file
             | on a cloud drive
        
         | bhbh wrote:
         | I keep my KeePass file on my OneDrive / iCloud account. This
         | way it is always up to date as it syncs automatically after
         | each change and my devices always open the most recent version.
        
         | lotsofpulp wrote:
         | KeepassXC and Strongbox, stored in iCloud Drive.
        
         | 2Gkashmiri wrote:
         | you dont exactly need to have it hot synced imo.
         | 
         | i've been running this scheme where i keep the "live" DB on my
         | phone so any change i need to do, i do it on the phone and
         | every often i sync or copy it to the laptop.
         | 
         | this has served me well for like the past 6-9 years so i guess
         | it works. You definitely do not need an online service.
         | 
         | its not like passwords change like crazy. i've had entries that
         | i only change because of stupid password reset policies (every
         | 4 months for example), other than that, i only update the DB if
         | i add a new entry.
        
         | JohnTHaller wrote:
         | For something like KeePassXC, sync your kdbx file across all of
         | them with your choice of cloud drive. Secure it with a key file
         | you manually add to each of your devices but do not include on
         | your cloud drive and a good password.
        
         | InCityDreams wrote:
         | Keepass on pc and on android. The android saves as .kdbx files,
         | which once saved as such, the pc reads and writes (default is
         | .kdb files). I also use a keyfile common to both devices.
         | Manual sync as i update irregularly. Nothing touches a cloud,
         | everything stays with me. My .kdbx files are steganographically
         | encoded, and the file extension is changed. Seems cumbersome -
         | isn't.
        
         | shoffmeister wrote:
         | I use cloud storage to save my .kdbx file(s).
         | 
         | On Linux and Windows, KeepassXC is my software of choice. On
         | Android, I like (and have donated multiple times to)
         | https://play.google.com/store/apps/details?id=keepass2androi...
         | 
         | With the cloud storage setup (which, in my case, happens to be
         | Google Drive), I always have the most recent version of my
         | password safe(s) where I need them to be.
         | 
         | With this, my major threat exposure comprises of * the cloud
         | provider losing my data, letting an aggressor get hold of my
         | (encrypted) password store(s) - and then the aggressor brute-
         | forcing * I myself losing my password store data to an
         | aggressor * I myself losing my password store credentials to an
         | aggressor
         | 
         | I am explicitly not using any of the online password providers
         | simply because they are by themselves a much too valuable
         | target. I myself, hopefully, am not valuable (or visible)
         | enough, and therefore am not subject to "at-scale" attack
         | patterns.
        
         | teo_zero wrote:
         | Keepass + rclone to synchronize to Google Drive.
        
         | ycombinete wrote:
         | That part freaks me out about using keepass. That I need to use
         | a third part app to access it on my phone.
        
         | lamontcg wrote:
         | I would recommend just switching to bitwarden for minimum-
         | viable-not-lastpass.
         | 
         | You can then choose at some later date to migrate to self-
         | hosting or not.
        
         | jeduardo wrote:
         | pass (passwordstore.org) backed by a remote git repo works well
         | across Linux, Windows, macOS, iOS, and Android, as all of them
         | have decent clients available and there is working browser
         | integration for all popular browsers using browserpass
         | (https://github.com/browserpass/browserpass-extension).
         | 
         | The learning curve to understand all the moving pieces and the
         | initial setup can be more hassle than many are willing to put
         | up with, but after the initial legwork is done, adding new
         | devices is not that much more complicated than what it is on
         | paid services, and using it is as simple as any of the popular
         | services, IMHO.
        
           | ufo wrote:
           | I wish pass wouldn't store website names on cleartext by
           | default.
        
           | aborsy wrote:
           | In my opinion, this is one of the most secure options.
           | 
           | Pass is a short bash bash script (very little code). It
           | passes the encryption to a dedicated utility GnuPG (out of
           | which only the AES and cv25519 routines are used).
           | 
           | You should use smart card to store the GPG key. Every touch
           | of the security key gives out only one password. So if you
           | copy the HN password, other passwords such as your bank
           | password is not at risk.
           | 
           | The missing part is integration with browsers, which
           | increases the attack surface (although it's minimal here,
           | since only one password is at stake), but protects against
           | phishing.
           | 
           | Pass probably doesn't need an audit, since you can just read
           | the script.
        
             | doubled112 wrote:
             | Browserpass works pretty well.
             | 
             | https://github.com/browserpass/browserpass-extension
        
             | codethief wrote:
             | > In my opinion, this is one of the most secure options.
             | 
             | Only if you disregard that pass doesn't encrypt file names.
        
               | aborsy wrote:
               | That's part of the appeal. It allows for sandboxing each
               | password to its own vault essentially (you pay a privacy
               | cost, which I don't mind anyways, and my disk is
               | encrypted).
               | 
               | Gopass does encrypt file names too.
        
       | Seattle3503 wrote:
       | I'm glad I read this. My database was on KDBX 3, when KDBX 4 is
       | the latest and most secure version of the DB. I upgraded my DB
       | right away.
       | 
       | If version 4 is mores safe, KeePassXC should insert a nudge for
       | their users to upgrade.
        
       | _dain_ wrote:
       | This part in the PDF gave me pause:
       | 
       |  _> As KeePassXC is a relatively complex program and the review
       | effort was limited, I did not review all of the code base. Some
       | helper features stay not reviewed, for example: TOTP, SSH agent,
       | browser plug-in communication, auto-type, KeeShare password
       | sharing mechanism, freedesktop integration, HIBP support,
       | database statistics feature. Maybe these features could be a
       | subject to a next review version._
       | 
       | Those integrations seem like scary weak-points, especially to the
       | browser.. and I'm a little confused because later on he says he
       | did review the browser extension code:
       | 
       |  _> KeePassXC supports integration with browser extensions. The
       | communication between the password manager application and the
       | browser extensions is implemented using secure and modern
       | libsodium-style encryption. I personally trust this cryptography
       | choice and salut the use of encryption to communicate with
       | browser extensions._
        
         | droidmonkey wrote:
         | Hi there, lead developer of KeePassXC here (and writer of a lot
         | of code). The TOTP and SSH Agent are generally not a security
         | issue. TOTP has no external interfaces and SSH Agent only
         | writes to the known interface standards of those programs.
         | There is actually not much to those code areas.
         | 
         | Auto-Type is similarly rather simple at the interface level
         | (except for X11 because its X11). We call native OS functions
         | to emulate typing.
         | 
         | Similarly the internal reporting features are rather benign.
         | HIBP checks requires explicit approval by the user before
         | anything happens.
         | 
         | The browser code and FDO Secrets code definitely needs
         | auditing. The browser extension is separate from the browser
         | code within KeePassXC proper.
         | 
         | KeeShare is going to be entirely rewritten for our 2.8.0
         | release.
        
         | HPsquared wrote:
         | Maybe we need someone to audit the audit.
        
           | iotku wrote:
           | Who audits the auditors?
        
       | kej wrote:
       | I feel like "Who is Zaur Molotnikov?" is an important question
       | that is not addressed on the page. His CV is here:
       | https://molotnikov.de/cv
        
       | woodruffw wrote:
       | > KeePassXC is written well and exercises defensive coding
       | sufficiently.
       | 
       | This might be a transcription or language problem, but: auditors
       | really shouldn't normative claims like "software X is written
       | well," much less actually _endorse_ the software they're paid to
       | review (as the audit's summary appears to at the end of the
       | post). It's a massive conflict of interest, and undermines the
       | actual purpose of an audit: to accurately report any weaknesses
       | found (if any!), rather than offer an opinion on the product's
       | value or future exploitability (including against unknown
       | adversaries).
       | 
       | (This is not a dig at KeePassXC or this auditor in particular;
       | lots of auditing shops are guilty of this.)
        
         | Beldin wrote:
         | > _auditors really shouldn't normative claims_
         | 
         | Audits are - by necessity(1) - value judgements (otherwise we'd
         | call them "proofs"). This audit concerned the source code.
         | 
         | I very much want a source code audit to make value judgements
         | about the audited source code. That is its entire reason for
         | existing, after all.
         | 
         | (1) audits involve examination and possibly testing. Neither of
         | these can offer guarantees beyond "what we observed, is there /
         | happened."
        
           | yjftsjthsd-h wrote:
           | I thought audits were usually of the form "I looked for
           | vulnerabilities in this code, and found the following", which
           | isn't really a value assesment. I mean, yes, the point of
           | doing that is to have the basis on which to form an opinion
           | about "is this software safe/secure?" which is _absolutely_ a
           | value judgment and at least partially subjective, but I didn
           | 't think the audit itself tended to concern itself with that?
        
             | bionade24 wrote:
             | IMHO an audit should always report about how readable a
             | codebase is, because it's a dependency for the quality of
             | the audit. E.g when the 1st kubernetes audit pointed out
             | that the (side-)effects of certains operations are too
             | complex to understand, this gives some insight about the
             | height of the possibility for uncaught bugs and the
             | possibility to introduce new bugs.
        
             | riedel wrote:
             | Most important any audit should state methodology and
             | assumptions and report findings based on this.
             | 
             | My big problem with KeepassXC is that the threat model is
             | not well documented. It does a lot of fuzz around memory
             | randomisation but it might be much easier to extract the
             | secret key of the browser extension when unlocked. So I
             | guess it mostly provides security for data at rest, but
             | afaik this is not documented. A general security audit is
             | IMHO difficult if nobody states any guarantees.
        
         | adrianmonk wrote:
         | Personally, I think I want auditors to try to assess this.
         | 
         | There are certain risky / iffy coding practices (manual string
         | manipulation in C, for example) that might or might not lead to
         | actual security issues, depending on whether you make an error.
         | If no actual security issues are found in an audit, that's
         | good, but I want to know about the potential for them, too.
         | 
         | Yes, this is difficult to evaluate in an entirely objective
         | manner, but I'd rather they just do their best because to me
         | that's still better than no information.
        
         | sdfghswe wrote:
         | > much less actually endorse the software they're paid to
         | review
         | 
         | > It's a massive conflict of interest
         | 
         | They weren't paid.
         | 
         | There's no conflict of interest, at least not a commercial one.
        
           | abdullahkhalids wrote:
           | The review file does
           | 
           | * ask for donations to the author, and
           | 
           | * provides contact details of the author, in case someone
           | wants to hire them to review their software.
           | 
           | We can debate whether these constitute conflict of interest.
        
           | woodruffw wrote:
           | That's important information, and should be included in a
           | public announcement of an audit!
           | 
           | Even still: pro bono audits carry reputational value, meaning
           | that there's no way to fully discharge the conflict of
           | interest here. The only _correct_ way to do it is to refuse
           | to endorse the software you audit; an audit that
           | enthusiastically recommends the software it covers sets off
           | red flags.
           | 
           | Edit: I misread the post, which does explicitly state that
           | the audit was conducted for free.
        
             | politelemon wrote:
             | It is in the first paragraph
        
               | woodruffw wrote:
               | You're right, sorry -- I missed that. I'm going to edit
               | my comment with an explicit correction.
               | 
               | The second point still stands.
        
       | djha-skin wrote:
       | It is worth noting that most users use KeyPassXC with the mobile
       | applications Keepass2Android or Keypassium on Apple. A complete
       | picture of the security of the system must therefore necessarily
       | include an audit of these tools as well.
        
         | pedrogpimenta wrote:
         | And the way you sync the databases as well, if you do that.
        
           | marcosdumay wrote:
           | The point of those tools is that the security requirements on
           | the database file are much less strict than on the tooling.
        
         | jbj wrote:
         | Not KeePassDX which is in F-Droid?
        
       | [deleted]
        
       ___________________________________________________________________
       (page generated 2023-04-15 23:01 UTC)