I have written a POS application, and now i want to create different versions of it. Something like a basic version, a premium version and a Full version. So if a client pays more they get more features in the same application. Is it possible that i could keep one standard application but features in my application get enabled / disabled depending upon what license key user enters. Restrict parts of code that can be executed only if a certain key was entered.
Any ideas guys...
There are many ways to do this, all of them breakable if skilled people are willing to put the time into it ;-) However, depending on the solution you choose, it will require progressively more work in your end, so be realistic and choose wisely.
For the actual license key, I highly recommend that you generate it using a standard public-private key encryption scheme such as rsa. That is, you create a license key text string that contains the name of the user (so you can track illegally shared license keys) and information about which code should be active. Encrypt the license on your end using the private key and distribute the app with the public key included. When the app starts, you read the license key and decrypt it using the public key. This will make it virtually impossible for people to modify or generate fake keys.
Now for the actual activation of code, here are two options I have used in production code: either simply include flags in the license key saying which parts of the code should be active and activate it using basic if then statements. Alternatively, depending on your programming language, you can dynamically load pieces of code from the license key making those parts of the code unusable without a proper key file (I did this in java with a custom class loader).... however, this last solution requires much much more work than the first, so think things through before you start designing your solution.
Related
I work on Labware LIMS, which has both configuration, and customization via its own programming language and internal code editor, and stores this customization code in database records. (Note, not the source code of the actual application itself, just the customization code a.k.a. LIMS Basic.) Almost everything in LIMS is stored in the database.
We want to investigate the possibility of using source control to protect this code but we don't know much more than the theory of using something like Git. (I have worked as a junior QA and used git but not as a dev and my knowledge is limited!)
Of particular use would be the merging tools, as currently we have to manually merge code in a text editor, if we even notice there is a conflict (checking content between dev and live is time consuming and involves using multiple tools, some of which are 3rd party tools we have developed ourselves, which are hit and miss. I personally find it easiest to cut and paste into a text file and then use Beyond Compare.
There is no notification that the code is different when moving it from dev to live (no deployment as such, you just import an xml file) so we often have things going live that someone was working on unbeknownst to each other. I.e. dev 1 is working on the code in object 1, dev 2 gets a ticket to make a change to object 1, does so and puts their change Live, whatever dev 1 was doing is now also Live in whatever state it was in. (Because we don't always have time to thoroughly check what state each object is in between up to 3 different databases.)
Is it possible to use source control just on the code within the database, but not necessarily the database itself? (We have backups and such for that but its easy for some aspects of the system to get overwritten by multiple devs working on overlapping areas at the same time.)
If anyone reading this has any specific knowledge of LW LIMS, we are referring to the Subroutines mostly, we have versioned Analyses which stands in for source control for the moment and is somewhat effective but no way to control who is doing what on the subroutines other than a comment log at the top. I have tried to find any information on how other teams source control their code in LIMS but to no avail.
The structure of one of these tables can range from as simple as the code just existing in one field as a straight text dump with a few other fields such as changed_on, changed_by and name (Subroutines), or more complex with code relating to one record being sprinkled around in multiple rows on another table entirely (Analyses) but even if it could just deal with the simple scenario to start with that would be great!
TL;DR: Could the contents of the Code field in a database record be treated like a regular code object in other dev environments somehow and source controlled using Git? (And is anyone willing to explain it simply for me to follow?)
As you need to version control table fields of subroutine, but LW LIMS doesn’t have the IDE for version control (such as git, svn etc). So the direct answer is no.
If you really want to do version control for the codes in database, you can create a git repository and only put the codes in git repository. when a file has updated, you can commit & push the changes. And it’s easy to compare the difference between versions.
More detail about git, you can refer git book.
LabWare LIMS has a number of options for version control. You COULD version the Subroutine table by adding a SUBROUTINE.VERSION field to the table, this works the same way as other versioned tables in LabWare where it asks you if you would like to create a new version of the object before saving. There are a few customers I work with that have done this.
Alternatively, (and possibly our more recommended method prior to LEM) there is the Snapshot capability where the system automatically takes a "snapshot" of objects as they are saved - when viewing these you have the ability to view them side by side in a comparison dialogue - it will show < or > for lines which are different.
Another approach is, if you have auditing turned on you are able to view the audit history for changes to specific objects - this includes subroutines.
One other approach is to use configuration packages - this has the ability to record version AND build numbers. Though individual subroutines is probably a bit too granular for it's intended design.
Lastly, since this question was originally posted we have developed a product called LabWare Environment Manager (LEM) which has some good change control functionality built-in.
For more information on the suggestions above, please have a look at the LabWare Technical manual for the version you are on. We also have a mailing list for questions like this to be posted. You might find an answer there. If you have access to our Support webpage you're able to search previous questions that have been asked. I'd also suggest that you get in touch with your Account Manager at LabWare who can help you answer some of your questions.
HTH
I successfully managed to create a SQLite3 DB with Perl using Perl::DBI module.
I was wondering if there was a way to add encryption to the database to my existing Perl code ?
I read thoroughly the 2 following links :
Password Protect a SQLite DB. Is it possible?
SQLite with encryption/password protection
but the provided examples seem only to include proprietary software or C# code (especially this bit here https://stackoverflow.com/a/24349415/3186538).
Thanks in advance.
Well, you could run your data through any of the Crypt::* modules (::DES, ::Blowfish, ::IDEA, etc, in conjunction with ::CBC), then possibly encode it with base64 to get text, before writing it to the DB. And, of course, reverse the operation when reading. You could even create a Perl::DBICrypt module that sat above Perl::DBI and did this automagically.
However, it depends pretty much on how you're going to use it. If you're just worried about someone stealing and using your data, the encryption would be feasible since, without the key, it would be useless.
On the other hand, if you're trying to protect data in a system you distribute, then the key will be available to the attacker (since, without it, your code won't work). So encrypting in that case would be a minor inconvenience at best.
It's something that could only really work if you kept the key away from the attacker (such as if the Perl code runs in an app server controlled by you).
Basically any solution that decrypts data on a box accessible to an attacker will be vulnerable.
I'm building a Windows Store application that uses SQLite for data storage. I have found out, that the database is easily accessible through User's local folder (actually all apps have all data publicly exposed). Is there a way to at least weakly protect the database from access?
you need to look at ProtectedData class
http://msdn.microsoft.com/en-us/library/windows/apps/windows.security.cryptography.dataprotection.dataprotectionprovider.aspx
It exposes easy to use Protect / Unprotect methods that can be used to encrypt / decrypt that at app level. Encrypt data before writing to db and unencrypt before consuming
I also looking for the same solution and found sqlite-crypt at http://sqlite-crypt.com/download.htm
I don't know whether this one good enough or not. There is a trial version that limit passphrase to 6 characters and store it as plain text in the header. It won't be suitable if you want complete data protection. But for testing, maybe it's worth a try. I don't have a chance to test it yet since I still working on the server side of my project. I'll update it when I've test it in the future.
EDIT: Ok. I've test the trial version and it's worked well with modificated version of SqliteWinRT wrapper on codeplex. Note that the trial is limited to 5-6 characters of passphrase and this phasephrase is stored in plain text, plus it's in x86 compiled binary, which means it won't work for actual product which need ARM support. You have to purchase the binary to get the production-ready binaries.
I am implementing an automatic update feature and need some advice on how to do this securely using best practices. I would like to use the downloaded file's Authenticode signature to verify that it is safe to run (i.e. originates from our company and hasn't been tampered with). My question is very similar to question #2008519.
The bottom-line question: what's the best, most secure way to check Authenticode signatures for an automatic update feature? What fields in the certificate should be checked? Requirements being: (1) check signature is valid, (2) check it's my signature, (3) old clients can still update when my certificate expires and I get a new one.
Here's some background information / ideas from my research: I believe this could be broken into two steps:
Verify that the signature is valid. I believe this should be easy using WinVerifyTrust as outlined in http://msdn.microsoft.com/en-us/library/aa382384(VS.85).aspx - I don't expect problems here.
Verify that the signature corresponds to our company, and not another company. This seems to be a more difficult question to answer:
One possibility is to check some of the strings in the signature. Could be obtained via code at MS KB article #323809, but this article doesn't make recommendations on what fields should be checked for this type of application (or any other, for that matter). Question #1072540 also illustrates how to get some certificate info, but again doesn't recommend what fields to actually check. My concern is that the strings might not be the best check: what if another person is able to obtain a certificate with the same name, for example? Or if there's a valid reason for us to change the strings in the future?
The person at question #2008519 has a very similar requirement. His need for a "TrustedByUs" function is identical to mine. However, he goes about doing the check by comparing public keys. While this would work in the short-term, it seems like it won't work for an automatic update feature. This is because code signing certificates are only valid for 2 - 3 years max. Therefore, in the future, when we buy a new certificate in 2 years, the old clients wouldn't be able to update any more due to the change in public key.
The person at question #2008519 has a
very similar requirement. His need for
a "TrustedByUs" function is identical
to mine. However, he goes about doing
the check by comparing public keys.
While this would work in the
short-term, it seems like it won't
work for an automatic update feature.
This is because code signing
certificates are only valid for 2 - 3
years max. Therefore, in the future,
when we buy a new certificate in 2
years, the old clients wouldn't be
able to update any more due to the
change in public key.
Since the concern is that the application trusts you rather than that a person trusts you, you could just use self-signing and embed any public keys needed in the applications themselves. This gives you much more control over the process. This is inappropriate when asking a user or application not under your control to give trust, but in this case the application is under your control, so it will work fine. This allows you to very easily avoid the concern of mistaking someone else's similar-looking certificate for your own.
For Windows.Forms, I have an application that needs to get a unique install id for each install from my server, and then persist this data so once registered, the install ID is included on all communications back to the server. The application is in occasional contact with the server.
How can I persist this data on the client in a way that is not easily tampered with?
First, you should note that if the data is on the local file system and your application can read and write it, it will always be possible for a determined user to tamper with it... perhaps not easy, but possible nonetheless.
That said, there are a number of options you could consider, including (but not limited to) :
encrypting the data with a key defined in your assembly : pretty safe is the user has no programming skills, but an advanced user could disassemble your app to find the key. Obfuscation could make it harder to extract the key, but not impossible.
using an isolated storage : I'm not sure whether the data is encrypted or not, but at least it's not easily found, hidden in a deep folder hierarchy... Not so safe is the user knows where to look, however
writing the data in a binary format, which makes it harder to read or modify for a non expert user
using a piece of native code to encrypt the data : similar to the first option, but a native DLL is harder to disassemble than a .NET assembly, so it requires more skills to find the key
Again, all these approches are not bulletproof : as long as your program can access the data, an advanced user could always reverse engineer it and do the same...
You could save the data in the windows registry. You'll use the [HKCU\Software\YourAppName] hive key if it's a per-user setting, or [HKLM\Software\YourCompany] if it's a global setting. However, the data would need to be encrypted, because its trivila to get the values in these keys