Since we can access private fields(and probably methods as well, havent checked) with reflection, they are not really private.
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#get(java.lang.Object)
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#set(java.lang.Object,%20java.lang.Object)
and
field.setAccessible(true);
Is there a way to make a field 100% private?
What are you worried about? In a devenv if some one is mucking around in the code private is never really private anyway. If you’re worried about someone stealing info then the only way to keep it safe is on the server side.
Reflection comes with a pretty big “you can use this to break the rules” warning, so it’s not really something you can -or should- worry about.
I mean, you can change the String that a String Object holds, and if you can do that, then pretty much all bets are off.
[quote=“KevinWorkman,post:3,topic:50579”]
Aint that a big security risk?
It seems like reflection is “to strong”.
well, since java is decompileable there is no “security” in java, if someone want to steal something, he will just do.
Nothing is safe.
Technically if software is client side all bets are off anyway, there are a ton of tools for breaking software.
In most environments where it matters theres a security manager running that prevents use of setAccessible()
Kev
[quote=“P0jahn,post:4,topic:50579”]
Anything that happens on the client side should be viewed as pretty much open to the client, including private variables, algorithms, passwords, etc.
What are you trying to do? What exactly are you afraid will happen?
Are you afraid someone will use reflection to “hack” your application?
we can make variables more safe by not using plain java objects/fields and use unsafe instead.
still accessible by the client by simply reading the pointer but content would not appear in heapdumps. see http://mishadoff.github.io/blog/java-magic-part-4-sun-dot-misc-dot-unsafe/ chapter “Hide Password”.
in the end you can use unsafe to do even more evil things then with reflections, but also more efficient. :persecutioncomplex:
In object programming, being private doesn’t mean safe from a security standpoint.
Private means that developers of other classes should not know about, and mess with that private entity. Then the compiler makes sure that rule is followed. It only “secures” programmers among themselves, to allow them not shoot themselves in the foot while they develop. That’s all.
If you want security, you’ll have to employ much more advanced techniques, such as in-memory encryption etc…
Have a look at client-side password managers (like KeePass) for an idea of how it’s done.
If a person as access to the code and data…security is impossible, regardless of language written in. They have all information needed.