3

I would like to obscure a password in my VB6 code, such that it cannot be revealed even via decompilation.

Is this possible?

CJ7
  • 22,579
  • 65
  • 193
  • 321
  • 2
    The usual course of action is not to store a password at all (especially not one hard-coded into a compiled executable). Use Windows-integrated security and make the protected resource accessible to a certain user account or group. Run the executable under that account. – Tomalak May 23 '12 at 05:45
  • 1
    Good question. How would you like to store the password? DIM a variable and store it in there? Or maybe a constant with the password in it? Are those readable by memory hacking, or decompilation? I would at least try to hash the password so that it's not totally exposed. Unless you need the original password for another application or something. Then a hash won't work. – Martin May 23 '12 at 07:11
  • @Tomalak: what if a password is required? For example, `.accdb` files need to have a password if they are to be encrypted. – CJ7 Jan 13 '13 at 15:17
  • 1
    @CJ7 If you need a secure database, you don't use Access. Smug comment, I know, but that's how it is. – Tomalak Jan 13 '13 at 15:22
  • .accdb security is actually OK nowadays. It was the old .mdb format that was the problem. – CJ7 Jan 13 '13 at 21:41

2 Answers2

2

If you program has access to it in plaintext, then it's possible to somehow retrieve it. You are better off getting your security in other ways. How to do this really depends on your specific application. Do you have to store the password in your application? Can you simply store a pre-computed hash and compare against that?

Oleksi
  • 12,947
  • 4
  • 56
  • 80
  • How can it be retrieved? And can any code be retrieved? Or only when it's stored in memory? – Martin May 23 '12 at 07:15
  • @Martin If the user can read an executable file they can read any hardcoded values. – user1937198 Feb 05 '14 at 14:35
  • What is the point of adding a hard coded hash when someone can go to the binary and simply crack your application by changing the hash? If you really need to do some authentication the way to go is create some sort of "client server" architecture. – Jhuliano Moreno Feb 06 '14 at 19:17
0

It really depends what you will be using that password for. If you just need to check against it you could simply use a really strong password and hash it (that way it will be hard to find it out even if they use some sort of rainbow table).

But think it this way, if someone is willing to decompile your code they could perfectly crack your application by just changing that password for another one simpler that they know the hash.

In the other hand if you are trying to store a password so that you can reverse it (DB password?) and use it, I would say you are going for the wrong architecture and there is nothing you can do to safely keep a malicious user to find out your password. You should create a server side app that is not accessible by "normal users" and a client side App that will send requests to your server side app.

Jhuliano Moreno
  • 929
  • 8
  • 23