Hi,

I’m trying to use the encryption library to encode passwords in the database. I was using md5 until now but now the application need to be able to decode passwords back somehow.

Using the encryption library, it seems that every time I encrypt a value I get a different encrypted value.
The library is able to decrypt back any of those encrypted values back to the original value but that’s preventing me from doing simple database queries where it should match the encrypted password in the database to an encrypted login value for instance.

Am I missing something? Is there a way to make the library always return the same encrypted value every time?

Thanks
Ben
ps. Development machine is Windows 2k3 with Apache 2 & php 5.2.4 with mcrypt installed. CI is 1.6.3

Show us your code implementation, so we can point out any problems that may exist. (feel free to trim up the example so only what we need to see, is shown)

The encryption library is using the timestamp to create an encrypted value to make the encryption a bit harder to break. So if you want to do a login routine you need to decrypt the value and compare it with the input.

Hi Jon,

Thanks for taking time to help.

There’s not much code around it. I can put it down to a simple controller method like so:

every time I load that page, the result of the encryption is different

etc etc

ps. I’ve tested and all those different values always decode back to ‘test’ somehow.

Ben

xwero - 01 October 2008 08:22 AM

The encryption library is using the timestamp to create an encrypted value to make the encryption a bit harder to break. So if you want to do a login routine you need to decrypt the value and compare it with the input.

interesting, how does it know how to decrypt, wouldn’t it need to be aware of the timestamp used?

xwero - 01 October 2008 08:22 AM

The encryption library is using the timestamp to create an encrypted value to make the encryption a bit harder to break. So if you want to do a login routine you need to decrypt the value and compare it with the input.

mmmmm, that’s a bummer. Is there a way to disable that extra feature? I’m not that paranoid.

Ben

Jon L - 01 October 2008 08:29 AM

interesting, how does it know how to decrypt, wouldn’t it need to be aware of the timestamp used?

I’ve used that before actually, the timestand is just part of the value that gets encrypted, it’s not used for anything than making the encrypted value look different. Doesn’t actually add anything to the security check.

Ben

I’m looking at Encrypt.php, there’s no reference to any type of timestamp that I can see.
Unless mcrypt itself is using a timestamp, there doesn’t appear to be one in use.

The class does seem more advanced for encryption, regarding use of xor, plus mcrypt, plus base64.
So it appears there are 2-3 layers going on.

Ben, are you supplying a key (whether via config or passing via the encode method?)

Jon the decrypt method knows this and also the encryption key so there is nothing in the way to show the original value. Check the methods to see how they done it.

Ben it’s hardly an extra feature but using two-way encryption is already wiped off the table if you want to provide your users solid secured data as encryptions can be cracked. If you want two-way encryption you have to live with the encrypting/decrypting routines.
What you can do if you insist on having a encrypted value to check is add an md5-ed field of the password to the table.

Jon L - 01 October 2008 08:36 AM

Ben, are you supplying a key (whether via config or passing via the encode method?)

Yes, I’ve set that already.

Had a look at the Encryption class file, does seems fairly complicated. I’ve tried disabling some of the features but it’s still randomising a lot.

Never mind, I’ll just have to loop through records, decrypt and compare one by one rather than comparing encrypted values. 

Ben

xwero - 01 October 2008 08:46 AM

What you can do if you insist on having a encrypted value to check is add an md5-ed field of the password to the table.

I like that idea!

Maybe a sha1 field would be better, as there are many websites now that store known md5 hashes for passwords (i.e. - they show the password and the md5 hash that represents it), so if someone ever gained access to your database, they could easily determine most of the md5 passwords present.

sha1 is also crackable and two way encryption is too. If you want to go for secure pass words the only way to go is using sha1 and a random salt.

Yup, you definitely want a one way hash with a salt.  I like the method described here.