LGFL - staff password change

[strawberry7]

Hi,

It has been a long time since I posted on here. I was wondering what you all think of the LGFL change that happened today regarding staff passwords.

 

Traditionally, LGFL have always allowed approved support and nominated contacts to view passwords for staff. This allowed us to issue new passwords to the staff. If the USO Sync was in place, it also meant we could login as a staff member without having to disturb them to check their machines.

 

LGFL have now taken this ability away - citing GDPR compliance. I take issue with this for 4 reasons:

 

1. We did not receive notice that this was happening. I am asking LGFL if any was issued.

 

2. I am no GDPR expert but I have spoken to a few. I do not believe that having the ability to see users passwords was a breach of GDPR. GDPR is all about informing people what is happening with their data and protecting it as much as possible. It would actually be more relevant to hide the staff mobile numbers for example. As long as the staff are aware that we have the ability to see their passwords, then GDPR compliance should be met. Also it probably would have been better to give staff the ability to hide their passwords from support should they wish.

 

3. In the real world, this change is very impactful. An example is that during half term we are undergoing a change (coincidently LGFL related) at one of our new schools. During half term we are wanting to check various computers and teacher logons. This is now not possible as we cannot see their passwords and the staff are not contactable during half term. Any resets of passwords are going to the staff mobiles and we will not be able to access them.

 

4. LGFL have stated that 'In order to make it simple and efficient to reset staff passwords we would encourage staff to verify their mobile numbers.' Again, there has been no lead-in time to set this up or prepare.

 

I would be interested to hear if you are affected by this change and what your thoughts are.

[FishCustard]

IMO being able to log on as other (real) users is a terrible idea. I never liked the fact that you could view people's USO passwords, and it sounds like you're using the same passwords for network accounts which is... not the best idea.

 

Consider the case where someone did something nefarious on a PC, logged in as "jbloggs.999". Mr Bloggs could quite easily claim that "IT did it because they know all our passwords". Even if they don't claim that, it reduces traceability of actions. Yes, you could reset their password and do it, but at least then they'd know that something odd had happened.

 

To say nothing of the fact that we should be training people not to share/give out their passwords or have them known by other people. If you need a test account to check things as a staff user then create a test account.

 

I think this is a good change from an infosec standpoint - I agree it probably doesn't help GDPR compliance, but it's a positive step anyway. Now to get them to stop mandating password changes for NCs every 90 days (you know, against explicit GCHQ/NCSC guidance...).

Edited October 19, 2018 by FishCustard

[strawberry7]

Hi,

I understand your points, however my main point was actually the lack of notice of the change. If we had been notified about this a few months ago, it would have given us time to prepare the schools.

 

The password match I mentioned is done automatically via USO Sync. I agree it is not the best idea but if you provide users with too many passwords, they write them down and stick them to their computers, put them in a drawer, etc - a worse situation I am sure you would agree. That is the real world situation of what people do. It is therefore sometimes the lesser of two evils to standardise as much as possible. Consider being able to sign in to platforms with your Google or Facebook account for example. You are, in affect, creating a single login with single password. I realise there are extra security layers when using this system but the principle is the same.

 

Whilst I do also agree with your point about user accountability, our support requests are all recorded and tracked through our support desk. It is therefore recorded when we are working with a user or their machine and the school understands this.

 

I do not believe it creates an idea of sharing passwords. An approved, trusted support engineer, who administers your computer, being able to have access to your password is different to giving it to another staff member. Test accounts are fine but there are instances when specific user related issues need troubleshooting and ensure that it works for the exact user in question is preferable.

 

Do you administer LGFL yourself?

[Primus]

Viewing user passwords is horrific practice - it means they're being stored using either reversible encryption or in the clear. No one should ever ever ever be able to see passwords.

[Garacesh]

No sysadmin should ever be able to see what a user's current password is. For a start it's just a huge security risk since we know users re-use passwords. If a sysadmin does need access to a person's account, a change in password ensures that the user becomes aware that 'something has happened' (OK, the sysadmin can just lie and issue a standard password reset, but it's still better than being unaware at all).

 

