If you consider yourself a hacker and you are writing a zombie script that will try to guess someones password

First of all, this isn’t how a hacker will work.
They will first and foremost discover everything possible about the application, server environment, and use this to discover possible vulnerabilities.

A ‘zombie’ script is always the last resort, as it takes an almost infinitely large amount of time, it’s intensive, and the hacker will get blacklisted by iptables before they’re even close to getting a password.

A sha1 salted hash can only be cracked with brute force…
To crack a sha1 hash with brute force, you may have to try 2 to the power 80 attempts. Way too much for any hacker to attempt.

Whereas, in the event of your encryption key being discovered (due to the ‘clever’ hacker probing your server environment, php version, ci version, and finding a vulnerability), a hacker could use the encryption key to get your passwords with no effort at all.

It’s much much more likely you’ll be hacked after an extensive recon task and research rather than through blind luck or brute force.

What i do using decodable passwords is to add a value to the password and cut it off when i display the password. So they have to find that second value too before decoding.

@Elliot

looking at the hashing algorithm does not grant access.

Let me give you an example.
I use MD5 both on the client (javascript) and on the server

1. My server creates a key at random (i.e. qwer) and both stores it in the server and sends it to the client
2. User enters “mypass” on the browser and hits “Send”
3. javascript sends md5(“mypass”+“qwer”) to the server for validation
4. server recieves a weird hash. retrieves the real password for the user, (decrypts it if encrypted) and then appends “qwer” to the end and calculates its md5.
5. If it matches the weird hash sent then login worked fine.
6. Otherwise, the key is discarded and a new one is sent to the browser i.e. “zdrtfxc”

Now, the idea behind this is that on every request, the password sent will look different on each request even when its always the same. So if someone steals it from he packages being sent, it will be useless because the server will already be waiting for a different hash

The whole process seems pretty secure… the only vulnerability is that the password stored in the database uses a 2-way encryption method, which is possible to decrypt… remove this vulnerability, and then it’s properly secured.

Instead of using $config[‘encryption_key’] for the encryption salt, just randomly generate a new salt for each new password. But be sure of also inserting the salt in the database

I am glad I sparked such huge debate, and got great discussion out of this. I learned a lot and will defiantly implement some of the ideas here into my project, when I read the thread more throughly I may have some questions. This should possibly be stickied as it is a very important topic.

fdog - 16 February 2008 12:17 AM

Instead of using $config[‘encryption_key’] for the encryption salt, just randomly generate a new salt for each new password. But be sure of also inserting the salt in the database

Storing the salt in the database is less safe than putting it into a php file because a clever hacker will see the connection.

I agree with Elliot decodable passwords can be a security risk but if they can see the passwords they can also see the data they are really after. The only thing they can’t crack is the password which isn’t always the main target for a hacker.

If you are paranoid you will encrypt all hacker valuable data but it will reduce performance.

Let me just throw my view in. I have done a cryptography course at degree level. let me just say one thing, if you have a two way encryption algorithm it can be broken very easily. You don’t even need the key, if you know how it works (the algorithm) most can be broken by simple processes.

If someone really wants some data you store they will be able to get it, doesn’t matter how much you encrypt it. The only way you can stop it is to make the process so hard the data isn’t worth it to decrypt it.

I store my passwords using a SHA-1 with salt method. I would advice you all to do the same. DO NOT use two way encryption just so the password can be made into ****‘s. This is crazy, just say to the client NO. Your the expert they should listen to you, and if they still refuse print out a random length string of **‘s or something.

So just to clarify, use SHA-1 with salt, its the best there is at the moment. I know SHA-1 has been broken but unless your a crypto-geek its probably the best and easiest to use.

So you are saying encryption is useless?

No I’m saying its useless if you use basic methods. As said before even the SHA-1 with salt can be broken, its just very HARD. So don’t think there’s no point then to using encryption, there is, I just don’t want anyone here thinking anything is safe. Because its not, make sure you use a clever method thats all, and don’t do silly things.

How many hackers will want to brute force crack a SHA-1 string just to gain access to a small website? None, if you have more important data I would go talk to someone with the latest knowhow of cryptography.

adamp1 - 16 February 2008 03:15 AM

Let me just throw my view in. I have done a cryptography course at degree level. let me just say one thing, if you have a two way encryption algorithm it can be broken very easily. You don’t even need the key, if you know how it works (the algorithm) most can be broken by simple processes.

If someone really wants some data you store they will be able to get it, doesn’t matter how much you encrypt it. The only way you can stop it is to make the process so hard the data isn’t worth it to decrypt it.

I store my passwords using a SHA-1 with salt method. I would advice you all to do the same. DO NOT use two way encryption just so the password can be made into ****‘s. This is crazy, just say to the client NO. Your the expert they should listen to you, and if they still refuse print out a random length string of **‘s or something.

So just to clarify, use SHA-1 with salt, its the best there is at the moment. I know SHA-1 has been broken but unless your a crypto-geek its probably the best and easiest to use.

I’m sorry, but this bugs me. Not that you aren’t right (well, except for SHA-1 being the best there is, there’s SHA-256, SHA-512 ), but two-way encryption is redundant. Just like how Microsoft says reversible encryption. Encryption is, by its very definition, reversible. (A)Symmetric ciphers, block ciphers (eg. Fiestel Network), they are all encryption and are two-way in definition.

Hashing on the other hand is one-way. It cannot be reversed. Sure, you can get collisions, run birthday attacks, brute force it, and various other attacks, but you cannot reverse it. At the end of the day, you get a string, compare it to the hash you are trying to find, and keep going. Contrast that to the Level 7 Cisco passwords which can be broken in under a minute because they used sorry encryption algorithms instead of hashing (ala Level 5).

As for handling passwords, phpBB (my favorite bb software) [disclaimer: I used to be on the team, handling support and security] uses a slightly modified version of this: http://www.openwall.com/phpass/, which came highly recommended from SektionEins (http://www.sektioneins.de/). I would suggest you too look at it.