In the digital age, we store everything from photos of families, invoices and financial documents, to our login details to every service we utilizing, on a PC or smartphone, right? So, it is little question why security is a subject upon everyone’s lips. The security game keeps changing, but in 2016/7 a new crave hit my fancy, password managers.
The whole premise of a password manager is to store a key and username for accounts in an encrypted database, allowing the use of a master password to retrieve the credentials upon request – nifty.
Storing a local database that houses both the username and password to a multitide of accounts? Sounds risky, right? Not if you use the right methodology (or, tool)! There are a large array of posts about “should you trust password managers“, and I tend to be concerned about the security surrounding the product as well, but let me tell you the 5 key benefits to implementing a password manager as one solution to your security, that make it worth while:
- Being able to use unique passwords per service reduces the risk of cross-service exposure should your password be leaked;
- Being able to generate “strong” passwords based on requirements allows for a more randomized and secure approach to accounts;
- Being able to ensure your passwords are stored in a centralized encrypted database, as compared to “passwords.txt”;
- Allowing restricted access to your personal data (such as licenses, two-step codes etc.) in a restricted application amplifies security and;
- Prevents you from forgetting passwords (and therefore, making easy-to-remember passwords, or repeating them cross-site)
Now, I would consider password managers as one layer to password security. When implementing a secure process for storing logins, one can never be too careful. For example, to ensure the integrity of my data stays secure (or at least, more secure), I implement the following approach to my digital accounts:
- I use 1Password to store my usernames to services, with the password field being a reference;
- I use EnpassIO to reference the password codename to the actual password and;
- I use Google Authenticator to provide a 2-Step Authentication approach.
This ensures that without access to both databases, there is no ability to compromise my accounts – the master passwords to both are unique and not recreated for any other service.
So, by relying on 3 unique services to all work in cohesion with one another for access to my accounts, I have improved the security layers surrounding my accounts. It is, however, worth mentioning that implementing 2-Step Authentication adds another layer of complexity to the account process. We will post more about two-step authentication in future posts.
What Encryption can we expect?
In this post, I am going to cover EnPass in a rather broad (and non-technical) medium, but also reference key information that can relate to other solutions.
What makes a password manager so safe, and how does encryption work?
There are several methods (and encryption protocols) that can/should be implemented per program; there is no real answer to how your tool will implement encryption. This unique approach to variances in security has widely been discussed, argued and vetted by the general community; the only core theory to the unique password manager application is the process where the product will hash your passwords in line with your master password, using their own algorithms to encrypt “their database”.
The statement released by EnPass states that your data is encrypted with 24,000 rounds of PBKDF2, as follows:
Your data is fully encrypted with 256-bit AES with 24,000 rounds of PBKDF2 using the peer-reviewed and open-source encryption engine SQLCipher, providing you with advanced protection against brute force and side channel attacks.
Source: EnPass Security
Yes, that’s all good and well, but what exactly does that mean, you ask. To understand the process in which this product operates, one must understand the process PBKDF2 is implemented.
PBKDF2 applies a pseudorandom function, such as hash-based message authentication code (HMAC), to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key, which can then be used as a cryptographic key in subsequent operations. The added computational work makes password cracking much more difficult, and is known as key stretching.
This is why I have the disclaimer that I am not familiar with computer security. If we look at the core basic, EnPass is passing your Master Password through 24,000 rounds of Salt (“Number of Iteration” in the below mentioned image), you are able to ascertain your derived key for access.
The process for this can be summarized with the below diagram:
Or more simply put:
The salt value is appended to your password, which is then hashed with the iteration count to supply the hash result (Derived Key) with the salt value for decryption. This process can further be depicted as:
Without the SALT value, there is no direct method to decrypt the password. For EnPass, the process for the Hash Function incorporates encrypting the data with an AES-256Bit Encryption, with SQLCipher implementation.
Your local database is hashed 24,000.0+1 using AES-256BIT Encryption and is validated against the master password per entry. Loss of the master password results in loss of data.
SQLCipher – the process EnPassIO implements.
Please be aware, the information is sourced direct from SQLCipher, in order to be as factual and transparent as possible.
SQLCipher is an extension of SQLLite, and is marketed as:
SQLCipher is an open source extension to SQLite that provides transparent 256-bit AES encryption of database files.
SQLCipher has an array of features, and can be summarised as:
- The default algorithm is 256-bit AES in CBC mode (cipher and mode can be changed at run time via
PRAGMA cipher, though only when using a cryptography provider that supports multiple ciphers, i.e. OpenSSL).
- Each database page is encrypted and decrypted individually. The default page size is 1024 bytes but this can be adjusted at runtime to improve performance for certain query types.
- Each page has it’s own random initialization vector. The IV is generated by a cryptographically secure random number generator (e.g. OpenSSL’s
RAND_bytes, CommonCrypto’s SecRandom, LibTomCrypt Fortuna), and is stored at the end of the page. IVs are regenerated on write so that the same IV is not reused on subsequent writes of the same page data.
- Every page write includes a Message Authentication Code (HMAC_SHA1) of the ciphertext and the initialization vector at the end of the page. The MAC is checked when the page is read back from disk. If the ciphertext or IV have been tampered with or corrupted the HMAC check will cause SQLCipher to report a problem with the database.
- When initialized with a passphrase SQLCipher derives the key data using PBKDF2. Each database is initialized with a unique random salt in the first 16 bytes of the file. This salt is used for key derivation and it ensures that even if two databases are created using the same password, they will not have the same encryption key. The default configuration uses 64000 iterations for key derivation (this can be changed at runtime using
- The key used to calculate page HMACs is different that the encryption key. It is derived from the encryption key and using PBKDF2 with 2 iterations and a variation of the random database salt.
- If use of a passphrase is undesirable, an application may provide raw binary key data (for instance to support vaulted keys, or the use of PKI based key exchange).
- When encrypted, the entire database file appears to contain random data.
- SQLCipher does not implement its own encryption. Instead it uses the widely available encryption libraries like OpenSSL libcrypto, LibTomCrypt, and CommonCrypto for all cryptographic functions. The cryptography provider used depends on the platform and configuration options.
Some areas I would like to highlight are:
- The HMACs is unique and not identical to the encryption key (by default);
- SQLCipher encrypts entire databases, not just entries and;
- When initialized with a passphrase SQLCipher derives the key data using PBKDF2. Each database is initialized with a unique random salt in the first 16 bytes of the file. This salt is used for key derivation and it ensures that even if two databases are created using the same password, they will not have the same encryption key.
Installing and using EnPassIO
Okay, we’re not going to ram more information down your throat in relation to security…or are we? No. No sir, we are not. Let’s get down to business. To install EnPassIO on a Ubuntu instance, you can follow the process detailed from EnPass:
$ sudo su $ echo "deb http://repo.sinew.in/ stable main" > \ /etc/apt/sources.list.d/enpass.list
Once the repository is added, use wget to import the signed key:
$ wget -O - https://dl.sinew.in/keys/enpass-linux.key | apt-key add -
Lastly. update your link and install the package:
$ apt-get update $ apt-get install enpass
Of course if you’re a Windows or MAC OSX user, Android or iPhone user you can just download the package, and you’re done.
Upon initial setup, you will need to input your fancy, ultra-secure Master Password to order EnPass. Once within the product, you can create your accounts, licenses etc. and organize them as you wish – I am not really going to step through this for you, however.
The only setting within EnPass I would recommend you look into, is the backup functionality. There are 3 backup process you can perform:
- Device Backup – for example, on Android it might be /dkim/apps/enpass;
- Cloud Backup – log into a cloud service and sync your database or;
- Start a service on your LAN and share the file direct to PC / Other device.
For me, I prefer to keep everything local and not on the cloud, so I use option 3.
2 Step Authentication
Of course, 2FA, or Two-Step/Factor Authentication is the means in where utilizing a secondary token, or application to supply a login combination is required. Key services such as Google, Steam and Discord all natively recommend the use of Two-Step Authentication.
Implementing a secure two-step process alongside secure passwords help improve the durability (if not indefinite) of an accounts security.
Do you have information, or examples of the security protocols and methodology? Is there a mistake or non-factual statement in this document? Let me know!