Re: Is it safe to use social securty number as intranet username? (long)

From: Alun Jones (alun@texis.com)
Date: 05/20/02 

From: alun@texis.com (Alun Jones)
Date: Mon, 20 May 2002 16:59:27 GMT

In article <zNeF8.22$JV3.176@paloalto-snr1.gtei.net>, Barry Margolin
<barmar@genuity.net> wrote:
>My point was that email addresses are something that everyone gives out
>freely, so the coffee boy could easily know it. The person's internal
>login name is not. It would normally be available only to the people who
>are in charge of running the servers. It could also be exposed to someone
>who managed to hack into the servers; I don't consider that the same as
>"available to everyone from the coffee boy on up."

My concern is that a company that believes it's saving on namespace by reusing
a person's SSN as their login ID, and their payroll PIN as their password, is
going to envision similar benefits from using their login ID as their email
address, their cubicle assignment, their parking bay, etc, etc. Maybe this
does require a certain belief that where the chain of "who needs to know this"
gets extended by one, it'll most likely get extended by two, or by three, but
if you don't get scrutiny on the first extension of the chain of trust, then
you won't get scrutiny on the second extension, either.

>Hopefully an organization with a worldwide corporate network would know
>enough to use secure communications (e.g. SSL) to servers that contain
>private data like this, so that the coffee boy can't put a sniffer on the
>LAN (although since most LANs are switched these days, sniffers are much
>less useful than they used to be).

The metaphorical "coffee boy" was merely a nod to the idea that the SSN would
be potentially available for observation by many more people within the
company. It's perhaps worth noting that I used to be a coffee boy, or more
precisely, the copy boy, and at the time I knew more about computers than most
of the people I brought photocopies to. In that situation, I've shoulder-
surfed more than a few usernames and passwords without even bothering to try,
so I can envision a dispersal of information that should, by rights, remain
yours.

>And even if they can sniff the traffic, if they want your SSN they can just
>as easily sniff your traffic to the Payroll system as they can to this
>new intranet server.

I'd assume, personally, that traffic to the payroll system is more likely to
be encrypted than traffic to an intranet server. Sure, in some places, both
will carry the same protection, or lack thereof, but again, the point is more
that, by extending who you are required to trust with your SSN, you are also
extending the number of chances of that trust being misplaced.

>In my opinion, the real problem with the OP's organization isn't that
>they're using the SSN as the login ID. The problem is using the same
>password for both systems, although the privacy requirements of the data on
>them is far different.

>From the company's point of view, that's a definite flaw. From the
individual's point of view, however, the SSN should be used for generating tax
reports and filings. I'd argue it shouldn't even be part of the login to the
payroll system! The less opportunity for exposure of private information,
IMHO, the better.

>Login ID's are not usually expected to be private,
>and other posters have pointed out how easy it is for people to find out
>someone's SSN (there are dozens of "find out anything about anyone" web
>sites out there).

That a piece of information is available from other arenas does not mean that
the company can gaily relinquish its responsibility to hold that information
secret. Maybe your SSN is available worldwide from web search engines because
you've made an infelicitous deal with a minor demon from heck, or because your
state insists on a driver's licence whose ID is your SSN, and which is then
publicly available. What about the employee that hasn't got a publicised SSN?
 What about... the coffee boy? Maybe this is his first job, and maybe the
boss's secretary gets extra income selling whatever personal details she can
glean to those very web site. Is he going to be pleased that the company
essentially forces his SSN into the public domain?

Yes, my argument does assume some extra slip-ups on the part of management -
that they don't monitor their employee's outside involvements (but can they?),
that they allow user IDs to be listed by other users, etc. But unless you've
had a sheltered existence within the bowels of a company devoted to security
from day one, I'd imagine that all of those slips are within the realms of
possibility, and strongly into the area of probability.

>I think the OP said that the intranet server in question
>was used for some mundane task like registering for training. The security
>of such a system is not likely to be scrutinized as well as the payroll
>system, so it's not appropriate for them to share their authentication
>data; you're only as secure as your weakest link, and now the intranet
>server is a link to the payroll system, and must be hardened as well.

For systems within a training class, it's usually sufficient / best to use
"student1", "student2", etc, and to disconnect the classroom from the outside
world.

Alun.
~~~~

[Please don't email posters, if a Usenet response is appropriate.] 

-- 
Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place   | http://www.wftpd.com or email alun@texis.com
Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.

Relevant Pages
Quantcast