Hi Ai! I was just going to message you in one of your threads to let you know 6.1 arrived =)  Thank you for the feedback so far!

One thing to mention right off the bat, I just saw the post where three users, including you, talked about the issue of seeing a different user's account when signing into the website. I responded in that thread and am now in talks with our site admin to get the issue fixed. I believe it's a site cacheing issue, probably something to do with WordPress, and it's something we've experienced before when 6.0 was released. That issue will be fixed as soon as possible.

In response to your points of feedback...

1. We always try to fall on the side of being least intrusive as possible with things like the "What's New" view. It's a tricky one, because some people like to have that information shown multiple times, and then other people don't even want it shown once =)  I will talk this over with our developer to see what he thinks about changing the way it works. Maybe an in-between way to manage it would be to offer a "Don't show this again" toggle on the last screen. It could be on or off by default, but if the user definitely wanted to see it again, at least they would have the option.
2. I found out the redirect I created for the roadmap link was not right, but I was able to fix it. If you check now, you should see the roadmap page. Thank you for bringing that to my attention.
3. For the password history feature, for the first iteration, all of the passwords accumulate in the list and there is no way to clean them out. However, this type of feedback is exactly what we need to improve the feature in future releases. We typically feel it best to implement in a broader fashion, then sort of trim the fat with user feedback. First, you should be able to copy the passwords in the list. I think that might actually be a bug, but I'm not sure at this time. Regardless, I'm writing it up to be fixed/implemented in 6.1.1, because being able to copy the passwords in the history to the clipboard seems like obvious functionality that should be present. Now for the hard one =)  We deliberated about how many passwords to show in the list and decided for the first release to show all of them at all times. The problem is, for some they might want all of them, but for others, they may only want 5 or 10 or ???. I think you're idea to provide manual housekeeping on the entries could work. Maybe we simply show up to 5 or 10 by default, then provide a "Show All" link at the bottom of the password history UI. That way, only a few are displayed by default but you can see all of them if you need more. Do either of those sound good? 

Hi Ai,

I love talking to customers when there's good, productive discussions like we have, so I'm happy to hear this type of feedback! It's this kind of talk that makes mSecure better over time, so this is good stuff. Of course, there are times when I get a little busy over here so I can't be as responsive as usual, but I do really appreciate the feedback you have given before and after the V6 release.

For the roadmap link, I'm pretty sure the problem is a caching issue in Safari. Yesterday and today I've been wrestling with the links we have in the app, but I'm almost certain I have everything working now. That sounds silly I'm sure, but it's a bit more complicated then it might seem. What we do is create redirects for all of the links in the app. That way, when the app is in development, the programmer can simply enter any redirect link we decide on. Then on the website side, we can create the page at any time later and "simply" redirect to that page we create. I say "simply" because the redirect is the problem I've been running into. Somehow, an earlier version of the roadmap page made its way into the AWS Cloudfront cache, and it's been a nightmare to release it. Then after it's released, it's possible that everyone's browser still has the old page cached, so it's no good. I would try again to tap the link really quick in the app to see if it loads the correct page. If that doesn't work, then I would try to delete Safari's cache and try again. Hopefully, that will fix the problem but do let me know if it doesn't.

For the password history feature, we have already decided to add the ability to copy each password from the list. That was just weird oversight on our part when we implemented the feature. Every password in the list should have been copiable from the get go. It wasn't a bug, we just didn't implement it that way =)  I'm pretty sure the developer has already added it to the newest development build.

For the other things we've been talking about, however, we've decided to wait for other customer feedback. Since the passwords are all in descending order from newest to oldest, you should always be seeing the most recent passwords at the top of the list. Now, that may be another problem for you, so please do let me know if it is, but how we see the feature working is that a user might need to find out if they've used a certain password in the past, and they can look to see if they have or not. They could use older passwords for verifications as well like for Google accounts. I'm sure there will be other use cases, but I think those two are the common ones. 

Maybe it would be a good idea to simply hear what your workflow is for your password history, then we can continue the discussion afterwards.

Thank you for the extra information on this Ai. I'm hoping I'll be able to get something implemented for the password history window. I don't think it should be difficult to simply add a checkbox/toggle at the bottom of the password history dialog that says "Show last 5 passwords" and if that's turned on, it will only show the last 5 passwords in newest to oldest order. That way, for users in your situation, you can at least have a way to only show a few passwords. This setting should persist across records, so once it's turned on in any password history dialog, it will remain on until turned off in any dialog. We could certainly make this an app Setting, but I don't think it warrants that much detail. We can make it an app-wide preferences but also more transient in nature so that's more visible to the user and easier to turn off and on. I'm hoping that will suffice most use-cases for the near future.

@Jon I actually had a long discussion with the support rep you are in communication with regarding the QR code. I'm hopeful he'll be better prepared to answer questions of this nature better in the future.

