Is it safe to use social securty number as intranet username? (long)
Machine Messiah
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.
I have learned the hard way to be very stingy about giving out my ss# and
am very concerned about the security implications of using my ss# as a
computer password or logon name. I'd be more willing to use a credit card
# because if there were a problem I could at least cancel the card. I do
not carry my ss# on my person, it has never been on the hd of my computer
and I
have never used it on a website. I do not access any of my financial
information online because many such sites seem to require it.
I plan to email the administrator of the training program and ask about
changing my username. If they are unwilling or unable to change it, what
sort of questions should I ask about the security of their network? All
I know about intranet security I got from this page:
http://intranetjournal.com/features/isecurity.shtml
I know intranets can use ssl/128 bit encryption so I plan to ask about
that. If they don't use that, what are some other ways to secure an
intranet? Should I ask them about their firewall, How often the system is
scanned for trojans?
If anyone here is in charge of an intranet, what sort of security setup
would make you willing to use your SS# as a username?
We were given a url to use if we wanted to try accessing the training
course from home. I checked the url with Neotrace and now have the names
of the network administrator and coordinator. Would one of these 2 be in
charge of assigning or changing user names? Should I direct my questions
to them. Do you think they'd be pissed to get an email from me?
I entered the url on my computer and got this message:
Enter Network password
please type your username and password
Site: joe.shmo.com
Relm: HTTP Authentication(ID#####)
I typed nothing, hit enter and got this:
Error: Authen Rejected.
No 401 or 403 message. Does this give any hints as to how the network is
secured.
Finally, the company has a web page where you can apply for a job with
them online. They ask for your name, address, phone number and you can
even upload your resume. THE PAGE IS NOT SECURE! No "https" in the url,
no little yellow padlock at the bottom of the screen! I think you'd have
to be pretty foolish or desperate for a job to use this page. It only
heightened my concerns about the security of their network.
This company is a huge corporation, they are listed on the NYSE. You
think they'd have better sense than to use SS#s to log on to a network.
Sorry to go on so long and the crossposts.
TIA for any advice or help.
m.m.
CJ
one....
510-38-5354 belongs to a guy in Kansas. The internet is full of them
if you know where to look. unless they match your real SS# to your name
they'll never know it is a "utility SS#!"
-CJ
Machine Messiah
says...
Thanks for the reply. Bogus ss# won't work, they've already set it up
only to accept MY ss#.
I have Richard Nixon's SS# stashed away in a file somewhere. I've
downloaded a few pages about how to create a valid but fake SS#. Been
thinking of giving my self one from Guam.
mm
William J. Meyerbeck
you and others who worry about using their
SS# really should take a different approach to the problem. Your SS# is
already on hundreds of documents and databases that
are not safely guarded. The same with mine and every other American.
Your best defense is to assume you information is already out there and
monitor your credit history for the first sign
of trouble that someone has taken advantage of your information. There are
services that will alert to anyone accessing
your credit report. People may argue that you should not have to pay for
such a service but you don't have to. Neither
do you have to pay for an alarm system or insurance.
Go ahead and use your SS# as an ID. I have to do it on some web sites for
testing at times.
??
forced to issue alternatives for student ID's, it gets even worse that
student ID databases have been stolen from servers with student info
including name, address, and SSN#. There are also some states in legal
trouble for requiring a persons SSN# on drivers license, which has been
found to violate a persons privacy.
It's not a good idea for you employer to require this.
--
"Machine Messiah" <Poo...@nospamdamnit.com> wrote in message
news:34gE8.39238$G%3.177...@typhoon.columbus.rr.com...
ch...@nospam.com
>I have learned the hard way to be very stingy about giving out my ss# and
>am very concerned about the security implications of using my ss# as a
Why? Any one serious about getting your ssn can get it by querying
one of the credit agencies. Or perhaps a little social engineering
by calling your old college. Hell, some states used to use your SSN
number on your drivers license.
Your SSN is not as sacred as you might think. You should be more
worried about the waitress you stiffed on the tip snagging your credit
card info which is far more useful.
-Chris
Lassi Hippeläinen
>
> 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?
Stupid.
If they can set up a username, there is no need for insisting on the
SSN. If they are so brain dead that they can't manage usernames derived
from real names, they could use the employee number, for example.
-- Lassi
Machine Messiah
says...
snip
> Why? Any one serious about getting your ssn can get it by querying
> one of the credit agencies.>
I know that.
You can ask, and I have, the credit agencies not to release your info
unless YOU specifically have requested more credit or have a potential
employer doing a backround check on you. Really cuts down of junk mail.
Snip
>Or perhaps a little social engineering
> by calling your old college.
snip
Mine was sued and they no longer post student SS#s for all to see. They
won't release such info now w/o a court order or written request from me.
Snip
Hell, some states used to use your SSN
> number on your drivers license.
snip
My state will remove it for $15. If someone needs a number for me I give
them the drivers licence #.
snip
> Your SSN is not as sacred as you might think. You should be more
> worried about the waitress you stiffed on the tip snagging your credit
> card info which is far more useful.
Snip
I don't let go of my credit or debit card. I only do business where I
can run the card tru the reader myself. I love self check out. The law
protects us from unauthorized use of a credit card. You can close the
account and get a new card with a different number. Try getting a new
ss#. I also had my spending limits on my cards reduced to a very low
level. They couldn't have too much fum before maxing out the card.
>
snip
I guess I should metioned that I've been robbed 3 times and have learned
to be wary about personal data.
mm
>
Machine Messiah
lahi...@ieee.orgies.invalid says...
thanks for the reply.
The want us to use ss# as username and payroll pin # as password.
mm
Alun Jones
>Why? Any one serious about getting your ssn can get it by querying
>one of the credit agencies. Or perhaps a little social engineering
>by calling your old college. Hell, some states used to use your SSN
>number on your drivers license.
>
>Your SSN is not as sacred as you might think. You should be more
>worried about the waitress you stiffed on the tip snagging your credit
>card info which is far more useful.
Here's the whole point - the SSN _should_ be as sacred as you might think. It
_should_ be used only where taxes may need to be assessed against an
individual. It should _not_ be used as a unique identifier for any other
purpose. By saying "foo, it's already used as a unique identifier", you
aren't helping to solve the problem, you're just saying "problem? I don't see
a problem."
With an SSN, and just a little further information even more public than your
SSN, that same waitress could open a new credit card in your name.
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 al...@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.
Alun Jones
>The want us to use ss# as username and payroll pin # as password.
This sounds like they want to take information that you use to access the
payroll system, and pass it to more people than is required for just accessing
the payroll system. Sounds like an excellent way for the company to find
themselves defrauded.
Barry Margolin
Alun Jones <al...@texis.com> wrote:
>In article <MPG.174c2ad4b3b1bf7f98968b@news-server>, Machine Messiah
><Poo...@nospamdamnit.com> wrote:
>>The want us to use ss# as username and payroll pin # as password.
>
>This sounds like they want to take information that you use to access the
>payroll system, and pass it to more people than is required for just accessing
>the payroll system. Sounds like an excellent way for the company to find
>themselves defrauded.
But also an excellent way to avoid being defrauded.
The payroll system already has a list of valid employees, along with unique
identifiers (SSN) and an authenticator (PIN). If they use something else
for the intranet, they have to devise a new way to identify and
authenticate the users. This provides an opportunity for errors,
mismatches between the systems, etc.
Note also that he's talking about an *intranet*, i.e. a server internal to
the company. They're not sending payroll information to an outside agency
(unless operation of the intranet is outsourced), so who is going to be
defrauding them? This is information that already exists in the company's
databases.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Alun Jones
>Note also that he's talking about an *intranet*, i.e. a server internal to
>the company. They're not sending payroll information to an outside agency
>(unless operation of the intranet is outsourced), so who is going to be
>defrauding them? This is information that already exists in the company's
>databases.
It is, however, information that is traditionally restricted to only a few
people within the company - those people that file the tax forms, and thus
have a legitimate reason to know it - and a legal requirement, in fact, to do
so. Others within the firm are generally not privvy to such information, and
for good reason. With a little knowledge of a person's public information and
a SSN, you can get a credit card in their name.
When this becomes the person's internal login name, and thus available to
everyone from the coffee boy on up, there's considerably greater chance of
fraud and identity theft against the employees.
The OP noted that he also was required to login with his payroll system's PIN
as his password on the Intranet. Why does anyone other than himself know
_his_ PIN? Presumably he's given a PIN number to the company's payroll system
so that he can do something with his payroll. Who should have access to that
employee's data in the payroll system? The accountants, who are presumably
vetted in some manner (even if it's just a handshake and a smile), and the
employee, one would assume. Now, that information has been given to another
person or group - the one setting up accounts in the intranet. What could
someone do in the payroll system? This is where I see a vague possibility for
defrauding the company _and_ the employee.
There's an assumption that when you join a company, the company will keep your
financial information secret, and use it only in the manner necessary to
employ you. It appears that there is ample opportunity here for that
financial information to be exposed to a greater number of people than those
who strictly need it. That can't be good.
Walter Roberson
Alun Jones <al...@texis.com> wrote:
:The OP noted that he also was required to login with his payroll system's PIN
:_his_ PIN? Presumably he's given a PIN number to the company's payroll system
:so that he can do something with his payroll. Who should have access to that
:employee's data in the payroll system? The accountants, who are presumably
:vetted in some manner (even if it's just a handshake and a smile), and the
:employee, one would assume. Now, that information has been given to another
:person or group - the one setting up accounts in the intranet.
Unless, that is, that what they did was just copy the password file
with encrypted passwords -- or perhaps they are using the same NT
domain (or other Single Signon system) for credentials. Thus, it is
not -necessarily- the case that anyone extra has deliberately been
given access to the information.
Mind you, employee logins to check payroll are likely relatively
uncommon, whereas on-line course logins are likely to happen several
times a day, so sniffing becomes a bigger risk...
William Fason
> Why? Any one serious about getting your ssn can get it by querying one of
the credit agencies.
That's not as easy as it used to be since the passage of the
Gramm-Leach-Bliley Act. So the replace "anyone serious" in the sentence
with "anyone willing to break the law, and bribe others to break the law..."
> Your SSN is not as sacred as you might think. You should be more worried
about the waitress you stiffed on the tip snagging your credit card info
which is far more useful.
Exactly.
Machine Messiah wrote:
> You can ask, and I have, the credit agencies not to release your info
unless YOU specifically have requested more credit or have a potential
employer doing a backround check on you.
You can ask, but it wont matter one iota.
The permissible purpose standard for obtaining consumer credit reports is
articulated in the Fair Credit Reporting Act (FCRA). There are about a
dozen different circumstances which allow someone else to pull a consumer
credit report about you (technically not "your report"), and most of these
reasons do not require your permission. Examples include in response to an
order from a court having competent jurisdiction, in response to a subpoena
from a federal grand jury, in connection with collecting an existing debt,
for use in determining or enforcing child support, for use by the FBI in
connection with certain counter-terror investigations, etc.
Barry Margolin
Alun Jones <al...@texis.com> wrote:
>In article <ejxE8.8$GK3...@paloalto-snr1.gtei.net>, Barry Margolin
><bar...@genuity.net> wrote:
>>Note also that he's talking about an *intranet*, i.e. a server internal to
>>the company. They're not sending payroll information to an outside agency
>>(unless operation of the intranet is outsourced), so who is going to be
>>defrauding them? This is information that already exists in the company's
>>databases.
>
>It is, however, information that is traditionally restricted to only a few
>people within the company - those people that file the tax forms, and thus
>have a legitimate reason to know it - and a legal requirement, in fact, to do
>so. Others within the firm are generally not privvy to such information, and
>for good reason. With a little knowledge of a person's public information and
>a SSN, you can get a credit card in their name.
>
>When this becomes the person's internal login name, and thus available to
>everyone from the coffee boy on up, there's considerably greater chance of
>fraud and identity theft against the employees.
How would the coffee boy get access to the internal database of the
intranet server? We're not talking about the person's email address.
>The OP noted that he also was required to login with his payroll system's PIN
>as his password on the Intranet. Why does anyone other than himself know
>_his_ PIN? Presumably he's given a PIN number to the company's payroll system
>so that he can do something with his payroll.
I'm guessing that he's referring to automated system for entering
time-sheet data, expense reports, and/or W-4 withholding information.
> Who should have access to that
>employee's data in the payroll system? The accountants, who are presumably
>vetted in some manner (even if it's just a handshake and a smile), and the
>employee, one would assume.
And the system administrators of the payroll system.
> Now, that information has been given to another
>person or group - the one setting up accounts in the intranet. What could
>someone do in the payroll system? This is where I see a vague possibility for
>defrauding the company _and_ the employee.
Of course, if the system administrators of the payroll system are the same
people who also operate the intranet servers, they already have that access.
My company has a number of different intranet servers. One for time and
expense reporting, others for various technical tasks. We also have
extranets implemented by our benefits providers (one for 401k and stock
options, another for medical insurance). It sure is confusing to have
different ID's for each (the benefits providers need to have the SSNs for
tax purposes, so they use it as the user ID as well).
Barry Margolin
William Fason <wfa...@houston.rr.nospam.com> wrote:
>ch...@nospam.com wrote
>> Why? Any one serious about getting your ssn can get it by querying one of
>the credit agencies.
>
>That's not as easy as it used to be since the passage of the
>Gramm-Leach-Bliley Act. So the replace "anyone serious" in the sentence
>with "anyone willing to break the law, and bribe others to break the law..."
If you're worried about identity theft, then you're already presuming that
they're willing to break the law.
Lassi Hippeläinen
<...>
> My company has a number of different intranet servers. One for time and
> expense reporting, others for various technical tasks. We also have
> extranets implemented by our benefits providers (one for 401k and stock
> options, another for medical insurance). It sure is confusing to have
> different ID's for each (the benefits providers need to have the SSNs for
> tax purposes, so they use it as the user ID as well).
This is one of the things that I object to. Easing the work of the
computer room clergy isn't the prime motive when choosing security
features. Using the SSN is just an attempt to assign the management of
uniqueness to someone else.
If the employees have access to the corporate intranet, they should have
a single identity for the intranet - not for each service. My employer
has about 60'000 employees, most of which have intranet access, and runs
a global intranet with innumerable services. We have a single network
logon. Some strictly limited databases have their own passwords and
access lists as extra protection, but those are so limited that they can
be managed by the ownners of those services.
The intranet identity should not be overloaded with uses that are
independent of intranet access. The SSN is certainly something that has
its own separate use, independent of the company. It even is outside the
authority of the company. In a multinational company it simply won't
work, because the SSNs of different countries have different formats.
That's why I called it stupid.
-- Lassi
Barry Margolin
Lassi Hippeläinen <lahi...@ieee.orgies.invalid> wrote:
>Barry Margolin wrote:
><...>
>> My company has a number of different intranet servers. One for time and
>> expense reporting, others for various technical tasks. We also have
>> extranets implemented by our benefits providers (one for 401k and stock
>> options, another for medical insurance). It sure is confusing to have
>> different ID's for each (the benefits providers need to have the SSNs for
>> tax purposes, so they use it as the user ID as well).
>
>This is one of the things that I object to. Easing the work of the
>computer room clergy isn't the prime motive when choosing security
>features. Using the SSN is just an attempt to assign the management of
>uniqueness to someone else.
I think of it as taking advantage of the fact that you already have a
working list of unique IDs and passwords.
The alternative is assigning new IDs and passwords, and somehow
communicating them to all the employees. Letting the users know their new
passwords is the really tricky part. One common strategies is to assign
initial passwords algorithmically, but these are then easily guessed by
other employees; more popular these days is to send email telling the
employee their initial password. The way to assign passwords securely is
to require the employee to physically sit down at a console when the IT
staff is creating their account; this is usually done when creating
accounts for new employees, since the volume is manageable, but it's rarely
practical when installing thousands of accounts all at once.
>If the employees have access to the corporate intranet, they should have
>a single identity for the intranet - not for each service. My employer
>has about 60'000 employees, most of which have intranet access, and runs
>a global intranet with innumerable services. We have a single network
>logon. Some strictly limited databases have their own passwords and
>access lists as extra protection, but those are so limited that they can
>be managed by the ownners of those services.
The reason things are so messy here is because there isn't a single,
centrally-managed intranet server. There are lots of independent servers
that have been set up by different groups, because the bureaucratic hassle
of getting content added to centrally-managed servers is too much of a
bother.
Mathias Grimmberger
> In article <zhBE8.7182$%9.1742...@newssvr30.news.prodigy.com>,
> Alun Jones <al...@texis.com> wrote:
> >In article <ejxE8.8$GK3...@paloalto-snr1.gtei.net>, Barry Margolin
> ><bar...@genuity.net> wrote:
> >>Note also that he's talking about an *intranet*, i.e. a server internal to
> >>the company. They're not sending payroll information to an outside agency
> >>(unless operation of the intranet is outsourced), so who is going to be
> >>defrauding them? This is information that already exists in the company's
> >>databases.
> >
> >It is, however, information that is traditionally restricted to only a few
> >people within the company - those people that file the tax forms, and thus
> >have a legitimate reason to know it - and a legal requirement, in fact, to do
> >so. Others within the firm are generally not privvy to such information, and
> >for good reason. With a little knowledge of a person's public information and
> >a SSN, you can get a credit card in their name.
> >
> >When this becomes the person's internal login name, and thus available to
> >everyone from the coffee boy on up, there's considerably greater chance of
> >fraud and identity theft against the employees.
>
> How would the coffee boy get access to the internal database of the
> intranet server?
Why would he need to?
What are the odds that the login info is transmitted in cleartext (it's
an intranet so nobody cares even if most attacks are reported to come
from insiders)?
What are the odds that the network is properly secured against sniffers
put onto it by just anyone able to physically access a host or even just
a random ethernet outlet?
What are the odds anyone would notice a sniffer at all (one with the
transmit wires intact I mean)?
Pretty slim I'd say.
> We're not talking about the person's email address.
Exactly. This is kind of the point, isn't it? :-)
MGri
--
Mathias Grimmberger <mg...@zaphod.sax.de>
Eat flaming death, evil Micro$oft mongrels!
MARK BURGGRAF
news:m3adqzs...@zaphod.sax.de...
> Barry Margolin <bar...@genuity.net> writes:
> > In article <zhBE8.7182$%9.1742...@newssvr30.news.prodigy.com>,
> > Alun Jones <al...@texis.com> wrote:
> > >In article <ejxE8.8$GK3...@paloalto-snr1.gtei.net>, Barry Margolin
> > ><bar...@genuity.net> wrote:
> > >>Note also that he's talking about an *intranet*, i.e. a server
internal to
> > >>the company. They're not sending payroll information to an outside
agency
> > >>(unless operation of the intranet is outsourced), so who is going to
be
> > >>defrauding them? This is information that already exists in the
company's
> > >>databases.
Hurumphhhh!!!! Our *intranet* (and each node) has DIRECT access to the
*internet*! It's a *corporate* LAN that spans several countries! Not your
little *garage* type lan connecting two computers!
> > >It is, however, information that is traditionally restricted to only a
few
> > >people within the company - those people that file the tax forms, and
thus
> > >have a legitimate reason to know it - and a legal requirement, in fact,
to do
> > >so. Others within the firm are generally not privvy to such
information, and
> > >for good reason. With a little knowledge of a person's public
information and
> > >a SSN, you can get a credit card in their name.
Yup. Bad idea all the way 'round. Period. He shouldn't do it. Again,
period.
> > >When this becomes the person's internal login name, and thus available
to
> > >everyone from the coffee boy on up, there's considerably greater chance
of
> > >fraud and identity theft against the employees.
> >
> > How would the coffee boy get access to the internal database of the
> > intranet server?
Easy. In most cases now-a-days he doesn't even need to be an employee. Our
company uses a 'wire-less' intra-net in addition to the traditional
'hardwire'. This accomodates laptops, etc. I've written several memo's
with step by step instructions on how some one could sit in our parking lot
and hack into our net-work. I've offered a demonstation...
The response? Heh, heh... yup! 'People who don't *need* to get on our
network, won't.'
> Why would he need to?
Ahh... the corporate mindsight. 'Employee's who don't *need* to, won't.'
Ignorance... and (trust me) it's gonna cost you.
> What are the odds that the login info is transmitted in cleartext (it's
> an intranet so nobody cares even if most attacks are reported to come
> from insiders)?
Yup... nobody cares. ROTFL!!! Nope, nobody! Information isn't valuable.
Hacking a network isn't interesting... or fun... or profitable.
> What are the odds that the network is properly secured against sniffers
> put onto it by just anyone able to physically access a host or even just
> a random ethernet outlet?
I'd say about 50/50. Probably less. Our shipping clerk has access. So
does *every* employee at our location!
> What are the odds anyone would notice a sniffer at all (one with the
> transmit wires intact I mean)?
>
> Pretty slim I'd say.
Glad I don't work where you work! There's plenty of 'software' sniffers out
there! Some are *very* difficult to find and isolate.
> > We're not talking about the person's email address.
>
> Exactly. This is kind of the point, isn't it? :-)
What, exactly... is your point? That any and all personal information can
be used, transmitted, and balleyed about... without *any* fear of it being
used because 'those that don't *need* the information' won't use it?!?
Heh, heh... me thinks you might have an anterior motive?
M.L.
>>> one of the credit agencies.
>>
>> That's not as easy as it used to be since the passage of the
>> Gramm-Leach-Bliley Act. So the replace "anyone serious" in the
>> sentence with "anyone willing to break the law, and bribe others to
>> break the law..."
>
> If you're worried about identity theft, then you're already presuming
> that they're willing to break the law.
Agreed. This reminds me of the controversy last year when one of the Bush
daughters was busted for underage drinking. The manager who called the cops
soon found her credit report details spread all over the Internet
(specifically in regards to a bankruptcy, IIRC). It was all done very
quickly -- and illegally.
Barry Margolin
MARK BURGGRAF <mbur...@prodigy.net> wrote:
>Mathias Grimmberger <mg...@zaphod.sax.de> wrote in message
>news:m3adqzs...@zaphod.sax.de...
>> > intranet server?
>
>Easy. In most cases now-a-days he doesn't even need to be an employee. Our
>company uses a 'wire-less' intra-net in addition to the traditional
>'hardwire'. This accomodates laptops, etc. I've written several memo's
>with step by step instructions on how some one could sit in our parking lot
>and hack into our net-work. I've offered a demonstation...
Access to the network is not the same as access to the internal database of
the server. If the machine is properly secured, people with access to the
network should only be able to access their own accounts.
If people can hack into servers with important data on it, then you have a
far bigger problem.
Mathias Grimmberger
> In article <OAYE8.6474$v23.18...@newssvr17.news.prodigy.com>,
> MARK BURGGRAF <mbur...@prodigy.net> wrote:
> >Mathias Grimmberger <mg...@zaphod.sax.de> wrote in message
> >news:m3adqzs...@zaphod.sax.de...
> >> > How would the coffee boy get access to the internal database of the
> >> > intranet server?
> >
> >Easy. In most cases now-a-days he doesn't even need to be an employee. Our
> >company uses a 'wire-less' intra-net in addition to the traditional
> >'hardwire'. This accomodates laptops, etc. I've written several memo's
> >with step by step instructions on how some one could sit in our parking lot
> >and hack into our net-work. I've offered a demonstation...
>
> Access to the network is not the same as access to the internal database of
> the server. If the machine is properly secured, people with access to the
> network should only be able to access their own accounts.
>
> If people can hack into servers with important data on it, then you have a
> far bigger problem.
Of course.
This doesn't mean that in some company this isn't exactly the state of
affairs, i.e. anyone with network access can run sniffers and all login
data is transmitted in cleartext and "Switch" is an unknown concept.
But whatever security is in place I still don't believe that exposing
sensitive information (a SSN AFAIK is sensitive info) without any need
is a clever idea. KISS applies to security.
Mathias Grimmberger
> Mathias Grimmberger <mg...@zaphod.sax.de> wrote in message
> news:m3adqzs...@zaphod.sax.de...
> > Barry Margolin <bar...@genuity.net> writes:
> > > In article <zhBE8.7182$%9.1742...@newssvr30.news.prodigy.com>,
> > > Alun Jones <al...@texis.com> wrote:
> > > >In article <ejxE8.8$GK3...@paloalto-snr1.gtei.net>, Barry Margolin
> > > ><bar...@genuity.net> wrote:
Please, you seem to be a bit confused about how Usenet News works. Pay
attention to the attributions and who said what. These were three
different people you answered to.
> > > We're not talking about the person's email address.
> >
> > Exactly. This is kind of the point, isn't it? :-)
>
> What, exactly... is your point? That any and all personal information can
> be used, transmitted, and balleyed about... without *any* fear of it being
> used because 'those that don't *need* the information' won't use it?!?
>
> Heh, heh... me thinks you might have an anterior motive?
No this was not my point. If you had paid attention you probably would
have noticed.
Barry Margolin
Mathias Grimmberger <mg...@zaphod.sax.de> wrote:
>This doesn't mean that in some company this isn't exactly the state of
>affairs, i.e. anyone with network access can run sniffers and all login
>data is transmitted in cleartext and "Switch" is an unknown concept.
I can't speak for other organizations, but we use SSL to connect to any of
our intranet or extranet servers that require a login.
Barry Margolin
>> >When this becomes the person's internal login name, and thus available to
>> >everyone from the coffee boy on up, there's considerably greater chance of
>> >fraud and identity theft against the employees.
I wrote:
>>
>> How would the coffee boy get access to the internal database of the
>> intranet server?
In article <m3adqzs...@zaphod.sax.de>,
Mathias Grimmberger <mg...@zaphod.sax.de> wrote:
>Why would he need to?
...
>> We're not talking about the person's email address.
>
>Exactly. This is kind of the point, isn't it? :-)
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."
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).
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.
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. 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). 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.
MARK BURGGRAF
> "MARK BURGGRAF" <mbur...@prodigy.net> writes:
> > Mathias Grimmberger <mg...@zaphod.sax.de> wrote in message
> > news:m3adqzs...@zaphod.sax.de...
> > > Barry Margolin <bar...@genuity.net> writes:
> > > > In article <zhBE8.7182$%9.1742...@newssvr30.news.prodigy.com>,
> > > > Alun Jones <al...@texis.com> wrote:
> > > > >In article <ejxE8.8$GK3...@paloalto-snr1.gtei.net>, Barry Margolin
> > > > ><bar...@genuity.net> wrote:
> [snip]
>
> Please, you seem to be a bit confused about how Usenet News works. Pay
> attention to the attributions and who said what. These were three
> different people you answered to.
These were three different people?!? Wazthamean?!?
I *did* pay attention, [expletive deleted] I can't help it if you can't
figure out how your news-server works!
I MEANT to respond the way I did (obviously)...
I posted to insure that EACH individual that responded to your stupid
response got the message that *I* believe was a much more accurate response
to *their* post!
It ain't all about you, ma'boy! (Trust me, you're the only one who thinks
it's all about you!)
You really should read up about threads! From what I see here, many people
here should have *PLONKED!* your idiotic responses (i.e. "Yes, your SSN is
fine as a login password because nobody cares") long, long, ago.
What's next in your sage-like advice?!? Wait, lemme guess.... "Using
Credit card numbers are an even MORE secure way of insuring that login
passwords are kept secret because there's a whole lot of (meaningless)
numbers in them" or "the best way is to use all them really stupid,
meaningless numbers on the lower right side of your check, cuz it's got a
whole bunch of numbers that NO ONE will ever guess!".
Puhleeeze!
I'm guessing that many probably don't read your responses because you're in
their KILLFILE!
The attributes (as you post above) are very clear. I was, again, very
clearly posting a response to you.
Since you are obviously confused about the mechanics of NGs, posting,
threads, etc.... I kindly recommend that you reply ONLY to posts that are
directed SPECIFICALLY to YOU.
From now on, if I am addressing YOU, I will post thusly, so as not to
confuse you...
___________________________________________________
"ATTENTION ONE AND ALL:
Mathias Grimmberger, I am speaking to you, in response to the idiocy that
you personally, posted in message XXXXXXXXX.
YES, Mathias Grimmberger, not only am I personally posting to you, Mathias
Grimmberger (email address: mg...@zaphod.sax.de) but I am specifically
posting in response to your post of XXXXXXXX:"
ADDENDUM: Apologies to those netizens whose bandwidth is wasted by the
demands of an individual that insists that HE knows netiquette, and has
thusly defined it for all."
______________________________________________________
Would that be good enough?!?
OK, if that is clear, than you may assume that *If* I don't post the above
preface, than my verbage is not directed at you.
You may also assume, that if my verbiage is not directed at YOU, than no
response from you is wanted or desired.
Wanted OR desired!
Are we clear on this?
That's the way you want me to respond, no? Only to YOU. No one else
matters, eh? I shouldn't address the concerns of any one, else, and ONLY
support YOUR view, eh? None of my business - that's what you'e saying.
Unless I am speaking to Mathias Grimmberger than there is a breach of
Netiquette, eh?
Yes, yes... didn't know this was YOUR newsgroup and that you have defined
that ONLY you should be responded to... look asshole, make the group
moderated so that ONLY your view is supported or shut the fuck up.
EITHER WAY, YOUR ADVICE IS NOT ONLY WRONG....... BUT DANGEROUS!
> > > > We're not talking about the person's email address.
> > >
> > > Exactly. This is kind of the point, isn't it? :-)
> >
> > What, exactly... is your point? That any and all personal information
can
> > be used, transmitted, and balleyed about... without *any* fear of it
being
> > used because 'those that don't *need* the information' won't use it?!?
> >
> > Heh, heh... me thinks you might have an anterior motive?
>
> No this was not my point. If you had paid attention you probably would
> have noticed.
I did. It was. Your motives and message are more than clear.
"Use as much personal information as you possibly can in login scripts,
because NO ONE is out there trying to gather information."
Or was your message "Trust us, you are safe... we are Big Brother!"
BWAAAHAAAAHAAAAAA!!!!
Winston Smith
> Give them a SS # for your login ID. Just make sure it's a phony. Here's
> one....
>
> 510-38-5354 belongs to a guy in Kansas. The internet is full of them
> if you know where to look. unless they match your real SS# to your name
> they'll never know it is a "utility SS#!"
>
> -CJ
I read the SS say you can use 987-65-432(1-9) as a bogus # which they
recognize as phony, preventing you from stealing someone's identity.
jgo
> 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?
Ahh, yet another abuse for socialist insecurity numbers.
Yes, it is a rotten idea to use socialist insecurity
numbers as user-names or pass-words. It violates the
privacy of the individual doing the logging in. It
spreads it around, making it an easier target for
additional abuse. It encourages more abuse by
accustoming the ones implementing it to the rotten
notion.
Will program Macintoshes or UNIX boxes, or
help write or doctor screen-plays for food.
Mathias Grimmberger
> In article <m3r8kaq...@zaphod.sax.de>,
> Mathias Grimmberger <mg...@zaphod.sax.de> wrote:
> >This doesn't mean that in some company this isn't exactly the state of
> >affairs, i.e. anyone with network access can run sniffers and all login
> >data is transmitted in cleartext and "Switch" is an unknown concept.
>
> I can't speak for other organizations, but we use SSL to connect to any of
> our intranet or extranet servers that require a login.
So you work in a place where security is taken somewhat serious.
I can of course only speak about where I work: SSH was only installed on
the Unix servers 1 week ago (clients are the responsibility of each
user), SMB uses cleartext passwords and so do the web thingies.
OTOH the network is divided into smallish broadcast domains and any
attempt to connect a NIC with an unknown MAC results in the port being
disabled.
IOW not really good enough. BTW, is it impossible to spoof ARP, DNS, are
server certificates actually verified, blah-blah where you work? Is it a
wise decision to expose more data than one absolutely needs to?
Mathias Grimmberger
> someone whose atrribution seems to have been lost wrote:
>
> >> >When this becomes the person's internal login name, and thus available to
> >> >everyone from the coffee boy on up, there's considerably greater chance of
> >> >fraud and identity theft against the employees.
>
> I wrote:
>
> >>
> >> How would the coffee boy get access to the internal database of the
> >> intranet server?
>
> In article <m3adqzs...@zaphod.sax.de>,
> Mathias Grimmberger <mg...@zaphod.sax.de> wrote:
>
> >Why would he need to?
> ...
> >> We're not talking about the person's email address.
> >
> >Exactly. This is kind of the point, isn't it? :-)
>
> My point was that email addresses are something that everyone gives out
> freely, so the coffee boy could easily know it.
I understood that, I just found it funny to give a different twist to
your statement... :-)
> The person's internal login name is not.
That I do not understand. Login names are no secret, they never were.
It's trivial to find out login names on a Unix host. It is also a very
common setup where the login names are actually the internal e-mail
address of people. Where I work people one often works with are actually
referred to by their three letter login, at least if it is pronouncable.
> 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."
This may be so if the logins were for a special service, but with single
sign-on this becomes increasingly unlikely. Even so, there is no really
good reason to give people different login names for different services
- they won't remember them.
> 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).
Hmm, I have to say that at least to me this doesn't seem to be the case.
> 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.
Of course, except that it is more likely that the traffic to the payroll
server will be encrypted and the SSN will be transmitted much more
seldom than if it is the login name to some service.
> 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. Login ID's are not usually expected to be
> private,
Hmm, this seems to contradict what you said earlier. If login names are
not expected to be private then using sensitive info as one is just
stupid, no?
> 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).
Different issue, has nothing to do with the subject, more with bad data
protection laws in the US.
> 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.
That is pretty much what I argued or not? Only that I say that no
sensitive information should be used for a purpose it is not actually
*needed* for - SSN as a login name say. That would be stupid even for
the payroll system because it's a totally unnecessary risk.
Mathias Grimmberger
[snip drivel]
> Yes, yes... didn't know this was YOUR newsgroup and that you have defined
> that ONLY you should be responded to... look asshole, make the group
> moderated so that ONLY your view is supported or shut the fuck up.
Thank you for showing me my place on Usenet. I shall defer to your
infinite wisdom and vastly superior experience.
BTW, you forgot to criticize my inferior grasp of the english language.
Submissive greetings,
Anne & Lynn Wheeler
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 | ly...@garlic.com - http://www.garlic.com/~lynn/
Alun Jones
>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.
Barry Margolin
Mathias Grimmberger <mg...@zaphod.sax.de> wrote:
>Barry Margolin <bar...@genuity.net> writes:
>> The person's internal login name is not.
>
>That I do not understand. Login names are no secret, they never were.
>It's trivial to find out login names on a Unix host. It is also a very
>common setup where the login names are actually the internal e-mail
>address of people. Where I work people one often works with are actually
>referred to by their three letter login, at least if it is pronouncable.
I was specifically referring to these "internal" login names, which were
only usable on the intranet servers. Intranet servers are not like Unix
systems, where anyone who can login can read /etc/passwd to find out all
the other usernames. Nor are these internal login names being used as
email addresses. There's little reason why these internal names would ever
be given out to other coworkers, except that since that site is using SSN's
they would be given to people in Payroll, Benefits, and similar departments.
>> 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."
>
>This may be so if the logins were for a special service, but with single
>sign-on this becomes increasingly unlikely. Even so, there is no really
>good reason to give people different login names for different services
>- they won't remember them.
That seems like the logic that these system designers used. Since people
already know their SSNs, and this is used as the login name on the Payroll
system, they decided to import that user database to the new server rather
than give users a new login name.
>> 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. Login ID's are not usually expected to be
>> private,
>
>Hmm, this seems to contradict what you said earlier. If login names are
>not expected to be private then using sensitive info as one is just
>stupid, no?
Yes, I realize I was contradicting my earlier statements. I decided to
take a fresh look at the issue.
>> 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).
>
>Different issue, has nothing to do with the subject, more with bad data
>protection laws in the US.
But given that the data isn't well protected, the SSN isn't particularly
"private". If someone wanted to find out your SSN, there are undoubtedly
easier ways to do it than hack into the intranet server.
William Barwell
Machine Messiah <Poo...@nospamdamnit.com> wrote:
>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.
Abysmally stupid. And probably illegal.
Check with the SS people. Try www.ssa.gov.
A number of Senators are now trying to end the practice
of allowing states to use SS#'s on driver's licenses.
These sorts of things invite identity theft.
You may want to try google "social security numbers+legal
issues+federal law" for giggles.
You might be able to scare them with a few well chosen news stories.
Cheerful Charlie
>I have learned the hard way to be very stingy about giving out my ss# and
>am very concerned about the security implications of using my ss# as a
>computer password or logon name. I'd be more willing to use a credit card
># because if there were a problem I could at least cancel the card. I do
>not carry my ss# on my person, it has never been on the hd of my computer
>and I
>have never used it on a website. I do not access any of my financial
>information online because many such sites seem to require it.
>
>I plan to email the administrator of the training program and ask about
>changing my username. If they are unwilling or unable to change it, what
>sort of questions should I ask about the security of their network? All
>I know about intranet security I got from this page:
>http://intranetjournal.com/features/isecurity.shtml
>I know intranets can use ssl/128 bit encryption so I plan to ask about
>that. If they don't use that, what are some other ways to secure an
>intranet? Should I ask them about their firewall, How often the system is
>scanned for trojans?
>If anyone here is in charge of an intranet, what sort of security setup
>would make you willing to use your SS# as a username?
>
>We were given a url to use if we wanted to try accessing the training
>course from home. I checked the url with Neotrace and now have the names
>of the network administrator and coordinator. Would one of these 2 be in
>charge of assigning or changing user names? Should I direct my questions
>to them. Do you think they'd be pissed to get an email from me?
>I entered the url on my computer and got this message:
>
>Enter Network password
>
> please type your username and password
> Site: joe.shmo.com
> Relm: HTTP Authentication(ID#####)
>
>I typed nothing, hit enter and got this:
>
>Error: Authen Rejected.
>
>No 401 or 403 message. Does this give any hints as to how the network is
>secured.
>
>Finally, the company has a web page where you can apply for a job with
>them online. They ask for your name, address, phone number and you can
>even upload your resume. THE PAGE IS NOT SECURE! No "https" in the url,
>no little yellow padlock at the bottom of the screen! I think you'd have
>to be pretty foolish or desperate for a job to use this page. It only
>heightened my concerns about the security of their network.
>
>This company is a huge corporation, they are listed on the NYSE. You
>think they'd have better sense than to use SS#s to log on to a network.
>Sorry to go on so long and the crossposts.
>TIA for any advice or help.
> m.m.
William Barwell
Machine Messiah <Poo...@nospamdamnit.com> wrote:
>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.
In California, after July, this sort of guff will be illegal.
You ain't in Cal are ya?
9 News: California Bars Public Posting of Social Security Numbers
(p2 of 4) Events [arrow.gif?OpenElement ] ConferencesAll Events
Links All Links Payroll Library[0.5C8?OpenElement&FieldElemFormat=gif]
Volume: 13 Number: 9 April 24, 2002 Privacy Law California Bars
Public Posting of Social Security Numbers California has enacted a new
law (S.B. 168) that would, among other things, preclude ``a person or
entity'' from publicly posting an
number or printing that number on anymaterials mailed to the individual,
unless state or federal lawrequired the number to be on these materials.
The law also would prevent an entity from requiring an individual
totransmit his/her Social Security number over the Internet or use
that number to access a Web site. These provisions would apply to the
use of SSNs on or after July 1, 2002.
Cheerful Charlie