I admit there's some nuance where it might be beneficial to impersonate a user without them knowing about it and without locking them out of their account, but an option to do that should be a separate thing that doesn't expose password info.

[FishCustard]

I agree entirely about having fewer passwords - but the comparison with Google/Facebook login (which use OAuth, not just copy-pasting passwords essentially) isn't a great one. OAuth and similar single sign on systems pass hashes around, not actual passwords. The idea that even trusted users can get hold of people's network passwords in plain text rubs me very much the wrong way, and IMO should never, ever be possible. I realise that if someone compromises an NC account then that is a whole separate can of worms, but the attack surface is significantly reduced with having separate, completely secret AD passwords.

 

I suppose it's easier for us as only about 5% of our staff actually use their USO account - most don't have any cause to.

 

My point about accountability was more along the lines of users being able to point the finger at IT should anything happen under their account. "I wasn't logged in, it was IT!".

 

I agree that trusted support engineers are different to staff members, but it still goes against the message that we try to get across to users. "Never share your password, nobody should ever ask for it, not even your bank should ever know your PIN or ask for it, etc". The idea is that passwords are secret, and must stay that way. Things like this poke holes in that message.

 

I do administer LGfL for my school - and please understand that I am the last person who would usually defend them! I agree that more warning should probably have been given, but then I'm never surprised at their inefficiency.

[CAM]

Hilariously, if you changed your password to something offensive then LGfL's filtering would send warnings and block external messages when the list was mailed around between management.

[JohnJackson]

Hi everyone. Firstly, I'm grateful for the feedback. By way of background, we wrote to all schools in June recommending the encryption of staff passwords and LGfL indicated then that we would subsequently take action to do this. I also consulted with representatives of schools, representatives of MAT's and Councils and the recommendation to improve security as a priority was supported. I guess there was never going to be a perfect moment to implement this change but we worked on the assumption that staff would be conversant with their passwords by now. I have asked Atomwide to enable a solution for new starters which will allow a viewable temporary password which was identified as a need during the consultation period. Please rest assured that in terms of LGfL overall, I'm listening carefully to the feedback on the services that are provided for us through our partners, including Atomwide, and I am determined to ensure that schools have the best possible service into the future. Some very significant changes and IT innovations are coming!! In the meantime , if you have any issues, please don't hesitate to contact me directly. I really do value your support.

[strawberry7]

Hi John,

Thanks for the response. I wanted to contact you directly about this but could not find your email and it was a bit long for Twitter!

 

I understand your points, however the information back in June did not specifically say that you were going to remove this ability. As mentioned in my other posts, some notice would have given support companies and schools some more time to prepare and ensure staff mobile compliance.

 

I am more than happy to provide feedback on the Atomwide services and LGFL. You can reach me anytime on 01252 279777 or [email protected]

[JohnJackson]

Hi, I appreciate the response. Going forward, in response to feedback from schools and third party support organisations, LGfL will be making some changes to the way services are currently managed and delivered. In particular, I will be forming a new team called TECH SQUAD that will be the equivalent of our curriculum team to provide consultancy to third party support organisations and also product leadership. In terms of the process, I've commissioned some work to introduce a new process for starters that will help and we'll also ensure that staff can provide other meaningful information than just the mobile phone to reset passwords. I am grateful for your offer to feedback and I'll pick this up directly with you next week. Very best wishes

[Primus]

Hilariously, if you changed your password to something offensive then LGfL's filtering would send warnings and block external messages when the list was mailed around between management.

 

So passwords were stored in the clear and then emailed between people? WOW!

[JohnJackson]

Colleagues, I've asked Atomwide to consider some urgent changes to the USO login pages to enable password resets to happen on this screen and have requested that some further tweaks to the reset process are considered to make personal reset simpler. Once again I appreciate the feedback.