I'm coding a desktop application for our university . Users need to signup before using this software and registration request is sent to a server written by me, too. So I'm struggling with kind of network application. ( Suppose that the request format is as simple as a HTTP request sent to an arbitrary port number )
But now I'm wondering whether it's necessary to protect registration process using CAPTCHA or not? Do I need to ensure that the signup request is not generated by a computer?
As your application is for a limited user group (your university only), I think you do not need a captcha, because the risk is very low that someone is in this group how wants to annoy you.
Also scripting for a desktop application is (a bit) more complicated than for web applications, this will decrease the risk, too. IF you are struggling with bot-registrations you could still ship the captcha as an update and only accept registrations from the updated version, don't you?
I think that would irritate the human users, who, I believe, would make all your users. Please note that on the net, only a small portion of users are bots. What about a campus? How many computers are on a campus to be worry about? Besides, all those computers are supervised by people you know, and even if a program is installed on one of them (or even all of them) to joke with you, you can call the authorities of the university. So if I were you, I would put my time on betterment of other things, instead.
No you don't need CAPTCHA. CAPTCHA was made because of the limitations imposed by a web browser while still wanting the wide availability that a website provides. Your application doesn't have either of these limitations. Your desktop application can implement whatever security methods it wants and it only needs to be distributed to a specific set of clients.
That doesn't mean you shouldn't have some security policies set up to prevent anyone on the school campus (or internet) from telneting to the port and creating an account. This can most easily be done by using PKI and distributing a unique private key and open public key with the desktop application. The server can then verify that the client has the private key before accepting registrations (plus you could encrypt any communications between the client/server). Of course anyone with access to the desktop application could get the private key, but it's at least more secure than not doing anything at all to prove they can register accounts.
Related
I am building a multiplayer site in Rails, and I need a reliable way of blocking computers from using the site. For example, someone has been banned from the site multiple times, and there should be a way to block their computer from using the site.
I would find a way to do this with IP addresses but they're not always static are they? Also I'm asking about identifying browsers so that if there was unauthorised access from a different browser or machine, then I could implement a security feature to make sure the account belonged to them. I would also need to store these locations as trusted locations in a database, hashed.
So I'm creating an iOS framework that will be a static library that developers will add to their project, when they create an account on our site I'd like to give them a unique token that they put in their app to use my static library.
For iOS dev's, think TestFlight, you sign up, get an App ID and then run [TestFlight takeOff:<#some-key#>];
I'd like to authenticate the requests that the framework makes to my REST webservice (using https).
Is there anything I can do to prevent people from "breaking into the app code" and stealing the developers api token and using it to make requests? My api endpoints will not be public information, at least for now. and I can't authenticate the user because it's a framework and that would be an awful UX.
The question is, is there anything I can do to prevent this sort of behavior? Should I even care? I will charge the developer per X requests eventually so I was hoping to authenticate this so we don't have spammers racking up a bill for the developer.
How do other iOS frameworks handle this?
Any design ideas and criticism welcome.
I'm not sure what you're trying to do is ever possible. If the text is in the client code, it can be pulled out. SSL-pinning won't really help you here either because the cert is in the client binary as well.
One way you might be able to get close is to use the developer's authentication system. Say a user logs in into the developer's auth system, then server side you generate a short-lived key for that user. Then the client code can be passed (over SSL-pinning) that short-lived key and use that to make your API calls. However, this requires the developer to actually have a secure auth system, and without SSL-pinning, they're vulnerable to a simple man-in-the-middle attack which will reveal the short-lived key.
You can try to minimize the damage by throttling API calls on your end, or trying using per-app heuristics to approximate what normal API usage would look like. Anything out of the norm will get flagged as potentially hacker based. That might be enough to flush out most of the wanna-be-hackers. The true hackers will learn of the throttling and be clever about circumventing it...
Your safest bet is to make it a server-side library instead of a client-side library. However, that's certainly not a super-sexy solution either. Not all apps have a server side component... and even if they do, once the developer's server is compromised (ie. gets spammed or hacked, etc) it's game over once again. But, in the end, the nice thing about a server-side solution is that you're at least less vulnerable to an attack and you put the responsibility of securing the system on the developer.
What's really lacking here is some form of Apple-based verification for network calls originating from Apple devices.... but that probably won't ever happen. :)
I a thinking of creating an iPhone/iOS app that would include a feature where one user could create a list of words and then save them to their account on a server. Also (and this is very important), the user could share their list with other users by giving them permission.
So my question is, how can I go about creating such a server? For right now, I have a home computer (running Windows XP that just stores data for my music system) which I can use to host the server. I am also open to the use of other online storage services like Google Drive or Dropbox (I can't remember if Amazon does anything like that). However (and I know this may complicate things a bit), but at least for now, I want/need to stick with free services/options.
Just to recap, the key features that I am looking for are:
create users/accounts (on the server)
eventually I may [try] to incorporate the use of other services to log users in like with their email account, OpenId, etc.
the ability to access (log in to) the server (with credentials) from my app
the ability to send/receive data between the server and my app
the ability to share data between users
I know this is a lot to ask for, but if anyone has any suggestions or can get me going in the right direction, it would be much appreciated.
The basic setup would be as follows:
Backend: Database (MySQL), Web server (Apache), with server side scripting (PHP).
Client: iOS device with developed app.
Communication: use HTTP client/server model, communicating with something like JSON.
This is much the same setup as a web server, but instead of serving html/css/javascript etc the results will be JSON.
As far as implementing specifics such as login in, and sharing data between users, this is purely dependent on your implementation. This is not trivial, and not something that can be easily stated in a single post.
Hope this helps.
You could build your own webservice in PHP, Ruby or Python. If you do so I would recommend building a RESTful webservice (http://en.wikipedia.org/wiki/Representational_state_transfer) and then use RestKit (http://restkit.org/) to handle the data in the iOS app. Especially RestKit's CoreData integration is nice in my opinion.
Another solution would be using a service like Parse (https://parse.com/products/data). The first million or so requests per month are free but after that it could get pricy. I personally have not tried it so I couldn't tell you if it is any good.
I'm currently building a mobile application (iOS at first), which needs a backend web service to communicate with.
Since this service will be exposing data that I only want to be accessed by my mobile clients, I would like to restrict the access to the service.
However I'm in a bit of a doubt as to how this should be implemented. Since my app doesn't require authentication, I can't just authenticate against the service with these credentials. Somehow I need to be able to identify if the request is coming from a trusted client (i.e. my app), and this of course leads to the thought that one could just use certificates. But couldn't this certificate just be extracted from the app and hence misused?
Currently my app is based on iOS, but later on android and WP will come as well.
The web service I'm expecting to develop in nodejs, though this is not a final decision - it will however be a RESTful service.
Any advice on best practice is appreciated!
Simple answer: You cannot prevent just anybody from acecssing your web site from a non-mobile client. You can, however, make it harder.
Easy:
Send a nonstandard HTTP header
Set some unique query parameter
Send an interesting (or subtly non-interesting) User Agent string
(you can probably think of a few more)
Difficult:
Implement a challenge/response protocol to identify your client
(Ab)use HTTP as a transport for your own encrypted content
(you can probably think of a few more)
Of course anybody could extract the data, decompile your code, replay your HTTP requests, and whatnot. But at some point, being able to access a free Web application wouldn't be worth the effort that'd be required to reverse-engineer your app.
There's a more basic question here, however. What would be the harm of accessing your site with some other client? You haven't said; and without that information it's basically impossible to recommend an appropriate solution.
I hate to re-invent the wheel so I'm looking for an existing solution to create a simple authentication system for my application. I've experimented for a while with using CardSpace or OpenID inside the application but I can't convince management that these would be working solutions.
Of course, I could just build a simple login dialog where username, domain and (hashed) password is stored inside a database table and I've done such a thing many times already. I hate this solution since I feel it's just a weak option. And I don't want to spend too much time trying to make the whole logon system as secure as possible, especially since I suspect that there should be existing solutions for this.
So, next to OpenID/OpenAuth and CardSpace, are there any other Authentication solutions that can be used from a Delphi/WIN32 application?
Right now, the application will be used by many customers. Most are single-user environments, although it's likely that some of those will start to have two to 5 users once this authentication system is added. But we want to support a customer who needs to allow about 500 different users on the same application. These are spread over about 100 offices but they all connect to the same SQL Server database. (MS Access right now, but we're making it possible for this user to use SQL Server instead.) To make matters even more interesting, the customer uses Citrix to centralize the user systems and the application has straight access to the SQL Server database. It's not an ideal setup but then again, the customer isn't really paying for this. We're just setting up a test environment. A proof-of-concept which the customer will test for us. Flaws will be solved later on. But right now I need quick solutions and one of them is a practical authentication system where I don't have to write a lot of code.
Have you considered using SQL Server authentication and not allowing authentication for those using an Access Database?
If you use the new SQL Server Native Client and SQL Server 2005 you can have passwords expire and change them from your client application. All of the tools to create and manage user accounts are built into SQL Server Management Studio. And if you decide later to support Windows Authentication you just need to modify your connection string.
We have a system where users on the network use Windows Authentication so they don't need to worry about another user name and password. For users that access the system via a VPN and non-domain joined machines they use SQL Authentication.
Here is the MSDN Page that talks about dealing with passwords programmatically in SQL Server 2005
You do need to make sure that SQL Server Native Client is installed, but that is simple compared to the rest of ADO.
I would suggest then
Delphi - since you are using Delphi :)
Open source - since you need to be able to figure out what is wrong if there is a problem, you probably want it cheap.
So, here are some solutions:
http://www.torry.net/pages.php?id=313
CoWindowsAccount v.1.0
SSecurity v.1.2.1.3
http://free-password-manager-plus.software.informer.com/1.6/
It might work for your purposes, but why not ask Windows for the current domain and user name, and use them as unique IDs. Windows has already done the authentication, and it saves the users making up new passwords or anything. I've used this to good effect. I also made it optional to include the machine name in the ID, so that the same user on different computers would also be unique.