According to http://gaganpreet.in/blog/2013/07/24/kwallet-security-analysis/ , the KWallet password management system is quite weak, it uses key splitting, Blowfish 56, and no salt.

The key generation can be described as – break up user password into blocks of 16 characters each, and apply SHA1 2000 times on each of them. This is key stretching without a salt. These blocks are then trimmed and concatenated to fit into 56 bytes, the maximum key length allowed by the Blowfish cipher.

It also says that, although it uses CBC, the way it uses it it becomes ECB.

KWallet uses CBC, or to be accurate, it pretends to – the keysize used for CBC is the length of the string to be encrypted, which turns CBC into the less safe mode of cipher – ECB.

My issue is, I use the same password for root as I do for my KWallet. /etc/shadow is only readable by root, but my .kwl file is readable by anyone, so anyone can get the file and try to brute force it, with possible success.

So is there any way I can improve the security of KWallet? It's not just for my manually inputted passwords, it's also for web browsers and applications which rely on KWallet to store passwords (e.g. Chromium), so I can't just switch to another program. Perhaps I could edit the source code, or find a fork that's compatible?

My final questions are: Is there any way I can improve KWallet's security, and how much of a security concern is using it?

5 Answers 5


The blog post you quote is quite imprecise in its formulation. However, by looking at the KWallet source code, especially this file (for the password hashing) and that file (for the invocation of the encryption code), we see the following:

The password is extended into a symmetric key of size 20, 40 or 56 bytes (160, 320 or 448 bits) by applying SHA-1 repeatedly. Namely:

  • If the password has length 0 to 16 characters, the key will have length 20 bytes and be the repeated application of SHA-1 (2000 times) on the password (the password is hashed, then the 20-byte output is hashed again, and again, for 2000 invocations of SHA-1).

  • If the password has length 17 to 32 characters, then the key will have length 40 bytes: the first 16 characters are processed as above, then the remaining characters are processed similarly, yielding 20 more bytes.

  • If the password has length 33 to 48 characters, then the key will have length 56 bytes: the first 16 characters are processed as above, the second chunk of 16 bytes of characters as well, and then the third chunk; the output for the first chunk is then truncated to 16 bytes, for a total of 56 bytes.

  • If the password has length 49 characters or more, then the 2000 SHA-1 invocations will happen four times. For the fourth chunk, the complete rest of the password will be used. The four 20-byte output are then each truncated to 14 bytes, and these are concatenated, yielding a 56-byte output.

As a password hashing function, it is quite poor. It is clunky and not regular. It is not salted, allowing for efficient parallel attacks, when several KWallet instances must be broken (as usual, "parallelism" also means that precomputed tables can be used, negating the slowing effect of the 2000 SHA-1 invocations). Moreover, it "splits" the password, so if an attacker finds a password hash, then he can attack each chunk independently of the others. This means that the security of the whole thing relies a lot on how well the Blowfish block cipher behaves when used as a hash function. This is, at best, a poorly studied property.

The encryption purports to use CBC, but does not. In CBC, you are supposed to encrypt a sequence of blocks (8 bytes per block with Blowfish); before encrypting a block, it is first XORed with the previous encrypted block. For the first block, we must conjure a formal "previous block" which is the Initialization Vector. CBC requires a random IV.

In the KWallet code, we see that the code indeed prepares a random IV of the right size.... then completely fails to do CBC. The call to encryption is:

int rc = bf.encrypt(wholeFile.data(), wholeFile.size());

(line 291 of backendpersisthandler.cpp)

