Embedding username in C++ application to make logins easier?

Question

Protecting against piracy when developing desktop applications through product keys, obfuscation, or similar client-side protections is pointless (plenty of stackoverflow posts regarding that). The only real way to prevent piracy is to create a client-server communication where important code is only on the server.

That's what I'm attempting to do with my software, require a login in order to authenticate requests to the server to process some data. Throw in an easy way to change the password and IP session tracking and it's pretty foolproof. However, now the user must enter a username and password when they want to use it, and they could enter someone else's credentials very easily.

Then thought then crossed my mind, what about embedding the username within the application when a user downloads the client software? Only a password would be required from the user's point of view, speeds things up a bit. Yes it's still possible to edit the program to someone else's username, but now it's less obvious.

---

So that's my question, are there any security risks or design flaws with having the username hard coded into the program? And secondly, how does one begin to implement the username embedding and C++ compilation on say... a Node js server application?

Thanks for your time.

Answer 1

You're missing the point of server-hosted software, and that's this:

You always have control over the server. You never have control over the client.

So when you say:

the user must enter a username and password when they want to use it, and they could enter someone else's credentials very easily

What you really mean is:

When someone enters someone else's credentials what can I do?

The answer to that is to limit or cancel access for credentials depending on access patterns. If you see suspicious access, like coming from IPs in different countries, you may want to investigate and possibly ban the account.

You're not powerless here when you control the server. Lock people out if you must.

You also don't want to embed information in the executable because legitimate owners, your customers, will want to verify they downloaded the right file based on a cryptographic hash like SHA2. If you modify each file they can't do this, and every version looks "hacked".

Instead, if you must, create some kind of encrypted access or license file that can be supplied to the server and decrypted with a key that's only stored on the server. Sure, they can share that file with someone else, but you can identify the unauthorized access and handle it accordingly.