D-Link exposes WiFi routers with new 'security feature' A new security feature added to some D-Link wireless routers actually makes users more susceptible to network intrusion, according to a hacker blog, which provides enough evidence to be taken seriously. Manufacturer D-Link was still busy congratulating itself for adding a CAPTCHA designed to prevent malware bots from logging …
An MD5 hash is not "notoriously insecure". It's neither secure nor insecure. It's just input passed through a hashing algorythm. A hashing algorythm is designed to take input and obfuscate it in a way that you can't get back the original input. That's all it does. It's not "notoriously insecure" because it does what it's supposed to do perfectly. It's not intended to secure anything. It's intended to obfuscate the original source input.
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?
You can't. You can only try to brute force the password by hashing lots of possible passwords to see if any of them match the hash i gave you. But even if they do, that doesn't mean you've found my password. Lots of passwords would generate the same hash output.
This is the difference between encryption and hashing. If something's encrypted, you can decrypt it back to the original source. If it's just a hash, you can't. It's a one way algorythm by design.
Example 2, I have an iso image of windows xp. It's 700meg in size. i run it through an md5 hash. The resulting hash output is 32 bytes in size. Can you see why you can't "decrypt" that back to the original 700 meg iso?
MD5 hashes are not insecure. They are what they are.
"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 :-)
But you CAN defeat a hash by finding an input that gives you the same hash as output. It's a known problem known as Hash Collision. MD5 has been discovered to be weak against hash collisions--given a known hash, a laptop could product a hash collision within hours. That IS a problem AND a weakness. That's why Certificate Authorities don't use MD5 anymore. In contrast, no one's been able to get an SHA collision for any given hash in any reasonable length of time with user-level hardware.
> 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.
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.
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?
"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 :-)"
Yes, if you know the salt being used. Do you?
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?
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.
Your comment @ 21:56 was great, yes, I think that would be way better!!!! Why did you bother with the second comment, it annihilated your image??
"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.
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.
The issue has been brought up on the D-Link forums (http://forums.dlink.com) in a number of topic areas. The only one I've noticed a response from a moderator is this thread:
http://forums.dlink.com/index.php?topic=5492.0
The SourceSec article on the flawed implementation is here:
http://www.sourcesec.com/2009/05/12/d-link-captcha-partially-broken/#more-159
"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.
"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."
Wow. It protects against brute force attacks.
Wonder why no'one in crypto thought of this foolproof plan before now.
"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.
The reason extra entropy is added to a password prior to hashing ( the crypt system call which performs this hashing has a parameter called salt with exactly this purpose) is to increase the required rainbow table size needed to crack the hashed result. Personally I doubt that using 2 hash algorithms in sequence is as effective as using the stronger of the 2 and a long and random salt. This is because a good rule of thumb to follow (Bruce Schneier's rule ?) is that complexity is the enemy of security and simplicity is its friend. Combining a known weak and a considered to be strong hash with similar objectives in mind, in my understanding is more likely to lead to design errors resulting in vulnerabilities.
SHA1 is now thought to have weaknesses, not yet known to have been exploited, though based on the history of MD5 these are likely to be exploitable in future. So some variant of SHA2 is probably now preferred, e.g. SHA512. For comparative information about the SHA family of hash functions see: http://en.wikipedia.org/wiki/SHA_hash_functions .
Also for many purposes a system using a weak hash algorithm and password is likely to be secure enough if the attacker can't obtain a copy of the hashed password and many repeated failed login attempts in a short period are logged and blocked. For similar reasons your home probably doesn't need a bank vault style lock and multilayer fireproof reinforced steel front door. There is very little entropy in your banking PIN, but banks having to balance user support against fraud costs seem to prefer people to have short PINs they can easily remember without having to write these down.
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
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
