@Anonymous Coward 20:40

"Example - My password is "N0t0r10usly1ns3cur3". I run it through an md5 hashing algorythm and give you the hash output. How do you work backwards from that to my password?"

I don't have too... I throw the hash into a rainbow list and it gives me a word that generates the same MD5 as your password. It might be your password, but it probably won't be... But that doesn't matter if the system in question is only storing the MD5 of a password and comparing that against any attempted passwords... I'm in :-)

ultimate protection :

Turn off wifi, snip off antennas', apply hot-glue to ethernet ports. I'd like to see them hack into that machine over the network...

Re: "Notoriously insecure hash"?

> An MD5 hash is not "notoriously insecure". It's neither secure nor insecure.

Unfortunately this is not the case... The MD5 algorithm has got known design flaws (the oldest of them being over 10 years old now) and produces hash collisions way too frequently for comfort. Given practical exploits of these problems have existed for almost four years, I would say MD5 no longer qualifies as secure.

Am I being dumb?

I don't know if I'm being dumb here, but surely, if you are able to recieve (and be able to intercept and understand HTTP GET) packets from the wireless network, then you must already be connected to the said authorised network? Therefore, you must already know the WPA password?

Granted, you will be able to access the routers config page and therefore change it, but it's not like you can sit next to someone elses WPA protected network and access their router config page, is it?

As I said, I may be barking up entirely the wrong tree, please tell me if I am.

(untitled)

good job i turned that stupid captcha off the second i updated the firmware then.

Hash security

Regarding using MD5 hashing as a security mechanism --

It seems that in the interests of security, many places want to store a hash of a user's password. That way, nobody can reproduce the user's password, resulting in increased security. By now, it's possible to brute-force MD5 to get a hash collision in relatively little time. So my question is this -- why don't we use two hashes? Take your input and run it through both MD5 and SHA1 hash algorithms.

For example, if your password is "password", then calculate and store the MD5 hash and the SHA1 hash of that. If someone finds an MD5 collision for "password", it won't matter because the SHA1 hash won't match. If someone finds an SHA1 collision, the MD5 hash won't match. This way, we can still use one-way hashing while gaining a much higher degree of security.

Does that make sense, or am I being stupid?

Hashes as security tokens

If someone wants to use a one-way hash for security, couldn't they call the algorithm twice, appending the input onto the end of the first hash for the second call?

For example, let's say our password is "password". For the sake of this example, let's assume the MD5 hash for "password" is 1a2b3c4d (yes, I know it's too short, but it's just used as an example). Furthermore, let's assume "crash" and "password" yield identical MD5 hashes. If we were using a single, one-time MD5 hash, a cracker would now be able to fake the password using "crash".

However, if our authentication function takes the MD5 hash of the password, appends the password, and gets a hash of the concatenated string, this collision would be meaningless. We would take the MD5 hash of "crash" (1a2b3c4d) and append the password, giving us an input string of "1a2b3c4dcrash". We would then generate the MD5 hash of "1a2b3c4dcrash" and compare it to our saved authentication hash. Because our saved authentication hash is the MD5 hash of "1a2b3c4dpassword", they would not match, so access would be denied.

Does that make sense, or should I, as they say, not give up my day job?

@Hans

"The whole point is, the authentication system does not know the real password, only the hash. If it knew the password, ppl could break it open and find the password."

Perhaps I didn't explain myself well. I didn't mean to imply that the authentication mechanism knew the actual password; when I spoke of the password, I was referring to the password entered by the user at the login prompt. The reason I used the text examples ("1a2b3c4d", "1a2b3c4dcrash" and "1a2b3c4dpassword") was to show that the second hash would not result in a collision even when a cracker found a collision for the first hash.

To clarify, I was envisioning a system which only stored a single hash (let's say MD5) as a password authentication token. This could, for example, be used to increase the password security without changing the structure of the database used to store the account details.

When a user account is created, the user enters their password. The account creation mechanism would take that password and calculate its MD5 hash. It would then take that hash, append the same password onto the end of the hash, and calculate the MD5 of that combined string. It would then store that second hash as the password token. After this point, the real password is never known.

When a user attempts to log in, they would enter their password. The authentication mechanism would take the password entered and calculate the MD5 hash, then append the entered password onto the end of the hash and calculate the MD5 hash of that new string. It would then compare that second hash with the stored hash.

@Chris C & two hashes

I see what you are saying, but I have a sneaking suspicion that it just gives you MORE data to use to crack the password, so that rather than getting an approximate password you get the actual password.

e.g. all possible words that make md5 hash of 1a2b3c4d is a 300 item list. All possible words that make an SHA1 hash of xyzxyzxyz is a 5 item list. Only one item appears on both lists, the actual password. Given that most people use the same password for everything you now have access to all their accounts not just the ones covered with md5. My brain hurts now.

@Simon Neill re: two hashes

"I see what you are saying, but I have a sneaking suspicion that it just gives you MORE data to use to crack the password, so that rather than getting an approximate password you get the actual password."

I thought about that after I posted that comment, and that's the conclusion I reached as well. As unlikely as it would be to be able to guess/crack a good password by matching the hashes from two algorithms, it would be relatively trivial with a rainbow table and a bad password (such as a common word). That's why I posted my second comment (single algorithm used twice). It's extremely unlikely that anyone would have a rainbow table of those types of hashes.

After a bit more thinking, let me propose this as an even more secure authentication method (using a single hashing algorithm):

1. Take the password and calculate its hash.

2. Append the password onto the end of the hash string. However, instead of appending the password as-is, take a piece of non-changing account information (such as the account creation date) and use that to alter the password. For example, if the account was created on a Sunday, rot-13 the password before appending it to the string; if the account was created on a Monday, base64-encode the password before appending it; Tuesday = reverse-case the password; Wednesday = reverse-direction the password; etc.

3. Take the concatenated string from step 2 and gets its hash. This is the hash to store during account creation and used to authenticate the user's password.

By using a variety of different obfuscation techniques in step 2, in addition to using the hashing algorithm twice, I would venture a guess that this virtually guarantees the password could not be cracked via a rainbow table, by a collision, or by any brute-force method in the foreseeable future.

re Chris C @ 13:55

The problem is is that there is still an md5 or sha1 hash to rainbow table with, and though your password may be crazy complex and impossible to brute force with reasonable hardware, the hash may still collide with the hash for dog.

Fourth attempt?

"The problem is is that there is still an md5 or sha1 hash to rainbow table with, and though your password may be crazy complex and impossible to brute force with reasonable hardware, the hash may still collide with the hash for dog."

That's true. For every hash, there will always be collisions. The point of my comment was that a cracker would not be able to use a rainbow table to find a collision. The end result would be that the cracker would need to brute-force to find a collision (either trying to brute-force the authentication algorithm, or by creating a new rainbow table using the authentication algorithm).

So, if anyone is still reading these comments, how about this:

1. Take the user's password, append a piece of non-changing data, and generate the MD5 hash of the concatenated string.

2. Take the MD5 hash, append the user's password, and append a piece of non-changing data, then generate the SHA1 hash of the concatenated string.

3. Store the MD5 hash and the SHA1 hash as the user's authentication tokens.

Because the two hashes are not derived from identical strings, a cracker could not find matching collisions to get the original password.

Wireless Security

Good article. People will have to take protecting their privacy into their own hands. A great tool I found for WiFi security is Covert Surfer. It is a software application that is designed to encrypt your Internet connection wherever you are at. It also prevents cookies from collecting information about you as well. You can operate completely from a flash drive so you can use it on multiple computers. Smart Computing Magazine just did a great review on it. I found it at www.covertsurfer.com