How should I store my database password and map plugin id and tokens?
-
The only option is to save in some encrypted db or file. It all depends on how much crypto you would like to use. If you don't want the user read the entries, you can opt for base64 encoding or Crypto classes. If you want more secure then search in google for encryption using public and private key. That should help you.
-
@tham Just wanted to add that even encrypted they will still be accessible to the determined user. Since you have to have the ability to decrypt them in your application it means that the user can find out how. Including the encryption key you used or the private key file.
There are ways to obfuscate it and make it harder but eventually someone will get it.
So if you need the password to stay secure, you can't put it in your application. Instead you would need to use one of the other methods of connecting to outside services (and authenticating). A google search would help you here. :)
-
@dheerendra said in How should I store my database password and map plugin id and tokens?:
encryption using public and private key. That should help you.
If I am correct, I need to store private key on my app if I use this solution?
@ambershark said in How should I store my database password and map plugin id and tokens?:
Instead you would need to use one of the other methods of connecting to outside services (and authenticating). A google search would help you here. :)
Do this means user need to enter some data for authentication? If possible I do not want to bother user with manually authentication.
Assume I have no choice but to force users to do authentication, I may prefer OAuth2.0 according to my search results(Qt5.8 support it now). Are following flows correct?
1 : create a small server to store sensitive data like db password and account
2 : authenticate user by OAuth2.0(maybe use gmail as webservice?)
3 : let users download passwords from the server with ssl encryption
4 : use the passwords to access the data of database, with ssl encryptionThanks for helps
-
@tham Yes you would have to store the private key on the client box which means they could "hack" the password. So PKI isn't any better than conventional means when it comes to local non-user encryption.
I would not allow the app to connect to the database directly, but instead write a small server component that runs on a remote machine that you control, and has access to the database. Then you could use any socket or web interface like REST, or just plain TCP/IP sockets, SSL, HTTP, whatever you wanted to talk to your server and make requests from the db.
This makes it so client apps never have the password on their machine in any form, encrypted or plain text.
-
@ambershark said in How should I store my database password and map plugin id and tokens?:
Yes you would have to store the private key on the client box which means they could "hack" the password. So PKI isn't any better than conventional means when it comes to local non-user encryption.
Thanks
@ambershark said in How should I store my database password and map plugin id and tokens?:
but instead write a small server component that runs on a remote machine that you control, and has access to the database. Then you could use any socket or web interface like REST, or just plain TCP/IP sockets, SSL, HTTP, whatever you wanted to talk to your server and make requests from the db.
So the steps should change to
1 : create a small server(resource owner) to store sensitive data like db password and account
2 : authenticate user by OAuth2.0(maybe use gmail as webservice?)
3 : users send request with access token to the resource owner
4 : resource owner get data from resource server
5 : resource owner send data back to usersThis is fine with plain text database for my app, but it would be too difficult to deal with map plugin of Qt5.
-
@tham Yea if you need direct db access you have to provide the credentials and if you do they are hackable.
Here is a post that pretty much says exactly what I did in this thread. Example #3 in the accepted answer is the server method I mentioned which is really the only secure way to do it:
https://security.stackexchange.com/questions/20294/how-should-an-application-store-its-credentials
-
@ambershark said in How should I store my database password and map plugin id and tokens?:
Yea if you need direct db access you have to provide the credentials and if you do they are hackable
I wonder how are the other apps protect their sensitive info in this case, other apps which need navigation function just leave their id and token in their apps? No matter it is private key or encryption, hashing, as long as I need to store some sort of "key" in the application, hackers will find their way to hack it.
-
@tham From what I read most people set up multiple accounts and then use a limited user (read only) for accessing the data. If they have to be able to write then you're really left with the server route.
And yea if they have credentials client side, it's hackable. It can be made very difficult, and most of the time the cost to hack outweighs the benefit so it's "safe", but given the will hackers will get into it.
I would if I needed to, and security isn't my strongest area. Just need to throw the app in a debugger, find where it is getting the key for the decryption and grab that. No real way to stop someone if they have access to it like that.
-
set up multiple accounts and then use a limited user (read only) for accessing the data
Map plugin I am using got limited transaction per months and read only, no worry for data written issues.
@ambershark said in How should I store my database password and map plugin id and tokens?:
And yea if they have credentials client side, it's hackable. It can be made very difficult
Any suggestion way to make it very hard to hack?Thanks
-
@tham Well just some things off the top of my head:
-
Nesting things in structures will make them harder to track down. It's much more confusing when going through the disassembly. So instead of simple variables for the decryption key and password, make them part of a class that builds up the final value, see #3. Then to store the actual data make it a struct of structs that hold a piece of the data. This makes it way harder to track down.
-
Read registers a while after setting them (assembly lingo here). So basically don't read/write values close together. This makes it easier to track down in a disassembler.
-
You can build up your encryption key from multiple sources. And in between building the key, do some other things and waste a few hundred milliseconds. This makes it much harder to track in a disassembler. So basically when building your key to decrypt your password into memory get part1 of the key, then do some random stuff/kill some time, then get part2, more random stuff, then get part 3.
-
Make sure you read the key/decrypted password into secure memory so people can't dump the memory to disk and go through it. There are APIs for this on all operating systems but they are different.
That's the easiest things I can think of right off the top of my head. Keep in mind that to a good hacker/reverse engineer this will only slow them down. They will be able to get it at some point. So if your application gets popular, expect it to get hacked. ;)
-
-
@ambershark Thanks for your suggestions, I will try them out, at least I can answer my clients I did some minimal protection to the key
-
@tham Yea and really someone has to be interested enough in hacking your application to do it. That is ultimately pretty rare unless it gets really popular or is a security based app.
Other than either of those scenarios I'm betting nothing will ever happen to/with your encrypted password. :)
