0

This seems like a fairly easy question, but I'm having a hard time finding a definitive answer. Currently, I have a public class, and in the constructor I'm defining a variable like this:

private String password = "abcd123456";

Then I have a method like this:

public String getValue(String inputValue)
{
    String returnValue = encryptor.decrypt(inputValue, password);
    return returnValue;
}

The class is defined as public as well. When I reference this class from a form, I'm doing this:

ValueGetter vg = new ValueGetter();
String decryptedValue = vg.getValue("xfr3sf342d#2");

I would think that by defining password as private, only that class would be able to see it. However, if I am in debug, after I hover the mouse over the "vg" variable to view the contents of the object, I can see the password plain and clear. Is there a way to make the variable password only known to that class, but still defined in the constructor? There will be several methods within the class using that variable, which can be called from external forms, so I'd rather have it in the constructor than having to re-define the variable in each method.

Thanks in advance!

I used password as the most obvious reason why you would want to hide a variable, but in actuality, I don't want someone to write an interface to a class, and get a bunch of garbage that doesn't mean anything to them back out of the object. So I might have a class called beach, and a method called getBeachBall. It returns me a beach ball that is orange, inflated with xx pounds of air, etc. In the class that contains the method, I have another variable called TableShape. This color would always be white, and non-changeable. I was just wondering if tableShape could be masked, since only the Beach class would use it for something. The original caller would never know anything about the tableColor variable.

user1420914
  • 279
  • 1
  • 3
  • 15
  • 5
    Don't store passwords in the code. – Jordão Aug 31 '12 at 19:25
  • password is private and thus visible only inside ValueGetter. You can see the value of password from the debugger only because the debugger allows you to view private members. Try to reference ValueGetter.password from your form and you will see that it is inaccessible. – Maciej Aug 31 '12 at 19:27
  • @Maciej It still doesn't in any way prevent access to it from a malicious user. You could access it via reflection, decompiling the code, dumping and inspecting the memory, etc. – Servy Aug 31 '12 at 19:30
  • @Servy: agreed, but I interpreted the question as asking why password was not scoped as private. – Maciej Aug 31 '12 at 19:32
  • May be SecureString is ok? http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx – Pavel Voronin Aug 31 '12 at 19:42
  • Jodao, I only used password as an example. There's other things, like internal variable such as coffeeBean for example, that would only need to be used by the coffee class, but not the cup class. Just pulled that out of thin air as another example, but there are several different types of variables that I would want only the class to utilize. – user1420914 Aug 31 '12 at 20:08

5 Answers5

2

Making something private doesn't make it invisible.

The access modifiers are for the compiler, it determines how you can access things from the code. Making a member private means that you can't write regular code to access it from outside the object.

The debugger can see everything, and you can also use reflection to access everything from code.

Guffa
  • 640,220
  • 96
  • 678
  • 956
1

It is a bad idea to store passwords in code. The closest you can get to hiding code is via obfuscation. Otherwise, anybody with access to the compiled code, can run any free decompiler and get that value.

Here is a SO question that has some good links on storing passwords

Community
  • 1
  • 1
Justin Pihony
  • 62,016
  • 17
  • 131
  • 162
1

Fields marked "private" in OOP are not meant "private" as in "private corespondence". This is object-oriented-design concept that tells the programer from where to expect any field changes (only from inner class code).

Consider using SecureString for this purpose: http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx. It doesn't however make your code safe from decompilation.

Kuba Wyrostek
  • 5,913
  • 1
  • 18
  • 39
0

It's (provably) not possible for you to prevent anyone from accessing that information if you store it in code.

You can make it harder, you can add more and more hoops for them to jump through, but at the end of the day if you are including everything in an executable that you give to the user then they are the one in control; they can access any information that you've hidden in there.

If you obfuscate the code you don't prevent it from being de-compiled, you just make it harder. It makes complete re-engineering of the project impractical, but finding a password buried in there is still quite practical.

You can encrypt the password, but the problem there is that the executable itself needs to have everything to decrypt the password for it to be used. The user can either grab the password from memory after you have decrypted it, or just pull out both the encrypted password and the encryption key and decrypt it themselves.

If it's important that the information not be accessible to a user then you simply cannot include it in the code of a program that you give them under any circumstances.

Source

Community
  • 1
  • 1
Servy
  • 193,745
  • 23
  • 295
  • 406
0

Although you can see the value of private string password through the debugger, I bet it is listed in the watch window as a private member. To confirm, try accessing it the following way:

ValueGetter vg = new ValueGetter();
String decryptedValue = vg.getValue("xfr3sf342d#2");
string password = vg.password; //won't compile because password is private

You will get a compiler error stating that password is private.

The debugger will let you see the value because it is useful to view private properties for debugging purposes.

Maciej
  • 2,147
  • 1
  • 17
  • 27