Crypt a QByteArray without external dipendences [Solved]
-
[quote author="peppe" date="1306745967"]
[quote author="Luca" date="1306664168"]Hi all,
I need a very easy way to crypt a password in a text file and get it back when needed.The application should works in various Linux and Windows PC so I'd like to avoid the use of some external library for cryptographic function.
Some ideas? [/quote]
Yes: don't do that and use a password storage mechanism.[/quote]
Does Qt supply a platform independent way to do that? Does it even exist on Windows? No, I didn't think so. By all means, if you are on KDE, use KWallet. But AFAIK, there is no cross platform solution for this (yet).
In the meantime, I think encrypting the login data, even if it is by using a weak encryption like my SimpleCrypt class provides, is a better solution than no solution at all.
[quote author="koahnig" date="1306667191"]"qcryptographichash":http://doc.qt.nokia.com/4.7/qcryptographichash.html
I have read an explanation here in the forum, but cannot find it anymore. [/quote]
A (cryptographic) hash is a one-way function for calculating a fingerprint of a piece of data. The whole purpose of the algorithm is to create a short code that can not be used to re-calculate the data it was calculated for, yet be as unique to that text as possible. It should be hard to construct two pieces of data that result in the same hash, even if those obviously exist.This function is not an encryption algorithm, though it can be used as a component in one. In SimpleCrypt, it is optionally used to validate if you are using the right key for decryption.
-
Luca - do you really need to store the password itself, or do you just want to be able to check if a password entered by the user is correct?
To be able to check if an entered password is correct you can use QCryptographicHash to create a hash from the original password, store the hash, and then compare the stored hash with a hash created from the password entered by the user. -
[quote author="ludde" date="1306750046"]Luca - do you really need to store the password itself, or do you just want to be able to check if a password entered by the user is correct?
To be able to check if an entered password is correct you can use QCryptographicHash to create a hash from the original password, store the hash, and then compare the stored hash with a hash created from the password entered by the user.[/quote]As I said in my first post:
[quote author="Luca" date="1306664168"]
I need a very easy way to crypt a password in a text file and get it back when needed.
[/quote] -
[quote author="Andre" date="1306747520"][quote author="peppe" date="1306745967"]
Yes: don't do that and use a password storage mechanism.[/quote]Does Qt supply a platform independent way to do that? Does it even exist on Windows? No, I didn't think so. By all means, if you are on KDE, use KWallet. But AFAIK, there is no cross platform solution for this (yet). [/quote]
What's the point in having the user inputting a password for decoding one, another, specific password?
-
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. The point is that the user does not need to remember a load of different passwords for different services. That will make it easier for the user to use different, complex passwords for different services, thus strengthening the users security in the long run (one compromised service does not compromise the users credentials with other services).
*) And no, I am not claiming that using a hard coded key is very save practise. But then again, I also did not claim that SimpleCrypt provides strong cryptography.
-
[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 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. :-)