Welcome Guest, Not a member yet? Register   Sign In
How to store password
#1
Smile 
(This post was last modified: 07-26-2015, 02:50 PM by ignitedcms.)

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. Big Grin


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.
Practical guide to IgnitedCMS - Book coming soon
Reply
#2

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...ttings.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.
Reply
#3

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.
Practical guide to IgnitedCMS - Book coming soon
Reply
#4

(This post was last modified: 07-28-2015, 12:50 AM by ivantcholakov. Edit Reason: a typo )

I would be glad to know if somebody can imagine a better way...
Reply
#5

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.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB