Correct place to store things securely

codenutzcodenutz GBMember

I'm doing some work with azure mobile services which requires me to store both an application key, and also cache user authentication information locally (not passwords, just a token).

Is there a standard approach to storing / caching something like this with Xamarin Forms?

Posts

  • AdamPAdamP AUUniversity ✭✭✭✭✭

    I use https://www.nuget.org/packages/Xam.Plugins.Settings/ for the caching user authentication token.

    For storing the application key, I hard code it. Unfortunately there is no .config type file for Xamarin projects, unless I have missed something. I mean you could store it in a file and read it back but doesn't make much of a difference.

  • TektonTekton USMember ✭✭✭

    I'm just now about to test out the Akavache SecureBlobCache, here. Not really seeing much info on that, but I'm sure it might be where/how I'm looking.

    @AdamP I've been using the Settings package, for a lot of stuff. However, even if I were to encrypt stuff like authentication tokens, before I put it into a plain text file, I think if I had seen about the Akavache SecureBlobCache stuff before, I would have probably chosen that. That is, unless it's somehow attached to some license that for a shoestring budget becomes an immediate roadblock. :expressionless:

    @Xamarin I'd use the secured SQLite implementation Xamarin offers, but something like that, even if it doesn't exist open source or free of charge yet, really feels like something that should be more the norm, rather than the exception. That is, forensically speaking, mobile devices and whatnot are so insecure, for the most part that I've seen, especially with how much media coverage is given to privacy breaches--it baffles the mind why we have to donate organs, or a year of our life, just to be able to get access to something like a secured SQLite db, on Xamarin Forms. :weary:

  • AdamPAdamP AUUniversity ✭✭✭✭✭

    @Tekton - with securely storing an authentication token, I am of the opinion it doesn't even matter that much. The point of tokens is that it gives the client something to use to connect to the API that can be revoked and also has an expiry.

    Because the client needs to use the token, it will have to be decrypted somewhere, hence the decryption key is on the mobile device as well. Encrypting the token doesn't make it secure, it would only delay an attacker.

    That is why tokens are normally short lived and have limited permissions as compared to what a username and password can manage. E.g. they can't generate more tokens without the username and password.

    Basically with mobile apps, don't store anything too valuable on the device itself at all. As you stated mobiles are insecure and they certainly are, we just need to treat them as such. If someone has access to the users mobile device to read information off the filesystem, it would be safe to assume they can get whatever else they want while they are at it.

  • TektonTekton USMember ✭✭✭

    @AdamP For auth tokens, it's not quite as serious to me, although it seems like a good idea, if feasible. Mainly what I'm thinking about is stuff like if I wanted to store someone's private conversation, in the DB, or something along those lines. Akavache sounds interesting for that and I'll definitely be looking at XLabs ISecureStorage. @SKall, thank you. I should probably look around more, sometimes, before I open my mouth. Although, last time I looked at this stuff, apparently I didn't dig deep enough. :)

  • AdamPAdamP AUUniversity ✭✭✭✭✭

    @Tekton - Just to clarify my position. Some security is better than nothing it may prevent a few leaks, I just like to point out that securely storing on the mobile device shouldn't give the illusion that anything is secure. Once someone breaks through the OS to get access to the user account on the mobile device, anything is up for grabs, encrypted or not because the encryption keys are going to be right there with the mobile app or granted to the app running with the user privileges.

    But you will notice that both Xamarin Settings and Secure Storage store within some form of Isolated Storage that wouldn't be accessible to other accounts / background tasks running on the same mobile.

  • TektonTekton USMember ✭✭✭
    edited May 2015

    @AdamP I think that's good to point out too. On Android, for example, if I wanted to, I could sit and watch everything in memory or just about anything else I wanted to. All that would be needed are super privileges and a kernel module compiled for the specific device, to do something like that. And there's not much going on (beyond illusion), as far as I know, when it comes to having that part of the system more secure. I know that there are certain things, in the more recent versions of Android, the kernel does to make it more difficult to do stuff like that and know what's going on, but like you said, these are all just layers/barriers.

    Then, there's always side channels, like devices leaking RF. Which I think that if people truly were worried about that, all our devices would be required to have more than just FCC spec shielding, it'd probably be more like military spec. Side channels like that one have been around for many decades, albeit unknown until more recent years. The good thing is that the more sophisticated attacks do take a more devious and well-prepared actor, than what people like to call a script kiddie. In such a case, if you're worrying about that, you're likely a major enterprise or an actor of the state. Although, that's just an assumption.

    Personally, I've seen a lot of lax security practices. And where they exist, when it comes to code, the code is likely to be fairly lax too. I think for hobbyist stuff, that's completely expected. When it comes to commercial endeavors, I think people are much more expectant of having better security practices. Plus, there's always the fear of litigation, for stuff like negligence. (Although I'm not sure how much weight I'd give to just being concerned about fancy pants Mc Scrooge.)

    Just for clarification, I'm not pretending to know any more than I'm saying here. One thing that drives me, when it comes to learning more about this stuff, is that it's just pretty interesting. Plus, it's one of those topics where even if you think you're smart, the topic teaches you over and over that you know nothing. :dizzy:

  • codenutzcodenutz GBMember

    Thanks guys - really great discussion and totally answered my question!

    @SKall - I had no idea about the secure storage implementation in Xamarin Forms Labs - thats awesome!

  • SKallSKall USMember ✭✭✭✭

    It's not a matter of if it can be broken/decrypted but when it will be. That's why you would store tokens and other data that will expire. For encrypting data on the device you'd probably want something like SQLCipher.

  • HrafnLoftssonHrafnLoftsson ISMember ✭✭

    @SKall - Is it correct that the data in the Droid storage (XLabs.Platform.Droid/Services/KeyVaultStorage.cs) is "wiped" when a new version of the app is installed? This seems to be the case in my app, whereas the same is not true for data stored in the iOS secure storage.

  • adamkempadamkemp USInsider, Developer Group Leader mod

    Check your preferences for this setting:

    image

  • HrafnLoftssonHrafnLoftsson ISMember ✭✭

    @adamkemp Thanks - this fixed the issue.

  • HrafnLoftssonHrafnLoftsson ISMember ✭✭

    Currently, we are using XLabs.Platform.*.Services/SecureStorage (iOS, Win) and KeyVaultStorage (Droid) for storing a connection GUID on the device. Any thoughts on using Xamarin.Auth instead?

  • faceoffers28faceoffers28 USUniversity ✭✭✭

    @codenutz What did you end up doing? I'm working with an MVC 5 API that requires me to authenticate and get a token to use the API. I then pass that token along with user and pass to get an access token. The access token is then used to make subsequent calls to the API. Currently, I'm able to authenticate and get the API token. I'm then able to use that token to call the account endpoint and that's where the app currently fails. I assume it has something to do with the resulting access token that is being returned. I need to do something with that. I'm currently investigating some of the ideas discussed here along with these ideas.

    http://developer.xamarin.com/guides/cross-platform/xamarin-forms/working-with/app-lifecycle/#Properties_Dictionary

    http://www.codeproject.com/Articles/624624/Using-a-Cookie-Aware-WebClient-to-Persist-Authenti

    Security of the token is not a big issue as this is not a banking app. :) Also, I would like to reuse or keep using the token as long as its not expired etc...

    Any help or guidance is much appreciated.

    Thanks in advance.

  • @Dumber_Texan2 it was a little while ago now, but I was using Azure Mobile Services and passing the token worked just fine as far as I can remember.

    For storing the token I used Xam.Plugins.Settings mentioned by @AdamP earlier in this thread.

  • sameerksameerk USMember ✭✭

    Published this plugin for securely storing strings. Please check it out.
    http://www.nuget.org/packages/sameerIOTApps.Plugin.SecureStorage/

  • Vikas.0825Vikas.0825 USMember ✭✭

    @sameerK,
    How to use the nuget. kindly share any sample code which will work for ios/android

  • sameerksameerk USMember ✭✭

    Thanks for downloading Secure Storage. The sample can be found at:
    https://github.com/sameerkapps/SecureStorage

  • DeveshMishraDeveshMishra USMember ✭✭

    @sameerk said:
    Thanks for downloading Secure Storage. The sample can be found at:
    https://github.com/sameerkapps/SecureStorage

    Hi Sameer,
    How this Secure Storage plugin is different from Application.properties of Xamarin Forms ?

  • sameerksameerk USMember ✭✭

    Application.properties stores the data in unencrypted form in the IsolatedStorage file. Secure Storage encrypts the data as per the platform and stores it in the platform specific place (KeyChain in iOS, encrypted file in Android and data protection vault on Windows.). Secure Storage can be used to store sensitive data such as password, session token etc.

  • RhiRhi USMember ✭✭
    edited May 2017

    @sameerk For Android and Windows platforms, your API requires setting up of a password which in turn encrypts the file on disk. How to you suggest storing this password securely ?

  • sameerksameerk USMember ✭✭

    Sorry about the delayed reply. The storage is useful for encrypting and storing sensitive information obtained during the runtime. Password for the store is defined at the compile time. There are various ways to protect it. I use professional edition of Dotfuscator that encrypts strings in the app (including the password for the store.). So the password for the store cannot be retrieved even if someone reverse engineers the App. Hope this helps.

  • batmacibatmaci DEMember ✭✭✭✭✭

    @sameerk said:
    Sorry about the delayed reply. The storage is useful for encrypting and storing sensitive information obtained during the runtime. Password for the store is defined at the compile time. There are various ways to protect it. I use professional edition of Dotfuscator that encrypts strings in the app (including the password for the store.). So the password for the store cannot be retrieved even if someone reverse engineers the App. Hope this helps.

    password for the store? what does that mean? do you mean certificate password? you cant even restore this password when you forget it. please explain what you exactly mean by that

  • sameerksameerk USMember ✭✭

    Hi @batmaci
    That was applicable to Ver 1.2.2 and lower. Ver 2.0 and above have a built-in password for the store for Android platform. A developer can also have a custom password instead of the built-in password.

    In either case, password refers to the password that is supplied by the developer at the compile time to the android storage. (It is somewhat equivalent to a key for using an API.). It is not the user's password. So the case of a user forgetting the password is not applicable.

    You can find the technical details in my blog posts.
    1.X version: https://sameer.blog/2016/02/01/secure-storage-plugin-for-xamarin/
    2.X version: https://sameer.blog/2018/01/19/whats-new-in-secure-storage-2-0/

  • BruceHamiltonBruceHamilton USMember ✭✭

    It seems that rather than dealing with secure storage or encryption, simply delete the source data file upon ViewDidDisappear (for iOS anyway).

    For an app with no offline scenario, downloading data (that would otherwise need to be secured) from the cloud for each life of the app seems not to be a bad experience.

    Is this reasonable?

  • adamkempadamkemp USInsider, Developer Group Leader mod

    ViewDidDisappear won't be called if the user homes out and then the app leaves memory, and even if you tried to handle the app going into the background there's still the chance that the app crashes. You just couldn't guarantee you deleted that file. I would argue that if you wanted to delete it on exit anyway then you probably just shouldn't write it to disk at all.

  • BushbertBushbert Member ✭✭✭
    edited July 2018

    If only there were an OnAppCrashing event :-) I agree though, no need to write to disk.

  • UnreachableCodeUnreachableCode USMember ✭✭✭

    @HrafnLoftsson said:
    Currently, we are using XLabs.Platform.*.Services/SecureStorage (iOS, Win) and KeyVaultStorage (Droid) for storing a connection GUID on the device. Any thoughts on using Xamarin.Auth instead?

    I too would like to know this. Xamarin Auth seems highly regarded and now supports Xamarin Forms. Has anyone any experiences in using this package?

  • batmacibatmaci DEMember ✭✭✭✭✭

    @CharlieFinlayson.3926 said:

    @HrafnLoftsson said:
    Currently, we are using XLabs.Platform.*.Services/SecureStorage (iOS, Win) and KeyVaultStorage (Droid) for storing a connection GUID on the device. Any thoughts on using Xamarin.Auth instead?

    I too would like to know this. Xamarin Auth seems highly regarded and now supports Xamarin Forms. Has anyone any experiences in using this package?

    not needed. just use akavache even you can use for other purposes to store any key value.

  • JohnHardmanJohnHardman GBUniversity mod

    @CharlieFinlayson.3926 said:

    @HrafnLoftsson said:
    Currently, we are using XLabs.Platform.*.Services/SecureStorage (iOS, Win) and KeyVaultStorage (Droid) for storing a connection GUID on the device. Any thoughts on using Xamarin.Auth instead?

    I too would like to know this. Xamarin Auth seems highly regarded and now supports Xamarin Forms. Has anyone any experiences in using this package?

    For Secure Storage, I'd look at Xamarin.Essentials to see if that meets the particular requirements.

    I implemented stuff using Xamarin.Auth some time back. One of my multiple concerns about it was the key-person risk involved, as one person was doing the vast majority of the work on it. At the time, it was also buggy enough that I removed all trace of it from my PCLs, and instead only used Xamarin.Auth from the platform-specific projects. That allowed me to use different versions of Xamarin.Auth on Android and iOS compared to UWP, in order to avoid bugs on particular platforms in particular versions. The documentation was also poor, and lots of out-of-date samples etc were still kicking around confusing people. Given how much time has passed, I would hope that things have improved, but I would have more confidence if Xamarin.Auth were maintained/enhanced/documented by a team in the way that Xamarin.Essentials now is. Perhaps it now is, but I haven't checked recently - you might want to if you are considering using it.

  • UnreachableCodeUnreachableCode USMember ✭✭✭

    Thank you both for your replies. I am intrigued by Essentials at some point as it comes straight from the Xamarin team. It's in pre-release right now but I take it it must be pretty stable?

  • JohnHardmanJohnHardman GBUniversity mod

    @CharlieFinlayson.3926 said:
    Thank you both for your replies. I am intrigued by Essentials at some point as it comes straight from the Xamarin team. It's in pre-release right now but I take it it must be pretty stable?

    As it's in pre-release, you'd want to test whatever bit you want to use (TBH - you'd want to even if it wasn't in pre-release). Some bits still needed some work the last time I investigated, but for the basic stuff, even in pre-release, I'd rather use Xamarin.Essentials (maintained by a team) than use the multiple plugins that it effectively replaces (some of which also suffered from key-person risk and lack of support IMHO).

Sign In or Register to comment.