How is my integrity protected when I use Spoddler?

Spoddler stores data at client and in the cloud. To understand the data that it stores and how it is protected, we separate auto-collected data and manually entered data.

Auto-collected Data

Auto-collected data is what Spoddler automatically records from your use of the computer when you do not actively interact with the program. We see this data as the most sensitive data since it includes all visited web sites and the documents and programs you

actively have been using.

Auto-collected data are protected by strong encryption both locally and on our cloud services. We also make sure that we ourselves do not have any possible access to them as we impossibly could decrypt them. Only our users have the keys locally on their devices.

Manually Entered Data

Manually entered data is data that you create or update while actively interacting with Spoddler. Examples of such data is clients, projects, tasks, comments and time stamps of when you started or stopped working with a project.

Manually entered data are protected by industry standards - strong authentication and strong SSL encryption.

More secure and integrity aware than most other apps
Spoddler takes your integrity one step deeper than other services through strong encryption of sensitive data both locally and in the cloud. This gives you a much stronger protection than what other cloud service or phone operators could offer. And the reason for this, is that we respect your integrity and we have no interest in having access to our user's auto-collected data. In fact, we want to use the best method to avoid any possibility for ourselves or our partners to have any possibility to access that data.

Encrypted locally, Encrypted in the cloud
All auto-collected data such as visited URLs, used documents, programs etc are immediately encrypted locally using a 128-bit symmetric key, which is in its turn protected by the encryption of the operating system of the client computer. Spoddler can also sync the encrypted between your devices and with the cloud. Your data is encrypted all the way - also when stored on our cloud services, but the encryption key never leaves your client machine - so no one can decrypt your data even if getting access to the database.

Strong Encryption Key protects your sensitive data

To protect automatically collected data but still being able to synchronize it between computers, as well as being able to backup that data, the client creates a unique 128-bit key (AES) when you install Spoddler on your desktop computer. This key is then stored using the built-in security functions of the operating system. Spoddler's cloud service has not idea about your key and it is impossible for any employer, technician or hacker to retrieve this information even if they could export our entire database.

Authentication and SSL-encryption protects manually entered data

Your manually entered data - projects, tasks, clients etc, and the time where you've actively submitted on these, are also protected with industry standards equal to those used by market leading cloud services. The data is protected by strong 128-bit API-key authentication (much stronger than passwords) and transport encryption (SSL) - in level with market leading cloud services and internet banks.

Lost keys
Lost encryption keys, for example due to re-installation will make you loose your auto-collected data but you'll still keep your projects, tasks and time entries as they are not part of the encrypted data. You'll be able to continue using Spoddler, but the last hours, days or weeks that you haven't mapped to projects will be lost. In a normal flow, you'll be mapping these entries to projects at least once per day so the loss does not need to be too harmful.

Chryptographic Details
The encryption key is a 128-bit symmetric AES key. Each encrypted database record has its own random-generated initialization vector (IV) of 128 bits. The key is encrypted with the built-in encryption in Windows and Mac and bound to the computer user. For Windows, a .NET framework System.Security.Cryptography is used to accomplish this. An application-specific salt / entropy is being used together with the OS-specific encryption of the encryption key.

Authentication key is derived from encryption key through a SHA1 digest of the encryption key. The cloud service stores only the digest of the authentication key (digest of the digest of the encryption key). In that way, the cloud service may only verify the client but not derive the encryption key. The reason that the encryption key cannot be be derived is that SHA1 is irreversible in its nature. The database of client digests in the cloud service is not vulnerable to brute-force attacks since the source of the digests are random 128-bit arrays. Brute force attacks on password-digest databases can only be successful for short or commonly used passwords from word- or name databases or earlier hacked databases. It is not possible with today's computer power to brute-force attack the database to gain the origin encryption keys.