we have created an application like adobe reader to read a special encrypted document file format which does recognize only by our application.
what we want to do is to let user buy the application using his/her account from a website & after that we'll let him/her download that document using this program and start reading it.
here is our concerns:
1) document files should not be read in another user computer which means if user1 gives the raw downloaded file to user2 which has our application in his/her own computer the second user must not be able to read that file
2) after users download their files, they can just read those file offline (not constantly be online to be able to read)
3) this security must not break down easily because these document data are vital & the user information & application must not be hacked and cracked !
4) maybe later we want to have our android/IOS version so the solution must be cross platform
5) solution like providing login mechanism for each document won't work because users are able to give the copy of their own files together with their username & password to other users.
6) file encrypting mechanism must not break down by crackers so that they just decrypt the document & post the free version all around the internet
Do you have any programming method, security mechanism or suggestion ?
You could use public-key (or asymmetric) cryptography. You encrypt the document with the public key of the user. Then only people with access to the private key (ideally: only the user) can decrypt it.
However if the user has access to his own key (and he should), nothing can keep the user from decrypting the document and sharing it with others (or sharing his private key with others).
In the end: if a user, or the program needs access to the unencrypted product and the user has no interest in keeping the document secure, confidentiality can and - if the product is interesting enough - will be broken.
This is the problem with .NET it's easily reversed, because of the executables having a lot of meta data stored and that it does not compile to native (asm), but to IL. Your best bet would be to use an obfuscator and something like .NET Seal (However if I am correct it requires the users to be on the net) http://forum.elitevs.net/
Again you want to go cross platform and for C# to do that you'll have to use something like Mono:
http://www.mono-project.com/Main_Page
Although that would require the end user to also have mono.
Now to answer your "points".
1) Make each file and application share some sort of encryption that is unique to each file and application, making sure that the file only matches for the application one user have ex.
User X downloads the application.
User Y downloads the application.
Both downloads are unique with some sort of encryption algorithm or encryption key.
User X downloads Document A.
Document A will be sharing the same algorithm / key as User X's application which makes it unique to him only.
User X gives Document A to User Y.
As User Y's application does not share the same algorithm / key as User X then the Document is not readable.
2) I will referre to what I said first in my answer.
3) I will referre to what I said first in my answer.
4) I will referre to what I said first in my answer. However I want to point out that it's not entirely a bad idea, but it's something that should be taken into consideration if C# really is the language of choice for this.
5) I will reffere to answer #1 here.
6) I will reffere to answer #1 here.
If you are going to allow the user to download the file, then there is going to be no way to 100% secure it. The reason is, there must be a way to decrypt it so that the user can read it. This decryption process must occur on the user's machine, since the program to read it will have to decrypt it and open it on their machine.
Once the program to decrypt it is running on the user's machine, he can reverse engineer it and hack it (assuming he's clever enough).
That being said, there are many way to make it difficult to crack your decryption. Now if you take away the ability to read offline, you have more control. A hacker cannot run a disassembler or decompiler on your remote server.
Hope this info helps
Related
I am trying to save the username and password of user at c# console application. Hence there will be just one username and password that must be saved (It is like pin code). I don't want to use a Database for this. Using .txt will be irrational because anyone can see and find txt file and enter program.
I tried to use Properties.Resources but because of Resources are read-only, there is no way of changing password at runtime if user wants to change its password.
Properties.Resources.Admin_Mail = Reading;
It gives error because of the reason I mentioned above.
What should I use, I cannot find any suitable way for this problem on the internet.
I am not sure where you are at in your development journey.
You'll need system.io to read and write to the text file. I would give in a different extension then .txt.
https://learn.microsoft.com/en-us/dotnet/api/system.io?view=net-6.0
Consider using a SecureString type in C#
https://learn.microsoft.com/en-us/dotnet/api/system.security.securestring?view=net-6.0
Encrypt the data stored in the file.
https://learn.microsoft.com/en-us/dotnet/standard/security/encrypting-data
Decrypt the users entry to ensure it matches the file.
https://learn.microsoft.com/en-us/dotnet/standard/security/decrypting-data
There is a StackOverFlow link talking at the actually input.
Password masking console application
Sorry for just linking to references instead of a straightforward code answer, but I not sure of your intent and level of security you wish to provide.
Ok this is a question about a concept of coding. I have seen many questions on how to implement a product key and I know how to do that, this question is related to the what, than the how.
Ok here is a backstory on what I am doing and then my question. My app Ultimate Diagnostic Suite, is about ready to roll out for testing. I am wanting to implement a product key (I know how to do this). I am torn between on how to do this.
Product Key: 7FD8-S89D-8746G-HUSJ
Product Key: example#example.com
I know how to do a regular product key, however with the first option, I have a random number generator that can generate the keys for me, then I can add them to a db and check the product key, this is fairly simple to do. The only problem I would have is, if 1 million people downloads the application, then that is 1 million product keys. That would take up more space than the app.
However, if I use the email form of a product key, and a person downloads the application, then it would be digitally signed, and would omit that 1 million line product key file. My question is this:
If I use the email form (digital signing), How would I weed out the spam. Also I know I will have wire up some events for the Authorization. I just need a starting point. This is for the ending after the # symbol, For example:
You would have two textboxes, one textbox will be the txtUser.Text and the other to compare to the text file of email endings will be txtEmailEndings.Text so in short if an email has the ending of:
*#163.com
*#aichyna.com
*#berahe.info
if (txtEmailEndings.Text == dbNotAllowed.Text)
{
messagebox.Show("Please use a valid email, i.e, Gmail, Outlook, AOL");
}
else if (txtEmailEndings != dbNotAllowed.Text)
{
// do something to allow access to full program
}
with the concept of I would have a list of known email endings that are a High Risk of spam bots. I would think this would cut down on the spam bots, however any email can be made for spam bots.
The only other option I would have is a flat fee, which would go back to the Flat Fee = Product Key. With a never ending lines of Product Keys. I do not want to have just one product key for the whole reason, that it can be exploited.
This is not in any particular application such as WinForms or WPF, the concept can be used for both. That is why the tags are listed.
Any questions or comments would be greatly helpful. I am using the concept as digitally signed, the way Microsoft migrated from Product Keys to Digital Signatures.
I would use a json file as license file you send when the user purchases the application which contains a RSA signature inside. Your application would have the public key part of the RSA key and it will use to verify the signature of the license and your server will have the secret key used to sign the license files.
The system is decentralized and will be prone to users leaking license files but you could send a machine identifier to your web api when checking for updates and if you detect a lot of distinct machines sharing the same license guid then you mark the license as inactive.
Store the public key part of the RSA key as base64 so it would be harder to find and replace with a hex editor. Additionally you might want to obfuscate your binaries.
Look at this project: https://github.com/dnauck/Portable.Licensing/blob/develop/README.md
You can protect against spam emails with Recaptcha and email verification.
You can also give out random product keys which are converted by your api into a signed license file. These keys have limited activations (stored on the server side) and are tied to a machine identifier.
What's the smartest way to prevent a textfile (e.g. xml) from being edited by a user?
I need to make sure that the file in which I store the usernames and there privileges for the desktop application can't be simply edited.
Maybe I can generate a certificate of the file and the desktop applications checks this?
I'm using C# in a WinForms app.
You could use File system permissions to prevent editing.
You could use encryption to make editing difficult
You could get a hash value for the file to detect editing.
I think encrypting the file, then decrypting it will be easiest. Though users might still be able to read the contents of the file if they're smart enough. e.g. reading the plain-text from memory
The simplest way is probably to use a database with username and password authentication.
The smartest is to encrypt it so that the data is not available to them.
However, if a user truly wants access to a file on their machine, they will get it. You can make it so that they cannot read anything useful or make useful edits, but if they want to, they will be able to edit the file.
Since your aim is to store users' privileges directly in an XML file, you need a level of security beyond just preventing users from editing the file. Even if you could (hypothetically) impose some restriction at the operating system level against editing the file, any administrative user could just edit the file on a different computer and then overwrite your protected version.
Thus, you have to assume that users can edit the file. The only recourse you have is to be able to identify when they have, and ignore their edits.
The approach you suggest of creating a certificate sounds exactly right. You could either compute a hash for the entire file, or could do so on a user-by-user basis (whichever makes most sense in your context), in either case using a private or secret key to ensure that someone editing the file cannot simply recompute the hash.
IMHO you can not guarantee no one can edit it, but you can encrypt the file to secure the information.
you can not guarantee as any one can boot the machine using disk start up for example and edit the text file simply.
Personally I don't think XML is the appropriate format for storing secure information in this case. The whole point of XML, compared to binary formats, is that it is human readable/editable. Use some kind of encrypted binary format with a known hash/crc that tells you if it's been interfered with if you want total security.
You can use cryptography, but use the DPAPI built into Windows as you will also have to store the encryption key safely, which again is another hassle.
The benefit of using DPAPI is that it uses a key unique to the user or computer, and is never disclosed, even to the programmer! But if you move the file onto another user's profile or computer, it will be unreadable.
If you MUST keep that data in a XML textfile you could consider digitally signing it by your application every time it is modified and checking the digital signature when you read the file.
More details on how to sign XML file and how to verify signature.
But I think it's better to just keep that kind of data in different formats - database, encrypted file, application properties...
I am trying to secure an application to only run from a specific USB disk.
I have code to get the serial number from the device, but the only way I can make this work the way I want to is to manually code the serial number into the binary.
Is there a way I could make a stub application that would modify the existing binary to insert the serial number into it after it's compiled?
I've seen this done in C++ in the past, but that was a long time ago and I cant quite remember how we did it back then.
Storing it in the assembly is a bad idea. Here is what I would do (and have done similar in the past):
Be sure you are signing your assemblies.
Create an XML document that contains your licensing data - in your case the serial number of the USB device.
Utilize the SignedXml library in .NET (implements XMLDSIG) to sign the licensing XML document that contains the serial number. You will use the same private key that is used to sign the assembly.
When your app starts up, it verifies that the signature of the XML file is valid using the public key that it was signed with (and is embedded in the assembly).
Obviously you don't ship your private key, so if the app needs to generate the XML config file itself (rather than it be a file you ship to the user) you will need to implement a web service.
I don't know, but that hasn't stopped me from answering before.
Maybe figure out where you want to store the SN in the executable (it should be only one place, right?) and just treat the executable as a giant binary blob, and use the stub program to insert it where it needs to go?
Perhaps you want to get a separate USB license key like these ones:
http://www.bhphotovideo.com/c/buy/USB-License-Keys/ci/12454/N/4294550039
???
Why would anybody want to save anything inside an executable. If you're planning to sign the executable for distribution changing the executable in some way would break the signing and saving something in binary to the executable won't prevent someone from taking the value out the executable.
Best thing you can do is store the serial number to a file, registry, or other place then encrypt the value so it can't be modified without breaking it. I use a library that ships with License Vault from a fairly new company called SpearmanTech. You can use their library to store encrypted values to the .NET machine.config file in an encrypted form so it can't be tampered with. This way you can pull the information from the .config file when your application starts.
Are you writing a .NET application in C++ or native C++ well either way you should be able to communicate with the .NET framework so this solution would work.
I would check out their product at http://www.spearmantech.com. Hope it works for you.
My company created an application that can send large attachements from one mail recipient to another (because most mailboxes are very limited).
But we were wondering how we can prevent the uploading of warez?
For now all extentions are allowed, but we could restrict the extentions to zip and images.
But if you zip warez you can still upload these.
Are there any tools, methods or something like it to prevent the uploading of warez through our system?
Some more info:
This project is semi-public. It will mostly be used for the communication between customer and company. Therefore an email address of our company is always required (either within the receivers as that of the senders, but you all know how easy it is to manipulate this).
Define what "warez" is first.
I'm pretty sure you're going to have problems with that.
You can probably implement heuristics that figure out that you're sending applications and just ban that, but there's no way you're going to figure out that one application is a pirated copy and another isn't and allow the legal one while ban the pirated one.
If you control the server, and is afraid that people will upload pirated copies of applications onto your server and use it to spread it with, then I'm pretty sure your only option is to check with a lawyer what you're obligated to do.
I think it boils down to that you need a system where copyright owners can inform you of pirated copies being present and that you have a system to remove said content within a time frame. I think that's all that is required.
EDIT
If as you said in your edit, that this is for customers to send stuff to you, then I'd be very careful about the allowed email addresses. Is there anything to stop somebody putting in Distribution Email addresses. e.g. If some naughty person sent a large file to All#YourCompany.com, will it be distributed or will it be blocked
ORIGINAL
If this is an open/public system, then its going to be abused. There are ways to unpack zip files on the fly to check their contents, and even to check the file mimetype headers to perform more restrictions, but it doesn't change the fact that someone might want to legitimately send an AVI file of a presentation, while someone else whats to upload a pirated movie.
If this is for internal use in your company, I'd suggest restricting access in someway (tie the system into your Company LDAP/ADSI system and make users login to the system.
Also putting some file size restrictions in place might be necessary as theres nothing to stop some script kiddie just sending 1Gb Junk Text files around, just to be a nuisance and eating up your bandwidth
You can always just rename, for example, a .rar extension to .jpg and let the downloader know to rename the file to open the "Warez".
There is no way to block it other than to take random samplings, test it your self, and then manually delete whatever it is you don't want.
Short answer: No, you can't.
You could look for filenames from a list, but that will fail (e.g. you might ban "MS Word", but then if someone uplads an innocent "MS Word.doc" you fail. Or if the bad guy renames his exe to "MS W0rd" you fail.
You could look for recognised sequences in the file - that fails as soon as they apply even simple encryption or compression.
You can create user accounts and ban users who misbehave, but this fails because you have to spend a lot of effort policing it and in any case users can just creat multiple accounts using web mail addresses.
My suggestion would be to make this someone else's problem. Get users to upload files to someone elses system (Microsoft SkyDrive, Amazon S3 etc) and then they can worry about the legal side.
What if someone sends a password-protected RAR archive to ensure security of some documents? You can't possibly look inside of it - and you shouldn't - not your business.
For example, we had a couple of times some access right issues with our network. And I needed to install some third-party components on my developer machine. As I was unable to access our repository at the time, I just got the installation package sent to me per email. Now, how can an outsider possibly decide whether a file "SomeCoolComponent.msi" is a warez copy downloaded from the intenet or a 100% legal copy which I have the rights to use?
We once had at university our email account suddenly block all password-protected archives as attachments. You guess what? I didn't stop encrypting them. I stopped using that account.
No - you cannot prevent this with a tool or framework.
You can prevent this by banning / blacklisting users who violate the policy.
Trying to do everything in code isn't always the best idea - sometime a simple "break the rules and you get banned" policy is best.
Assuming you can build decompression support in, you could use this heuristic method to determine whether a given uploaded archive is warez (derived from real world warez distribution methods):
get the filenames contained in the archive
if the archive contains (an .nfo OR a .diz file) and (an exe OR an msi or an archive containing one of the above) block the upload
if the archive contains a series of zip/rars/00X files block the upload
if the file is an exe, check whether it's a SFX and if it's a zip, rar or 7z SFX check the embedded archive
Otherwise just accept the upload, making sure you clearly state in your TOS that the company is not responsible for user uploads.