Chat support available. Click the chat icon on the bottom right corner to start chatting with us right away!

mSecure Support

Knowledge Base Forums Submit a ticket

6.1 has arrived!

Mike,


Finally see that 6.1 is available on iOS! (thats not meant to be read as a snide comment, more that I'm excited for it!)


Will have a proper play with it later. But initial comments:


1) Love the 'Whats New' section, very helpful. I was wondering if it would be better to have a persistent splash screen upon opening up the app of the new features until such point the user manually dismisses / disables the splash screen? At the moment it feels like its in the depths of the settings menu and people may miss it.

2) The link to the upcoming roadmap from the 'Whats New' section is broken - page not found

3) Biggest feature I've been waiting for is the password history, wohoo! I love it. Couple of points on it though. Firstly, I can't seem to 'copy / paste' each individual passwords in the password history. Secondly, is there a way to edit the password history? e.g. to delete certain entries or to set some housekeeping on it so it removes anything after 5 different password changes to keep things tidy, or do they just permanently store the password history forever in read only mode?


Thanks!

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? 

Mike,


As always, thanks in taking the time to reply to me. I know you and the team have been mega busy with this release.


Yes, I saw the reply regarding other people accounts on the other thread, thanks for picking that up.


Points on my feedback:

1) I think the 'don't show again' toggle would be a perfect compromise. It's really just a suggestion to improve user experience for the more casual users. I don't mind digging into the settings to find it myself, but for the more casual user then maybe a splash screen with a don't show again (and also indicating they can find it in the settings) could be the way forward.

2) I'm still having a 404 error from both the link in my iOS app and also from the webpage (assume they both link to https://www.msecure.com/roadmap/)
3) the copy password history is probably  bug, as its the same for my iPhone and iPad. With regards to how I would like the password history displayed, I think for me the clean up is more important to me that how many is displayed. Maybe a configurable value in the settings to ask how many entries of passwords you want before it starts getting deleted (e.g. keep the last 10 changes) and give an option to keep all. For my own use case I would never need more than the last 10 password changes, but not sure if others have a different use case for keeping everything. A manual 'swipe to delete' on each entry would also be helpful as well if that is possible.

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.

Hi Mike,


The link to the roadmap is working again from the iOS app and from MS Edge, thanks for getting that sorted.


For the password history, my workflow for it is pretty basic, I need a history of just the last password change that I had. This is mainly when I have to do routine password resets and sometimes when the password doesn't go through correctly, I still need a record of the old password to reset it again (the current workaround is to have to copy the existing one and the new one onto notepad and ensure that the password reset is done successfully before deleting the old password and keeping the one in mSecure). It sounds like a trivial use case, but multiply that by the amount of routine username / passwords out there, the password history becomes a godsend. I would say I would only like to keep between 5-10 of the latest password changes for 'safety's sakes' which is why I asked if there was some kind of automatic housekeeping parameter that can be set or at least a manual 'swipe to delete' so I can keep it in order.

My scenario is quite specific to me, I didn't consider that other people out there would need the entire history, so thats my bad, I was being selfish :-) I would have thought a configurable setting to only keep the 'x' amount of entries or a manual swipe to delete would be the perfect compromise for those that want all of it and those that only want some of it. Hope this makes sense.

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.

@Mike, that sounds spot on to me. Thanks for taking it into consideration, look forward to seeing it sometime in the future. Thanks!

@Mike,


I wonder if you can explain QR code vs new Two factor authentication in 6.1? Does the latter replace the QR or is it addition to?


I always thought that the QR code was your version of two factor authentication. However, I have an ongoing discussion with your support team who either do not understand or are not able to help. I installed Msecure 6.0 on another Microsoft account (not mine) on one of our PCs yet was able to log into MSecure on that account with my Msecure credentials without providing a QR code. Now I am really not sure when the QR code is required!!


Jon

@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.

Thanks so much Mike for taking the time to reply so comprehensively. Much of this I did sort of understand from reading your already great description on your page on your security model but the key bit of info I was unaware of was that the QR Code/EAK is available device wide and that certainly explains what I was seeing, thank you. I must admit I am surprised the EAK is stored somewhere accessible from all user accounts. Seems odd to me. Obviously that can't be true for all web passwords! But at least I know now and, obviously, the new two factor authentication options make things tighter.

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!

@Mike, any idea when the 6.1 updates will come through the Windows MS Store?

@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?

@Mike, I've been trying the 'get updates' (sadly) every day since it was released a week ago and nothing. Not sure if it matters, but I have a PC on Win 11 and Win 10, both no updates. Wonder if the any of the other user community has got the Windows update?

Hi @Mike, Thanks again most sincerely for engaging so thoroughly with this discussion. For what it's worth I do feel you should change how the EAK is stored so it's only accessible to the specific user account. Just seems sensible to me. I would never share my MSecure password with anyone but this is still a hole in your security. You said above "the only way a hacker could get access to that key is if they hack your email account". But, it seems we need to modify that statement to read "hack your email account or have a user account on the same computer as you". Your new 2FA certainly makes things a lot better, but that can't be right really, can it??

Login or Signup to post a comment