For my current application I use a very simple scheme to register new users. When a new user registers an email is sent with a key. To check wether this key is correct a kind of checksum is computed (3-7-11 digit check) which is added as the last 2 digits of the key. There is no check on any further validity of the key. The application does not check whether the key got invalidated.
It is a simple scheme and someone took the time to crack it by deassembling the code. I want to use another scheme for my new application but I am not sure what is the best way to do this.
Is there a Delphi library I could use?
Is it advisable to use some user supplied info in the key, like his name?
Is there a best practice way of registering users?
Anything else I have forgotten?
Some registration schemes require an application to check each time at a webserver whether the key is still valid. I'd rather not go that far because this requires a lot of effort on the server side.
Any suggestion or link for a robust way to register new users is very welcome.
A better registration scheme is based on asymmetric cryptography (usually RSA algorithm). The idea is that only you can generate a valid key, while everybody can check that a key is valid (asymmetric cryptography allows this trick). So when you see your program with a valid key on torrents you just cancel support for a customer who was given this key.
There are Delphi and non-Delphi libraries (i.e Protexis) available to protect your software - remember that almost anything that works with C can work with Delphi as well. But a sound copy protection scheme may be hard to achieve. A simple key may not work, usually it used together a machine fingerprint to allow it to be used on given system only.
A good key generator algorithm should generate keys that are not easily predictable, yet can be checked if valid. There are different ones around, there is not a "generic" one, depends on your needs, some may also include what features to activate or expiry informations. Some keys can be strings, other can be whole license files (as those used by Delphi itself). Anyway code can be disassembled to try to guess the algorithm, some techniques to obfuscate it and make it harder to understand can be used.
Also, one simple key check is not enough because it can be easily bypassed patching the executable. If you really need copy protection, you should scatter checks all around the code, maybe encrypting and then decrypting data or code sections using the key - it won't protect you against keygen, anyway and will require more code changes, it's not as simple as calling one function at startup.
The level of protection is up to you. If you need just a simple registration mechanism and you don't mind much about your software being cracked you can use a simple one. If you need a more secure one then there are more sophisticated one.
If your goal is to force people to download a cracked EXE from the Internet instead of a key generator from the Internet, then asymmetric cryptography is your answer.
If your goal is to be able to void serial numbers that have been released to the wild, restrict the number of installations, or force the user to have a real "paid for" serial number, then activation is your answer. Still, if they crack your EXE, they can get around this.
You only have control up to the point that someone cracks your EXE. We have to accept this and move on. We must figure out other ways to reach out to our customers, such as more affordable versions, value added support options, web services, and other ways that convince the user that the price of our software is fair, and there is a benefit in paying.
On my latest release, I use activation, so the serial numbers are randomly generated, though checked for uniqueness, and associated with an email address.
After all of this, the application is just $4.99, but with no individual support. The goal is to make it so affordable that if they want to use it, even just once, it's a good value.
We've been using Oreans' WinLicense for two years and are quite happy with it. They handle key generation (with the user name embedded), trial versions that time-out, hardware keys (where the key you send them is unique for their computer) and VM detection. They also use a variety of other techniques to make it harder for your code to be disassembled, including wrapping code of your choice in an encrypted VM they provide.
You can also disable specific keys if you determine that they are "stolen." Having done this, future updates you supply will no longer run with those keys.
We also have our software "phone home" at certain times to see if their key is stolen.
Any protection scheme can be broken by someone who is determined and skilled enough. But, we've been happy with the degree of security we believe that WinLicense gives us. Their support is also excellent. The library is callable from Delphi.
Related
I have a requirement (pending) that allows the user to buy "credits" and then to trade those credits for real goods or services.
This is the first time I have had to do this in an application and I am concerned it would paint a target on my database's back. A hacker could (in theory) change the amount of credits a user has and then "spend" those credits, or convert them to cash.
I'm building the solution in ruby/rails, but I am not limited to this tech. I can even use an outside provider if it's more practical.
Does anyone have any suggestions on how to do this? Would you encrypt your DB? Would that be enough?
There are a lot of different things to consider. When it comes to matters of security, there is never a silver bullet (anyone who suggests that is likely selling snake oil); rather, security often involves many different steps to mitigate and manage risks and also redundant layers of protection so that one is still protected if some subset of those layers fail for whatever reason.
In terms of storing monetary transactions, there are often a number of legal regulations that need to be followed, so I suggest consulting those in addition to other security measures. In terms of encrypting the database, there are many different ways to apply encryption... one can encrypt the database as a whole or individual rows of the database using different keys. If you just encrypt the database as a whole, it won't provide you much protection if someone has access to the key (which also begs the question of who has the key, where is it stored, etc.?). What you probably want, in addition to the database itself, is a write-only log of transactions with some sort of checksumming so that you can be assured of its authenticity that provides you with an audit trail that is independent of the database (and from which the database could be reconstructed in the event of some sort of breach). In addition, you'll want to ensure that only authorized applications (such as your production instance of your frontend server) can talk to and decrypt the database (and ensure that only a very limited number of people you trust can deploy new versions of those, so that no one can arbitrarily deploy malicious versions that abuse that access). If it's possible to independently encrypt individual rows with different keys (e.g. to encrypt each per-user row with key material derived from the user's login credential), then that is highly advisable (though this is not always possible to do, such as if you need to be able to process that row even when the user is not actively interacting with your application). I'm sure there are other things that I have not thought of, which is why you'll also want to regularly conduct penetration testing to check for any vulnerabilities (and not only fix anything you discover this way, but also use it to inform projects or processes that you can employ to prevent similar vulnerabilities in the future).
In addition to the security considerations, monetary transactions is one of the few cases where "eventual consistency" doesn't really work; you'll need to make sure that you are careful in your programming to make transactions appropriately atomic. That is, you wouldn't want the number of credits to decrease at a separate time step from the dispension of dollars, as that would allow the same credits to be spent twice... you'll want to be very careful in your coding that the decrease in credits and increase in dollars (or vice-versa) happen simultaneously. For this and other reasons thorough testing and good code review practice is a good idea.
I'm putting together an iOS/Mac library that I intend to open source. Part of the library vends data which client applications are likely to want to persist. The data is a mix of insensitive and sensitive. I've been trying to work out the best way to handle this divide. I've considered a few options, but they all involve trade offs I'm unhappy with. Are there any typical best practices for this situation?
Some background:
The class which stores this data is serializable via the NSSecureCoding protocol, but I only serialize the insensitive data.
Objects are still valid if the sensitive information goes missing, though clients of the library would need to take the user through an authentication process again.
Options I've considered:
Read and write to the keychain automatically in -initWithCoder: and -encodeWithCoder:. This puts the least burden on the client, but is arguably "surprising" behavior. I've largely rejected this option, but I'd be happy to be talked back into it.
Include an API to save and retrieve the sensitive information. This is what I currently have implemented and it works well for simple cases. It does put a burden on clients to remember to send these messages, though, which I find somewhat inelegant.
Include an API to serialize/deserialize the sensitive information in a form which the client can store in the keychain on its own. This puts the most burden on the client, and is even less elegant, but also provides the most flexibility in how the sensitive information is stored (keychain groups, etc). Of course it also allows client code to mishandle the sensitive information - but I'm not sure it's up to my library to enforce proper storage.
I implemented #1 first, switched to #2, and am currently mulling over switching to #3. I'm also sure there are other options I haven't considered. Is there an established best practice for this sort of thing (that I just haven't figured out the right search terms to find)?
Why should we not store the passwords or keys for encryption in source code for an iPhone App?
Is there any possibility for people to reverse engineer code and find the stored keys? or if the hard code values are stored in a location which is easily accessible?
If you store keys in source code, yes they can be reverse engineered. You can make this even harder by making the key "generated" through a generator function but this is still an extra level of obfuscation. A really motivated attacker can get through that. Another drawback of this approach is that the same key will work on all instances of your application, unless the generator function generates a key deriving from some hardware constants.
Again, you have to do an analysis of how secure you want your application to be and how much effort you want to put into security. Security is always a trade off. It is not worthwhile to spend a lot of effort on security, when the probability or cost of an attack are extremely unlikely.
A more secure approach would be to create a random key and then store it in a secure storage on the device. I am not terribly familiar with the iOS Api and if such functionality is offered. On Windows there is something called DPAPI that provides this, for example.
Anything that gets into users' hands is accessible. Obfuscation of keys does part of the work, but doesn't eliminate the problem completely.
Hi i would like to know best encryption technique for text file encryption and ecryption.
My Scenario:
I have software having two type of users Administartor and Operators. Our requirement is to encrypt text file when Administrator enter data using GUI and save it. That encrypted file would be input for Operator and they just need to select it and use that file. Here file should be automatically decrypt data for further calculation when Operator select those files.
Please help me which encryption/ decryption technique should i use?
A golden rule when doing crypto is to understand that cryptography as a whole it is very difficult.
There are a multitude of different approaches/algorithms to choose from, and no single algorithm/method can be said to be the best one. It all depends on your needs and possibilities to affect application distribution etc.
An example of a potentially problematic situation is that in your scenario the decryption "key" needs to be distributed with the application(s) and might make it insecure. This is generally referred to as the "Key Distribution" problem.
A good place to start reading about crypto is http://en.wikipedia.org/wiki/Cryptography.
As for ready made stuff for Delphi there are a few good packages available:
DEC v5.2 - http://blog.digivendo.com/2008/11/delphi-encryption-compendium-dec-52-for-d2009-released/
DCPCrypt - http://www.cityinthesky.co.uk/cryptography.html
Torry's pages also has a long list of components:
http://www.torry.net/pages.php?id=519
http://www.torry.net/pages.php?id=312
I strongly recommend you use some of the existing implementations and not start to do your own, since creating a secure working crypto algo is very very difficult.
When moving an encryptet message from place/appliction to another, one of the problems you have to consider is where to store the encryption/decryption keys.
As i se your scenario, it seems like it is build in your applications. If so remember to use al sorts of tricks to hide it: Password strings should be split in several bits and onlys appended in a protected memoryspace, that has to be marked as non-pageable (else password could be seen in the pagefile).
The same rules for the content that is unencrypted (the text-file). It's best that it never is saved (even temporaly) unencrypted to disk. If it is saved, the overwrite the date with garbage after use, before deleting it.
Another approch (specialy if you already use compression components), is that the (text) file, can be compressed using a password.
Truthfully, there is no "best" technique. It basically depends on the sensitivity of the data you're trying to protect and the number of people who might access this data. What might be "best" for me might be pure overkill for your project.
In your case, you could use any dual-key encryption method. Or asymmetric key. Basically, the administrator has one key and the operator has the other. The administrator can then encrypt files, but he won't be able to decrypt them again, unless he has an operator key. The operator can decrypt the file and -if need be- encrypt a file that only an administrator can access. (Asymmetrical keys encrypt in both ways.)
There are several solutions that make use of these asymmetrical keys. The one that would be best is the one that you could add to your project in the easiest way while still offering enough protection for your needs.
Building your own asymmetrical key algorithm is possible too, if you're a real Math Wizard. The calculations are complex and involve extremely high prime numbers in most solutions. As K. Sandell said, find a good, existing solution that matches your needs in the best way.
I want to store large files (videos, sounds) and access them via Database. I am balancing now between filesystem (references to files would be stored in DB) and pure DB (which could be enormously large after time).
I have to protect the content too, so I thought, that DB solution suits better for this purpose. (probably it is not a good idea).
On the other hand I have got hint to encrypt files to protect them, if I choose to use file system.
How should I do this?
P.S
please see the question What database should I choose not to worry about size limit?
P.P.S
Under protection I mean encrypt videofile/soundfile using a crypt algorithm. When the application need to read them, it have to decrypt files...
In that way the stolen files are useless unless appropriate decrypt algorithm is present.
I thought to use RAR secured with password. As far as I know it is very hard to break it, when password is long enough. (Maybe I am wrong).
I am not familiar about MD5....
I can not protect files against theft, but I want to prohibit to read it freely.
One approach would be to create a background process with an elevated security token that would it access a section of the filesystem only available to administrators and that process. On Windows you'd create a "service". They call it "daemon" on *nix, I believe.
That service could then expose an API via pipes, sockets, or a shared memory region where the unelevated, user-mode database tool could get and set files.
There's no way to completely prevent system administrators from accessing a file directly, so if that is a requirement, you're out of luck. On Windows administrators have a special privilege that allows them to take ownership of any securable item such as a file or directory. Once they're owners, they can do anything they want to the securable item. There's just no way around that.
I have implemented both approaches in different projects with different requirements and constraints. And I would strongly recommend to keep all the contents in the database, storing the media files in large blobs. Eventhough that will require very large tables, that should not be a problem for the latest versions of the most well known databases.
I recommend DB2. DB2 since version 9 supports very large tables. The maximum is monstrously large. 512000 petabytes, half a zettabyte.
You need to accept that the choice between storing the files in the database vs. in the file system ultimately doesn't matter much - in both scenarios they can be read trivially from outside, unless there is some encryption. That moves the problem from where to store the data to how to store the secret key to decrypt encrypted data, in your application.
This is a hard problem. There's probably nothing you can develop that can't be cracked by a determined attacker in a rather short time. It depends on the audience of your program whether that's a real concern; if it is, then you can't do much. It takes a single successful crack to access your data and make it accessible to all interested in it. The attacker will go for the weakest part, which isn't the hard-to-break file encryption, but your application.
Use a DB (firebird or -embedded) and keep large content out of it.
If it is encryption you are worrying about, do this at the filesystem level instead of the db level.
All modern OSes have support for encrypted filesystems
There are merits in both approaches.
If you want to have the files separately in the filesystem, I would encrypt each one individually. A password-protected RAR or ZIP file would be as good a method as any.
Use a different password/decryption key for each file, and store the password in the database along with each file name.
The following is suggested without knowing the specifics of your application.
As you mention that you can not protect against theft, just about the only option to make sure the multimedia files are safe (unusable) by anyone other than the "owner" you need to encrypt them using a cipher like AES or BlowFish and a secure secret Key. These algorithms are different from MD5 that you mention. MD5 is a HASH algorithm.
For Delphi a rather good encryption library is DCPcrypt forund at http://www.cityinthesky.co.uk/cryptography.html. If has both HASH and Cipher algorithms.
Your problem will be Cipher KEY Management, namely "What password to use for encryption?". The simplest solution without thinking about this would be to use the users own password, untill you realize that the user may change the password. If the user does that you need to Decrypt and ReEncrypt every single multimedia file associated with the user.
To answer the actual question about key management I'd suggest reading up on key management. As I'm no expert on cryptography I hope someone more versed in the crypto world can help here... Link: http://en.wikipedia.org/wiki/Key_management.
I think it all depends on a few things:
Where do the files come from initially
How will the files be accessed (over the network or locally)
Who do you want to protect the files from
If the initial files come from "you" (the developer) then encrypted database blobs would probably be the best way as most dbs' come with some form of encryption.
If the files come from the user of the software, then using the file system would suffice - possibly using an temporary directory to store and retrieve files if used over the network, but actually storing the files in a non-shared location so that network users don't have access to all the files.
Just a few thoughts.
Local file protection, web project protection, and secure email, Record-level security in databases (DB2, Oracle, Firebird, MS SQ:, My SLQ etc.). Creating encryption systems from primitives etc. Look for File Protect System - SE or SPE or PE.