ProtectmyID had a good writeup on WLAN security today. I think this is one of the writeups on this topic which contains the least amount of FUD and you can't go wrong with following its advice. However, I think a couple of improvements could be made.
First off I'd say that MAC filters these days are a waste of time as a MAC address can be easily spoofed. The time required to manage a MAC filter can be better spent elsewhere. If someone can crack your encryption, a MAC filter won't stop them in the least.
Next while I agree that WLANs are commonly used in most household, I think the first security precaution for a WLAN should be if you don't use it, disable it at the router.
Lastly, I'd like to emphasize what I think are the important points:
#1 enable encryption (WPA2 or WPA)
#2 change the password at the router
If you follow these 2 points, your home WLAN is relatively safe.
Thursday, October 21
Good WLAN Tips
Monday, October 11
The problem of 2^64 − 1
I was just looking at the securing coding practices at the CERT website and ran into a topic that has always been a pain point for me and that is the validation of pointers in C.
Growing up coding C, I was constantly exposed to the mantra of 'Check for NULL pointers'. Now it is hard to argue that NULL pointers are not bad, but I do think that when to check for them is not that straight forward.
Obviously, when trying to allocate memory one should verify that the memory was allocated and that NULL was not returned. What isn't so clear is when is there value to checking for NULL. I've been in several organizations and dealt with developers that demand that all functions that accept a pointer,check that pointer for NULL. The argument being that we don't want the code to try to use an invalid pointer. One issue I have with this broad approach is that it leads to horrendous code bloat.
Just look at one pointer that gets passed through a couple of wrappers to get to the actual code that will do something with it. For each function it passes through, we have said that it should be checked to insure that it is not NULL. So, for some number of times we have verified that the pointer is not one of 2^64-1 possible values. Since at any given time a pointer has only one truly valid value [if its not referencing the data it should,its not valid], then it can be said that it has 2^64-2 invalid values.
So, what does checking for NULL over and over accomplish? It eliminates 1 out 2^64-2 possible invalid pointer values.
Growing up coding C, I was constantly exposed to the mantra of 'Check for NULL pointers'. Now it is hard to argue that NULL pointers are not bad, but I do think that when to check for them is not that straight forward.
Obviously, when trying to allocate memory one should verify that the memory was allocated and that NULL was not returned. What isn't so clear is when is there value to checking for NULL. I've been in several organizations and dealt with developers that demand that all functions that accept a pointer,check that pointer for NULL. The argument being that we don't want the code to try to use an invalid pointer. One issue I have with this broad approach is that it leads to horrendous code bloat.
Just look at one pointer that gets passed through a couple of wrappers to get to the actual code that will do something with it. For each function it passes through, we have said that it should be checked to insure that it is not NULL. So, for some number of times we have verified that the pointer is not one of 2^64-1 possible values. Since at any given time a pointer has only one truly valid value [if its not referencing the data it should,its not valid], then it can be said that it has 2^64-2 invalid values.
So, what does checking for NULL over and over accomplish? It eliminates 1 out 2^64-2 possible invalid pointer values.
Subscribe to:
Posts (Atom)
