FacebookTwitterLinkedIn
Login / Register

Login / Register

IUG FORUM

Stay always connected!
  1. Allison Hunsberger
  2. Sierra/ Millennium/ Encore
  3. Thursday, April 20 2017, 10:48 AM
  4.  Subscribe via email
We're looking at our Sierra logins from a security perspective and trying to make some changes in the interest of better security.

Current structure:
We have 8 locations with anywhere from 2 to 15 shared circulation terminals at each. Each terminal has its own login (we track circulation by stat group/terminal). These terminals use a shared Sierra password. We change this shared password every 6 months, in compliance with our internal password policy.
Staff with a dedicated workstation/office (managers, supervisors, tech services) have individual logins for which they create their own password.

Concerns:
Our public and staff networks come from one external IP address. By opening our (hosted) Sierra server up to these networks, we're opening it to our staff and public machines and our staff and public wi-fi. Anyone with knowledge of our Sierra Web URL and shared login credentials (or the ability to guess either) can access Sierra from our parking lot on the public wi-fi. We have turned off Sierra Web for all the logins that have a shared password, but with Innovative on track to move Sierra entirely to the web client we're going to have to grapple with it eventually.
Turnover with frontline staff is constant. I can't imagine changing the shared password for all of them each time someone leaves.

Plans?:
We're considering context users with individual credentials for each staff person. This would be much easier if Innovative permitted us to push credentials from Active Directory. In lieu of that, we're considering a username/password OR username/PIN approach.

--What is everyone else doing about logins and security? Did you draw a line somewhere for the sake of your staff?

--If you use individual logins, how has this been for your hourly/part time staff? For your less technically-inclined staff? We're concerned about putting another stressor on staff--Type in your complicated password correctly while this patron is breathing down your neck about fines!

--What if staff forget a password? We may have as few as 2 people working on a weekend. If one forgets the password, that leaves one person with access to Sierra.

--Do you lock Sierra after a set number of incorrect entries? How do your staff reset their passwords?

--How do you manage a large amount of logins (onboarding, termination, forgotten passwords) without being able to integrate with something like Active Directory?

--Are you waiting for Sierra to permit you to push domain credentials before you take this plunge? Do you feel that it will be easier for staff to use their domain credentials in Sierra after every timeout, or a shorter/simpler password or PIN? We have a lot of debate on this topic!

--If you’re using a timeout in Sierra, what is your inactivity period?

We’re looking in all different directions and have staff with an argument on every side of this issue. It would be nice to share some outside perspectives and feedback with my team.

ahunsberger@dcls.org
Comment
There are no comments made yet.
Add Comment
Jeremy Goldstein Accepted Answer
0
Votes
Undo
I don't have any real answers for you but can certainly commiserate with all of your concerns. At IUG this year there was a birds of a feather session on user account management for consortia and these sorts of issues were an enormous concern for all involved. To summarize it very briefly, we generally all used the same practices for the same reasons and all hated what we we're doing.

In our case we manage a little over 400 logins (we just maintain a spreadsheet of them all), many of which are shared among multiple staff in a given department, and we have to maintain the ability to login ourselves to all those accounts in order to perform regular troubleshooting. That, plus staff inconvenience, plus regular staff turnover, plus auto-logon scripts in use at many locations really prevent us from having the sort of rigorous account/password policies we would ideally like.

jgoldstein@minlib.net

jgoldstein@minlib.net
Comment
There are no comments made yet.
Add Comment
Philip Ashmore Accepted Answer
0
Votes
Undo
Hi Alison
We (Gold Coast, Australia) changed to contextual logins in January this year. We have 13 libraries and a high number of library staff, including many casuals who move between libraries. We currently do not use any system-enforced password change or keyboard timeout settings. Each library has a Sierra login and then library staff sign in with their employee number (5-digits) and password to access Sierra functions.

Issues with logins:
1. Passwords are only checked on the first 8 digits - any additional characters are ignored. So if my password is "pumpkin1" I can successfully log in using "pumpkin12345abc". This is bad for obvious reasons and needs to be fixed.
2. Some username combinations aren't valid for SQL and Admin Corner access. So far, we have found that if the username's second character is "1" it cannot be used, but other combinations might also exist. Bad legacy coding which also needs to be fixed.
3. There has been pushback from library staff about having to use the contextual logins. Part of this is because our council's requirements for individual logins when accessing a business system (information privacy) was not enforced in our previous system and partly because of the increased time it takes when multiple staff are using the same PC within a short space of time. It is a change which we are still managing.
4. One of the confusing features of context logins is that it is still possible to perform transactions (to a point) without having the individual staff member sign in as the operator for that session. So they can scan a library card but not update an address, check in an item but not manage holds. When trying to do anything which requires a permission, the staff member is bombarded each time with an authentication request and if they then set the permissions to their login, Sierra clears the screen and list of recently accessed records, so they have to start again from scratch. Ideally, context logins should have the option of being completely locked off when no other login has set the permissions OR a checkbox when performing the first authentication request - which would then set the permissions to that user without breaking the flow of the transaction.
5. We don't get the level of reporting we would like from authenticating individual staff for all transactions. We can see overrides by user and financial transactions, but not who accessed, created or edited specific patron records; we can't create an activity report by staff member.
6. Passwords can only be reset by administrators, which is a challenge for library staff who predominantly work weekends and evenings. I've heard that there are plans for an email-reset option for Sierra users, but don't know which version that will become available in.
7. There are also some wins to using contextual logins, such as management of Create Lists and Rapid Update. Now we can list these functions on our library logins and only staff members with the correct permissions can use them. Previously, we had to maintain separate logins for access to these functions.

We have also raised concerns about the potential openness of Sierra Web. We are a hosted customer and have set up a VPN between the council network and the servers for Sierra. For council staff wi-fi networks, we can set up an IP range in Limit Network Access, but we might be wanting to use Sierra in an outreach capacity, so will be using mobile networks (which makes maintenance more difficult). Perhaps a two-factor authentication method with Sierra Web will make access more secure, rather than whatever the go is with domain credentials?

Philip
pashmore@goldcoast.qld.gov.au

pashmore@goldcoast.qld.gov.au
Comment
There are no comments made yet.
Add Comment
Phil Shirley Accepted Answer
0
Votes
Undo
Allison, have you looked into the possibility of using separate external IP addresses, one for your staff computers and a different one for your public computers / wifi? It might be possible to configure your firewall to do that. That way you could have a better restriction on which computers were allowed to connect to your Sierra server.

pshirley@cuyahogafallslibrary.org
Phil Shirley
Technology Services Coordinator
Cuyahoga Falls Library
Comment
There are no comments made yet.
Add Comment
0
Votes
Undo
Thanks, all, for the useful feedback.
Phil, I took your firewall suggestion to my IT Director and he is willing to look into it. Wifi and outreach will be sticky, but I think we'll give it a shot. It would definitely help to mitigate my discomfort with the shared passwords.

ahunsberger@dcls.org
Comment
There are no comments made yet.
Add Comment
  • Page :
  • 1


There are no replies made for this post yet.
Be one of the first to reply to this post!
Guest
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,pdf,ppt,pptx,doc,docx,xls,xlsx,,txt,rtf,jrxml
• Remove Upload Files (Maximum File Size: 2 MB)
You may insert polls into your post. The poll would then appear in the post.
Vote Options
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.