Glossary for non-Indian readers: PAN – Permanent Account Number
The geniuses at the Income Tax Department in India have set up a website called:
Know Your PAN
In reality, it should be called Know Anybody’s PAN because that’s what you’re able to do, as long as you know their last name and birthdate, neither of which anybody would consider a secret these days. You don’t even need to know the first or middle name, the website will give it to you.
I can’t fathom why anybody would think that this website is a good idea because it effectively facilitates identity fraud. Besides forgetting one’s own PAN, I cannot think of a single legitimate reason why anybody would need to use this website. And let’s be clear; allowing people to check their own PAN is not a good enough justification to make this information public.
There are plenty of illegitimate reasons why this website would be used. First and foremost would be identity fraud. Knowing someone’s PAN is crucial if you want to engage in fraudulent transactions on their behalf.
While the internet can be a useful tool, sometimes people need to think about why a tool is really necessary and think about the implications before putting it online.
However, I suppose in India, a country where privacy laws don’t exist, and the concept of personal privacy is alien, it should not come as a big surprise that the government itself is facilitating identity fraud.
Just to try out the system, you could look up one of many common Indian personalities’ names and dates of birth on Wikipedia and the website will give you their PAN.
Belorussian Translation provided by PC
I am responsible for overseeing the IT infrastructure of an office with about 40 Windows-based computers. We always keep the OS and relevant software patched, though sometimes even keeping Windows/Office/IE patched to the most current level is not enough.
The workarounds provided by Microsoft for this issue are frankly, not acceptable because website functionality with security set to ‘High’ is unacceptable and generate user complaints (and doesn’t even solve the problem completely).
Events like this give me cause to consider a company-wide deployment of Firefox as the default browser. We have no internal applications that rely on IE so this is not a sticking point for us as it is for many corporations. Plus, Firefox has far fewer “vulnerable days” as compared to IE (and when Firefox is vulnerable the potential risk to the system is usually lower).
However, there are a couple of blockers that stop me from taking this step. These include:
- Lack of an automated/scriptable way to deploy Firefox that is supported by Mozilla (though bug 231062 has been filed for an MSI install package – almost 5 years later there is still no resolution).
- Lack of any way to force Firefox product/security upgrades upon users. Without this, Firefox is arguably even more insecure than IE because at least with IE we can be reasonably sure that updates are being pushed out on schedule.
- Lack of any centralised way to make sure plugins are up to date (I will concede that IE is not up to par on this front either).
There are probably a few other points that I can’t think of at the moment. However, our company is an SME with less than 100 computers and I find these issues troubling. Imagine a Fortune 500 company – the problem for them would be multiplied many fold.
I am unhappy about the latest problems with IE and unhappy that there is no patch yet for an exploit that is so clearly in the wild and unhappy that there isn’t even an acceptable way to mitigate the risk.
Having said all this – at the moment I don’t see that switching to an alternative browser is an acceptable solution to this problem for enterprise users for the reasons above.
If work was done to make Firefox more enterprise friendly, this would go a long way towards adoption in the workplace. As it stands, there are just too many reasons not to deploy even though the product is clearly superior from an end user standpoint.
A couple of weeks ago I was talking to Yusuf about setting up wireless internet access at my workplace for guests. In the past we had them plug into our wired network, but the downside of this is that unless you have very expensive DNAC equipment like InfoExpress, or have static NAC configured (very cumbersome), your guests are clients on your main office network and can wreak havoc if their computers have viruses or are otherwise exploited.
Network infection via guests is a real vector and one of which companies should be very afraid. Ideally guests would always be on a separate VLAN.
One way to acheive this is to use a FON router to sandbox guests into a separate VLAN. The FON routers have two SSIDs, a private one that is WPA2 protected that gives full access to the local network, and a public SSID that is (by default) completely separate from the main network and guests on this VLAN cannot talk to computers on the main network, only through to internet IP addresses.
Using the friends and family feature of FON, you can set up a custom username and password that your office guests can use to authenticate on the public SSID (multiple logins with a single credential is possible).
This kills two birds with one stone because you not only have secure access to your own network via WPA2 (which is generally considered to be unbreakable using today’s technology) and you offer guests wifi access to the internet without allowing them access to your internal network.
A couple of things are on my FON wishlist:
- Seamless handover between FON access points on both public and private SSID
- Proper resolution of NetBIOS names on the private SSID (even though its on a different subnet from the main network)
- Better tolerance for old network drivers (this is a big one because in quite a few cases clients using older drivers could not connect to FON even though they could use other wifi networks – older Intel drivers in particular seem to be a problem)
- More powerful customisation options for the FON portal
- On the La Fonera+, allow the extra wired ethernet port to optionally connect to the public FON network instead of the private network
One other thing to bear in mind is that if you choose this solution, you allow anybody to use your bandwidth when authenticated through the FON network. Depending on your corporate policies, this may or may not be a problem for you. If bandwidth is the only issue, on the public SSID you can optionally limit this to as little as 512Kbps to make sure that guests don’t hog your pipeline.