Binding the touchIdEnabled Buttons state directly to the userdefaults
value.
Fixed bug that disabled the TouchIdEnabled button on an unsucessfull
TouchId unlock
Renamed touchIdEnabled outlet to touchIdEnabledButton in preparation
to bind a variable to the state value.
Used SecKeyCreateRandomKey instead of SecKeyGeneratePair as suggested
by the headers.
The fileURL for the current document does no longer have to be passed
in as a parameter but instead is retreived by accessing the windowControllers
document that hosts the MPPasswordInputController.
_touchIdHandleUnlockAttempt got renamed to _touchIdUpdateKeyForCurrentDocument
to better state its actual purpose and should no longer be called
on unsuccessfull unlock attempts. It also now removes stored keys if the
state of the TouchIdEnabled button has changed.
The key, that is derived from the document, is now the same whether it is
used to store it in the transient dictionary or the userdefaults
This is a good feature for security and stability. It gives users
the option to prevent TouchID unlock for any previously unlocked
database and it is also helpful in cases where only one part of the
keypair is in the macOS keychain.
While originally not intended, this changeset enables MacPass to
unlock a database with TouchID even after the process is completly
wiped.
It does this by introducing multiple modes of operation.
First: TouchId can be completly disabled. The TouchID checkbox is off
and MacPass works like the TouchID feature had never been added.
Second: The TouchID checkbox gets put into the mixed state. MacPass will now
remember the database key in memory as long as the process remains
alive and the database can be unlocked with TouchID until the
applications terminates.
Third: The TouchID checkbox is checked and MacPass will store the encrypted
database key on a successfull unlock attempt in the standard
userdefaults. TouchID unlock works now even after MacPass is completly
terminated and restarted.
kSecKeyAlgorithmRSAEncryptionOAEPSHA256AESGCM is now used. Apples CryptoKit makes
it very easy to use asymmetric cryptography to encrypt a symmetric key and with it
encrypt a message. So now the Database key material is no longer directly encrypted
with the asymmetric key but with a randomly generated symmetric one.
Changed the completion callback definition to take a KPKCompositeKey pointer
instead of a password string and keyfile URL. This is a intermedate step to
support key files with TouchID unlock. The next step is to make
KPKCompositeKey conform to the NSCoding protocol. The serialized data can
then be stored instead of the password.
Added a CheckBox to the PasswordInput view, so the user can see and
manipulate, whether the TouchID feature is enabled or disabled. The
choice is remembered in the standard user defaults.
This changeset adds the optional fileURL parameter to the
requestPasswordWithMessage function in MPPasswordInputController.
The controller uses this URL as a key to store the encrypted
masterpassword in a dictionary.
In my opinion edge cases like when a file is moved or replaced
do not have to get special handling since the worst case scenario
is that TouchID unlock does not work and users have still the
option to unlock with the masterpassword.
Also this changeset removes the unused
requestPasswordWithCompletionHandler function
Enabled the "Keychain Sharing" Entitlement that is required for
the Keychain APIs to work properly.
The additional buildstep signs the KissXML.framework nested inside
the KeePassKit.framework before this Framework itself is signed and
embedded. This is necessary because, to my knowledge, Xcode does not
support signing nested frameworks.
To use it a user must first enter the correct password for the database.
If the unlock succeeds, the supplied password is encrypted with the public
part of a RSA keypair. On subsequent unlocks a TouchID button appears. If
clicked, MacPass queries the Keychain for the private key part and uses it to
decrypt the previously supplied password and tries to unlock the database
with it.
