|
Posted by John Hyde on October 31, 2005, 2:06 pm
If you were Registered and logged in, you could reply and use other advanced thread options
>
> John Hyde wrote:
>
>>on 10/26/2005 4:55 PM ShadowEyez said the following:
>>
>>
>>>The arguments for security vs. practicality are all nice, but if have a
>>>business that has ANYTHING sensitive being transmitted over the air, DO
>>>NOT use WEP. It is trivial to break - trust me.
>>
>>
>>Yeah, I got that message loud and clear.
>>
>>
>>>WPA with a password (WPA-PSK) is can be brute-forced by an entity with
>>>enough computing power (read: $$$) and because of this most businesses
>>>use a radius server with WPA. Most of your cards probably support this
>>>with a driver and/or firmware update, and win XP with SP2 has the
>>>software for connecting securely to a radius server with WPA.
>>>
>>
>>So, in a brute force attack, how long does it take to try each possible
>>permutation? Surely this is a matter of sending each permutation to the
>>wireless access point and having it accepted or rejected. So how many
>>can you try a second? I assume the limitation is not processor speed,
>>but the turn around time for the wireless nodes to attempt a connection.
>> I have no concept of how long it would take an attacker. I know that
>>when my laptop attempts to connect to a wireless, it takes a few
>>seconds. Some of that time is also negotiating the rest of the
>>connection, so how long is spent up to the point of a WPA password being
>>accepted or rejected? This really is the question for whether a
>>password can be brute forced in the real world.
>>
>>If I understand the math correctly, a password made up of 5 "diceware"
>>words (from a dictionary of 7,000 right?) would have 7,000^5 =
>>1.68*10^19 possible passwords.
>>
>>If you can do 10 a second, that works out to 315 million tries a year
>>(3.15*10^8) so it will take about 10 million years.
>>
>>On the other hand, if you could transmit one attempt each clock cycle of
>>the sending computer (I assume bus speed, not cpu speed) say 333 Mhz,
>>then the tries per year is 1.05*10^16. It would still take 2,000 years
>>to try all the permutations, but someone might consider this a possibility.
>>
>>Of course, if the attacker does not know that they are attacking a
>>Diceware passphrase, then they'll have to try all the alphanumeric
>>combinations of the same length (Diceware words are 5 letters, right?)
>>so upper and lower case, numbers and the symbols over the numbers only
>>
>>So, 26 letters, upper and lowercase, that's 52, 10 numbers and 10
>>symbols and a 25 character password. Uh that would be 72^25 or
>>2.71*10^46. So, even if you can send one attempt a clock cycle (which I
>>doubt) then it will take you 10^30 years.
>>
>>But perhaps "brute force" means something else. I'm certainly no
>>cryptographer. (And not much of a mathmatician either).
>>
>
> WPA is dependent on CPU speed, and here's why. When attacking WPA with
> programs like Aircrack or COWpatty, the attacker first captures the
> 4-packet association that WPA always does. With WPA2 they optimized it
> to 3 packet - same in principle but no common software tries to crack
> WPA2 AFAIK - this does not mean it's hard to do for a good programmer.
>
> From what I understand WPA's 4-packet association has a
> challenge-response in it of a Pre-Shared Key that is hashed (calculated)
> using the user-supplied password and the ESSID (name) of the network.
> Once the attacker has the captured packets (usually in a .cap file)
> (s)he runs the program which basically calculates the hash from the
> essid and every password in his/her dictionary.
>
> Paranoia says if a really good attacker wanted to, (s)he could make a
> program to go through every combination of pre-shared key (which is 64
> HEX digits, so 0-9 and A-F), not even attempting passwords but would get
> any possible key, which would take a _long_ time. Reality says use a
> good password (not in a dictionary, I'm assuming you know the rules) and
> you'll be fine.
Uh, I think they'd be better off with passwords. The math on those
permutations: 16 hex digits, 64 in length = 16^64 = 1.15*10^77. If I
were buying the CPU time, I'd take 10^46 any day.)
>
> As a point of reference, I have a 3 ghz intel CPU which can go through
> around 120 passwords/sec on aircrack. I shutter to think what NSA or
> even a big/well funded company can do with mainframes and clusters of
> servers ;-)
>
Ok, that's an interesting data point. Note my "one try per clock cycle"
example above. Here's that math:
333 Mhz = 333,000,000 cycles per second.
333,000,000 * 3600 (sec/hour) = 1.19*10^12 or 1.19e12
1.19e12 * 24 (hour/day) = 2.87e13
2.87e13 * 365 (day/year) = 1.05e16.
If you assume that you can get one try per clock cycle, then this is the
number of tries per year. To figure the number of years, you can
divide, but it's close enough to just subtract exponents.
That's where the "10^30 years" came from" (1.0e30).
So how can a well funded company do? Assume from your example that they
have software/hardware that is 10 times as fast = 1200 passwords/sec.
They will need 277,500 such machines working together just to get to my
333 Mhz range.
Naturally you can slice and dice this anyway you want. Give me more
assumptions and I'll give you another ridiculous number of years (and
$$$) to brute force my password. Actually, I can give you a guaranteed
way to "crack" the passwords on my home network. Calculate the cost to
run a server farm of 277,500 for even one year (make sure that you
include hardware, maintenance, etc. or a fair market lease rate), and
then pay me instead. (Cash only please, I'll be opening new bank
accounts) Remember that even with that install, you are still looking
at 1.0e30 years, and I'll guarantee an answer in much less time. ;-)
Regards,
JH
>
>>>MAC filtering is useless, as any one who knows what they are doing can
>>>bypass this, as you don't even need to crack encryption to see the MAC
>>>address.
>>>
>>
>>Well, that was one of my questions, "is the MAC encrypted by WEP?" I
>>guess this would be a "NO." Still, I would not say MAC filtering is
>>totally useless. At least it forces an attacker to wait around until I
>>connect to see what an acceptable MAC address is. Not much of a burden,
>>but it prevents a "drive by."
>
> Think of it like this - if someone wanted in and could get through WPA,
> do you really think MAC filtering would slow them down ;-)
>
> ShadowEyez
>
>>>Hope this helps,
>>>ShadowEyez
>>>
>>>John Hyde wrote:
>>>
>>>
>>>>Greetings,
>>>>
>>>>I am in the process of setting up wireless access in our small office.
>>>>The wireless access point hardware I have seen is all equipped to do up
>>>>to 128 bit WEP encryption and MAC filtering. A couple of questions:
>>>>
>>>>1. I have read that WEP is broken. Is it really? Do I want to use
>>>>something else? One of the laptops that will be connecting is a few
>>>>years old and it's built in wireless supports WEP 128 but not other
>>>>encryption as far as I can tell.
>>>>
>>>>2. MAC filtering seems to me to be a great idea. Adds a layer of
>>>>security. If WEP is enabled, is the MAC address of the laptop also
>>>>encrypted? Does it matter?
>>>>
>>>>3. Thinking out loud now. If my laptop is busy looking for wireless
>>>>access points, and transmitting it's MAC address in the clear. Assume an
>>>>attacker learns my MAC address. Then I get to my office and log on to
>>>>the Wireless Access Point. It requires that I send the MAC encrypted.
>>>>Does the attacker have a crib that will them to pry open WEP 128? If
>>>>so, am I better off with just WEP and not MAC filtering?
>>>>
>>>>
>>>>Thanks for all your thoughts,
>>>>
>>>>John
| 
XML site map