+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Using CodeIgniter (https://forum.codeigniter.com/forumdisplay.php?fid=5)
+--- Forum: Best Practices (https://forum.codeigniter.com/forumdisplay.php?fid=12)
+--- Thread: How to store password (/showthread.php?tid=62542)
How to store password - ignitedcms - 07-26-2015
Hi guys,
I've just updated my password hashing to now use password_hash() instead of crypt() but I have another question. Thanks to narf and mwhitney.
In my CMS I'm sending email via SMTP or phpmail.
How do I store the SMTP password? Obviously I can't hash it as I would need to get the password in plain text to send the email so should I encrypt it and store in the database. Storing it as plain text just seems stupid? What is the best practice here? I never really thought about this one.
RE: How to store password - ivantcholakov - 07-26-2015
I faced this problem before and initially my solution was wrong for which I was badly punished. :-)
Now I have a library that keeps settings within the database with ability to encrypt certain setting at will. https://github.com/ivantcholakov/starter-public-edition-3/blob/v3.0.48/platform/application/libraries/Settings.php
See the method set:
public function set($key, $value = null, $encrypt = false)
Let us say we have the setting 'smtp_password'. If it is stored within the table in plain text (we don't want this), the key within the table 'settings' would be 'smtp_password' too. Encrypted 'smtp_password' (we want this) would be stored under the key 'smtp_password__encrypted'. This is how I distinguish non-encrypted and encrypted settings. Another way is a database field (as a binary flag) 'encrypted' to be added, but I did not want to change the structure of the table anymore.
While an encrypted setting is retrieved, it gets decrypted automatically, you don't have to worry about that.
Perhaps you have something for storing settings within a database table, upgrade it in a similar way, I think it would be fine.
RE: How to store password - ignitedcms - 07-26-2015
Yes that what I was thinking, but since the decryption key needs to be stored somewhere, normally in the config folder, if someone gained access to my database and config folder they would be able to retrieve the smtp password.
But I guess in that case I'm pretty much f'ed up anyway. At least with one time hashes that can't happen, well I say can't it depends on the strength of the hashing algorithm.
In any case at least encryption provides some security measures. Thanks for the reply.
RE: How to store password - ivantcholakov - 07-26-2015
I would be glad to know if somebody can imagine a better way...
RE: How to store password - mwhitney - 07-27-2015
The obvious benefit to encryption is that they have to get multiple pieces of information to decrypt the data (or brute-force it). The strength of the encryption you use will determine how long it takes to break the encryption (assuming the passwords are strong enough; a weak password will fall to any number of variants of dictionary attacks before a more thorough brute-force attack).
If either the encrypted password(s) or the key is compromised, you'll want to change both as soon as possible. If both the encrypted password(s) and the key are compromised, you're in the same boat. At least if it's only one or the other that's compromised, there's a smaller chance that they'll get to use the passwords to compromise other data/systems.
Finally, and this would hopefully go without saying, you want to make sure you lock down the systems and figure out how they got in. If you changed the password(s) and encryption key before figuring this out, assume they got the new data, too, and change it again after you lock them out.
The reason we use hashing instead of encryption for user passwords is simply because it is more secure (because, theoretically, you can't just decrypt a hashed password) and we only need to know whether the user knows the password; we don't need to know what the password happens to be.
In the case of passwords the system needs to perform its own duties, especially passwords which the users should not know (or even be aware of in the first place), you rarely have a choice other than encryption, because you need to be able to retrieve the original password. The only other option is to have some other form of authentication/authorization configured between the two systems (or the web server/application and the service being utilized). In most cases, something like that would be configured transparently, so CI would access the service (say a mail server, for example) as if there was no authentication required.