[ACCEPTED]-Saving passwords inside an application-qt

Accepted answer
Score: 10

It depends on what you are going to do with 100 the information.

If you are going to use 99 the name and password to access some external 98 service (but the user will have to reenter 97 the information the next time the program 96 is run), then storing them in some variables 95 is OK. It might be wise to store them encrypted 94 (at least, store the password encrypted) so 93 that it is not visible in core dumps or 92 the equivalent. When the password is needed, you 91 decrypt it, use it, and then write over 90 where the decrypted version was stored (zapping 89 it). (Note: hashing is not appropriate 88 in this context; you need to be able to 87 see the password, and you can't undo a hash.) You 86 could decide to store the information outside 85 the program (in a disk file), but it doesn't 84 seem necessary. Note that the binary will 83 still contain the encryption key (and encryption 82 algorithm), and encrypted data is more random 81 than the average contents of your program, so 80 to really conceal the encrypted password 79 is actually very difficult (verging on impossible). However, you 78 can make it hard enough that it will stop 77 all but the most determined attackers.

If 76 you are going to store the username and 75 password as a permanent record so that you 74 can validate that the same user is accessing 73 the information in the future, then you 72 must use storage external to the program; you 71 will use a simple database, which might 70 be as simple as a plain text file if you 69 ensure you resolve any concurrency issues. In 68 this case, you will hash the password with 67 some salt, and you'll store the username, salt 66 and hashed password in such a way that given 65 the username, you can easily find the other 64 two values.

Night Walker comments:

I use that 63 password to access some web database, so 62 I need it stored in my application after 61 it is entered for the first time. Are you 60 sure a plain text file is that smart an 59 idea?

It depends on how you conceive 'stored 58 in my application'. You can't modify the 57 executable, or at least shouldn't try to 56 do so. So, you need to look on it as a 55 permanent record stored in some sort of 54 file separate from the application executable. On 53 the other hand, you do face a different 52 problem from what I outlined - you are not 51 authenticating the user with the information; you 50 need to decrypt the information on demand 49 to send on to other applications.

First off, that 48 means that salts and hashes are not relevant; you 47 need to reverse the masking operation, and 46 you can't reverse a hash.

Next, you need 45 to decide how you will identify the user 44 of your application upon reappearance. Will 43 the user be obliged to enter some password 42 to get to their own data, or will you simply 41 rely on the operating system privileges, or 40 some other scheme.

If the user must enter 39 some password into your application to get 38 going, then you can consider using that 37 password (or a hash of it, distinct from 36 the password hash used to recognize the 35 password to the application) to encrypt 34 the username/password combination for the 33 external application. You can then store 32 the username and, for sake of argument, a 31 Base-64 encoded version of the encrypted 30 password into a text file; this is as safe 29 as the application password, which is stored 28 in the original salted hash format. When 27 the user returns, they have to supply their 26 application username and password, and you 25 can validate that combination against the 24 stored values, and then use the password 23 to decrypt the password to the external 22 application.

If the user does not enter a 21 password, then you are more restricted in 20 what you can do. You have to be able to 19 determine a key somehow from the information 18 available to you that can be used to store 17 the user's encrypted password in a file 16 in a restricted location such as a sub-directory 15 underneath their home directory with no 14 group or public access:

mkdir ~/.appname
chmod 700 ~/.appname
cp /dev/null ~/.appname/app.key
...store the encrypted information...
chmod 500 ~/.appname
chmod 400 ~/.appname/app.key

This is less satisfactory 13 because even if you combine a fixed key 12 with the user's name, say, the chances are 11 that someone can work out what that key 10 is (and the encryption technology) and reverse 9 engineer it. (The secrecy of encrypted 8 data depends on the keys; when the key is 7 determinable by the program, it is also 6 determinable by a determined attacker. It 5 is best, by far, to rely on the user to 4 provide the key (or a password or pass phrase) at 3 run-time; then the application does not 2 store anything that an attacker can use 1 offline.

Score: 6

Usually you store the username and a hashed 2 version of the password. See this wikipedia 1 article: hash functions, and this question.

Score: 2

Common method to store passwords for later 10 use is to store them in some encrypted cache. That 9 cache is encrypted using some master password. User 8 should enter master password each time you 7 need password from cache. KeePassX is a small open 6 source application that uses master password 5 to store personal data (user names, passwords, etc.) It 4 has a light interface, is cross platform 3 and published under the terms of the GNU 2 General Public License. You could check 1 it as sample and use some parts of it.

Score: 1

What about MySQL or SQLite? Hash the password 1 and store them in a persistent database, no?

Score: 1

I would suggest storing a hashed password 5 in SQLite. Then whenever you need to check 4 a password, hash it and then compare it 3 against the stored value. This keeps the 2 stored passwords secure so no one (not even 1 you) know what they are.

Score: 0

what kind of application is it? There are 2 many methods but if its ASP.Net it's common 1 to encrypt in the web.config file.

Score: 0

At spotep.com we only store the username 6 and a hashcode of the username combined 5 with the password. The benefit of this is 4 that similair (often trivial) passwords 3 wont result in the same hashcode (which 2 is stored in a cookie, and therefore very 1 unsafe).

Score: 0

You could try QSettings which provides persistent 3 platform-independent application settings. Solutions 2 like mysql would be overkill unless you 1 have hundreds of passwords to store.

More Related questions