The old values/test cases match behaviour on Debian, where the QDateTime
class gets confused at lower limits for the internal ms since epoch value
than it does on SUSE for some reason.
Add a 'proxy' to forward external API calls into the main application
control flow. Right now it only supports forwarding commandline
arguments, but this construct is already useful as a starting point for
future D-Bus API support.
Previously entering an incorrect password would appear to successfully "unlock" accounts, contrary to expectations.
By introducing a challenge object as part of the master key parameters, an incorrect password can now be detected and signalled accordingly.
This fix introduces a backwards incompatible change to the accounts data as stored on disk, meaning old Keysmith accounts configuration will no longer load and must be recreated from scratch.
This change is a building block towards receiving decoded QR codes from other applications and adding corresponding accounts in Keysmith.
Issues: #7, #14
Add support converting an otpauth:// URI into a model object.
Validation is quite lax and focused on what Keysmith can recover from within the scope of UI/UX for adding accounts via QR codes.
See-Also: https://github.com/google/google-authenticator/wiki/Key-Uri-Format
Issues: #14
This change provides a bare minimum implementation to parse an otpauth:// type URI into its component parts.
Parsing is quite lax, and focused on what Keysmith can support or recover from in the intended UI/UX for adding accounts via QR codes.
See-Also: https://github.com/google/google-authenticator/wiki/Key-Uri-Format
Issues: #14
One downside of offloading the token computation to a worker thread and having to do token decryption is an increase in latency.
For the case with a few accounts this latency does not matter, but in case of many accounts it can induce a significant delay when refreshing tokens in the UI.
To hide this latency, when computing an OTP token for the current state of the account the logical 'next' token is also computed as well and cached in the Account object.
When the next (re)computation of the OTP token is requested, the cached 'next' value is reused if still valid before the next pair of tokens is being computed.
This way the apparent latency of a token update is reduced to an near immediate property update in the UI, hiding the actual latency of the computation itself.
This 'optimisation' is implemented in the dumbest possible fashion that can still work.
This means that the code complexity of the change is quite limited, at the cost of rougly doubling the actual work being performed in the worker thread.
With this the AccountStorage module now fully supports some HOTP/TOTP parameters which are uncommon (but still part of HOTP/TOTP specifications).
- Better types for offset, tokenLength. Make this consistent throughout
- Finish support for offset, checksum parameters for HOTP tokens in AccountStorage
- Finish support for hashing algorithm, epoch parameters for TOTP tokens in AccountStorage
- Better API for creating oath::Algorithm instances
- Code formatting (break up long lines)
Issues: #7
With this change account storage and model work with accounts for which an issuer is recorded.
This is a prerequisite for fully supporting otpauth:// URIs (necessary for QR code support) in Keysmith.
Issues: #7, #13
See-Also: https://github.com/google/google-authenticator/wiki/Key-Uri-Format
Two bits of boolean state are introduces to track whether or not:
- an error has occurred
- accounts have been loaded from storage yet
This change paves the way for having error handling UX.
With this change token secrets are encrypted prior to writing them to
storage, and decrypted as and when needed to generate tokens. Additional
validation is performed to verify that token secrets can be decrypted
successfully when loading accounts from storage.
With this change issue #6 should finally be resolved.
With this change an unlock stage is introduced to loading account storage.
Key derivation parameters for a master key are recorded, and the master
password may be supplied to "unlock" the account secret(s) in storage.
This change paves the way for actually decrypting encrypted account
secrets later, and finally solving issue #6.
Introduce a secrets library which implements the necessary crypto using
libsodium. This change provides the basic building blocks for resolving
issue #6.
This change is a workaround for behaviour of QML controls: when fixup is
called during input validation, the `acceptableInput` property is not
updated correctly.
Provide a building block towards re-implementing the HOTP/TOTP
algorithms without using oath-toolkit: see issue #9.
The hmac::compute function trades simplicity (having to pre-allocate
a scratch buffer) for avoding accidental leaks of key material
(security).
This particular trade-off will help with resolving issue #6.
Provide a custom base32 implementation; relates to issues: #9 and #6.
In particular being able to control memory allocation prior to
decoding base32 will help with resolving issue #6 in a (more) secure
fashion.
* do cmake_minimum_required as first thing, as recommended
* bump KF to 5.37, first release with Kirigami (Qt 5.7 matching min dep)
* use KF5_MIN_VERSION also with ECM
* include KDE CMake settings as first
* remove unused cmake includes
* remove duplicated enable_testing()
* use correct KDEInstallDirs variables
- Add a new static library "validator_lib" covering the "validators" namespace in C++
- Introduce the Base32Validator to perform input field validation with fixup support
Johan Ouwerkerk
Yuri Chornoivan
Friedrich W. H. Kossebau