I am working on a MMORPG game built in java, with this the end user runs a java executable (client) on their system that connects to our game (server).
Sometimes you get some players that are less than nice, and require a ban, some people are however really persistant which require an IP ban, and then there is the third type of people that have above average knowledge of computers and know how to change (or mask using vpn/proxies) their IP.
To combat these last kinds of people, we used to generate a UID file somewhere in their AppData folder with a unique key generated when the client launches (if no file is found it will generate one for them, but the flaw here is that if someone finds this file, they could easily just remove it and on the next start it would recreate a new and different one for them)
A while back I read somewhere that Microsoft generates a "fingerprint" based on several system specifications which is pretty much unique for each system, but on regeneration will result the same key, this is why you can reinstall Windows 10 without ever having to use any serial key. Would a system like this be possible in pure java?
To summarize, we need a unique key for every machine it is being run on (or atleast a very very small chance of a duplicate key being generated), but should the generation code be run again it needs to generate the same key
Related
I have this java program that reads values from a database, and uses those values in each table for creating a schedule.
I do not have a server accessible, so the database will have to be moved around from computer to computer when the program is moved. It will have about 200 tables, each one with a time, number, title, and description.
I have tried using Microsoft Access, but Java 8 just changed some setting so that the program cannot link the Access database, even though there used to be a simple way to do this.
I know about Java DB, but to my knowledge it needs a server to host the database on, same with SQL, and I do not have one to use.
My question is, which program can I use to create a client-side database that can be linked with a java program, without breaking off an arm and a leg.
Thank You for any suggestions.
I am maintaining an existing Java product (which has a HUGE code-base). I discovered that it is setting (and getting) two of its internal passwords as Java system properties, at no less than 4-5 different places (methods). Now, the problem is, the passwords are being stored as plain text in the Java system properties, and so, the same is visible to external entities, as the application is not using any Java Security Manager. For example, if the application (process) is running on port number 1234, we can run the Java command:
jinfo -sysprops 1234
to view both the passwords as values of the corresponding Java system properties. I wish to ask if there is any remedy to this without changing the existing code-base too much? The desired effect would be to "hide" the two Java system properties (denoting the two passwords) from all external entities.
It may be noted that introducing a Java Security Manager into the application may not be a solution, as if we revoke read permissions from the said two Java system properties using the Java Security Manager, the application codes which read those properties would crash. Same is applicable for storing the passwords in encrypted form, as that would crash all codes within the application which are expecting to read the passwords in clear text form.
Since you said:
...at no less than 4-5 different places...
and you really don't want to do major code changes, I would:
Supply the password in an encrypted form.
Go through those 4-5 places (it's not so much!), and call a wrapper method that you have to write separately: MyPassUtil.getXYZPassword() which internally calls the System.getProperty() to get the encrypted password, decrypt it, and return the plain text version to whoever is calling it.
Keep in mind though, that this way, the decryption key and algorithm is stored within the application, and a good Java decompiler (JD-GUI or CFR) will still return this information. In other words, anyone with the access to the JAR file, can still get the information with some minor effort, something which I presume, since one can call jinfo, they can also get the JAR file.
The best is to use some form of keystore, which again, you can easily implement once you do the wrapper method mentioned in step 2, without affecting whoever is using it.
Also, some security tips:
If it's an SSH / SFTP connection, set up SSH keys between the two machines, and eliminate use of passwords.
If it's a database connection, at least configure the DBMS to allow connections only from this particular machine's IP address. If the connection is over the internet and you are behind an NAT, set-up a VPN first, and channel the traffic between the hosts through it.
For other setups, try and see whether there are some other tips you can do similar to these two points, to improve the security around these passwords.
I want to retrieve the following things from the user's desktop when the user uses logs into my website:
1) Mother Board Serial Number
2) Hard Disk Serial Number
3) CPU Serial Number
Now I am confused and not sure which way to go.
I cannot use Javascript because it will not provide these details because of security reasons.
I cannot use php because php runs on server side and not client side.
So last option is using Java Applets. As soon as the user logs in, the applet will be downloaded. When the user runs the applets, it will retrieve the necessary information. But I dont want to be using this because applets are obsolete these days and nobody uses them.
So is there any method in which I find find the user's hardware details without using Java Applets.
Using Java to get os level system Information will get you started in right direction.
Finding Operating System Information
How to get System Information using Java
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to get a unique computer identifier in Java (like disk id or motherboard id)
I am creating a small Java program. In there, I am creating a file called "James.txt". I am using this file to check whether the program has been moved from James computer or not. What I have done there is, writing Jame's computer's IP address to that file. So, when he start the program in the console, it will first check the file and will say "Hey James! Suprise!!!", and if the IP isn't belong to james it will print "Sorry, This is for James Party".
But, the case is, IP address can be changed even in the same PC right? So, how can I uniquely identify James computer? Please help!
MAC Address will change if the NIC is changed. Motherboard may fail and be replaced. The same may apply to processorId, hard-disk id and stuff.
Bottom line -
Develop an identifier for your application
Have your application maintain an identifier on the user's computer
When your application asks the user to identify himself/herself with userid/password/biometrics, validate the identifier too and then display the message you must.
Technically, you can't uniquely identify any computer because everything can be 'spoofed'. You can even change your MAC address as easily as your IP if you know how.
That being said, some systems attempt to calculate combinations of values that together can be used to define a semi-unique instance. Generally these come from hardware identifiers, like:
MAC address
Hard disc identifier
CPUID
These are then mashed together in a way that provides a unique key with some tolerance for change (like a hardware upgrade). There is also a generated identifier used in some systems called UUID which is created when a filesystem is built.
To access some of these you may need to use JNI. Some of these are contentious (CPUID) because they can be used to track people on the internet and thereby reduce their anonymity.
Frequently access to these are unavailable from certain applications (like web browsers). It may be easier to establish a login/password form of security.
There is no way to guarantee a computer hasn't changed. Your best alternative is to write a key file to the machine on first run that you can then use to check against. Whilst this could be deleted making it appear to be different as long as you have used a sensible hash algorithm to generate your key (i.e. you can be confident no one else could generate it) then you can be happy that you are guaranteed a correct match when the key matches. This method will give you confidence in positive identifications but leave you open to false negatives, which isn't normally an issue. You should look to use something like an SHA algorth based off some salted input that you can use as a reference.
Anything you can do in pure Java won't be very effective against a tech-savvy user who deliberately wants to 'break the system'.
But, nonetheless, low-tech things that you could do in pure Java:
just go ahead and store the MAC address; it's not totally reliable, but most users in practice won't change their MAC address;
allocate a random UUID and store it on the machine using the Preferences architecture; then, store that UUID, or a secure hash of it, in the program's local directory.
Either of these systems is easy to get round by a savvy user. But at the end of the day, a savvy user could doctor your class files to bypass whatever measure you put in place.
The disadvantage of the MAC address is that there is a 'legitimate' case external to your program where the MAC address may change, since a user may change their network devices.
IP address might change quite often (e.g. assigned using DHCP)
I propose to use serial number of disk or motherboard for identification.
Example of how to get these serial number on WINDOWS can be found here:
http://www.rgagnon.com/javadetails/java-0580.html (includes source code, platform dependant)
You could use the Java registry to write a simple value into the system registry. This will work on Linux and Windows and is a very basic way to do this. Not secure and quite hackable, but at least it's portable.
You can refer to read/write to Windows Registry using Java for some great examples.
I am creating a client program that talks to a server (which I programmed). I am making a little game for myself in which I roll a dice and the server does also. Whoever gets the higher numbers wins. However within my code, I send the server commands when the user presses a button, and then the server responds by sending back what it rolled, so it can be shown in the GUI window. However, I find this a very insecure method. For example, a person could just simply decompile the jar file, and make it so they always roll a 12. Since the only place that both rolls are together (the users and the servers) is the users screen, I have to evaluate the game from the client, obviously not very secure. I am trying to make my game more secure, and have found 2 options.
Obfuscators
Unless someone knows of a very easy one to use, I cannot figure out how to set any of them up, as they rarely come with a gui that I can easily "pop" my .jar file into
Binding to an .exe
I honestly dont know how secure this is. There are programs in which I can "bind" two things (mostly for making viruses which I am obviously not doing), into a single .exe file. I can bind my .jar into an .exe, but I still dont know if the .exe could be decompiled back into the .jar file and from there back into the .java code.
By the way, another security issue is that it connects to the server from my ip adress (which I do not want the client user to know about)
Never trust client input.
The only truly "secure" method is to have the server generate both its own roll and a roll for the client.
Of course, if the outcome of the comparison of the rolls has no impact beyond what the user sees (in other words, the client does not report back who won), then really, who cares? I could patch Solitaire to let me always win, but that's no fun.
If the code is on someone's computer, you should consider it compromised and exploited already. In the race between crackers and developers, the crackers always win because the crackers have everything they need. Jars can be (easily) decompiled and deobfuscated, .exes can be picked apart, and at extreme levels the OS can be modified to go behind your back - literally.
Instead, you should reconsider your architecture: do you really need the client to roll the dice? Could the server roll both?
Both obfuscation and compiling to a ".exe" can be defeated relatively easily. Hackers / crackers, and anti-virus security experts do this kind of thing every day.
Basically, you cannot trust any application that is running on any machine that could be controlled by someone you don't trust. In practice, this means anything that isn't in your (locked and firewalled) server room.
(Aside: even systems based on TPM are potentially vulnerable, since there have been successful attacks on TPM chips. And that wouldn't be practical anyway, since TPM is not available for securing application-level code. AFAIK, it is not even used at the OS level ... though I've heard that the next version of Windows is going to require hardware that is TPM encumbered.)