mSecure Support
Account key encryption and management
Mike - mSecure
Hi Johan,
I'm sorry about the delay in my response. I was away on holiday recently. I'll try my best to answer your questions here:
- Correct.
- Correct
- All our encryption is done via 256bit AES encryption
- Correct
- We do have different options to store the encrypted account key on Android and Windows.
- On Android, we store the encrypted account key file (mSecure.msecurekey) in the Google Drive Android Backups (https://drive.google.com/drive/u/0/backups) where available. If you sign in to your Google account on another Android device, you'll have the chance to restore your Android Backup and can restore the encrypted account key file if you selected to restore an Android Backup or sync the Android backup.
- On Windows, we store the encrypted account key in your computer's Web Credentials secure credentials management system. (https://support.microsoft.com/en-us/help/4026814/windows-accessing-credential-manager). These credentials should sync across your Windows 10 computers using the same Microsoft Account. However, unfortunately, that is not always the case in our testing.
- To send the encrypted account email, mSecure 5 on your device will send our separate server your user id (not the account email address) and encrypted account key. From there, the service we use will create the QR code image based on the encrypted account key, attach the PDF file to the email, compose the message, and the email is sent to to the email address for the user. We use HTTPS API, implicit SMTP-SSL, or SMTP with STARTTLS when sending the emails. when we deliver your message we will attempt to negotiate a TLS connection with the recipient’s mail server. This means that so long as the recipients’ mail servers are configured to properly support TLS (all major email provides now support TLS encryption), it will be impossible for a passive adversary along the route to intercept and/or modify the message. Please note that our email system is not part of our mSecure account system. It is a completely separate system and never talks directly to our account system.
- Correct
- This is the next step and only if using a cloud sync method, and if using Dropbox syncing, you might have to first link your Dropbox account in order to start being able to download or sync the information you might have in Dropbox.
- This happens before step 8 or is step 8. Nothing will ever be sync or downloaded until everything checks out.
I don't understand what you mean about the known text string though. The known text string is what validates the account key. Otherwise, we would have to store the account key validation key directly on our servers. How the known piece of text works is that the known piece of text will only be decrypted properly using the correct account key that was used to encrypt the know piece of text to begin with. If the account key cannot decrypt the known piece of text to the know string, the account cannot be valid. Does that make sense? I can go ove that some more if needed.
Unfortunately, or fortunately, we have to strive to make our process as easy as possible. Because of that, we opted to have a user's account key be encrypted via a user's password using 256-bit AES encryption and send to a user via email. To answer your question, we send the encrypted account key via email because without it, you might not be able to access your mSecure information if you install or reinstall mSecure 5. When we released mSecure 5, we did not store the encrypted account key as a file on platforms and use it to try to authenticate initially. Because of that, users need to have access to their account key outside of the app in case they uninstalled the app or needed to install the app on another device and did not have access to mSecure 5 on their initial device to view the QR code with.
Thankfully, we have been slowly adding other means to achieve this goal in the form of storing the encrypted account key files. However, until we can make it as easy as possible for a customer to be able to receive and view their encrypted account key, we will continue to provide your encrypted account key via email in the future. Our hope is to make the encrypted account key email be an optional setting in the near future though and eventually completely remove it or make it an obscured option.
When not using our mSecure Cloud syncing option, we store account information such as type of account (free, trial, paid, other), license payment date, and sync settings (what sync option you are using and settings info for each).
I'm happy to respond to any length of email. I hope I covered your questions here decently. Please let me know if you still have questions here though.
Johan
I would like to know how the encryption for the account key is done? I just upgraded to mSecure 5 and realised I cannot find the details that I would like as I was really surprised that you are sending the account key over email - I did not do my homework so now I end up worried.
I understand that the key is encrypted (good) and you are using TLS for email communication (that is fine but really doesn't matter as you cannot guarantee that holds all the way to me - and it probably doesn't...). So, I remember reading about mSecure 3 and earlier that you were using PBKDF with something like 5000 rounds. Can you please provide details on how the account key is encrypted and exactly how it is handled. I have taken the liberty of listing the process as I understand it below along with questionable area (sorry for the capital letters, screaming not intended):
* On device number 1 I create a database, an msecure account and the application creates another long password, the account key (which is what is used to encrypt the database).
* The account key is used to encrypt a known text string and the encrypted string is stored in the database (just like any other password)
* The account key is encrypted using the password. (HOW?)
* The encrypted key is stored in the database.
* On iOS or MacOS the encrypted key is (if possible) stored on the user's iCloud drive. (IS SOMETHING SIMILAR DONE ON ANDROID AND WINDOWS? HOW?)
* The encrypted account key is emailed to the user's email address (HOW DOES THIS HAPPEN - IN DETAIL? For example, where is the message composed, how is data transferred to this location, which SMTP servers are used to send?)
* When setting up a new device, the encrypted account key has to be provided, normally by reading the QR code from the email/pdf or in the case of iOS/MacOS from the iCloud drive.
* The user's database is downloaded to the new device
* The user's account password is used to decrypt the account key from the QR code and the account key decrypts the known text string from the database. If it checks out, the new device has been set up and can now be used.
The weakness that I see here is that the encrypted account key is sent over email, which by definition is not very well protected end to end unless you use something like gpg/pgp so anyone with access to email servers or traffic between mail servers (which is not always encrypted) could get it. The account key is protected by my password (somehow). The account key is also what encrypts the database. That means that in practice I don't need the QR code as the account key is also in the database and assuming that the encryption algorithm is known (which it normally should be)I could write a simple program to decrypt the account key if I have somehow obtained the password, bypassing the device verification step. Or I could use the obtained password to decrypt the account key from the QR code.
The QR code is like an SSH private key. Normally you keep it secure and as an added protection you should have a very good password protecting it. You don't usually send it around using email, at least not if you are using high-security applications, even if it has a password on it.
As far as I can see, the known text string encrypted with the account key is more or less used like the sync password of previous versions except that one was also used to encrypt the sync copy key.
In summary, the QR code account key via email seems redundant. If I have access to the database and the account password all the data is there. Why do you need to spread out my account key to the world, using email, even if it's encryoted? I saw a mention that the choice was made to make it easier to use - to be honest I think that is a crappy reason. Unless I have not understood the system correctly this lowers the security and makes me want to move to another password manager and change every one of my 400+ passwords immediately... I am using a very good password, but still!
Also, what information are you storing if I am not using the msecure cloud? Obviously license information, but it seems that a device has to know where a cloud-synced database is when logging in to a new device. Is that stored in the QR code or in my account?
Sorry for the length of this email and thank you in advance. I hope you can quench my worries so I can continue to use mSecure, which I like quite a lot.