Crypt a QByteArray without external dipendences [Solved]
-
... which is fine as long as you never fall for the illusion of security.
That approach is not secure and will only stop a very easy to frustrate attacker. That is fine, for as long as your database does not contain any data that makes it worthwhile to spend a couple of minutes with a debugger:-) That is independent of which encryption scheme you use: As long as you ship the key as part of your application the key is easy to retrieve for an attacker.
-
[quote author="Tobias Hunger" date="1306782974"]... which is fine as long as you never fall for the illusion of security.
That approach is not secure and will only stop a very easy to frustrate attacker. That is fine, for as long as your database does not contain any data that makes it worthwhile to spend a couple of minutes with a debugger:-) That is independent of which encryption scheme you use: As long as you ship the key as part of your application the key is easy to retrieve far an attacker.[/quote]
What solution do you suggest for a simple application?
-
There is no simple solution to security:-( It is always a compromise between "easy" and "secure". I am not saying that there are no scenarios where your suggestion does make sense (inhouse applications etc. where people are expected to behave -- they are bound by a contract anyway, etc.).
If you need to protect against the the user misbehaving then you are out of luck without hardware support.
-
[quote author="Tobias Hunger" date="1306784612"]There is no simple solution to security:-( It is always a compromise between "easy" and "secure".[/quote]
I also think so... :-)
If you work in a small company you know that you must follow:
- costs
- developing time
- client need
- ecc...
-
[quote author="peppe" date="1306785708"]I would simply suggest rot13 the password then, the security is pretty much the same (discourages the pryings, useless against malevolent users).[/quote]
This is another possible solution and avoid the hardcoded key but there isn't a big security increase.
Thanks for the suggestion. -
[quote author="peppe" date="1306785708"]I would simply suggest rot13 the password then, the security is pretty much the same (discourages the pryings, useless against malevolent users).[/quote]
Yawn! Get serious, peppe.No, a scheme like that will not protect you against a serious attacker, or even a semi-serious one, but it does protect against casual inspection. Meanwhile, I have not yet heard you suggest a cross platform solution for a serious keychain with the specs you mentioned that you can interface with with Qt.
-
[quote author="Andre" date="1306786848"]
[quote author="peppe" date="1306785708"]I would simply suggest rot13 the password then, the security is pretty much the same (discourages the pryings, useless against malevolent users).[/quote]
Yawn! Get serious, peppe.No, a scheme like that will not protect you against a serious attacker, or even a semi-serious one, but it does protect against casual inspection. Meanwhile, I have not yet heard you suggest a cross platform solution for a serious keychain with the specs you mentioned that you can interface with with Qt.
[/quote]Because it doesn't exist! He doesn't want to protect the password stored on that system from an external attacker; he wants to hide that password to the very users of that system (with physical access and all), and no wallet gives you that.
Apart from this, I'm serious. If you don't protect the key by some means of some good hardware/software protection (like having the password on a dedicated device, configuring the OS to give the least minimum privileges to the user in terms of resource access, etc.), there's no point in shipping any semi-serious form of encryption.
Let's write down the pros and the cons of the current approach:
| ||. Pros ||. Cons |
|. SimpleCrypt | - | Discourages the occasional snooper | - | Fails as soon as one reverse-engineers the code |
|. Rot13 | - | Discourages the occasional snooper | - | Fails as soon as one reverse-engineers the code |
|_. AES 256 | - | Discourages the occasional snooper | - | Fails as soon as one reverse-engineers the code |
Instead, what about setting up the DB so that:
all transactions are logged
the users know they username and password
even with direct, SQL access, an user can do exactly what he can do with your client app
the users are directly responsible for their actions
Now you don't need to store a secret any more.
-
[quote author="peppe" date="1306792127"]
Instead, what about setting up the DB so that:all transactions are logged
the users know they username and password
even with direct, SQL access, an user can do exactly what he can do with your client app
the users are directly responsible for their actions
Now you don't need to store a secret any more.[/quote]
I can do the same with a crypted password. And I add one more security level to what you said.
the fact that "an user can do exactly what he can do with your client app" is not always correct:
suppose an application that add or update a price in a price list. The user must have at least the SELECT, INSERT and UPDATE privileges on the DB.
With this privileges the user can alter all the price table without any software filter.This is why I'd like to hide db password.
I also think that no one is interested in hacking my application to get the key. :-)