Best Encryption Method?

[eluser]Unknown[/eluser]
Hey, guys.

I'm fairly new to CI, but even newer when it comes to general security measures.

What's the best way to encrypt important information in CI such as user passwords?

From what I understand, my main 3 options are:

- $this->encrypt->encode($password)
- $this->encrypt->sha1($password)
- $this->encrypt->md5($password)

Also, are the two last methods above any different from using PHP's default sha1 and md5 functions? Or are they the same thing?

Cheers!

[eluser]derBobby[/eluser]
[quote author="PhilTem" date="1322120378"]Correct me if I'm wrong, but it's actually working on two projects I worked on [/quote]

But on that way - as administrator - you will be able to decrypt the password of any user?

[eluser]WanWizard[/eluser]
Hashes are one-way encoded, you can not decode them.

And you should not want something else. Passwords are personal property, like the pincode on your creditcard. Not even an administrator should be able to have access to them.

As for password hashing, going method these days is:
- use a sufficiently random salt
- use a different salt for every user
- use either pbkdf2 or bcrypt to hash the combination of password and salt
- use a sufficient number of iterations (for pbkdf2 at least 10.000)

And if possible do not process passwords on a frontend machine.

Instead, use an API call to a secure server, pass the userid and password entered, and return an allow or deny. This way, if your frontend is compromised, the hacker will never be able to access the algoritm used, and the actual user data, because access is limited to what the API exposes.

You can do that with a standard mechanism like OpenID or OAuth2, or design your own API (but make sure it's secure if you do).

[eluser]Patrick Spence[/eluser]
[quote author="WanWizard" date="1351896655"]Hashes are one-way encoded, you can not decode them.

And you should not want something else. Passwords are personal property, like the pincode on your creditcard. Not even an administrator should be able to have access to them.

As for password hashing, going method these days is:
- use a sufficiently random salt
- use a different salt for every user
- use either pbkdf2 or bcrypt to hash the combination of password and salt
- use a sufficient number of iterations (for pbkdf2 at least 10.000)

And if possible do not process passwords on a frontend machine.

Instead, use an API call to a secure server, pass the userid and password entered, and return an allow or deny. This way, if your frontend is compromised, the hacker will never be able to access the algoritm used, and the actual user data, because access is limited to what the API exposes.

You can do that with a standard mechanism like OpenID or OAuth2, or design your own API (but make sure it's secure if you do).[/quote]

I ran across this article https://defuse.ca/php-pbkdf2.htm

It has a php implementation of the pbkdf2 setup, including control over number of iterations and hash algorighm... allowing you to change iterations and algorithm so older hashes are not broken.

The hashes it creates are actually in the format of algorighm:iteratsionsalt:hash so you just have one string to store that maintains the data that you need.

The code they give can easily be encapsulated in a helper.

[eluser]derBobby[/eluser]
PhilTem postet a method in which die encodes and decodes the password with some salt. That would then be unsafe? Is that correct?

[eluser]PhilTem[/eluser]
It's considered unsafe because you can decode the encoded string as soon as you know the salt and the encryption key (which by the way are stored in different storage systems - salt is stored inside the database, and the encryption key is stored in ./application/config/config.php, but that just as a remark).

The safest way of encrypting would always be going done a one-way street.

[eluser]derBobby[/eluser]
Then i wonder why his post was left like that for so long!

[eluser]PhilTem[/eluser]
You did see that I basically corrected my post? Well, I didn't correct it for two reasons: Didn't want to alter the flow of this thread and I don't think that it's that insecure. An admin should never ever - even if he's technically able to - read a user's password. Sure, this can be prevented using one-way encryption, but using two way encryption admins should just not use this direction of travel