I have a WPF client that uses a JWT to access an ASP.NET Core Web API. I already having the client app running quietly in the 'System Tray'[1]. I would like to have the app start on Windows startup and continue running quietly there until the user needs it, but that would require the user to login again on each startup, making 'quietly' meaningless.
To prevent this, I will need a remember me option on the login dialogue, and when checked, I will have to safely store the JWT in use until the next startup.
How should I go about this? I have seen recommendations on using the registry or Isolated Storage for persisting runtime data over just storing it out on the hard drive somewhere. Then I would have to encrypt the JWT to keep it secure, but then a very similar question arises on how to store the encryption key.
How can I securely store these two values, most preferably in separate places?
[1] Or whatever it is called these days.
Related
I've been thinking about this quite a while and it's bugging my head off, lets say we have a website a mobile app and a database.
Usually when we develop our websites we pretend to store our database credentials in a configuration file and connect the website directly to the database without using a multi-tier architecture, but when it comes to a mobile application such Android or iOS this applications can be engineer reversed meaning that there's a risk of exposing your database credentials.
So I started thinking about this multi-tier architecture and kind of thinking about how Facebook and other social network do their job, they usually make an API and use a lot of HTTP Requests.
Usually social networks APIs have a app_id and a secret_key, this secret key would be used to increase the safety of the application but I'm thinking about how could I store these keys inside my application since I would go back to the begining of my discussion, if I was to use Java I could use the Java Preference Class but that isn't safe either has I saw in this question, plus I would need to make sure my HTTP Requests are CSRF safe.
So, how could I store these keys inside my app? What's the best way to do it, since hard-codding it's out of the question.
You should always require users to log in - never store credentials or private keys in an app you'll be distributing. At the very least, don't store them unless they're specific to the user who has chosen to store them after being validated.
The basic idea is that the user should have to be authenticated in some manner, and how you do that is really too broad to cover in a SO answer. The basic structure should be:
User asks to authenticate at your service and is presented with a challenge
User responds to that challenge (by giving a password or an authentication token from a trusted identity provider).
Service has credentials to access the database, and only allows authenticated users to do so.
There are entire services out there built around providing this kind of thing, particularly for mobile apps.
You might store the users own credentials on the device, and if so it should be encrypted (but you're right, a malicious app could potentially pick them up).
Bottom line: never distribute hard coded access to a database directly.
I'm working on a web application and I'm having problem accessing the database on server side because there is no user for the DB proxy to map. In other word, I have a method which will start as soon as the application comes online and will call itself every 5 seconds to check for new messages. If it receives a specified message, it then goes to the database and finds whatever it needs. However, accessing database on server side wouldn't be possible because there is no user for the DB proxy to map. So what is a good design pattern for this type of application? Should I need an application account for these type of automation process?
Btw, I'm using Weblogic JPA 2.1 for database stuff.
Thanks in advance.
First of all, what exactly do you mean by "no user for the DB proxy to map"?
I assume, you meant that you don't have a user known by a session who connects to the database?
If yes, you usually wouldn't do that anyway and instead nearly always have a database user for your application. Then, no matter a user triggers a database call by an action or the backend triggers it by some scheduling, it will always be the same user who does it. In your Java EE application, you'd have a datasource containing this user in its configuration and all your application parts use the related entity manager when doing persistent actions or queries.
UPDATED: We are building Mobile apps on Windows, IOS & Android platform to generate OTP (one time password) for a regulated system. The system will prompt challenge phrase when user attempt to login and the displayed challenge need to be keyed into mobile App to generate the OTP. The generated OTP is then entered back into System to successfully login.
So far the requirements for mobile OTP generate app is good as we can expose a service to generate OTP with required security.
But, we have a wired requirement to support the same feature with offline capability where mobile has no internet connectivity. The only choice we know is to embed the OTP algorithm & key into app and apply suitable security mechanism. Algorithm is custom built propitiatory algorithm and without compromising security we need to achieve the offline capability. Is that a good approach to embed algorithm & key into app to enable offline capability? What is the recommended solution.
I have no idea what you mean by "Enterprise will expose API".
But, you will need something tied to the physical phone device, like the SIM module (i.e. the phone number) or an app with secure/private storage for two-factor to work.
An API exposed on the internet, without a strong link to the authentication token (phone), is not secure.
So, I guess the only answer is: Yes, you should implement the "OTP algorithm" in the app. The app must store the shared secret in a private storage that is not (easily) accessible to other apps. Then, depending on the kind of OTP, you need to provide some means of synchronization between the app and the server. For Google's Authenticator this is just establishing a common timebase because the "OTP" is not strictly one-time but changes (only) depending on the current date+time; hence the current time becomes the "challenge" the server implicitly poses for the client to return the correct response. The good thing is that you don't need access to the internet to know the current time in your app. You only need to synchronize the timebase now and then to make sure the clock in your app does not differ too much from the server's.
The server could instead also send an explicit challenge, like a sequential number. This challenge would be displayed to the user attempting to log-in, the user would have to type the number into the app and return the app's answer to the server.
Many more options are available, but the bottom line is: To provide reasonable security, the OTP must be calculated on the phone.
What's the best way to implement authentication for mobile app that will be secure and also wont annoy the user by asking to authenticate every time the app starts? In other words, for the first time after installing the mobile app, the user needs to register/login, and after that the app always works without asking to authentication.
Native mobile applications ask for credentials when using the app for the first time, but subsequently they don't require login. The app just start and try to connect to data network (wifi, 3g, etc.), if it finds the data network then it loads the latest data, else uses the data that it was able to fetch last time it could get access the data network. Also, the app is able to reconnect automatically when data network is available and fetch the latest data with out user intervention.
I tried to develop similar features using meteor mobile app (accounts-password, useraccounts:core, useraccounts:ionic), however the app quite frequently times out and asks for re-login everytime the data network is lost. Sometimes it even hangs on the login screen and the only way out is to kill the app. The behavior seems very similar to a web app, where a session id is created and has an idle timeout, or forces login when internet connection has issues.
Any tips on how to store the credentials on first login and use it subsequent; and also good way of handling data network when disconnects are frequent?
Frameworks:
1. Meteor Platform
2. Ionic with AngularJS
3. ngCordova
Code Structure:
1. Common directory, where all the meteor method calls and schema definitions (simple schema).
2. Application files are organized as per guidelines (client,server, resources).
One of the solutions I found on stackoverflow:
Send the UDID or mac address with the initial login details to your server. create a unique token for this user/UDID (or mac) combination and send it back(encrypted) to the device if username/pass is successful. on subsequent access, the device sends the encrypted token and UDID/mac (over secure connection) for re-authentication.
if you want to put paranoid people at ease about tracking UDID, you could instead use the UDID/mac to salt the encrypted token, but this wont be as secure, but should do the job still.
Appreciate your help, thank you!
I am going to be developing an application for work, and I am trying to decide whether to use Silverlight Business App or Asp.Net Web App. My manager is concerned about the performance and download time it would take if I created the entire application as a Silverlight app, with authentication. I have been playing around with some tutorials over the last week trying to get a perspective on my situation and have come up with a design question I need to ask those that are more experienced than me.
Is it possible to use a Asp.Net application and just embed a silverlight application in one of the pages that will be used inside a folder that is configured with the roles authorization? And if so, would it be possible to get user credentials from the client silverlight app without passing them through the initParams.
I understand that I can set the authentication to "useCookies", so I was thinking I would be able to get the cookie on the client and hopefully get a property verifying if the user is authenticated.
Also, would this be a risky practice? Thanks for any advice and direction.
There are a few approaches you could take. While I know you don't want to expose the credential in init params, you could generate a "ticket" (claims-based authentication) for the credential, and include the ticket (for example, a GUID) in the init params. When the Silverlight application launches, it would consume the ticket, possibly validating it via a secured web service call, and the ticket would no longer be valid so even if someone spoofed it or viewed the source, it couldn't be used.
Quite a bit depends on your architecture. For example, if you are using the roles-based authentication, and most of the business logic and/or decision making is based on web service calls, the web services can use HttpContext.Current.Identity to validate the user. Even if someone opens the Silverlight application, any service calls would fail unless they were appropriately authenticated. Otherwise, I would either go with passing a ticket so Silverlight trustst the user is valid (you can create a service that accepts the Guid and returns the role information) or have the user log in from Silverlight (you have a service facing in front of the authentication mechanism and then return a ticket and/or role information).
It gets even more interesting if you decide to use WCF RIA, check out these examples for baked-in authentication:
http://code.msdn.microsoft.com/RiaServices/Release/ProjectReleases.aspx?ReleaseId=2661
1.) It's absolutely possible to embed a Silverlight xap on an ASP.NET page.
2.) As far as credentials, using cookies could work, or you could pass in a token over initparams and validate that token via a web service to see if the user is valid
It's always a risk passing credentials around, especially when it's running on a clients computer. That said, Silverlight buys you a lot, so don't let the challenge of authentication hold you back.