encryption and decryption

ramsonphp

which function is better to encrypt data and for decrypt in php

bogu

U can try this one ...
Mcrypt Encryption Functions

MarkR

Normally you should not need to do encryption / decryption in PHP as it should be handled at a different level. Describe what you're trying to achieve and let us suggest a solution.

Mark

ramsonphp

Well,i just wanted to store the information like password in database in encrypted form while registering users and decrypt them while retrieving from database to show the actual password for the authorized users.

bogu

ramsonphp wrote:
Well,i just wanted to store the information like password in database in encrypted form while registering users and decrypt them while retrieving from database to show the actual password for the authorized users.

This stuff are done like this:

use md5() encrypt when u store in DB, if he forgot his password u generate a password change it in DB, send him an email with the new pass and have a section in the site where he can reedit his pass ...

ramsonphp

Okie i'll use md5() encrypt while storing in DB and if he forget his password how am i supposed to know the original password without decrypting it ..so i need decrypt function too . i think md5() is oneway

MarkR

If you store the password hashed, you can still check it by hashing the supplied password with the same algorithm / salt, then comparing the hash values.

This would work for md5.

As far as storing data generally encrypted in a database:
- It's pointless because you'd have to store the key on the server to decrypt it; someone who compromised the server could also get the key
- It breaks indexing (for columns which need to be indexed)
- MySQL and other databases support SSL connections anyway, so if you're worried about interception between your web app server and your DB server, use that instead.

Storing hashed passwords in the database is one option- but in my opinion it's no more secure than storing plaintext ones.

Mark

donsjuand

MaRk R:
Could you expand on that opinion so we understand why you think storing hashed PWs is no more secure?

What do you think about using the Dispatch Method on this page (http://phpsec.org/projects/guide/1.html#1.2) to refer to a main security cases php file that allows a connection to hashed password with a seperate salt in a mysql db?

Also, you implied this is done on another level...which level is that? What would you suggest?

MarkR

donsjuand wrote:
MaRk R:
Could you expand on that opinion so we understand why you think storing hashed PWs is no more secure?

Because you should presume that the database has not been compromised. If the database is compromised, your entire application's data are available to an attacker anyway.

Moreover, they can easily do dictionary attacks against hashed passwords. And they probably have more than enough information to do social engineering attacks anyway.

What do you think about using the Dispatch Method on this page (http://phpsec.org/projects/guide/1.html#1.2) to refer to a main security cases php file that allows a connection to hashed password with a seperate salt in a mysql db?

Erm, I think you're trying to do several things at once. There's nothing wrong with the dispatch method, and there's no problem using hashed passwords (except a false sense of security), but I fail to see how combining them is more interesting than using them individually.

Also, you implied this is done on another level...which level is that?

HTTPS will encrypt all data between the client and server - this is clearly advantageous as it prevents interception of sensitive data.

Encrypting connections to the database is also possible - but is only required if you have an untrusted network between your web app server and database.

Normally this is not the case.

What would you suggest?

Use hashed passwords if you want to, but don't encrypt anything else at the application level - it's simply unnecessary and will cause severe headaches.

Work on the assumption that your application server and database server have NOT been compromised (obviously, try to keep them that way) - as there is no way to protect your data if they have.

Mark