6

I am making a standalone exe application that does not connect to the internet. There is an 'edit mode' that is 'password protected' but the mechanism in c++ (which I wrote it in) looks like:

string passwd = getString();
if(password=="something"){//do stuff}

Where "something" is my real password. So I know if it was reverse engineered or something the password would be easily obtained.

The program does not connect to the internet, and if a user found out the password it would only be a minor inconvenience. Is there are more secure method, or is this enough? Nothing, to my knowledge, is encrypted in any sort.

Improve this question
3
  • As S.L Barth points out in theory your users could just modify the executable binary directly to give themselves edit mode. I also imagine it must store whatever it edits locally? Meaning they could just modify that directly.
    – Hector
    Oct 24, 2017 at 7:48
  • @Hector yes to everything you say. I'm thinking of using a 'salted hash'
    – Joao Noch
    Oct 24, 2017 at 7:50
  • As Barth says a salted hash makes sense. You may as well just use std::hash (never normally use this for security purposes) on a random (constant - i.e. hardcoded into the application) string concatenated with the user entered password. Whilst std::hash isn't cryptographically secure anyone that has managed to pull the salt out of your code and find a hash collision could have just replaced the hash in the binary to one for a password they know.
    – Hector
    Oct 24, 2017 at 7:53

2 Answers 2

Reset to default
7

Use a salted hash, just like you would in a tool that is connected to the internet.

Clearly, if an attacker has the software installed on their own system, they can just modify it and remove the password altogether. But then they're only hacking it on their own system.

If the password is a salted hash, they will only know the salted hash, not the actual password.
There should be implementations for calculating a salted hash in C++, that you can use to verify the password that the user types in. So you don't have to write it yourself. This is still a thing to consider even if your application does not connect to the internet. Your application may not go to the internet, but the computer on which it runs probably does have a connection, and is liable to attack - it is only as safe as the computer on which it runs.

Improve this answer
5
  • 1
    Hmm... that's right. So even if I use some method of password-ungettability, a determined user could just remove the restrictions out of the binary code altogether. Thanks.
    – Joao Noch
    Oct 24, 2017 at 7:53
  • 1
    Don't forget to encrypt the data you want to protect with a key derived from the password as well. Otherwise it is trivial to replace your pwd check with NOPs.
    – Stephane
    Oct 24, 2017 at 7:53
  • 1
    @Stephane - if this is to enable an "edit mode" that won't work. Sounds like normal users need read access. Best you could do is move the edit functionality into a separate DLL and encrypt that - but this sounds like overkill for what OP is trying to achieve.
    – Hector
    Oct 24, 2017 at 7:56
  • @Hector I was about to suggest just that: moving the relevant functionalities in a separate module and decrypting it in memory. But, of course, that only makes it a bit harder for someone to reverse it, far from impossible.
    – Stephane
    Oct 24, 2017 at 8:05
  • It makes it impossible to get access to that library (assuming the key is derived from OPs non-dictionary password). They can still manually modify the underlying files or write their own code to do so. But reverse engineering file types (assuming its not something like XML) is often a lot more effort than identifying a hash in a binary and swapping it out.
    – Hector
    Oct 24, 2017 at 8:32
0

As @S.L. Barth suggested, the best way is to use a salted hash and maybe a few iterations of hashing as well. Avoid deprecated algorithms such as MD5. SHA256 and greater is better, but you can also use PBKDF2, which is a slow algorithm, making it more difficult to crack if many iterations are used. You could also make a chain of controls which, if a given password passes them all, it will have to be correct, but it's not the brightest idea. Given enough time, a good reverser will break through the chain.

Last, but not least, consider packing and/or obfuscating your executable, so a reverser would have a harder time from the beginning.

P.S.: If you want to be a little funny with the reversers, take a look here and here :D

Improve this answer
1
  • The other issue with a chain of controls like Chris describes is you'd basically just be reinventing the cryptographically secure hash, except that since you're (statistically speaking) not a cryptographer, you'd probably do it worse. So, yes, Chris is correct -- a good enough attacker will eventually break through, compared to a solid good password hash, which they can't break (by definition). You could also consider using scrypt or Argon2 or the like.
    – anon
    Aug 16, 2019 at 16:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .