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

• Previous message: Rob J Meijer: "Re: VPN inside larger secure network?"
• In reply to: Machine Messiah: "Is it safe to use social securty number as intranet username? (long)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: Anne & Lynn Wheeler <lynn@garlic.com>
Date: Sun, 19 May 2002 00:53:59 GMT

Machine Messiah <Poorham@nospamdamnit.com> writes:

F> What do the experts here think of a policy of requiring an employee to
> log on to an intranet using a social security number as a username?
>
> My employer wants me to complete an online training course and they have
> set up a system where we can log onto their intranet individually, but
> they expect us to use our social security number as a username. I asked
> my supervisor if it were possible to change my username to something less
> personally vital as my SS# and said she didn't think so and she was NOT
> very civilized about it.

is the login a real "user" as in unix .... or is it an identifier used
by some database application ... possibly some CICS application
sitting behind the scenes ... aka ... there is no user in the unix or
windows sense; it is just an identifier used by a database application
for validation purposes (i.e. restricting the requester to only
information in the database related to the SSN)?

lets say it is a database application ... an approach might be to use
a totally random identifier and some PIN/password to get past the
first screen. The random identifier probably would mean a new field in
the database ... the SSN# is possibly already an indexed field; so
using it as a psuedo userid would be a trivial effort.

The database application could possibly already exists ... some number
of companies are "web'izing" various call center operations ... a
person calls the call center, the call center asks for various
information like SSN and mother's maiden name, date-of-birth, pin,
etc. They enter the supplied information into various screen fields
... if things check out ... the call center screen proceeds with the
requested transaction.

Some number of "call center" web'ising ... are trying to front-end
various call center screens and applications with some form of web
forms ... substituting person direct entry of the information that the
call center person would be doing as an intermediate proxy typist
(i.e. they are typing in what you speak to them, and then doing some
simple procedural steps and then the requested transaction). In such
scenarios ... the SSN# is not a userid in the traditional sense
... just the identifier used by the existing application.

A security issue then becomes the security of the web'ized call center
forms vis-a-vis the standard call center operation with telephone
interaction. The company might even have a can'ed package ... which
would also support touch tone operation ... whether or not activiated
... which asks for you SSN# followed by a PIN. A possible web'izing
process is just translating the touch-tone operation into a web form.

Some security questions (trying to compare to human call center or
touch tone call center) would be:

1) what machines is the web version available from
2) is the web version just restricted to intranet or is it also availabe
   from general intranet
3) is the web version implemented with SSL
4) assuming a web-server passthru to database back-end application,
   what security is implemented on the web-server and does any of
   the entered data ever hit a web-server disks ... or does the
   web-server purely act as a protocol converter from SSL/browser
   to established database back-end application.
5) how isolated is the database back-end from the web-server are
   their filtering security procedures to drastically limit what
   can pass between the database back-end and the web-server

another approach is that there is some gateway router between an
existing office net ... and internal intranet that has various
platformed services. The gateway router runs radius for authenticating
incoming connection requests (in much the same way the majority of
ISPs perform internet connection authentication)

The radius authentication server needs to provide some "id" and
"password" for the radius authenticated connection. Some radius
servers are done by defining a system "userid" and "password" of the
same information ... so the radius authorization and system login
authorization use the same id & password. Various operations that have
no interest in offering system login capability .... maintain a
subscriber database of "ids" and "passwords" that don't correspond to
any real userid on any system. This database information is just for
the purposes of offering up very temporary & transient information
that is quickly checked and then deleted (in the gateway). An existing
database of SSN with existing PINs for an existing corporate
application could be one way of providing the information for radius
server function.

In this scenario the ID/password information can flow into the gateway
(for the radius authentication) either in the clear or encrypted.
There then is some security implication that if the information flows
in the clear ... what kind of evesdropping opportunities are there.

A somewhat ancillary side issue involves web-servers that perform
client authentication using a flat file of userid/password information
(again these are not real system userids ... just authentication
information). However, it also relatively straight-foward for
web-servers to implement client authentication using radius ... and
the source information is on some secure corporate database and only
existis at the web-server for very, very short duration of time when
the id/password is actually being checked.

For more information on radius see rfc 2865.

It is possible to go to:
http://www.garlic.com/~lynn/rfcietff.htm

and select "Term (term->RFC#)" from the RFCs listed by section

from the Term screen select "RADIUS" from the acronym fastpath at the
beginning of the file.

remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139
2138 2059 2058

selecting any RFC number will bring up the summary in the bottom frame.

selecting the ".txt=nnnn" field fromt he RFC summary will retrieve the
actual RFC.

-- 
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/ 

• Next message: NeuTekniqx: "Norton Personal Firewall - how does it stack up?"
• Previous message: Rob J Meijer: "Re: VPN inside larger secure network?"
• In reply to: Machine Messiah: "Is it safe to use social securty number as intranet username? (long)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]