----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115497/#review49065 -----------------------------------------------------------
I think the salt selection should be improved (or at least stored with the passwords on disk in case the user chooses a different login name). You might also want to consider 'scrypt' instead of PBKDF2 (both are available in libgcrypt). kwalletd/backend/kwalletbackend.cc <https://git.reviewboard.kde.org/r/115497/#comment34646> libgcrypt supports the "scrypt" key derivation function since 1.6.0, and we require 1.6.1. Since scrypt is superior in almost all respects to PBKDF2 I'd recommend using it instead since we're improving KDFs here anyways. More info at http://www.tarsnap.com/scrypt.html There are "side channel" attacks possible with scrypt by its design that don't occur with PBKDF2, but there shouldn't be malicious code running on the user's system at the same time as they're opening the wallet anyways (if that's the case we have bigger problems). The "bcrypt" algorithm is apparently even better for this particular use case, but it doesn't appear to be available in libgcrypt. kwalletd/backend/kwalletbackend.cc <https://git.reviewboard.kde.org/r/115497/#comment34645> The salt here seems to be based off of the user's login-name, which can change (for instance, someday my KDE git user account will change away from "kde-svn"... I've just been lazy so far ;). Beyond that the salt should really be random bytes otherwise you could still build rainbow tables of the top-100 most popular user names, for instance. Using random bytes would complicate this since you'd have to actually store the salt and re-load it to re-derive the right key, but it's the right way to do it. In any event it's probably more important to ensure that there's no data loss if the user tries to open their wallet under a different UNIX login, even if we have to use a plain constant string as the salt. kwalletd/backend/kwalletbackend.cc <https://git.reviewboard.kde.org/r/115497/#comment34643> Seems to be no error checking here, if this fails and we overwrite the hashed passwords on disk, couldn't there be data loss when we try to re-open them (when the user can't guess the key)? - Michael Pyne On Feb. 5, 2014, 3:10 p.m., Àlex Fiestas wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115497/ > ----------------------------------------------------------- > > (Updated Feb. 5, 2014, 3:10 p.m.) > > > Review request for KDE Runtime, Teo Mrnjavac and Valentin Rusu. > > > Repository: kde-runtime > > > Description > ------- > > Uses the MINOR_VERSION (which until now it was 0) to upgrade the hash from > SHA to PBKDF2-SHA512+salt. > I would have loved to completely replace it once the wallet is ported to the > new hashing but because > of kwalletd code that is not possible without a bigger rewrite. > > There are 2 reasons for this patch: > 1-We avoid using our own implementation of SHA > 2-We use a modern hashing technique > > I'm cooking more patches to use the system user password to open the wallet, > we want that password to be > hashed using PBKDF2_SHA512 for security reasons. > > > Diffs > ----- > > CMakeLists.txt 275a6c7 > cmake/modules/FindLibGcrypt.cmake PRE-CREATION > kwalletd/backend/CMakeLists.txt 5a5837c > kwalletd/backend/backendpersisthandler.cpp bdef6ca > kwalletd/backend/kwalletbackend.h 83ebf7f > kwalletd/backend/kwalletbackend.cc e4d461c > > Diff: https://git.reviewboard.kde.org/r/115497/diff/ > > > Testing > ------- > > > Thanks, > > Àlex Fiestas > >
