I am creating an application and I want to have the application 'authenticate' with some form of registration key in order to cut down on piracy. I was thinking of perhaps building a string when the customer purchases the product and use something like MD5 to create a hash.
The question I have is where is the best place to store this key once it's entered.I am also curious how you design the application to require it or not allow it to run.
EDIT:
The application is written in .NET and any server side techonlogy that will be used will interface with SQL Server database.
Some thoughts... is this a 'one time activation', or something that happens each time the app runs? Users tend to view the latter as a privacy concern. I've gone down the path of one-time registration, with an app called Protection Plus. It handles generation of the challenge/response, which is really the hard part.
PP creates a challenge key which changes each time the form is loaded on the client. With this key, the remote system generates a 'trigger code' using the challenge and a system code provided by the client. PP can be configured to create this system code in several different ways... a bios hash, hard drive serial #, hard drive volume label, etc, ...
When the trigger code is created (which does one of several actions), and sent back to the client, PP decrypts it and returns the correct integer-based action to take.
If interested, check it out:
Protection Plus Website
Related
I have an application but for security reasons I need to keep track of who uses it. It will be used in my company and the users will be informed that their usage will be tracked. This is because it's dealing with some sensitive information so we need to know who has accessed it.
That said, I don't know how to approach this in a secure way. The simplest way would simply be to write computer name, Ip, etc etc to a text file and upload it to a FTP file server. However for this to be possible, I need to include the authentication details in the code which, if decompiled or otherwise seen would be very dangerous.
So I was wondering if there's any good/decent approaches to doing this in VB.NET?
Thanks.
In my project i used DBManager class where i did all my DB stuff, so to keep track of what users are doing, I wrote an function that fired up every time Data was edited, inserted, deleted etc, or even User has logged in, my function Inserted new data with query (what user has done), username, date, IP and so on...
It's not perfect, but it worked and I think this method is worth to recommend.
I working on a simple vb application. But I want to protect it to give the user the option to use it only for a specific time.
So I was thinking to make a text file with a key-code (Beside Random characters, it contains an expire date). When the application is started after this expire date, the application should close automatically.
The location where this textile is location can be the same location where the executable is running from.
Does somebody of you have a good idea how to implement it? Or is there a easier way how to implement this
If you want to give a "Trial period" to your application you might want rather hard-code that to prevent tampering. Then, when purchased make a modification to registry and different files (maybe downloads a few files that "register" the application so that it recognizes itself as "full". To go one step further maybe periodically have the application reach out to your server and verify the license.
This is a huge subject that a lot of smarter people than me can weigh in on. I will note that this is part of a constant battle between developers and hackers trying to get around licensure.
To make software unlocked for some period of time, you can create text file on websites like Pastebin and add them an expiry date. Then make your software check if file is still valid.
Note that users can "track down" requests your software sends, never store your private information linked with your software.
You can also use HWID protection which ensures your software will work only if it matches hardware information stored in encrypted string.
You can hash other user's information like username, wifi name and so on, but remember that changing any of this information (OS, hardware or system information) will create new unique HWID, which may not match the previous one - resulting in failed HWID authorization.
To make bypassing protection harder, you can obfuscate your software.
I have an application that generates a barcode using a third party library. This barcode is not static and changes every 30 seconds or so from within the app.
I'm aware the proper way is to get a signed pkpass file from your server to supply to passbook, and use APN or some sort of trigger within the iOS app to acquire a new barcode. But...due to certain reasons...some of this is not viable at the moment...
So...
Ideally, I would like to be able to allow the user so that every time they select my pass, I'm able to supply them with the dynamically generated barcode (or pkpass file) from the application.
Is such a way even remotely possible? I know it doesn't really conform to "best practice"...
the proper way is to get a signed pkpass file from your server to supply to passbook
This is not just the proper way, this is the ONLY way! Passes cannot be dynamically generated and signed on the device as it would require embedding of your Pass Type ID certificate into your app.
Also, if you are generating and replacing passes with such frequency, the Passbook App will throttle your pass to preserve your users' battery and bandwidth. This would prevent your pass from updating.
An ugly hack would be to educate users to use the "pull to refresh" function on the back of the pass, then serve a new pass in response to the user request, but this would require a degree of synchronisation between your server, your app and the pass.
Practically, if the barcode is changing every 30 seconds or so, then there is a probability that the barcode expires before the user is able to retrieve the pass and present it for scanning. Perhaps there is a better way to achieve what you want without such frequent rotation of the barcode?
I made a program that gets the data from the clipboard and saves it in a string variable. Then it looks for specific words in that string and generates several URLs. Afterwards it open the browser and shows each URL in an own tab.
Some of my friends already use this program frequently and I want to have some statistics about how often. I simple counter variable would be enough but I need to get access to it.
I came up with two options that could work:
I could send an email to a specific adress every time my app is executed. Then I can track the amount of uses by manually or automaticly counting the amount of emails in the postbox. I think this would be a Vers dirty solution.
I could create and publish a website containing a counter. This counter could be refreshed by my application. This solution is a bit better I think but a lot more work for just one single counter.
Do you have better ideas to solve my problem or is one of mine already a good one?
Thank you in advace!
You can use Measurement Protocol Overview. This provides you statistics of usage your application compared with Google Analytics. You can see even a geo statistic, version distribution, crash reports. It is easy to use it from .net. It is just about requesting http request to google.
our application wants to be able to create static, searchable pages based on user profile information, which would be linkable to other public profiles.
I am looking at LinkedIn as an example...it seems like they actually auto-generate the page to be a static file that is indexable and searchable.
Can someone suggest how we would do this? I am thinking there would need to be a cron job that runs and writes a the path and file name.
The user may want to keep the whole page private, in which case I imagine it would need to delete it.
There's alot of sub-requirements but that's the general concept and wanted to start getting ideas and feedback.
Thanks.
You can do without the cron job if you generate the static pages in real time whenever the profile information is created/updated or whenever user changed the setting to keep info public/private. This way you are not constantly looping through all users, and do not depend on another component (your cron job) to be running.
One alternative would be to adopt an explicit RESTful information architecture so that a profile resource ("page") is addressable with a permanent URL. The resulting resource could be a static page. Or not. That would be an implementation detail invisible to the search engine crawler and any web browser accessing the resource.
umnik700's answer is fairly dead-on if you're not considering issues related to authentication or who gets to see what. Consider the difference between the profiles you see when you're logged into Facebook versus those same profiles' publicly facing, searchable counterparts. Even MySpace, with a lot less consideration for search engine privacy, has viewability that is dependent on your relationship to the other person, defaulting, for private profiles, to "This profile has been set to private by the user" or something to that extent.
If you're looking to suddenly scale out a social tool where individuals are eliciting their personal information, I would suggest umnik700's answer (dynamically generate the content, but not the URLs, for public versions of the profile) with the following corollary: you need to be able to support privacy preferences varying from extremely strict to completely open, and default to a version that at least errs on the stricter, more private version of the profile. If you're just now pushing out searchable personal content when there never was any way to find it outside the site before, it's important not to abuse information given under different pretenses.
I know this probably requires maybe more scalability and added functionality than you were hoping this project would take, but to do otherwise could be most likely taken as a violation of your user base's tacit trust. Anyway, the best strategy to do this will probably require you to lean on your database more anyway, so it might be time to rework it a bit--including adding some privacy preferences.