* The hardware key missing error message is properly shown and the user can try to Quick Unlock again after plugging in or tapping the hardware key in time.
* Special thanks to @HexF and @smlu for their contributions towards this feature.
* Add MVP support for Windows Hello as a Quick Unlock solution using the WinRT API. This works by signing a random challenge vector with the Windows Hello protected key store (typically from TPM). The signed challenge is hashed using SHA-256 and then used as the encryption key to encrypt the database credentials. Credentials are encrypted using AES-256/GCM. This ensures the database password can only be decrypted following a successful authentication with Windows Hello in the future.
* Unify Touch ID and Windows Hello behavior under the Quick Unlock branding. Remove all timeout features of Touch ID as they are unnecessary and complicate the feature for no security gain.
* Quick Unlock is automatically reset only when the database key is changed vice whenever database settings are modified.
* Don't set database unlock dialog as always on top. This allows Touch ID and Windows Hello prompts to appear above the dialog properly.
* Prevent quick unlock when using AutoOpen or opening from the command line.
Shows a warning when trying to open with a newer minor version than what is currently supported.
We always try to save with the lowest KDBX version possible for maximum compatibility.
* Support NFC readers for hardware tokens using PC/SC
This requires a new library dependency: PCSC.
The PCSC library provides methods to access smartcards. On Linux, the third-party pcsc-lite package is used. On Windows, the native Windows API (Winscard.dll) is used. On Mac OSX, the native OSX API (framework-PCSC) is used.
* Split hardware key access into multiple classes to handle different methods of communicating with the keys.
* Since the Yubikey can now be a wireless token as well, the verb "plug in" was replaced with a more
generic "interface with". This shall indicate that the user has to present their token to the reader, or plug it in via USB.
* Add PC/SC interface for YubiKey challenge-response
This new interface uses the PC/SC protocol and API
instead of the USB protocol via ykpers. Many YubiKeys expose their functionality as a CCID device, which can be interfaced with using PC/SC. This is especially useful for NFC-only or NFC-capable Yubikeys, when they are used together with a PC/SC compliant NFC reader device.
Although many (not all) Yubikeys expose their CCID functionality over their own USB connection as well, the HMAC-SHA1 functionality is often locked in this mode, as it requires eg. a touch on the gold button. When accessing the CCID functionality wirelessly via NFC (like this code can do using a reader), then the user interaction is to present the key to the reader.
This implementation has been tested on Linux using pcsc-lite, Windows using the native Winscard.dll library, and Mac OSX using the native PCSC-framework library.
* Remove PC/SC ATR whitelist, instead scan for AIDs
Before, a whitelist of ATR codes (answer to reset, hardware-specific)
was used to scan for compatible (Yubi)Keys.
Now, every connected smartcard is scanned for AIDs (applet identifier),
which are known to implement the HMAC-SHA1 protocol.
This enables the support of currently unknown or unreleased hardware.
Co-authored-by: Jonathan White <support@dmapps.us>
* Use hash based storage for last used directories instead of a key/value for each type
* Explicitly declare certain operations as sensitive and follow the "Remember Last Database" setting for those.
* Introduce database backup directory location (close#6619)
Selected the [Botan crypto library](https://github.com/randombit/botan) due to its feature list, maintainer support, availability across all deployment platforms, and ease of use. Also evaluated Crypto++ as a viable candidate, but the additional features of Botan (PKCS#11, TPM, etc) won out.
The random number generator received a backend upgrade. Botan prefers hardware-based RNG's and will provide one if available. This is transparent to KeePassXC and a significant improvement over gcrypt.
Replaced Argon2 library with built-in Botan implementation that supports i, d, and id. This requires Botan 2.11.0 or higher. Also simplified the parameter test across KDF's.
Aligned SymmetricCipher parameters with available modes. All encrypt and decrypt operations are done in-place instead of returning new objects. This allows use of secure vectors in the future with no additional overhead.
Took this opportunity to decouple KeeShare from SSH Agent. Removed leftover code from OpenSSHKey and consolidated the SSH Agent code into the same directory. Removed bcrypt and blowfish inserts since they are provided by Botan.
Additionally simplified KeeShare settings interface by removing raw certificate byte data from the user interface. KeeShare will be further refactored in a future PR.
NOTE: This PR breaks backwards compatibility with KeeShare certificates due to different RSA key storage with Botan. As a result, new "own" certificates will need to be generated and trust re-established.
Removed YKChallengeResponseKeyCLI in favor of just using the original implementation with signal/slots.
Removed TestRandom stub since it was just faking random numbers and not actually using the backend. TestRandomGenerator now uses the actual RNG.
Greatly simplified Secret Service plugin's use of crypto functions with Botan.
As discussed in #4317, the next KeePass2 release will ship with
support for a new generation of XML key files which enable
hash integrity checks.
This patch adds support for reading and generating this new format.
By default, KeePass2 now uses the .keyx extension for generated
key files, which was added to KeePassXC's key generation file chooser
filter. We continue to generate hashed binary key files by default,
but the user can explicitly save the file with the new .keyx
extension to generate an XML v2 key file (currently undocumented).
When opening a database, the key file type is still determined
by content negotation, so the file extension has no impact here.
As an additional change, the legacy key file warnings have been
improved slightly to be less confusing and more helpful.
As discussed in #4317, the next KeePass2 release will ship with
support for a new generation of XML key files which enable
hash integrity checks.
This patch adds support for reading and generating this new format.
By default, KeePass2 now uses the .keyx extension for generated
key files, which was added to KeePassXC's key generation file chooser
filter. We continue to generate hashed binary key files by default,
but the user can explicitly save the file with the new .keyx
extension to generate an XML v2 key file (currently undocumented).
When opening a database, the key file type is still determined
by content negotation, so the file extension has no impact here.
As an additional change, the legacy key file warnings have been
improved slightly to be less confusing and more helpful.
* Include new icons for toolbar overflow to ensure they are tinted correctly and fit in with the rest of the UI.
* Replace custom code for clearing line edits by including a proper icon for the default action.
Definitions:
* Database Key - Cryptographic hash used to perform encrypt/decrypt of the database.
* Database Credentials - User facing term to refer to the collection of Password, Key File, and/or Hardware Key used to derive the Database Key.
Changes:
* Remove the term "master" and "key" from the user's lexicon and clarify the code base based on the definitions above.
* Clean up wording in the UI to be clearer to the end user.
* Only clear password field when switching tabs or minimizing. This prevents the setting "Remember Key Files and Hardware Keys" from being useless with multiple databases.
* Convert key file field to Line Edit, simplifies usage. Fix clear field button as well.
* Removed need for clearForms to check if the database is being opened (was a solution to tab switching while unlocking, no longer a problem).
* Significantly improve user experience when using hardware keys on databases in both GUI and CLI modes. Prevent locking up the YubiKey USB interface for prolonged periods of time. Allows for other apps to use the key concurrently with KeePassXC.
* Improve messages displayed to user when finding keys and when user interaction is required. Output specific error messages when handling hardware keys during database read/write.
* Only poll for keys when previously used or upon user request. Prevent continuously polling keys when accessing the UI such as switching tabs and minimize/maximize.
* Add support for using multiple hardware keys simultaneously. Keys are identified by their serial number which prevents using the wrong key during open and save operations.
* Fixes#4400
* Fixes#4065
* Fixes#1050
* Fixes#1215
* Fixes#3087
* Fixes#1088
* Fixes#1869
Replaces all string configuration options with enum types
that can be checked by the compiler. This prevents spelling
errors, in-place configuration definitions, and inconsistent
default values. The default value config getter signature was
removed in favour of consistently and centrally default-initialised
configuration values.
Individual default values were adjusted for better security,
such as the default password length, which was increased from
16 characters to 32.
The already existing config option deprecation map was extended
by a general migration procedure using configuration versioning.
Settings were split into Roaming and Local settings, which
go to their respective AppData locations on Windows.
Fixes#2574Fixes#2193
* Remove repeat password on entry edit
* Move show/hide password and password generator buttons into the field as actions.
* Register keyboard shortcut Ctrl+H to toggle password visibility
* Register keyboard shortcut Ctrl+G to open the password generator
* Cleanup code and improve interactions between elements
* Simplify Password Generator button layout; convert advanced mode button to toggle button
* Update GUI tests
* Fixes#4120
* Fix#3735 - Don't focus on OpenDatabaseWidget fields that are not visible; ensures password field is focused after database lock.
* Fix#3487 - Password input is selected after failed unlock.
* Fix#1938 - Password input is focused after toggling visibility using the keyboard
The new unlock dialogue seems to confuse users
as to what the purpose of the key file is. This
patch changes the generic "Select file..." affordance
to the more explicit "Select key file..." and adds
a help button to the label just like the one we
already have for the hardware key. Furthermore,
it prevents the user from using the KDBX file as its
own key file (since that would never work anyway).
The change breaks existing translations on purpose
(instead of simply adjusting the en_US locale)
in order to force translators to update this string
for their languages.
Resolves#3678
Updating mingw-w64-x86_64-qt5 to version 5.12.4-2 caused EditEntryWidget to fail
building. Fixed that with proper includes. Also ran `make format` which revealed
one file in need of formatting.
With this change we get rid of the confusing key component checkboxes.
Now a component is either there or not (if left empty). There is
no redundant distinction between "unset" and "emtpy" anymore.
For compatibility with older databases that have "empty" passwords,
KeePassXC will ask if the user wants to retry with an empty password
if unlocking failed and the password field was left blank.
Besides these functional changes, the widget's layout has been
rearranged to be more compact, less stretched out (e.g. input fields
do not fill the full window width anymore), and more user-friendly
by providing a help tooltip for the hardware key field and accessible
descriptions for screen readers.
* Fix#2877 - password is unchecked by default
* Smarter activation of key components based on contents of text entry fields
* Prevent multiple copies of the same database from opening when the canonicalFileName != fileName
Many lines were not conformant with the project's formatting rules.
This patch should fix all formatting and whitespace issues in the code
base.
A clang-format directive was put around the connect() calls containing
SIGNALs and SLOTs whose signatures would be denormalized because of the
formatting rules.
* Fix SSHAgent identity removal on database lock
* Refactor storage and manipulation of SSHAgent keys to streamline process with multiple db's
* Clear password field when widget is hidden, resolves#2502
The Database, DatabaseWidget, and DatabaseTabWidget classes share many responsibilities in inconsistent ways resulting in impenetrable and unmaintainable code and a diverse set of bugs and architecture restrictions. This patch reworks the architecture, responsibilities of, and dependencies between these classes.
The core changes are:
* Move loading and saving logic from widgets into the Database class
* Get rid of the DatabaseManagerStruct and move all the information contained in it into the Database
* Let database objects keep track of modifications and dirty/clean state instead of handing this to external widgets
* Move GUI interactions for loading and saving from the DatabaseTabWidget into the DatabaseWidget (resolves#2494 as a side-effect)
* Heavily clean up DatabaseTabWidget and degrade it to a slightly glorified QTabWidget
* Use QSharedPointers for all Database objects
* Remove the modifiedImmediate signal and replace it with a markAsModified() method
* Implement proper tabName() method instead of reading back titles from GUI widgets (resolves#1389 and its duplicates #2146#855)
* Fix unwanted AES-KDF downgrade if database uses Argon2 and has CustomData
* Improve code
This patch is also the first major step towards solving issues #476 and #2322.
Use nullptr instead of 0 or NULL to initialize a null pointer. In some
cases, readability was enhanced by replacing 0 with more meaningful
values according to the type of the pointer being initialized.
This patch implements a new database wizard to guide users through the process
of setting up a new database and choosing sane encryption settings.
It also reimplements the master key settings to be more
user-friendly. Users can now add, change, or remove individual composite
key components instead of having to set all components at once. This
avoids confusion about a password being reset if the user only wants to
add a key file.
With these changes comes a major refactor of how database composite keys and key
components are handled. Copying of keys is prohibited and each key
exists only once in memory and is referenced via shared pointers. GUI
components for changing individual keys are encapsulated into separate
classes to be more reusable. The password edit and generator widgets
have also been refactored to be more reusable.
