It's gotta be out there somewhere. I mean, if encrypted passwords and sensative information can be stored in a MySQL database, then recovered, there has to be a method of unencryption, right? How is this done?

There's no 'unencryption' as such, but someone with a lot of time (or computational power) on their hands can just try hashing millions of possible combinations of characters until they get a hash that matches the original hash, thus getting the original string used to generate the hash (or, in some cases, such a database of combinations already exists [frequently called 'rainbow tables'] which could be used to look up a hash).

It's not hugely difficult to make both of these types of attack unfeasible if your implementation of hashing is robust enough.

If it could be done easily, nobody would use it. The point in a hash is that it is normally one-way.

As mike said, it all depends on what and how it was hashed. If the data is large or the hashes are salted then forget it - it's going to be too difficult. If it's short unsalted data then it may be possible using brute force or rainbow tables - but don't bet on it.

Just using a salt will not protect against brute forcing if you're using plain old MD5 or SHA1. It may take a while, but not too long by any means.

It will if it's a long salt. Salt = increased length = more infeasible.

The length of the salt has no practical impact on the difficulty of brute forcing. Security through obscurity isn't really security at all - we must assume that an attacker has the salt (and if they have the hash, chances are they would have the salt); when you have the salt, its length does not matter at all.

Salting will greatly decrease the likelyhood of cracking it through rainbow tables. However, it does no good with brute force. Also, the longer the salt the better. Now, granted, I haven't done any work with hashes in the new dual-and-quad-core age, but brute forcing anything over 8 chars usually takes months, assuming it's not a dictionary word.

Rainbow tables are by far quicker, usually taking only up to 2 days or so to crack a 14-char letters/numbers/symbols pass. I used to have a setup that could crack most passwords in 3 days or less. The tables took up nearly 500GB of hard drive space though, so I got rid of them a few years ago.

Not really. To an amateur/script-kiddy perhaps, but not to someone who knows what they are doing and has the equipment to do it. If your data is irrelevant enough that nobody other than script-kiddies, doing it only for the thrill, would want to get their hands on it, then consider avoiding password based schemes entirely as they may put your users' passwords at additional risk from 'genuine' attackers.

Again, I don't want to start a new thread, so could someone tell me how to make a configuration file for EasyPHP, so I can turn image #1 into image #2?

- Brandon

Heck, I'll just start a new thread.

_

Attached Images

	screenie.PNG (68.4 KB, 8 views)
	mysql5.jpg (7.5 KB, 6 views)

I'm not sure how effective this is, but to greatly increase the time taken by brute forcing, I've heard people including a php execution pause (of a few seconds) between checking for password authenticity, and sending a reply back to the browser. Any ideas if there is any point to doing this?