Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am at the first experience of releasing my windows application and I don't have a cue how I should move on. Here my question:
I have my own website running on hosting. I would like to implement a customer
portal so after receiving an order I will provide a username and password via email
where users can download the activation code. I know that this is a big question...How to protect my application against duplication? Do you know what is the "best" solution to apply license system to my software?
How I can force the application to be excuted just on specific pc? Is it complex to achive?
In this scenario should I create a new build for each user so the activation key will
unblock just the right build?
If so I understand that each profile will have its own build file along with activation code and a sort of service agreement information (i.e. 1 year of free updateds).
Again I see it to complex to manage, for every changes in the application I need to compile, build and upload new version...? Ok... my application right now is a simple exe file with some folders and xml configuration files but what in future...?
Is it possible just to share among all user a single application file which can be activated by using the user activation code (in this scenario user will have his own profile just for activation key and SA information). what about security? if someone share the activation code I guess the application can be unblocked anywhere.
Should I implement the customer portal on a dedicated server (i.e) ? I don't have possibility to install my own server. What do you think about virtual server on ISP?
What about invoicing and ordering process? You think that an ecommerce commercial solution is a good choice? For istance I was thinking to get order via email or fax and then process the license (still don't know how) and send invoice whith information for payment (i.e wire tranfer). What do you think?
If the software it would cost (still don't know the price) let's say less then 30 dollars does it make sense to use as payment method a wire tranfer? What about share-it.com? Is it safe? Do they also handle customer portal?
Thanks a lot.
The usual way to prevent users from just replicating your application on many machines is 'node-locking' - at runtime the application checks that certain machine parameters match the values recorded in an encrypted license key or activation record. The Ethernet MAC address is a popular locking parameter, but this is not a good choice as on some systems the MAC address can be set or spoofed. A combination of parameters such as Windows ID, machine name, perhaps user log-in name etc. is more secure.
To issue a license you either request these details from the user or have them run a small utility that writes them to a file they send to you. You can then encrypt them in the license key, which can also contain other information such as a trial or subscription time limit, feature configuration info etc.
Alternatively, all this can be done automatically using [product activation][2]. When your application first runs it connects to a hosted license server, checks it is a valid license, and automatically reads the names of the locking parameters on its host, so it can then encrypt them and persist them in a local file it then reads each time it runs after that (so the app does not need to connect to the server again after the initial validation). If you go the activation route it is much more convenient for you and your users.
Whatever route you go, you need to think about:
- Integration with your chosen ecommerce provider/payment processor?
- How to handle users who don't have an Internet connection?
- How to support users who want to relocate their license, perhaps because they bought a new system? Can you ensure they have only one copy active at any one time? (and you may also want to limit how often they can relocate their license).
- If you lock to several machine parameters, can your locking system accommodate the user upgrading part of their system, so potentially causing one of the node-locking parameters to change?
- If the user's system crashes, how can they get their license running again on another machine?
- How do you issue trial licenses?
- How do you protect against people who try to hack your license protection?
- Might you in future want to configure features in your product e.g. offer different price points, or different combinations of features to different types of users. Can your licensing system handle this?
All these issues and more have of course already been considered and resolved by competent commercial licensing systems.
i would go with similar system to what i have seen used by Nod32 ( which is why i don't use it anymore, but still suggest to buy for everyone else ).
Application has two states: demo and full.
You can use the demo version for time period of 30 month.
And each application has a product key, which is daily verified against remote server. If verification fails, application slips back into demo mode.
If the verification server is unreachable, you show user a message that "verification server unreachable, check your connection or verify manually". Then try again in an hour. If for .. lets say .. 3 days application hasn't been verified. It does into demo mode.
If user, which has connection issues clicks on notification bubble, he sees a view containing information about how to verify manual or button for "try again".
For manual verification you have a generated code (based on his hardware data), which he can enter in your website together with his product key. And get a number for manual verification.
my 2 cents.
How I can force the application to be excuted just on specific pc? Is
it complex to achive?
You can store his computer ID/Key pair in your database.
In this scenario should I create a new build for each user so the
activation key will unblock just the right build?
No. Definitely you do not want to create 1000 builds for 1000users.
If so I understand that each profile will have its own build file
along with activation code and a sort of service agreement information
(i.e. 1 year of free updated).
It is easy to manage it with a right tool. You can ‘bind’ each key to a specific version range of your product (say v1.0.00 – v2.0.00) or specify the validity period of the key ( SaaS scheme)
Is it possible just to share among all user a single application file
which can be activated by using the user activation code ..?
Yes. It’s called floating or network licenses.LAN license server allows to run some limited number of product’s instances in corporate network. This approach is widely used by corporate customers.
Should I implement the customer portal on a dedicated server (i.e) ? I
don't have possibility to install my own server. What do you think
about virtual server on ISP?
It depends on what you mean under ‘own server’. You can’t run separate daemon/process on shared hosting, you need VPS or dedicated server. But you can use the solutions that are present on the market already.
Why do you need to implement activation system yourself? And run servers yourself? It may appear a far more complicated and costly as it seems.
ActivationCloud https://activation-cloud.com provides a good set of features that can fit needs of ISVs that is selling software to home and corporate user. Consider to use it.
Read my question "A licensing system for my (WinForms) application. Would this be secure enough? (Within reason)"
I listed a few possibilities.
Mainly, I noticed that you wanted the program to be only runnable on a specific PC, for which I used a function which returns a unique code for each PC, and required it to be the last 5 characters of the Product Key.
Hope this helped. :)
Related
i want to sell one program to customer， but I want to make one program can run at one server with only one lisence code, if customer want to run the program at other servers, he needs to buy more activation codes.
so is there a good method to generate activation code? i imagine that it will be related with one password and server mac-address
BTW: I just need one easy method, because my customer is not technology man
I can give you a rough idea, but, it isn't very easy.
Have a server running, and, at the start of your program, make it query your server with an activation code and a generated hash code (that is unique to each compile of the program) and have your server check if the combination has been queried before.
There are well-established solutions for [product activation][2], and they already deal with the issues you need to think about, including:
Securely activating licenses on systems without an Internet connection
Allowing users to securely relocate licenses
Allowing installation on virtual systems without enabling unlimited copying
When a user's system crashes, how you get their license up again on another system.
Protecting against various hacking attacks
What to use for locking? And as Alex says, the MAC address is not a good choice, even if it has been a common one. A combination of systems parameter is best, but then how do you deal gracefully with a user who does a minor system upgrade?
Secure trial licenses, whether time-limited, function-limited, or indeed both.
Configuring product features
Licensing upgrades...
....and much more.
There is no perfect way to do this since virtualization can basically emulate any environment to amazing detail. License files, signed executables, and remote license servers are all options but are such a strain on your customer. I recommend you form a license agreement with your customer and trust them. There is no reason that you couldn't adopt some sort of periodic audit but in the end it comes down to a matter of trust vs convenience.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
what i have until now:
session on server side
unique id (md5) of computer created by Request.ServerVariables("HTTP_USER_AGENT") & REMOTE_HOST and saved on the database
but what else can i do in this case? users continue to share their login details :(
This is a problem in almost any line of work: from software, where someone can simply copy the program, to simple ticketing, and having an individual walk past the ticketing desk. (I worked in a ticket selling position, and we did have individuals walk in without paying.) This is largely a social problem, not a computing one, and it's been my experience that trying to fix social problems (people) with computers is largely futile. Here is a culmination of what I've heard on this topic, and the two categories the advice tends to fall into:
Try to control the problem.
Try to somehow identify and control the unscrupulous users of the system. This can be DRM for software, or a security guard in the example of the ticketing desk. This is essentially what you're trying now.
A problem I see with your current method is it doesn't support multiple browsers. I routinely browse from multiple browsers, and from multiple websites. If this is your method for identifying theft of your service, are you sure you're not seeing false positives?
If you do try to control the problem, the best thing I've heard is to make sure you don't affect the users legitimately using the system. Causing pain to a legitimate user by either making him install DRM software on his machine, or by requiring him to take off his shoes to get on a plane, only causes him trouble and degrades the apparent quality of your service in his eyes. Try to find ways to identify troublesome users without affecting the normal crowd: selecting blacklisting (banning) of IP addresses might be effective in the case of a web service. (Wikipedia controls spammers and malicious editors this way, and some people have controlled spam email this way.)
Now, the other line of reasoning:
Ignore the problem.
This stems from the "don't get in the user's way" ideals. Make your service as good as it can be for the user, and offer him a high quality service that he won't mind parting with his cash. In other words, make it worth his money. This depends on enough people being honest that you're still profitable, of course. Some argue that those who steal a service often wouldn't have paid for it anyways.
In reality, some mix of the two is probably the most effective measure.
Number two doesn't work. I login from at least five different devices. You definitely do not want to couple yourself to the hard- and software upgrade cycle of your customers
Get an cell phone number of user and send SMS with one-time password each time he tries to login. Email wouldn't work because it is too easy to share.
But you can see a great decrease in your user count: this thing is REALLY annoying.
The way I prevent users from sharing account information is by prevent multiple logins from one location. So if the user logs in, it will log out all other sessions.
This is relatively easy to do. Associate to each user in the database a field like session_key that is randomly generated on login. Store that session_key in the database AND in a cookie in the users browser, and check that the session keys match. If not, log the user out. Whenever someone else logs in, it generates a new session key, thus inactivating all previous sessions and logs out the user. You can also try keeping track of other information as well, such as the users IP address, etc associated with the session. It's not 100% foolproof, but it prevents most users from sharing accounts.
Log the IP addresses, times and usernames in a database table. Check the database for users that are active from more than one IP on the site, and ban those users.
Or, stop users from logging into an account if there is a session already on the server for that user.
There is no way to prevent this. You can only make it more difficult - But you should consider the downside: Legitimate users get caught in the crossfire. If I were you, I'd simply tackle the source of the problem - The reason you don't want people to share logins - And fix that instead. Make an incentive not to do it. Remove advantages for doing it.
The only way to stop the users from sharing something is to make that something non-shareable (at least not with some serious hacking). But this involves hardware which can be not appropriate for your project. I am talking about hardware cryptotokens, which hold private keys and don't let one copy them. If you give your user such token with the private key inside, the user can pass the token itself to other person, but he can't copy it.
That's simple. Use the 10 to 15 favourite questions and their answers during registration processes. Ask randomly one of them during each login.
now i think it is a combination of several factors if not all that can work
lower the subscription costs
prevent multiple sessions at the same time
use two factor auth
if app disable screen shots...make too much content on single pages to make it tiresome for someone to scroll down taking screen shots..disable screen recording if possible.....offcose by not giving any permissions
i think considering fingerprint scanning and face recognition hand in hand with device ids can work
lastly consider loading your website in a webview based app for android users
Our clients must pay a monthly Fee... if they don't, what is the best way to block the asp.net software usage?
Note: The application runs on the client own server, its not a SaaS app...
My ideas are:
Idea: Host a Web Service on the internet that the application will use to know if the client can use the software.
Issue 1 - What happen if the client internet fails? Or the data center fails?
Possible Answer: Make each web service access to send a key that is valid for 7 or 15 days, so each web service consult will enable the software to run more 7 or 15 days, this way the application will only be locked after 7 or 15 days without consulting our web service.
Issue 2 - And if the client don't have or don't want to enable internet access to the application?
Idea 2: Send a key monthly to the client.
Issue - How to make a offline key?
Possible Answer: Generate a Hash using the "limit" date, so each login try on software will compare the today hash with the key?
Issue 2 - Where to store the key?
Possible Answer: Database (not good, too easy to change), text file, registry, code file, assembly...
Any opinion will be very appreciated!
Ah, the age old issue of DRM. And that's what you're talking about here. Frankly, the fundamental answer to your question is: you can't. No matter what you do to the system, it can be hacked and modded in such a way that your DRM authentication scheme can be bypassed and/or broken.
This is a fundamental fact of software development: it can and will be pirated.
So, the answer to your question is that you will have to trust the client to pay you the fees you determine to be correct (which is the whole point of contracts in this situation).
Any other actions you take are a hardship and annoyance on your paying customer, and has the potential to erode your customer base.
Now, if you want control of your software in the nature described, then do not provide it to users to run on their own servers. Force them to be SaaS. In that way, you control all of that. But this is the only way.
Something that you don't appear to be thinking about, but I have seen networks which do not allow any type of "dial home" solutions, as a majority of the systems were internally focused and thus these internal servers were NOT allowed to contact the outer internet. At all. It was deemed a security risk to even allow them access. How would you handle those networks?
Frankly, if I was the customer, and I paid my fees to license your software (which I installed on my own device) I would be irate if I had to allow that device access to the internet in order for it to work. Doubly so, if the software in question was any type of financial management, customer management, HR management, quality management, inventory management, sales, or just anything related to my business, customers or employees. I don't trust software developers enough to have their software talk to something else when my business-relevant data is held in their software.
In the end, what you are describing is an antagonistic approach to take with your paying customers. If you don't believe me, look at the comments that UbiSoft is getting for their latest customer-hating DRM scheme.
IMO, you have two good paths here:
Go SaaS
Ensure your contract has a
bite for non-payment
usually you provide an scrambled key that includes a valid authorization token and the expiration date through which service is paid. Then the installer will use this to "activate" your software. Not sure how this would be viewed if you have 1-2 week periods. you'd want to warn them about upcoming expiration. Also not sure how to tell if they've set their own clock back.
In short, nothing will be perfect.
I've dealt with this before and its not possible to make a perfect system. There are risks in anything you do. The best thing is to weigh your options, and determine the method that has the least likelihood of being hacked and the most likelihood of working correctly and easily for the customer.
Like others have said, they could change their clock and invalidate the license checking mechanism. If you didn't trust the user, you could make the license system connect to your servers. You would then need to ensure that they always have a connection to your servers to check the license.
What if there is a valid reason that they cannot access your server?
Their internet connection has a problem.
YOUR internet connection has a problem.
In that case, should you disable the application? Probably not. But then again, what if they shut down the connection on purpose? Then you would WANT to disable the application.
If you give them a monthly key, you're adding a monthly annoyance and you may lose a customer after a while (people tend to do business with those who make it easy).
For example: If you base it on their clock, and the application needs their clock to be accurate for some reason, then its unlikely that the customer will change their clock.
I agree with Stephen but ultimately, I think that your contract is your best ally here.
As been previously mentioned, you don't want to inconvenience customers, especially if you have a large deployment.
As for SaaS, if I were a customer using your product and you said that the model is changing and we need to access the software from your server and ours must be decommissioned, I'd not be happy. I'd probably use the opportunity to switch packages.
In corporate settings, the contract really is the best way to handle these issues. I've worked on licensing issues for desktop and ASP.NET applications and they can cause a number of headaches for both you and your client.
However, if you insist on using something like this I suggest you go with a middle ground. Instead of only unlocking the application for a week or two, provide a license for 6 months or a year. This way, if you run into licensing issues (and you will run into issues) they only occur once a year rather than a couple of times per month. That will be cheaper for you in support and your clients will be less unhappy about dealing with licensing issues. If the company stops paying and you need to terminate the license you can handle that on a one-off basis, using contract enforcement as needed.
On the web service or client license options, I think a good license system would incorporate both. A client license to provide a the application a stable license and a web service to generate and deliver the license key when it is time for the application to be renewed. If the client won't allow the application to call home to get the license key also provide a manual entry method.
If you are going to store a license on the client, do not try to build a component yourself. There are many components available which will be much more robust and reliable than the one you build. There is a .NET .licx-based licensing method and a number of 3rd party methods that you can use. Which one is most appropriate depends on your scenario: how flexible you want the license and what other options you need. Most importantly, find something reliable - any time your customers spend fixing problems caused by licensing is non-productive for them and will reflect poorly on the application.
The important thing to keep in mind is that no system is fool proof. If your application is valuable, someone is going to figure out how to steal it. But at the corporate level and with custom software it's more likely the licensing will be used to remind people to pay rather than stop wholesale piracy.
I'm about to get finished developing a windows application which I want to release as shareware. It was developed in C# and will be running on .Net 3.5+ machines.
To use it the user will have to be online.
My intent is to let the user try it for 30 days and then limit its functionality until a registration is purchased.
The installer will be made available via an msi file.
Could anyone give the general steps on how to implement this?
Here are some more specific questions:
Since I am trying to avoid having to invest a lot upfront in order to establish an e-commerce site, I was thinking of a way to just let the user pay somehow, while supplying his email in which he then receives the unlock key.
I found some solutions out there like listed here:
Registration services
I am still not sure, if they are the way to go.
One of my main concerns is to prevent the reuse if a given serial, e.g. if two users run the program with the same serial at the same time, this serial should disabled or some other measure be taken.
Another point is, that my software could potentially be just copied from one computer to the other without using an installer, so to just protect the installer itself will not be sufficient.
Maybe someone who already went though this process can give me some pointers, like the general steps involved (like 1. Get domain, 2. Get certain kind of webhost ....) and address some of the issues I mentioned above.
I'm thankful for any help people can give me.
I don't have a useful answer for you, but I did have a couple observations I wanted to share that were too large to fit in a comment. Hopefully someone else with more technical expertise can fill in the details.
One of my main concerns is to prevent the reuse if a given serial, e.g. if two users run the program with the same serial at the same time, this serial should disabled or some other measure be taken.
To ensure that two people aren't using the same serial number, your program will have to "phone home." A lot of software does this at installation time, by transmitting the serial number back to you during the installation process. If you want to do it in real time, your application will have to periodically connect to your server and say "this serial number is in use."
This is not terribly user friendly. Any time that the serial number check is performed, the user must be connected to the Internet, and must have their firewall configured to allow it. It also means that you must commit to maintaining the server side of things (domain name, server architecture) unchanged forever. If your server goes down, or you lose the domain, your software will become inoperative.
Of course, if a connection to your service specifically (rather than the Internet in general) is essential to the product's operation, then it becomes a lot easier and more user friendly.
Another point is, that my software could potentially be just copied from one computer to the other without using an installer, so to just protect the installer itself will not be sufficient.
There are two vectors of attack here. One is hiding a piece of information somewhere on the user's system. This is not terribly robust. The other is to check and encode the user's hardware configuration and encode that data somewhere. If the user changes their hardware, force the product to reactivate itself (this is what Windows and SecuROM do).
As you implement this, please remember that it is literally impossible to prevent illegal copying of software. As a (presumably) small software developer, you need to balance the difficulty to crack your software against the negative effects your DRM imposes on your users. I personally would be extremely hesitant to use software with the checks that you've described in place. Some people are more forgiving than I am. Some people are less so.
The energy and effort to prevent hacks from breaking your code is very time consuming. You'd be better served by focusing on distribution and sales.
My first entry into shareware was 1990. Back then the phrase was S=R which stood for Shareware equals Registered. A lot has changed since then. The web is full of static and you have to figure out how to get heard above the static.
Here's somethings I've learned
Don't fall in love with your software. Someone will always think it should work differently. Don't try and convert them to your way of thinking instead listen and build a list of enhancements for the next release.
Learn how to sell or pay someone to help you sell your stuff
Digital River owns most of the registration companies out there
Create free loss leaders that direct traffic back to you
Find a niche that is has gone unmet and fill it
Prevent copying: base the key on the customer's NIC MAC. Most users will not go to the trouble of modifying their NIC MAC. Your app will have a dialog to create and send the key request, including their MAC.
The open issue is that many apps get cracked and posted to warez sites. Make this less likely by hiding the key validation code in multiple places in your app. Take care to treat honest users with respect, and be sure your key validation does not annoy them in any way.
Make it clear that the key they are buying is node locked.
And worry about market penetration. Get a larger installed base by providing a base product that has no strings attached.
cheers -- Rick
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
This might be more of a serverfault.com question but a) it doesn't exist yet and b) I need more rep for when it does :~)
My employer has a few hundred servers (all *NIX) spread across several locations. As I suspect is common we don't really know how many servers we have: more than once I've been surprised to find a server that's been up for 5 years, apparently doing nothing but elevating the earth's temperature slightly. We have a number of databases that store bits of server information -- Puppet, Cobbler, Nagios, Cacti, our load balancers, DNS, various internal spreadsheets and so on but it's all very disparate, incomplete and overlapping. Maintaining this mess costs time and money.
So, I'd like to come up a single database which holds details of what each server is (hardware specs, role, etc) and replaces (or at least supplies data for) the databases mentioned above. The database and web interface are likely to be a Rails app as this is what I have most experience with. I'm more of a sysadmin than a coder.
Has this problem already been solved? I can't find any open source software that really fits the bill and I'm generally not too keen on bloaty, GUI vendor-supplied solutions.
How should I implement the device information collection bit? For instance, it'd be great to the database update device records when disks are added or removed, or when the server serial number changes because HP replace the board. This information comes from many different sources: dmidecode, command-line disk tools, SNMP against the server or its onboard lights-out card, and so on. I could expose all this through custom scripts and net-snmp, or I could run a local poller that reported the information back to the central DB (maybe via a RESTful interface or something). It must be easily extensible.
Have you done this? How? Tell me your experiences, discoveries, mistakes and recommendations!
This sounds like a great LDAP problem looking for a solution. LDAP is designed for this kind of thing: a catalog of items that is optimized for data searches and retrieval (but not necessarily writes). There are many LDAP servers to choose from (OpenLDAP, Sun's OpenDS, Microsoft Active Directory, just to name a few ...), and I've seen LDAP used to catalog servers before. LDAP is very standardized and a "database" of information that is usually searched or read, but not frequently updated, is the strong-suit of LDAP.
My team have been dumping all out systems in to RDF for a month or two now, we have the systems implementation people create the initial data in excel, which is then transformed to N3 (RDF) using Perl.
We view the data in Gruff (http://www.franz.com/downloads.lhtml) and keep the resulting RDF in Allegro (a triple store from the same guys that do Gruff)
It's incredibly simple and flexible - no schema means we simply augment the data on the fly and with a wide variety of RDF viewers and reasoning engines the presentation options are enless.
The best part for me? no coding, just create triples and throw them in the store then view them as graphs.
The collection of detailed machine information is a very frustrating problem (many vendors want to keep it this way). Even if you can spend a large amount of money, you probably will not find a simple solution to this problem. IBM and HP offer products that achieve what you are seeking, but they are very, very, expensive, and will leave a bad taste in your mouth once you realize that probably all you needed was 40-50% of the functionality they offer. You say that you need to monitor *Nix servers...most (if not all) unices support RFC 1514 (windows also supports this RFC as of windows 2000). The Host MIB support defined by RFC 1514 has its drawbacks however. Since it is SNMP based, it requires that SNMP be enabled on the machine, which is typically not the default for unix and windows machines. The reason for this is that SNMP was created before the entire world was using the Internet, and thus the old, crusty nature of its security is of concern. In many environs, this may not be acceptable for security reasons. However, if you are only dealing with machines behind the firewall, this might not be an issue (I suspect this is true in your case). Several years ago, I was working on a product that monitored hundreds of unix and windows machines. At the time, I did extensive research into the mechanics of how to acquire detailed information from each machine such as disk info, running processes, installed software, up-time, memory pressure, CPU and IO load (Including Network) without running a custom client on each machine. This info can be collected in a centralized fashion. As of three or four years ago, the RFC-1514 Host MIB spec was the only "standard" for acquiring detailed real-time machine info without resorting to OS-specific software. Sun and Microsoft announced a WebService based initiative many years ago to address some of this, but I suspect it never received any traction since I cannot at the moment even remember its marketing name.
I should mention that RFC 1514 is certainly no panacea. You are at the mercy of the OS-provided SNMP service, unless you have the luxury of deploying a custom info-collecting client to each machine. The RFC-1514 spec dictates that several parameters are optional, and if your target OS does not implement it, then you are back to custom code to provide the information.
I'm contemplating how to go about this myself, and I think this is one of the key pieces of infrastructure that not having around keeps us in the dark ages. Hopefully this will be a popular question on serverfault.com. :)
It's not just that you could install a single tool to collect this data, because that's not possible cheaply, but ideally you want everything from the hardware up to the applications on the network feeding into this thing.
I think the only approach that makes sense is a modular one. The range of devices and types of information is too disparate to come under a single tool. Also the collection of data needs to be as passive and asynchronous as possible - the reality of running infrastructure means that there will be interruptions and you can't rely on being able to get the data at all times.
I think the tools you've pointed out form something of an ecosystem that could work together - Cobbler can install from bare-metal and hand over to Puppet, which has support for generating Nagios configs, and storing configs in a database; for me only Cacti is a bit opaque in terms of programmatically inserting new devices, templates etc. but I know this is possible.
Ultimately you have to sit down and work out which pieces of information are important for the business you work for, and design a db schema around that. Then, work out how to get the information you need into the db, whether it's from Facter, Nagios, Cacti, or direct snmp calls.
Since you asked about collection of data, I think if you have quite disparate kit (Dell, HP etc.) then it makes sense to create a library to abstract away as much as possible the differences between them, so your scripts just make standard calls such as "checkdiskhealth". When you add new hardware you can add to the library rather than having to write a completely new script.
Sounds like a common problem that larger organizations would have. I know our (50 person company) sysadmin has a little access database of information about every server, license, and piece of hardware installed. He's very meticulous, but when it comes time to replace or repair hardware, he knows everything about it from his little db.
You and your organization could sponsor an open source project to get oyu what you need, and give back to the community so that additional features (that you may not need now) can be developed at no cost to you.
Maybe a simple web service? Just something that accepts a machine name or IP address. When the service gets input, it sticks it in a queue and kicks off a task to collect the data from the machine that notified it. The nature of the task (SNMP interrogation, remote call to a Perl script, whatever) could be stored as part of the machine information in the database. If the task fails, the machine ID stays in the queue and the machine is periodically re-polled until the information is collected. Of course, you also have to have some kind of monitor running on your servers to notice that something has changed and send the notification; hopefully this is easily accomplished with whatever server monitoring software you've already got in place.
There are some solutions from the big vendors for managing monstrous sets of machines - such as some of the Tivoli stuff from IBM. That is probably, however, overkill for mere hundreds of machines.
There are some free software server database solutions but I do not know if they provide hooks to update information automatically from the machines with dmidecode or SNMP. One I heard about (but no personal experience, sorry), is GLPI.
I believe you are looking for Zabbix. It's open source, easy to install and use.
I've installed for a client a few years ago, and if I remember right it has a client application that connects to the zabbix server to update it with the requested information.
I really recommend it: http://www.zabbix.com
Checkout Machdb Its an opensource solution to the problem you are describing.