Looking at the implementation for this encrypt() method, in cbc.cc, we see that it will create a temporary buffer of the same size of the whole file; then fill it with zeros; then XOR all these zeros with the data to encrypt (which won't change the data...); then proceed to encrypt each block independently of each other. This is, indeed, ECB mode, not CBC. It is quite obvious that this is a programming error; the lesson to learn, though, is that since KWallet appears to work, then the mistake was not detected: security cannot be tested through functionality.

(This implies that the random IV which was computed does nothing here; it is encrypted by itself but does not impact any other byte in the whole file.)

ECB mode is known to be weak in the following sense: it leaks information about what blocks are equal to each other. For an uncompressed picture, this is deadly, as demonstrated with the usual penguin image. For a KWallet, this is a source of worry: the internal structure has some redundancy, and this may be exploitable, although it would require some effort to ascertain the extent of the issue.

Note that since the password is not salted, two successive versions of the KWallet protected with the same password will use the same symmetric key, so block equalities leaked by ECB apply to all successive versions of the KWallet.

There is a homemade MAC. The last 20 bytes of the file (excluding some padding) contain a SHA-1 value computed over the rest. This is, generally speaking, not a good MAC. It would be an extremely bad MAC if the encryption used RC4 or a block cipher in CTR mode. With a block cipher in ECB mode (as used here), it is not as bad, but still poor.

The whole code reeks of homemade crypto slapped together by someone who did not master the concepts. This is bad. Also, I find the code to be atrocious in many respects (e.g. when the password chunks are hashed, the loop which invokes SHA-1 repeatedly is ruthlessly duplicated; that's a shooting offence). To "improve" KWallet, I suggest deleting the whole code and starting from scratch.

It seems that the code includes some optional support for not doing the password hashing and encryption itself (as we saw, it does it very poorly), but instead using GnuPG. Now THAT is a good idea. GnuPG implements the OpenPGP format which, for all its shortcomings, is at least decent cryptographically speaking (when properly used), and GnuPG is also known to be a tolerably good implementation. To improve storage of your KWallet, see if you can convince your computer to use this GnuPG support code and format.


Since KWallet is still the default password manager in KDE, I think this deserves an update.

Current Status, Apr 2021

The security bugs originally discussed in this question and the answers from 2013 (particularly Tom Leek's answer) are disclosed in CVE-2013-7252, which links back to the same blog post that was referenced in this question, which itself links back to Tom Leek's analysis here.

These issues have since been addressed. In particular, GPG support was added in kde-runtime 4.12, the password encryption was improved in 4.13, and the ECB/CBC issue was addressed in KDE Applications 14.12.1 and KF5::KWallet 5.6.0.
(Note: As I understand, in the latter link, "kde-runtime KWallet" refers to the older "KWallet 4", and "KF5::KWallet" refers to the newer "KWallet 5".)

Modern KWallet should not have these vulnerabilities, at least when using the GPG support (this post suggests using Kleopatra instead KGPG to set this up). But that is not to say there aren't any other vulnerabilities. For example:

  1. The password database and GUI manager are unlocked together. While the DB is unlocked, no additional password is required to view the stored passwords. Anyone with access to the PC can view every stored password as plain text via the GUI. This is made worse by the common practice of leaving it unlocked for the entire duration of a user's session.
  2. Likewise, the DB itself is stored as plain text while its unlocked. During this time, the DB security is only as good as the filesystem security (and in fact worse, due to other access options such as point 1 above).
  3. Any application can query the DB via CLI, and there's no isolation between different applications' passwords. So a malicious application can potentially query another application's password. (To be fair, this is likely a problem with other password stores as well.)
  4. When an application requests access to the wallet, the message is not always clear on which application is attempting access. So it can be difficult to tell if it's a legitimate request. Furthermore, it's easy to impersonate a valid application for such requests.
  5. It was, and likely still is, vulnerable to keylogger and ptrace attacks.

This thread from 2016 on the Plasma-devel mailing list provides more details.

Some of these can be reduced at the cost of some user convenience, by disabling auto-unlocking, enabling auto-locking, and requiring a prompt each time an application tries to access the wallet. In addition, don't store highly-sensitive secrets together with your application passwords, and use two-factor-authentication for the really sensitive stuff like your email (which can be used to reset many of your other passwords), bank account/website, and credit card/website passwords.

PAM auto-unlock:

Auto-unlock itself already reduces security as noted above, but according to ArchWiki, it's actually worse:

  • kwallet-pam is not compatible with GnuPG keys, the KDE Wallet must use the standard blowfish encryption.
  • The wallet must be named kdewallet (default name). It does not unlock any other wallet(s).

So you get either GPG or auto-unlock, not both; and the default wallet name is easy for a malicious script to guess (though the script could just run ls on the wallets folder anyway).

KSecretsService, QtKeyChain, libsecret

Back in the day, there was an attempt to replace KWallet with KSecretsService, aka KSecrets. This was an implementation of the FreeDesktop Secret Service API draft, which is also implemented by GNOME Keyring. But this was abandoned due to lack of developer time, and newer developments in the Linux ecosystem.

This was discussed on the Plasma-devel mailing list, and the consensus seemed to be to migrate the KDE apps to QtKeyChain, which would separate the API from the backend implementation. I don't know if that decision was followed, but given the level of activity on QtKeyChain, that seems like a reasonable assumption (this post somewhat confirms that as well).

A few months later, QtKeyChain added support for libsecret, which is also based on FreeDesktop Secret Service (included since QtKeyChain 0.8). More recently, libsecret is now required by QtKeyChain (unless disabled).

libsecret itself is a replacement for libgnome-keyring (but with no GNOME dependencies), so GNOME applications should also be migrating to libsecret.

KeePassXC and KDE Integration

KeePassXC is the modern successor of KeePassX, itself a Linux port of KeePass. KeePassXC is cross-platform via Qt5. It added libsecret support as of version 2.5.0 (2019). Theoretically (haven't tested this myself yet), this should allow KDE apps to communicate with KeePassXC, if those KDE apps use QtKeyChain.

(note: KeePassXC have done some work towards client isolation, but it's not a complete solution yet.)

Update, Aug 2022: Intiall support for the Secret Service API was added to KWallet in KDE Frameworks 5.97.0.


I AM NOT A SECURITY EXPERT. The information provided herein is merely a summary of what I found with Google. I am not responsible for any damages, loss of data or finances, security breaches, inconvenience, and so forth, resulting from your use of the information or advice provided herein. USE AT YOUR OWN RISK.


  1. CVE-2013-7252
  2. Bug 1048169 - CVE-2013-7252 kwallet: crypto misuse [fedora-all] - Bugzilla
  3. KDE Security Advisory 9 January 2015
  4. The situation of KWallet, and what to do about it? - Plasma-devel mailing list, 2016
  5. How secure kwallet is - KDE Forum
  6. Taming KDEwallet: Using GPG - Thoughts on computing
  7. Unable to configure Kgpg kwalletmanager - AskUbuntu
  8. Unlock KDE Wallet automatically on login - ArchWiki
  9. KSecretsService - KDE.org, KSecrets - GitHub
  10. Secret Service API Draft - FreeDesktop.org
  11. Libsecret revealed - LWN.net
  12. libsecret in Focal - Ubuntu Packages
  13. QtKeyChain commits history - GitHub
  14. QtKeyChain PR62: Added libsecret support - GitHub
  15. KeePassXC PR2726: Implement Freedesktop.org Secret Storage - GitHub

I'm the one who wrote the original blog post in question. I also wrote a Python script to read KWallet files, which should be easier to understand than the original KWallet code.

Tom is spot on with his analysis though. I tried to write for an average user, and didn't dig into the technical details. The KWallet code is in a horrible state, and other than the security issues described, the code is very poorly documented. KDE 5 will to bring a completely new password store, which is still a while away.

KWallet with GnuPG is in development, but has not been released yet. It'll come with KDE 4.12.

  • First thing you should do is not use the same password as root. Root is sacred!
  • You could protect the the password database better by creating a TrueCrypt volume and dropping it in there.
  • You could edit the source code but only if you really know what you're doing. If you don't know exactly what to do in the source you could make it worse.
  • Lastly you should look at KeePass it's open source, cross platform and a great password generator/manager.
  • 1
    I like KeePass because too many other recommended password managers tend to be proprietary managers you don't control. Oct 17, 2013 at 14:48
  • 1
    As I said in the OP, I'm not using this just as storage of manual passwords, for that I use Truecrypt. I use this because in KDE it integrates with Chromium and other applications so they don't have to store sensitive information in plaintext like it otherwise would have to do. Is KeePass able to integrate with the KWallet system?
    – taree
    Oct 18, 2013 at 3:47

Oy! Enough with the cipher mumble jumble, lets start with some remedial security:

chmod 600 *kwl

Why the hell is your KWallet file visible to anyone but you?!?

Second, who else uses the computer or otherwise has access to your stuff? If you are sitting behind a half-way decent router at home on a wired network that includes your computer, the router and a printer, then you probably have other things more important than fretting over cipher strength.

Third, TrueCrypt is great, but can be a bit of a headache to set up. You can use the user home directory encryption built into your distro (in openSUSE I have an option to check a box to encrypt user home directory), although that will end up with a fixed size of your home directory (sort of--I think you can mount additional stuff in there and make it look as big as you wish).

If you have somewhat modern SSD it might come with built-in hardware encryption (and many laptop HDD used in business class products, esp. Hitachi had this in their 7200 RPM 2.5 drives) which would protect you if you are at risk of your computer growing legs. When you log into the bios (typically) the key gets put into the lock so anyone using the system wouldn't be terribly hindered, at least until they had to reset the machine. Still, good idea for all laptops, and hardware encryption means no CPU overhead.

Another option, a bit more risque, is to put your wallet (whether Keepass or KDE or even your generic bog-standard keyring) in a cloud-synced directory. While Microsoft and Apple have seem to have had some technical difficulties in figuring out how to deliver this to their Linux using customers, DropBox and Copy.com have decent Linux clients. I was favorably impressed with Copy.com's security measures, but they are a company run by humans, so something could possibly happen someday.

I have lost a few USB drives from my pockets over the years, so I am not too keen of keeping my keys on it without some serious protection. This is where the TrueCrypt level of paranoia is probably helpful. The drawback is that you cannot be assured that you can mount TrueCrypt on someone else's machine (Kinkos your brother-in-law, etc.) in any environment. An alternative would be encrypt (easy way: 7zip is portable and on most every OS and has built in support for 256AES encryption, harder way: GNU Privacy Guard (GPG, the open source alternative to PGP) which is also available on most platforms, and again I think you can run it under Windows from a USB drive. There are several other options for using AES, with some also doing Twofish or Serpent (more exotic, but probably just as good for this use).

If I was using a USB to carry around my passwords, I would be sure to run as much software as possible as a portable app (with either a subsequently deleted RAM drive or a directory that gets encrypted at the end). Most of the stuff from PortableApps.com runs great under WINE (except for that ugly Windows-look to them), although I have had problems w/ Chrome. If your aluminum foil hat is getting too tight, the kindly folk at Tor have a portable version of a semi-hardened Firefox hooked up to Tor that you can also download and run from a USB drive.

You just have to get disciplined about decryption of the key store, and when finished, using a secure wipe program to clean up traces off the USB (or whatever) drive. You also will leave copies in RAM, cache swap space, etc. so a reboot is probably needed to be sure all the keys are gone.

Again, if you do this off a USB drive, assume it will drop out of your pocket and be found by someone who really doesn't like you and/or is looking to exploit you. So no off-line files, delete history automatically, etc. and run bleachbit or whatever the portable eraser program that comes with PortableApps when you are done.

Whatever your solution, the best way to test it is to use it religiously for a few weeks and then stop (go back to whatever your previous bad habits were). Then, after you forgot all the details, try and hack into your own stuff w/ the usual and customary tools. Nose around a bit. Amazing where today's Linux distros will stick stuff you thought only lived inside the walled garden of your home.

Now my plea for others who might stumble on this years after the original post: we need Keepass integration in KDE. Maybe they need stuff like that in GNOME, Xfce, etc. but since I (and honestly, none of my cool friends either) wouldn't be caught dead running it, that just isn't as important.

I am trying to figure out how to use KeepassX as a replacement for KWallet. It is a bit more secure, and has the advantage of being portable when I am forced to used that damn'd Windows crap.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .