Related
this is my first question so please be gentle...
I am working on a software which I would like to protect using some kind of licensing scheme.
A basic scheme would be to generate some "unique" key for a user. The user sends this key and a registration code when he wants to register the software and receives an activation code.
When the application runs it validates the activation code by comparing the "unique" key and a datablob received by decrypting the activation code.
This is fair and quite simple to implement, one can choose different crypto algorithms etc. however this scheme lacks two properties:
If the user manages to spoof hardware signature etc. to produce the same "unique" key on another computer he could use the same license data.
If the user decides to uninstall the application and wants to move it to another computer, there is nothing that prevents him from using the old license data again at the old computer and still obtaining new license data for the new installation.
Do you have any suggestions on how to resolve these issues?
One idea I had was to add some random data to the "unique" key, this random data would be stored in an obscure way, if the user deinstalls the application this random data would be removed, and some kind of hash with the previous random data and the license data would be generated which could be sent to me to verify that he really have uninstalled the application and made me sure that he wont be able to use the previous license data again since the random data had changed.
Over and out, for now...
EDIT:
I currently have a scheme that works, I should mention that the most common product is installed in an embedded enviroment where hardware-changes are very rare and if there is a hardware failure then most certain the machine is broken. But I could modify the hardware-key scheme to take into account and allow for some changes.
Also because of this the software will most likely not be run inside a VM, good point though and I haven't thought about that.
The application does not call out regularly, if a network connection is available the user gets the option to make a more automatic registration, otherwise he/she gets a registration key, enters it in the software and gets an installation ID which is provided to me, registration code + installation ID generates an activation key that the user gets from me which then unlocks the software.
What I am looking for is good/feasible solutions to the 2 points. Hardware spoofing, Revoking license keys i.e. to be sure the user can not use the same regcode+activationcode.
Thank you for all your feedback
It is not necessary to
First, you should make it clear what you're trying to protect. Apparently, you want to ensure that for each purchase of your application, there will only ever be one computer on which the application is installed and runnable.
You propose to use a hardware signature as part of each user's unique key. What happens if my hardware fails (e.g. my hard disk breaks)? I'm certainly not going to purchase your application if I can't go on using it after a hardware problem, so at a minimum you must be prepared to handle key change requests. You'd better respond fast, because if your application is important I want to minimize downtime. And I'm not inviting you to check that my hardware has failed, so you'll have to take my word for it. That means any user can get a free licenses from time to time by pretexting a hardware failure.
What about virtual machines? It's probably feasible to detect all currently existing virtual machine configuration, at the risk of a few false positives now and then. If you forbid virtual machines, how do you justify this to users? If you allow virtual machines, how do you prevent the user from making multiple copies of the whole VM? (This can happen even with physical machines, with hibernation).
Is the application going to call back to you every time it starts? I guess so, from your deinstallation scheme. That's a bandwidth and availabilty cost, and will also put off some users — not everyone is online, especially in sensitive environments. But then you don't need such a complex scheme: your server can keep track of how many copies of the application are running, though you do have to handle the case when the application doesn't terminate cleanly for any reason (application crash, OS crash, power failure, loss of connectivity...).
You don't discuss this in your question, but you have to protect the application executable, so that someone can't bypass the license check with a debugger.
Place your software into appliance hardware and put a padlock on the hardware. Ship the appliance to the customer.
If you believe the customer will hacksaw the appliance open to get your code, consider encrypting the storage medium.... Then they have to hacksaw the box AND find the keys. A TPM chip or secure USB token may aid with the latter.
Being a shareware author and longtime member of ASP myself i think you are going into the wrong direction with your solution. The only way to make this workable is with a hardware device as already suggested. This or constant online activations is the only way if you want to be sure and your product is so good and without competitors that your customers will still use it.
But what we (organized small ISV's) learned from practice is that you should not do what you are trying to do. Do not bind it to hardware. Sell one license per person not one license per computer. In the end you will make more sales because of the relaxed license.
Just do enough to make the honest people stay honest. So limit the trail version (i decided to terminate the application after one hour for me) and leave the final version free from all stuff. Give a separate download for payed customers and thats it. Be a nice company and not a greedy profit maximizing by legal restrictions company.
I used some of the better windows protection programs first but they all had serious problems with my code. And they call get cracked sooner or later. So i gave up all of them.
P.S.: I use a hardware fingerprint schema on windows where i don't restrict the program but just to keep people away from getting new trial keys every 30 days. Together with a nag screen it seems to work. The fingerprint is an xor of user name, windows installation time, modify time stamp of a system files and harddisk serial id.
Let the registration code also be the activation code.
You generate the unique registration code at point of sale, or packaged with the product. Customer registers/activates/deactivates with you (or your server) in one step using that single code. The customer's hardware doesn't have to generate any keys.
Reregistering/reactivating still requires contact with you, so you're aware of reinstall attempts.
I think that the only solution to your problem is a cryptographic hardware dongle. Usually it would be a USB-based tamper-resistant challenge-response dongle, that can be easily transferred between computers.
These devices cost less than $1 for large quantities, and not more than $10 for very small quantities. The good ones are very hard to forge, very easy to embed in your application, and usually supplied with a free EXE encryptor which also contains anti-debugging and anti-reverse-engineering functionality.
I'm creating an application to track publications and grants for a university. Professors will need to put they CV into the system when it is up and running. Yeah, right.
The person in charge is planning on hiring someone to input all of the information, but my questions is how?
The strategy I'm thinking of is to install a backdoor. The lucky undergrad can log in as any professor using the backdoor. Once all the data is removed, the backdoor can be removed.
Doing so would probably be as simple as editing out a comment in the config file. The IT guys would still have access, but since they control the machines, they would have access anyway. Are there any flaws to this strategy?
Instead of installing a backdoor, why not create a priviledged user role. Users with this role can view and modify data for any other users (or a select group of users if you want to be fancy - and more secure - with it). So, the undergrad could use an account with this role to input the necessary data. When he is done, an admin can remove the role from his account, effectively closing the "back door".
You risk the undergrad dealing some other damage. What you should do is have them create a new user, give that user a small partition, and have the user enter the data on to that. Then just copy it over when he's done. Bad idea to give a student actual access, and even worse to have him log on as the guy - he should have his own user.
Don't underestimate the ongoing need for staff, students, or temps to enter and maintain the data. As simple as upkeep may be after the initial loading (typing) period, some professors simply will not do it, and will delegate it to staff.
In an eerily similar application (ours tracks publications and grants, among other things, as part of a career review for raises and promotions) our decision was to use a "proxy" system, where certain users can "switch to" other users. It's not really a switch because we store who was doing the input/editing along with who the data applies to.
Contrary to what Justin Ethier said about privileged roles, these people are the least privileged in the system, allowed only to switch to another account and do data entry.
I am the webmaster for a small, growing industrial association. Soon, I will have to implement a restricted, members-only section for the website.
The problem is that our organization membership both includes big companies as well as amateur “clubs” (it's a relatively new industry…).
It is clear that those clubs will share the login ID they will use to log onto our website. The problem is to detect whether one of their members will share the login credentials with people who would not normally supposed to be accessing the website (there is no objection for such a club to have all it’s members get on the website).
I have thought about logging along with each sign-on the IP address as well as the OS and the browser used; if the OS/Browser stays constant and there are no more than, say, 10 different IP addresses, the account is clearly used by very few different computers.
But if there are 50 OS/Browser combination and 150 different IPs, the credentials have obviously been disseminated far, and there would be then cause for action, such as modifying the password.
Of course, it is extremely annoying when your password is being unilaterally changed. So, for this problem, I thought about allowing the “clubs” to manage their own list of sub-accounts, and therefore if abuse is suspected, the user responsible would be easily pinned-down, and this “sub-member” alone would face the annoyance of a password change.
Question:
What potential problems would anyone see with such an approach?
Any particular reason why you can't force each club member to register (just straight-up, not necessarily as a sub or a similar complex structure)? Perhaps give each club some sort of code to use just when the users register so you can automatically create their accounts and affiliate them with a club, but you then have direct accounting of each member without an onerous process that the club has to manage themselves. Then it's much easier to determine if a given account is being spread around (disparate IP accesses in given periods of time).
Clearly then you can also set a limit on the number of affiliated accounts per club, should you want to do so. This is basically what you've suggested, I suppose, but I would try to keep any onerous management tasks out of the hands of your users if at all possible. If you can manage club-affiliated signups, you should, rather than forcing someone at the club to manage them for you.
Also, while some sort of heuristic based on IP and credentials is probably fine, I would stay away from incorporating user-agent, or at least caring too much about it. Seeing a few different UAs from the same IP - depending on your expected userbase, I suppose - isn't really that unusual. I use several browsers in the course of my day due to website bugs, etc. and unless someone is using a machine as a proxy, it's not evidence of anything nefarious.
I'm planning to add some vote up/vote down buttons to a website I run. This seems easy enough but I want to stop people voting multiple times. One solution would be to make them register before allowing them to vote but I'd prefer not to have to force them to register.
Is there are a reasonably straightforward way of doing this? Checking the IP address doesn't seem like a good solution, since it's possible that multiple users may come from the same IP address.
Cookies might be the answer, but a savvy user could delete the cookie. Any better ideas?
Sorry I don't have a useful answer, I just want to share my experience.
About 8 years ago I worked for a site that ran online polls. We once got hacked by some bots voting on some of our questions several hundred votes a minute.
I had to implement some emergency checks: IP address, cookies, and I really don't remember what else.
At the end of the day we decided to take the polls down. Those damn robots just didn't care. IP adresses were spoofed, cookies were being deleted, etc.
If you really really need the polls to be unhackeable I don't see any other way that requiring registration and using captchas to avoid bots signing up for new accounts.
And the sad thing is that this was just an entertainment site with polls on what's your favorite color and things like that.
The only thing we didn't tried was using captchas because they didn't exist at the time. That might have reduced non-human cheating a good deal.
Don't take this as any kind of expert advice on the matter, because that was the only time I had anything to do with online polls, but I remembered my story and wanted to share.
I think it really comes down to the nature of your website, and how accurate your results needed to be.
Using a cookie seems like the best option, but it depends on the target audience of your website. Would they be tech-savvy enough to try and beat the system to allow them to vote multiple times? If not, the risk should be fairly low and this would seem like the best approach.
Checking against an IP address, as you said, may be too restrictive. But if it's critical for all votes to be from unique individuals, this might be the better approach even if it means some legitimate voters won't get to vote.
I thought of another option, but I'm not sure if it's possible or feasible. If you could combine the IP address approach with a hardware based check (e.g. MAC address of NIC) this would eliminate the IP address approach being too restrictive due to NAT within a LAN. But it wouldn't help the situation where you have a computer in an Internet cafe used by different individuals.
You should also use captcha (for non registered accounts) to reduce the likelihood of voting bots. If someone wants to maliciously cast multiple votes, making it more difficult for them to automate the voting process through bots will help to hopefully reduce the occurrence of such behaviour.
So, you want to have each unique person have only one vote on each item. When a person tries to vote who has already voted before, you want to detect this. This means that you have to identify the person. There are no tricks to get around that.
Now, since persons can log in from any computer, identifying the computer doesn't help. This rules out IP checks and cookies, as well as anything else based on the user's hardware.
How to identify a person? You can't. You can only force them to identify themselves, by providing unique credentials, like a social security number (I think this is often used in Korea), a passport number, or similar. This, of course, doesn't help if you don't check it, since anyone can make up a 10 digit number with little chance of collision.
Even having the user register doesn't really help per se -- they can just register another account.
I wonder if you could make it a multi-step process, to make it more difficult for BOTs.
Registering, or some similar task, gets you Cookie-A, and then when you vote you get Cookie-B, but if you have Cookie-B and don't have a suitable matching Cookie-A your vote doesn't count. If you try to re-register on the same machine that can be detected by you already having Cookie-A. Going through the steps too fast is treated as a BOT.
We had a psychometric test, with many questions, and users had to make thoughtful answers. An answer in sub-N seconds was someone just pressing buttons to get through it. We never told them that their answer was too quick, we just marked the data as "suspect".
So anyone trying to go straight to the Vote Button won't work. They would have to do Step-A, then Step-b then Step-C in order.
To re-vote I would have to clear cookies, re-register, read the blurb-page (whatever) and finally re-vote, all in the right order, and not too fast.
Requiring JavaScript to be enabled may help, as may a Captcha system. Captcha could have some sort of delay - "Please watch as the two words appear" so that there are two words, shown one after another, but "real words" so that they can be easily memorised, and then typed in. Any response that is "too fast" is not valid.
At some point people will just become annoyed and not bother though.
Obviously you need to identify the user so he can only vote once. But identify the user does'nt mean you have to pop up a login screen. As said above you can ask for the email
address, ans use it as an identfier.
No one mention the way stackoverflow works, if the user has something to win (here reptutation) when becoming a register user and if the login process is as simple as giving an email address, then that's a win-win situation in wich the user is happy to login and vote, and you're happy to have him registered and voting things (and only once per question).
Jeff Atwood wrote an article about the "login barrier", wich may give you clues.
I once created a voting system for a contest. I was restricted from limiting votes by IP due to the fact that multiple people would be legitimately voting from the same IPs. As such, I went with the email confirmation method, requiring each voter to input an email address which a confirmation link was sent to, which, once clicked, would activate their vote and prevent additional votes using that address.
It did not work well. People created hundreds of false email addresses on various free sites.
What did work in the runoff vote, somewhat surprisingly, was adding the email address/vote pairs to a database but not immediately sending the confirmation emails out. Instead, I had a cron job send the batch of them every 15 minutes or so. This adds an additional complication for people registering many addresses, as they have to either leave them all open or remember the login info for each of them at some point in the future.
Of course, still easily bypassed for someone motivated enough, but it seemed to work well in this case.
I've never used a system like this, but try to identify a user by their browser's fingerprint. This jQuery plugin combines screen size, color depth, user timezone, and installed plugins to create a unique ID of a user. Definitely not foolproof, but it's a different approach.
There's no accurate way to avoid multiple votes from the same user, even if they don't delete cookies, they can use another browser, or another computer.
I think you should register user before he up / down vote. You can get a little piece of information from the user to get registered, so he does not bored or break his registeration. Afterwards he can update his account if he wants. IMHO this is the best solution.
As has been said there is no 'perfect' solution.
As an attempt at an imperfect solution, how about storing a hash of the IP address and the User agent.
This would mean that different users from a given IP, which have different browser user agents, can still vote.
Use a cookie-based approach, it is accurate enough for most entertainment-grade polls on the web. Stay away from IP restrictions. This would mean that only one person from larger companies gets to vote and that only one person in a family gets to vote.
Also a possibility:
let the user vote and fill out his emailaddress.
The user receives a confirmationemail with a link he needs to click in order to confirm his vote.
But this way, the user also has quite some overhead.
Or do this in combination with registered userss (who will not be forced to confirm)
I know that this is an old thread. In any case I suggest to use evercookie (http://samy.pl/evercookie/) to track a user that have already voted!
It's matter of how many identities a single person can control. The more harder you make for a single person to control multiple identities the more secure your poll will be.
For entertainment grade polls where the results doesn't matter, single cookie approach is enough. Very easy to circumvent if the user opens icognito windows.
Better protection can be obtained if you put a registration barrier, you can use OAuth based logins for seamless authentication, it would take some effort to switch accounts for more votes. But this doesn't stop the desperate ones to vote multiple times.
Even better if you send confirmation code in SMS. Though people may own multiple phone numbers, it's not common to have a considerable number of phone numbers to execute a fraud. But this approach costs money for you and can be abused by DoSing the server to exhaust all the SMSes.
If you want goverment-grade polls, where the votes can decide an election.
Then you should have the voters show up in the registration office to apply for the poll and let them choose one from the prepared PIN envelopes, which contains a long hash they can enter when casting the vote.
So unless the organizers commit a fraud then voters can't. This also ensures anonymity.
An old question but for to touch on new ways - these days there are many Poll services out there who work tirelessly to implement numerous measures to avoid dupe votes, and constantly tweak their systems to counter new ways people introduce to circumvent etc. Doing this yourself is a job in itself.
They even offer branding. And large corporations use them, so it's not like your company will look bad for outsourcing a poll.
If you need to do it yourself.
As has been said, registration is the only sure fire way. If it's really important to avoid dupe votes (i.e. it's not just fave colour or something trivial/fun) then you can also limit voting to a link you send to their email they registered with.
While still not fool proof (nothing is) at least you force them to have a genuine email address which they have access to.
This isn't too much trouble for users voting, but makes it fiddly to make many dupe votes - registering, waiting for email, using the link, etc.
You already named all usable solutions. ;) It's your task to decide now.
I'd recommend combining an IP and cookie check.
Within your organization, is every developer required to lock his workstation when leaving it?
What do you see a risks when workstations are left unlocked, and how do you think such risks are important compared to "over-wire" (network hacking) security risks?
What policies do you think are most efficient to enforce locking the workstations? (The policies might be either something "technical", like a domain group security settings for screen-savers to be locking, or a "social", like applying some penalties to those who do not lock, or encouraging Goating?)
The primary real world risks are your co-workers "goating" you. You can enforce this by setting a group policy to run the screen saver after X minutes, which can lock the computer as well.
For me, this has become habit. On a Windows machine, pressing Windows-L is a quick way of locking the machine.
The solution might be social rather than technical. Convince people that they don't want anyone else reading their email or spoofing their accounts when they step away.
In my org (government), yes. We deal with sensitive data (medical and SSN). It's instinctual for me: Windows+L every time I walk away.
The policy is both social and technical. On the social side, we're reminded that personal security is important, and everyone is aware of the data with which we are privy. On the technical side, the workstations use a group policy that turns on the screensaver after 2 minutes, with "On resume, password protect" turned on (and unable to be turned off).
No, but I'm an organization of 1 - the last time I worked in a large organization, we were not required, but encouraged to. If I were in an enviroment with other people, I would probably lock my workstation now when I left it.
While certainly people with physical access can add hardware keyloggers, locking it does add an additional level of security. Depending on the type of organization you are, I think the risks are more from internal organizational snooping than over-the-wire attacks.
I used to work at a very large corp where the workstation required your badge to be inserted inside it to work. You weren't allowed to move in the building (you needed the badge to open the doors anyway) without that badge on you. Taking the badge out of the workstation's smartcard reader logged you out automatically.
Off topic but even neater, the workstations were more like "networkstations" (note that it is not a necessity to use the system I've just described, though) and the badge held your session. Pop it into another workstation in another building and here's your session just as you left it when you pulled the badge on the other computer.
So they basically solved the issue by physically forcing people to log off their workstation, which I think is the best way to enforce any kind of security-critical policy. People forget, it's human nature.
The only place I have seen where this is truly important is government, defense, and medical facilities. The best way to enforce it is through user policies on Windows and "dot files" on Unix systems where a screensaver and timeout are pre-chosen for you when you log in and you aren't allowed to change them.
I never lock my workstation.
When my coworker and friend mocked me and theatened to send embarassing emails from my machine, I mocked him back for thinking that locking does ANYTHING when I have physical access to his machine, and I linked him to this url:
http://www.google.com/search?hl=en&q=USB+keylogger
I don't work with any sensitive data my coworkers wouldn't already have equal access to, but I am doubtful of the effectiveness of workstation locking against a determined snoopish coworker.
edit: the reason I don't lock is because I used to, but it kept creating weird instabilities in windows. I reboot only on demand, so I expect my machine to run for months without becoming unstable and locking was getting in the way.
Goating can get you fired, so I don't recommend it. However, if that's not the case where you work, it can be effective, even if it's just a broad email that says, "I will always lock my workstation from now on."
At the very least, machines should lock themselves after X minutes of inactivity, and this should be set via group policy.
Security is about raising the bar, making a greater amount of effort necessary to accomplish something bad. Not locking your workstation at all lowers that bar.
We combine social and technical methods to encourage IT people to lock their PCs: default screen saver/locking settings plus the threat of goating. (The last place I worked actually locked the screen saver settings.)
One thing to keep in mind is that if you have applications (particularly if they are SSO) that track activity, changes, or both, the data you collect may be less valuable if you can't be sure the user recorded in the data is the user who actually made those changes.
Even at a company like ours, where there isn't a lot of company-related sensitive information available to most users, there's certainly potential for someone to acquire NBR data from another employee via an unlocked workstation. How many people save passwords to websites on their computer? Amazon? Fantasy football? (A dangerous goating technique: drop a key player from someone else's roster. It's really only funny if the commish is in on it with you, so the player can be restored ...)
Another thing to consider is that you can't be sure that everyone in your building belongs there. It's much easier to hack into a network if you're actually in the building: of course the vast majority of people in the building are there because they're allowed to be, but you really don't want to be the victimized company when that one guy in a million does get into the building. (It doesn't even have to be an intentionally bad guy: it could be somebody's kid, a friend, a relative ...) Of course the employee who let that person in could also let that person use their computer, but that kind of attack is much more difficult to stop.
locking your workstation each time you go for a coffee means that you type your password 10 times per day rather than once. And everyone around you can see you type it. And once they have that password they can impersonate you from remote computers which is far more difficult to prove than using your PC in the office with everyone watching. So surely locking your workstation is actually more of a security risk?
I'm running Pageant and have my SSH-public key distributed over all the servers here. Whoever sits down on my workstation can basically log into any account everywhere with my keys.
Therefore I always lock my machine, even for a 30s break. (Windows-L is basically the only Windows-key based shortcut I know.)
I personally think the risk is low, but in my experience most of the time it's not matter of opinion -- it's often a requirement for big corporate or government clients who will actually come in and audit your security. In that case, some kind of technical (group policy) solution would be best because you can actually prove you are complying with the requirement. I would also do it in cases where there is a legal privacy requirement (like medical data and HIPAA.)
I worked at a place where the people who supplied some of our equipment were from a company in direct competition with us. They were in the building when the equipment required maintenance. An email would go out every now and then saying they would be there, please lock your machine when you're not at it. If a competitor got our source because a developer forgot to lock their machine, the developer would be looking for a new job.
We are required to at work, and we enforce it ourselves. Mass chats are started professing love for people, emails are sent, backgrounds are changed, etc. Gotta love the first day when it happens to a new hire, everyone is sure to leave a nice note :)
The place I used to work had a policy on always locking your workstation. They enforced it by setting up a company wide mailing list - if you left your workstation unlocked, your co-workers would send an embarrassing mail to the list from your account, then lock your machine. It was kind of funny, and also kind of annoying, but it generally worked.
You could start sitting down at people's workstations and loading up [insert anything bad here] right after they walk away. That will work I'm sure.
In some/most government offices I've visited, that have the possibility of having members of the public walking about they have smartcards that plug into a USB reader on the PC. The card is on a necklace around the user's neck and locks the workstation when it's removed.
The owner of my company (and a developer), will make a minor change to your code window if you left your computer unlocked, making you go crazy wondering why your code isn't working until you find it.
Have to say, I never keep my computer unlocked after hearing about that prank, I go crazy enough as it is with some of my code.
You could rig up a simple foolproof way, have a fingerprint reader plugged into the computer programmed for your password, then wear this necklace with a usb receiver, and if you move away from the workstation, the screen saver actively locks it, then when you appear within the range, swipe your finger off the fingerprint reader to unlock the workstation - I think that would be a quite cheap way of doing it, simple, un-intrusive, and clutter free, no forgetting to lock via 'WinKey+L'
Hope this helps,
Best regards,
Tom.
Is it important or is it a good habit? Locking your computer is may not be important say in your own house, but if you are at a client's office and walk away then I would say it is important.
As for how to enforce...
After reading Jeff's blog entry on Don't Forget To Lock Your Computer; I like to change co-worker's desktop backgrounds to...
1,238px × 929px
Needless to say, co-workers started locking their computers.
GateKeeper is an easy solution to this. It locks the workstation automatically when the user walks away, and unlocks automatically when the user comes back within range of the computer. It can also require two factor authentication and other methods of lock/unlock.