Tonto

I was making a program that stores login information from a user, just so that they don't have to enter it every time. I was just wondering what sort of security measures I should take in storing the information in a file?

I know there's lots of ways to do things but I just don't think I can store the hashes only, and I was wondering what kinds of encryption might be good to use for this application

__________________

╔╗╔╦══╦╗╔╦══╦╗
║╚╝║╔╗║╚╝║╔╗║║
║╔╗║╠╣║╔╗║╠╣╠╣
╚╝╚╩╝╚╩╝╚╩╝╚╩╝

codez http://code.google.com/p/zxcvbn/

Sebastiani

>> I know there's lots of ways to do things but I just don't think I can store the hashes only

Why would you think that?

>> what kinds of encryption might be good to use for this application

Currently, I think the SHA-2 and variants are recommended over MD5 and SHA-1, as there have been weaknesses found in the latter ones.

Besides this though, you should also consider that an attacker may be able to override the security by altering the executable on disk or the program in memory. These are much less likely risks, but nonetheless quite real.

EVOEx

I think he means he's going to store other sites (or similar) login information. Which means he also has to decrypt the password again.
Look into openssl. It has the capability of a private key file with a password protection. But still, if someone would be able to hack the computer, he could simply detect your keystrokes to find the password. So it provides only backwards security, not forwards. That is, if it's hacked, nothing is compromised directly, only in the future.

m37h0d

edit: correction. the one i was thinking of is this one

http://hoozi.com/Downloads/AES_Encrypt.rar

matsp

The key to ANY security situation is the balance of threat vs. extra complexity. If your most valuable item is a half-read softback book, you may not need the Fort Knox security, right?

Who are you hiding the password from? Some spy organization (CIA, FBI, KGB etc) or someone in your family (assuming they are NOT CIA/FBI/KGB)?

So you are storing passwords for what? And on what machine? Who has access to that machine? What is the "threat" and what may be the "loss". If you are keeping passwords to open Fort Knox you need more protection than if you are keeping the passwords of a user to Cprogramming.com.

In the latter case, you may find that it's sufficient to encrypt using a xor-encryption (perhaps using some clever tricks to get the initial key). Obviously, that would not be enough in the former case!

--
Mats

__________________
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.

linuxdude

You should look into salts if you want a secure password store. Linux stores (encrypted) user passwords in a file /etc/shadow. However, it is secure because it is only readable by root and even if your root account is compromised, the encrypted password suffixed with a salt. This way even two identical passwords are different + there is an added protection against dictionary attacks.

matsp

It is also one-way encrypted, which if you want to send the password matching an account at cprogramming.com's forum, won't work. It is POSSIBLE to crack the passwords in Unix systems by trying passwords and knowing the salt - but it is not possible to get the original password back if you haven't got a "guess" to encrypt and then check if the "guess" matches the encrypted value.

--
Mats

__________________
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.

tjb

If this is for logging onto services that you do not control (meaning, you need compatibility with existing systems), the only way to store the information in a somewhat secure fashion is to use a master key (a decryption key, usually provided by the user, that decrypts all of the secured information in a password database). The disadvantage is that the user is required to remember at least one password, though the user should only have to type in the password once per session. Depending on the situation, care may need to be taken as to how this information is stored in memory, as a program that can read the process's memory could compromise this information.

The more information that you store about an account, the more likely that information could be compromised. Security is usually inversely proportional to convenience.

Mario F.

It's my guess any method you choose Tonto, will always be hackable if you allow the encryption/decryption process to occur in the application. It would be useful to know how you plan to store the login information.

Assuming you plan to store it on a database in a three-tier environment, you should rely on the database own encryption methods. This provides you with a reliable secure system, since it takes the whole process away from the application user. They would need to hack into the database, not the application. And the database, again assuming a multi-tier structure to your application, would not be accessible by the user.

To illustrate... assuming MySQL, you could use the SQL functions AES_ENCRYPT and AES_DECRYPT with the key stored on the database also. These functions would reside inside stored procedures. The application would only pass the password entered by the user and the stored procedure would get they key from the database itself and validate the password. It would only return success or failure.

__________________
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.