I am writing an application that needs to read a user name and password and store them so that the program can read them again later. Storing it in some variables sounds like a stupid idea.
Found that KDE library, but it has too huge dependency, and I am too newbie programmer to understand how to use it.
What are the common Methods to storing passwords, and how I can solve my problem?
It depends on what you are going to do with the information.
If you are going to use the name and password to access some external service (but the user will have to reenter the information the next time the program is run), then storing them in some variables is OK. It might be wise to store them encrypted (at least, store the password encrypted) so that it is not visible in core dumps or the equivalent. When the password is needed, you decrypt it, use it, and then write over where the decrypted version was stored (zapping it). (Note: hashing is not appropriate in this context; you need to be able to see the password, and you can't undo a hash.) You could decide to store the information outside the program (in a disk file), but it doesn't seem necessary. Note that the binary will still contain the encryption key (and encryption algorithm), and encrypted data is more random than the average contents of your program, so to really conceal the encrypted password is actually very difficult (verging on impossible). However, you can make it hard enough that it will stop all but the most determined attackers.
If you are going to store the username and password as a permanent record so that you can validate that the same user is accessing the information in the future, then you must use storage external to the program; you will use a simple database, which might be as simple as a plain text file if you ensure you resolve any concurrency issues. In this case, you will hash the password with some salt, and you'll store the username, salt and hashed password in such a way that given the username, you can easily find the other two values.
Night Walker comments:
I use that password to access some web database, so I need it stored in my application after it is entered for the first time. Are you sure a plain text file is that smart an idea?
It depends on how you conceive 'stored in my application'. You can't modify the executable, or at least shouldn't try to do so. So, you need to look on it as a permanent record stored in some sort of file separate from the application executable. On the other hand, you do face a different problem from what I outlined - you are not authenticating the user with the information; you need to decrypt the information on demand to send on to other applications.
First off, that means that salts and hashes are not relevant; you need to reverse the masking operation, and you can't reverse a hash.
Next, you need to decide how you will identify the user of your application upon reappearance. Will the user be obliged to enter some password to get to their own data, or will you simply rely on the operating system privileges, or some other scheme.
If the user must enter some password into your application to get going, then you can consider using that password (or a hash of it, distinct from the password hash used to recognize the password to the application) to encrypt the username/password combination for the external application. You can then store the username and, for sake of argument, a Base-64 encoded version of the encrypted password into a text file; this is as safe as the application password, which is stored in the original salted hash format. When the user returns, they have to supply their application username and password, and you can validate that combination against the stored values, and then use the password to decrypt the password to the external application.
If the user does not enter a password, then you are more restricted in what you can do. You have to be able to determine a key somehow from the information available to you that can be used to store the user's encrypted password in a file in a restricted location such as a sub-directory underneath their home directory with no 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 because even if you combine a fixed key with the user's name, say, the chances are that someone can work out what that key is (and the encryption technology) and reverse engineer it. (The secrecy of encrypted data depends on the keys; when the key is determinable by the program, it is also determinable by a determined attacker. It is best, by far, to rely on the user to provide the key (or a password or pass phrase) at run-time; then the application does not store anything that an attacker can use offline.