First, the 2FA feature is in addition to the QR code. And you are correct that the QR code is, at least in part, a form of two-factor authentication. However, it's actually much, much more than that, since it's a key component in the overall security of the data stored in mSecure.

I'll try to explain sort of quickly, since it may click for you, but then if you have questions, go ahead and ask and I'll just continue to add more information as we go. By the end, it should all be clear as to what the QR code is and how it works.

In mSecure, your data is always encrypted with what is known as an Account Key. That Account Key is programmatically generated by mSecure, so it is incredibly strong. It's very long and totally random, so for all intents and purposes, it's uncrackable. It would take billions of years for it to be cracked by even the most powerful of computer systems. I say "for all intents and purposes" because it's always possible for some guess to happen earlier in the process of a brute force attack. However, for that possibility to come about even within 10 years, the hacker would have to be lucky beyond imagination. On a very high level, this is the best you can do with encryption as you are simply making it as impossible as you can for someone to be able to guess at the password.

Now for the QR code. That code is simply your Account Key encrypted with your mSecure account password. At first that may seem like a bad thing, but it's not. The QR code is never stored in your account online, so the data in the cloud, if you use cloud syncing, is safe since the key to unlock the data is not stored in the system. The key is only ever sent in encrypted form via email, so the only way a hacker could get access to that key is if they hack your email account. Then even if they were able to do that, they would have to brute force attack the encryption protected with your account password. If somehow they were able to do that, then they would have to steal the data from the mSecure Cloud (or iCloud Drive or Dropbox depending on your sync method), find the data for the account and decrypt it. Every one of those three steps is heavily protected, so it's practically not possible. We still advise using a strong password for your account so that your QR code has better encryption strength, but it's highly unlikely anyone would ever be able to hack your email to get your mSecure QR code.

It's important to reiterate here that without the Account Key, it is not possible to read the data stored in mSecure, either data stored in the cloud or locally. So again, the Account Key is not stored in the mSecure Cloud, and it's only ever transmitted in an encrypted form. The account owner is the only one that will ever have the QR code, and that's what makes it, in part, a form of 2FA.

When you sign in to your account, you enter your account password. mSecure then gets access to the QR code, or Encrypted Account Key (EAK), but it's not always necessary to supply it (more on that in a moment), it then has what's needed to decrypt the EAK. If the password is able to decrypt the EAK, then not only does it know the owner of the account is the one signing in (2FA), but it now has what's needed to encrypt and decrypt the data stored in mSecure both locally and data downloaded from the mSecure Cloud.

What you might realize is, if your data is stored in the cloud, then the most important thing is that the Account Key is not present, so the data is safe. However, for the data stored locally, the account password is not present. So for the data stored in any cloud service, it's really the strength of the Account Key that protects the data. For data stored locally, since the EAK (encrypted account key) is stored locally on the device, it's the account password that protects the data. And this is on purpose, since it's far less likely that a hacker will steal your devices, break into them, then brute force attack the EAK. Even if they did, you would know your device was stolen, and you should then be changing all your passwords, first the password for your mSecure account and then the passwords for your most sensitive accounts. In that case, it no longer matters that they may succeed in brute force attacking your EAK, because it's no longer the correct key to get into your account.

Lastly, for now, the EAK is stored locally on your device. On Apple devices, it's stored in the user's iCloud Drive account. On Android devices, it's stored in the mSecure Backup folder. For Windows, it's stored in the Web Credentials object. For Windows, the Web Credentials are device-wide in scope, so all accounts have access to it. However, since the EAK is encrypted with your account password, even if someone has access to it in a different profile, they still need to know your account password to get into your account. And if you have 2FA set up, they would also have to pass that authentication as well.

No problem at all Jon! It's good to hear my explanation was helpful, because sometimes it's hard to convey everything going on with the security in a way that makes sense. I'm always trying but many times failing to make it clear!

It's possible we could change how the Windows versions stores the QR Code/EAK. I wasn't aware until recently that it actually is a device-wide object on PCs, so it was surprising to me as well. However, for the local functionality, we're ultimately relying on the strength of the user's account password. I couldn't think of a case in which a user would not allow someone access to their Windows Profile and at the same time give them their mSecure account password. That seems like an unlikely scenario. On top of that, if someone doesn't want a person to have access to their information in mSecure, then they should never make their password known. I could be wrong here, but it's very few users that would give out their mSecure password and then rely on the QR code not being device-wide to keep a user in a different profile on the same computer out of their mSecure account.

Your thoughts on the assumptions made above are always welcome, so if there is something we've missed in our rationale, please don't hesitate to call us on it!

@Ai 6.1 should be available to everyone in the Windows store. For Apple and Android, we're able to rollout the releases gradually to try and catch any problems early on so we can fix bugs that might be found the first day or two of a release. However, Microsoft doesn't give us that functionality, so when a new release is published, it goes out to everyone right away.

If you open the Store app on your PC, click Library in the bottom left, then click "Get Updates," are you not seeing 6.1 as an available update?