Crypt a QByteArray without external dipendences [Solved]
-
[quote author="peppe" date="1306781108"][quote]Who said that that may be the chosen implementation? The application may choose to hard-code the key, or determine key in another way*. And, what is more, your question equally applies to services like KWallet[/quote]
My point doesn't apply to a wallet. The purpose of a password wallet is to store a whole set of passwords, not only one, using strong cryptography, proper memory locking, etc.
Encrypting only one password with another one using a simply cryptography scheme is simply nonsense (why don't you just ask it? And if the first one is a valuable password, then you should not use a simple encryption mechanism, so we go back to "use a proper wallet").
And it's even more nonsense if the second one is hardcoded or saved somewhere along the encrypted password (WHY using encryption at all then? You're giving away the cyphertext, the key and the algorithm).[/quote]
Peppe, suppose you have an application that need to connect to a DB (using username and password).
You have 2 possibilities:- ask the password to the final user
- keep the password in an external file and allow the application to get it
In the case 1 the user know the DB username and password so he also can use some db client (such as ACCESS) and do some direct operation to the DB table.
To solve (partially) this problem you can put the DB password in an external file and let the application to get it to connect to the DB.
But what if the user open this file? He has the DB password again to use ACCESS.
An intermediate solution is to crypt the password saved in the external file and hardcode the decrypt key in your application. -
... 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. :-)