Educause Security Discussion mailing list archives
Re: stopping students sharing their login credentials
From: Charlie Reitsma <reitsmac () DENISON EDU>
Date: Fri, 23 Jan 2009 12:09:46 -0500
We assumed it would often be bogus but it rarely is. The account itself is named "gst" followed by a 4 digit number. The process is logged and so far the patterns of use have not raised any red flags. It is possible to revoke the privilege on an individual if this ever became necessary.
Quoting "Barros, Jacob" <jkbarros () GRACE EDU>:
Do you just trust that the student isn't creating a bogus name or do you even care about the true identity of the guest? We considered this approach and I am just curious to how you address this issue.Jacob Barros Network Administrator Grace College -----Original Message-----From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Charlie ReitsmaSent: Friday, January 23, 2009 11:17 AM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] stopping students sharing their login credentials We provide a self-service web page to create guest accounts. We allow our students to create up to 4 concurrent guest accounts. We allow our staff to create up to 10 concurrent guest accounts. The Library staff and Conference Services staff can create any number of guest accounts. The accounts are good for logging in to campus owned machines and wireless access on their own computer. They don't get email, printing or space on the LAN. The Library can sell printing to guests. Accounts last from 1 to 14 days. If a longer term is required then they need to get Information Technology Services involved. When they expire they are removed automatically. The policy states that the sponsoring department/individual is responsible for the behavior on the network. So make a strong policy against sharing AND create an easy method for providing access to guests. Provide tools for the reasons that anyone might give when asked why they shared their account. Quoting randy marchany <marchany () VT EDU>:One should never put in a policy/standard any item that can not be enforced. While the spirit of the statement "you must not share your userid, login credentials with anyone" is certainly clear, the reality is that this cannot be enforced without additional monitoring such as 2 factor authentication, video feeds or witnesses. The most common "abuse" of this would be a simple login and computer logs cannot show that a userid was shared or WHO the person was that actually logged into the system. Biometrics isn't foolproof since I could login with my biometrics and let you use my userid. Card swipe access isn't foolproof since people form trains to enter a facility. Shoot, I remember visiting a campus, going to a pizza place right across the street and seeing the building access code written on a piece of paper on the bulletin board next to the cash register. Apparently, that pizza place delivered a lot of pizzas to labs in the building :-). So the "must not share" clause is basically unenforceable and weakens your policy/standard. Another way to express the intent of the clause is needed. Why do people share these things? Could be something as simple as the site doesn't have a mechanism for guest access. An example of this is guest wireless access on campus. You have a guest speaker who needs wireless access, your campus has no mechanism to provide guest access so you, the sponsor, lets the speaker use your credentials to get access. Email access, door access are other examples. An email system doesn't allow sharing of email folders, a dept. head is on travel and the assistant needs access to those emails. The only alternative is to share the email password. So, how do we fix this? The best solution I found was to state "you are responsible for whatever activities originate from your userid, computer, id card..." (feel free to include whatever authentication/authorization mechanism you have). This is easily enforceable. Computer and access control logs note the "userid/token" that was used to gain entry. SInce you can identify the owner, that person is responsible for its use.I do believe having the "responsible for its use" strategy is more effective.In Russell's case, the access logs contain the name of the card owner. You contact the card owner and ask them the necessary questions :-). Just my .02. Randy Marchany VA Tech IT Security Office and Lab On Thu, Jan 22, 2009 at 9:25 PM, Russell Fulton <r.fulton () auckland ac nz> wrote:Background: Earlier this week we had an incident where the building security officernoticed a group of unfamiliar people using machines in one of our labs. Sheasked them for their ID cards and none could (would?) produce one. Onquestioning they said they were students from a neighbouring institution andthat they were using "borrowed" credential. We have cctv footage and swipe card logs from the door (which may show theytail gated someone in). We are now tracking down which machines were beingused so we can disable the accounts. To the point. We (the security techies) have been asked what measures we can deploy to prevent this sort of thing happening in future. We already do lots of education, posters, page on the back of the studenthandbook. Students have no excuse for not knowing that they should not sharepasswords. On the social/education side we could make an example of anyone we finger for this (assuming we can make charges stick) in the hope that this will persuade other students not to share their passwords. Technical solutions seem to revolve around some form of two factor authentication. I.e. something the student has but which they will be reluctant to part with for any length of time. Like their ID card. Our ID cards have bar codes and classic mag stripe. Some labs (like this one) also have proximity card locks. Generally only post grad students or students in special coursed (like medicine) have proximity cards. Anyway I would very much like to know what other are doing in this space. Cheers, Russell
Current thread:
- Re: stopping students sharing their login credentials, (continued)
- Re: stopping students sharing their login credentials randy marchany (Jan 23)
- Re: stopping students sharing their login credentials James M. Dutcher - Assoc. VP IS/IT & CIO (Jan 23)
- Re: stopping students sharing their login credentials Christopher Jones (Jan 23)
- Re: stopping students sharing their login credentials randy marchany (Jan 23)
- Re: stopping students sharing their login credentials Mike Wiseman (Jan 23)
- Re: stopping students sharing their login credentials Charlie Reitsma (Jan 23)
- Re: stopping students sharing their login credentials Neil Sindicich (Jan 23)
- Re: stopping students sharing their login credentials Barros, Jacob (Jan 23)
- Re: stopping students sharing their login credentials Basgen, Brian (Jan 23)
- Re: stopping students sharing their login credentials Brad Judy (Jan 23)
- Re: stopping students sharing their login credentials Charlie Reitsma (Jan 23)
- Re: stopping students sharing their login credentials Gary Flynn (Jan 23)
- Re: stopping students sharing their login credentials Valdis Kletnieks (Jan 23)
- Re: stopping students sharing their login credentials Neil Sindicich (Jan 25)
- Re: stopping students sharing their login credentials James M. Dutcher - Assoc of IS/IT & CIO (Jan 25)