Qt-interest Archive, November 2007
Re: How to encrypt a string?
Pages: Prev | 1 | 2 | Next
Message 16 in thread
Mike Broida wrote:
> I need a way for an app with a built in key/passphrase to encrypt the
> Password string before putting it in the QSettings .ini file, and
> decrypt it after getting it from that file. The decrypted Password
> would then be sent to the server.
Have you considered hashing instead? Look at QCryptographicHash. Works
great for me. Just store the password in a hashed format in the .ini
file, and then hash incoming passwords for verification with the stored
hash. That way, the clear text password never has to get stored on disk.
--Dave
--
[ signature omitted ]
Message 17 in thread
Thought about it, but the traffic pattern for this app is all wrong.
There are no "incoming passwords" from the point of view of this app.
This app sends data and username/password to a server, period. But it
needs to keep its password somewhat secure locally, so I want to encrypt
it before storing on disk.
Sending a hashed password is really no different than sending a plain
password: the server will accept or deny it based on the sent value,
because you can't de-hash a 1-way hash. It's being sent via SSL, so it's
"safe" in transit. It's just locally that I want to add a little
protection.
Thanks!
Mike
On Thu, 01 Nov 2007 01:06:22 -0500, Dave Smith <dave@xxxxxxxxxxxxxxx>
wrote:
> Mike Broida wrote:
>> I need a way for an app with a built in key/passphrase to encrypt the
>> Password string before putting it in the QSettings .ini file, and
>> decrypt it after getting it from that file. The decrypted Password
>> would then be sent to the server.
>
> Have you considered hashing instead? Look at QCryptographicHash. Works
> great for me. Just store the password in a hashed format in the .ini
> file, and then hash incoming passwords for verification with the stored
> hash. That way, the clear text password never has to get stored on disk.
>
> --Dave
--
[ signature omitted ]
Message 18 in thread
Mike Broida wrote:
> Thought about it, but the traffic pattern for this app is all wrong.
> There are no "incoming passwords" from the point of view of this app.
> This app sends data and username/password to a server, period. But it
> needs to keep its password somewhat secure locally, so I want to encrypt
> it before storing on disk.
>
> Sending a hashed password is really no different than sending a plain
> password: the server will accept or deny it based on the sent value,
> because you can't de-hash a 1-way hash. It's being sent via SSL, so
> it's "safe" in transit. It's just locally that I want to add a little
> protection.
I'm not sure if I'm missing something with your situation but I think
you are misunderstanding how to use the hashing. What you do is you
have the client send the password in plain text to the server. As you
say this connection is protected by SSL so its safe and can't be snooped
on. On the server side, you hash the password received by the client
and compare that to the saved hash of the correct password stored in the
ini file. The client password is only correct if the hash of it matches
the hash that has been saved. Since you are only saving the 1-way hash
of the password to disk, you aren't giving anything away to a user if
they view the file.
So the key is to store the hashed password in the file and have the
client send the plain text password. You will need some tool though to
set the password on the server. Something that asks for the old
password and a new one and verifies the hash of the old password matches
whats in the file now and then store the hash of the new password.
Security wise this is pretty good though not really hugely strong since
the password is likely very small and a brute force attack could likely
succeed. But it does mean getting the password isn't as simple as
casually viewing the ini file!
--
[ signature omitted ]
Message 19 in thread
Ah. What you're missing is that I'm trying to protect the password in the
.ini file on the CLIENT side, separately from the net transfer.
Server-side is fine: the password (sent plaintext over SSL) is only
correct if it matches the plaintext that has been saved there.
I'm looking for a solution on the CLIENT side to protect the password
stored THERE from prying eyes. And I can't have the user enter the
password: the app is a service that runs without user interaction. The
password really identifies/authenticates the system the data comes from
more than a specific person.
On Thu, 01 Nov 2007 12:29:26 -0500, Brad Pepers <brad@xxxxxxxxxxxxxxx>
wrote:
> Mike Broida wrote:
>> Thought about it, but the traffic pattern for this app is all wrong.
>> There are no "incoming passwords" from the point of view of this app.
>> This app sends data and username/password to a server, period. But it
>> needs to keep its password somewhat secure locally, so I want to
>> encrypt it before storing on disk.
>> Sending a hashed password is really no different than sending a plain
>> password: the server will accept or deny it based on the sent value,
>> because you can't de-hash a 1-way hash. It's being sent via SSL, so
>> it's "safe" in transit. It's just locally that I want to add a little
>> protection.
>
> I'm not sure if I'm missing something with your situation but I think
> you are misunderstanding how to use the hashing. What you do is you
> have the client send the password in plain text to the server. As you
> say this connection is protected by SSL so its safe and can't be snooped
> on. On the server side, you hash the password received by the client
> and compare that to the saved hash of the correct password stored in the
> ini file. The client password is only correct if the hash of it matches
> the hash that has been saved. Since you are only saving the 1-way hash
> of the password to disk, you aren't giving anything away to a user if
> they view the file.
>
> So the key is to store the hashed password in the file and have the
> client send the plain text password. You will need some tool though to
> set the password on the server. Something that asks for the old
> password and a new one and verifies the hash of the old password matches
> whats in the file now and then store the hash of the new password.
>
> Security wise this is pretty good though not really hugely strong since
> the password is likely very small and a brute force attack could likely
> succeed. But it does mean getting the password isn't as simple as
> casually viewing the ini file!
>
> --
> Brad
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 20 in thread
Hello,
On Thursday 01 November 2007, Mike Broida wrote:
> I have a non-interactive client app that sends Username/Password to a
> server, followed by some data. The connection itself is through
> QSslSocket, so all of that is sufficiently secure.
>
> But the Username/Password are STORED on the client in a QSettings .ini
> file. I would like to make the Password at least a little more secure by
> encrypting it before putting it in the QSettings .ini file. Base64 isn't
> quite good enough: anyone can undo that "encryption".
you can try to encrypt locally stored password with key that is not stored in
program at all. For example, on 1st connection software receives secret key,
decrypt the password then sends it (password) back to the server. When "user"
enters a new password, software use key (received on 1st connect) to encrypt
password and save encrypted password. In this case your key is stored in RAM
only, not on the disk.
--
[ signature omitted ]
