I am building a multi-tier application that will have multiple smaller apps apart from the main app to achieve certain goals.
Example:
I have a login class on my main app, asking for username and password. This class then does all the work, and then returns the login, with credentials, if any, or failed login state.
I want to re-use this code in my smaller client side app. Its precisely the same code, and outcome as in the main app. Therefore I want to re-use it, multiple times if necessary.
First Concern: If I use .net remoting, what security is applied? Would I have to encrypt my username and password initially, then send it through the remoting framework, and on the other side, decrypt it. And then back to the client again? I am worried about something sniffing out my username and password, and even if encrypted, can some clever hacker not just call my remote DLL with the encrypted "sniffed" credentials, as my remote DLL is expecting the encrypted format?
I am essentially trying to not make any DB connections from my smaller client app. Am I better off just putting the code in a local DLL (to the client app) and update the client app when my main DLL changes. If so, what security does MS SQL provide me for transmitting a SQL query containing the username and password to my remote SQL server?
I would appreciate any and all ideas regarding best practices and industry standards. I have always developed for an application server or desktop, so I never had to consider the security issues when sending data remotely.
Thanks in advance
I have since determined that remote access to a DB is just plain too slow to be usable. I am restucturing my solution to include a tcp middle teir, that sits next to the local db. This way I can have my business lgoic in the middle teir, and send appropriate updates to my conencted client.
Related
I am building a ASP.NET Core application. The client has an old ASP.NET application that exposes an API for authentication. It asks for a username and a MD5 hashed password (don't ask me why it works this way). Unfortunately, I do not get back any type of authorization token in the response. All it returns is some info about the user and a success or failure flag. My app needs to authenticate any request. My app will be pretty small and will only have a few API endpoints. Basically it involves opening a form, filling it out, and then uploading it to a folder on the server. That's it.
I need to be able to create some type of session so that users don't have to keep typing their username and password over and over again. They may open several of these forms on the same day. I also need some way to reauthenticate with the legacy API on each request.
I know that the right solution here would be to create some type of SSO login system that both the legacy app and my app would use. But unfortunately we're working under a tight deadline and won't have time to implement and test it. We may work on it for Phase 2 of the project later on.
One option I thought about was caching the MD5 hashed password in the encrypted ASP.NET Core Identity cookie. That way, on each request, I can retrieve the cached password from the session cookie and reauthenticate with the legacy API. I've read many posts on here about how it's always a bad idea to store the password in a cookie even if it is encrypted.
Another option is to cache the password using ASP.NET Core Session State or something similar so that the password at least never leaves the server. The problem with this though is that if the app has to be restarted, I believe this cache would get deleted and cause the user to have to login again.
Another option I thought of: Maybe I don't need to reauthenticate with the legacy API every time and therefore don't need to cache any passwords in the first place? The client specified that my app should automatically log out the user if there is no activity for 10 minutes. So maybe my app only goes to the legacy API once at the beginning and after that maintains its own session separate from the legacy app? This doesn't seem like a good solution either though as it means a user could be authorized for my app while not being authorized for the legacy app (if their password changed or account got deleted for example).
Is there a solution I'm not thinking of here?
Going to answer my own question. I ended up talking to the client about this issue and they seem to not be too concerned about it even after letting them know the risks of caching a password using one of the above methods or a similar method. I let them know this is a bad practice and should use access tokens instead. After a certain point, if they don't care then there isn't much I can do. They did seem to be open to changing things later though but like I said, we're on a tight deadline for the 1st phase of this project.
For anyone else facing this issue, the important thing is to talk to the stakeholders of your app to make sure they understand what the risks are.
I'm working on a Windows Phone 7 application, and to go with it I will need a web service to send out live tile push notifications. I will save the clients URI channel in a database and every hour or so I will send out the correct live tile to all the subscribed clients. I will not be sending out any sensitive data to the clients, nor do the clients send any data to the service save for their channel URI, and I've made sure to protect the database against any sql-injections.
The exposed methods are for registering and unregistering a client, as well as sending the correct live tile to a client that requests it.
Given this information, does anyone have any recommendations on how I should secure the service, or is security even needed to begin with in this case?
Thanks!
EDIT:
Thanks for the answers! My peers decided to not use any security at all though, other than purging faulty requests from the database, since the scope of the application is quite limited and no sensitive data is being transmitted. Let's hope it won't bite us in our behinds later on, eh!
Unfortunately the best solution to this problem (at the moment) is to generate a hash in your app and use that to verify the data is really coming from your app. Obviously you'll need to obfuscate tyour code if doing this.
This is the best you can do without any authentication against the backend.
If you can, have the users register and authenticate with the backend and then tie this authentication token to the ANID of the device and do everything over SSL.
Unfortunately, currenlty, security of services and prevention of spoffed requests is quite tricky with WP7 without requiring a login to the backend.
Make sure you secure your channel to your backend service with SSL. This way the data you send to the server such as a the ChannelUri will be secure.
Building a hash into your application isnt security. People could get your XAP and decompile it to get the hash.
IMHO you are better to ensure your ChannelUri (unique to your app and not "stored" in your XAP anywhere) is secured when you send it.
On the backend just make sure you purge records that fail when you try and send it a tile notification. This will get rid of any records entered by non-phone parties.
Bottom line is that you need a login infrastructure with your backend to properly ensure only valid users are using your service.
I am starting a service for students at my school which requires them giving me their user account information for our school's web system so that I can automate some annoying tasks for them. I will be logging them in using CURL but I am having trouble figuring out how to store their passwords in a secure method. With most web services, passwords are encrypted then stored and when logging in, we only compare the encrypted passwords. This is much different though. Since I will be sending their passwords via HTTP requests, it's required I am able to decrypt their passwords back into original text. How would you recommend I go about storing and retrieving them?
That might not be the answer you are looking at, but if you are going to store user's credentials for a third party service, there is no way to secure the storage with software only. As you mentioned it yourself, your app needs to be able to retrieve from that store the original credentials, in order to impersonate the user. And if your app can do it, so can any other code running on that box.
Thus, the only real solution is to ensure that only your software is running on the box. That assumes physical security as well, limited access to the machine, full audit and lowering the attack surface as much as possible, by turning off all unnecessary services.
On a separate note, if the school services support access delegation (through OAuth for example), you should consider going that route, and get out of the credentials storing business.
I'm currently thinking how I could protect my REST API which is used only by my mobile application from being used by other applications?
Could a API-Key be a good solution, because just me know the secret API key.
Is there a better solution?
Leon, you keep mentioning "someone else using my API with another application". So, you want to tie your API to be used only by one application? So, you don't want to give access rights to a user, you want to give them instead to an instance of your application running on the user's mobile device.
In essence: You don't trust the user!
Well, in that case you need to make sure your application is closed source, need to code your credentials into your application in such a way that nobody can retrieve them or store the credentials for it in a specially encrypted manner on the device, the decryption key for it being readable only by your application. In a way, you need to implement a form of DRM to prevent people from doing stuff with data on their mobile device. And you need to hope that nobody can reverse engineer it.
If your app becomes popular / interesting enough, count on the fact that people who are very, very good at this sort of thing will look at your application and will break your encryption before you know it. Maybe, if you put the same amount of effort into it as Skype has, maybe then you can ward them off for a while.
But ask yourself: Why bother? Why don't I trust my users? Is it really worth it to jump through hoops like this to prevent some other application from using my API?
Just lead your user through a registration process in which each app instance gets a unique key from the server (or a unique HTTP auth password) and stores that somewhere on the user's mobile device. Then, to access the interesting features in the API, require the presence of this key/password. But don't go through extreme length to obfuscate or encrypt the key when you store it locally, it's not worth it. If you every detect misuse later, you can always revoke the access rights for a particular account on the server anyway.
Use HTTP Authentication. REST is all about using the facilities available in HTTP, so the native HTTP auth should be used. With basic authentication you’ll have to use HTTPS though. If you cannot do that use HTTP digest auth or NTLM.
All of them have different strengths and weaknesses, and not every one of them might be supported by your HTTP server and client library.
I have REST services that I was planning on protecting with Windows Integrated Authentication (NTLM), as it should only be accessible to those internal to the company, and it will end up being on a website that is accessible by the public.
But, then I thought about mobile applications and I realized that Android, for example, won't be able to pass the credentials needed, so now I am stuck on how to protect it.
This is written in WCF 4.0, and my thought was to get the credentials, then determine who the user is and then check if they can use the GET request and see the data.
I don't want to force the user to pass passwords, as this will then be in the IIS log, and so is a security hole.
My present concern is for the GET request, as POST will be handled by the same method I expect.
One solution, which I don't think is a good option, would be to have them log into Sharepoint, then accept only forwarded reqests from Sharepoint.
Another approach would be to put my SSO solution in front of these services, which would then force people to log in if they don't have credentials, so the authentication would be done by SSO, and since the web service directory could be a subdirectory of the main SSO page, then I could decrypt the cookie and get the username that way, but, that would be annoying for the mobile users, which would include the senior management.
So, what is a way to secure a REST service so that it is known whom is making the request so that authorization decisions can be made, and will work for iphones, android and blackberry smartphones.
I have the same problem so let me give you the details and would also appreciate feedback. Since you are using an internal system you have one extra option that I have listed.
My first option isn't perfect, yes it could be hacked but still - better than nothing. With each request you pass the device's unique identifier along with a hash. You generate the hash using a salt embedded in the application along with the id. On the server you match the incoming hash with one you generate at the server, with the passed unique identifier. If someone "roots" their device, and is smart enough they could find the salt - you can obscure it further but ultimately it could be stolen. Also, I keep all requests on SSL to just help hide the process. My "enhancement" to this process is to pass back new salts after each request. New devices get 1 chance to obtain the next salt or get locked out ... not sure about that step yet.
Now another approach, is to have the user enter a "salt" or username and password only an internal user would know - the device obtains a token and then passes it (on SSL) with each request. Nobody outside your company could obtain that so this is probably best. I can't use this since my app is in the app store.
Hope that helps! Let us all know if you ever found a good solution.
My current solution, in order to protect data in the system, is to force people to first log in to the application that the REST services support (our learning management system), as I have written an SSO solution that will write out a cookie with encrypted data.
Then, the REST service will look for that cookie, which disappears when you close the browser, and I don't care if the cookie is expired, I just need the username from it, then I can look in a config file to see if that user is allowed to use that REST service.
This isn't ideal, and what I want to do is redirect through the SSO code, and have it then send the person back to the REST service, but that is not as simple as I hoped.
My SSO code has lots of redirects, and will redirect someone to a spot they pick in the learning management system, I just need to get it to work with the other application.