A question for IT Admins about password security in edtech products

[Lee989]

Disclaimer: I'm a software dev working for a UK edtech. Here to ask questions to make sure we're not causing unnecessary issues for School IT Admins.

 

Like most products, we support pupil login via various SSO's (Wonde/Google/etc), but we also support username & password combo's, and currently, the latter appears to be the preferred sign-in method of most of our schools at the moment, and the one we are having a lot of support issues with.

 

Teachers setup pupils, then either forget to hand out the login cards with the details on, they get lost, or a child leaves it at home. This then requires resetting passwords, which inevitably leads to problems where the old login creds are "somewhere" and they try to use them later, or they forget to send the new details home, parent shouts at the teacher about our app not working, and they then shout at us.

 

Our product manager already had us add a "you may want to save these in your One/Google Drive in case you lose 'em" note, but I don't need to tell you... people don't read (not that I love the idea of saving passwords in a shared drive anyway).

 

We have now been told to explore options for password recovery over resetting. Which essentially means encrypt it, instead of hashing it. So we can decrypt and regenerate the same login cards.

 

These passwords don't protect a great deal of personal data, pupil name, school they go to, and their progress in our app (homework basically, nothing that special), this is the justification being used internally for the reduction in password security, it's not protecting all that much anyway.

 

My concern is, that every new school customer starts with an IT admin tasked with doing a DPIA and setting a few bits up, and the minute they see "pupil passwords are encrypted, teacher passwords are hashed" in our DPA information sheet, they are going to push back hard, possibly even convincing the school to cancel the sale as "we don't know what were doing, cant even get basic password security right".

 

So what are the thoughts of IT admins here? Is this "encrypt don't hash" pupil passwords a major issue you'd fight, or do you just not care that much given the limited pupil info your sharing.

 

Poll for convenience, extra gratuity for anyone that says they don't care, but can explain what they'd want to see to make them reach that decision.

 

For clarity: What i'm trying to avoid is creating a fight match , where we do this, teachers love it and want it, IT admins hate it and have to argue with staff. It's not good for you, the other staff or for us.

[Cazab]

All it takes is one hack to ruin you. You are still processing collecting and storing PII of students. As a company you should be modelling best practice.

[mavhc]

Only offer SSO, don't store any passwords yourself, that's just asking to be hacked, and more annoying for you with GDPR, store as little info as possible

 

Teachers don't know what SSO is, make sure your setup process involves talking to the IT support people

[Lee989]

All it takes is one hack to ruin you. You are still processing collecting and storing PII of students. As a company you should be modelling best practice.

 

Absolutely, and to be clear I am very against this, hence why i'm here. I have never in my 10+ years of programming ever stored a plaintext or encrypted password. I'm fully aware of the implications, and I hate it.

 

But money talks, and if I can say "hey, we do this, and we'll never close a sale again" with a screenshot of the poll proving it's not going to go down well, it's a bit more impactful than "hey, if we get hacked, which none of you think will happen, we're done for".

 

On the flip side, i'm also verifying that i'm not being super anal about it. If contrary to my expectations the poll swings to "its fine", I'll have to revaluate my own stance on it.

[Cat_Jam148]

Only offer SSO, don't store any passwords yourself, that's just asking to be hacked, and more annoying for you with GDPR, store as little info as possible

 

Teachers don't know what SSO is, make sure your setup process involves talking to the IT support people

 

I think that's a very short sighted take on all this. We have SSO hooked up to as many services as we can but...

 

There is still a strong argument to be made for traditional usernames and passwords. Yes, in an ideal world we'd all be using SSO and MFA on all accounts, but there are many schools out there who just don't have the resources to get even something as simple as SSO working. Let alone maintaining it.

 

SSO should always be an option these days, but there is still a place for a username and password (with the option of MFA)

[Lee989]

Only offer SSO, don't store any passwords yourself, that's just asking to be hacked, and more annoying for you with GDPR, store as little info as possible

Teachers don't know what SSO is, make sure your setup process involves talking to the IT support people

 

IT are always involved to some degree, not sure why SSO uptake is so low, there's so many edtech products in schools these days, surely most, if not all have an SSO provider rather than managing 10 different logins per child.

 

Possibly we have a UX issue to address to promote SSO more heavily. Part of the setup wizard asks if they want to login with Wonde/Google/etc or use passwords, but that is usually completed by the teacher who is acting as the "Product admin" (usually a subject lead). Maybe we need to split that wizard up so IT admins are asked some Q's first, then it goes to the teacher for the other stuff like enabling / disabling the features they want to use with the pupils.

 

Food for thought, thanks!

[dmj]

What's wrong with SAML? It was specifically designed for education, it's a free to use open format that's been around for 20+ yrs, supported by all the major identity provider vendors. Why is having local logins even a 'thing' ?

[mavhc]

If they're still logging everyone in with the same account they're probably violating multiple rules, so should fix that before buying any more software

[dhicks]

we support pupil login via various SSO's (Wonde/Google/etc), but we also support username & password combo's, and currently, the latter appears to be the preferred sign-in method of most of our schools at the moment

 

Do you have any idea why? Are teachers / admins not realising you offer an SSO option, is it maybe not obvious enough in your documentation / sign-up process? I'd guess most UK schools have either Microsoft or Google accounts for their pupils by now, it should be much simpler in most classroom situations for teachers to say "now, login with your Google/Microsoft logins".

[dhicks]

Possibly we have a UX issue to address to promote SSO more heavily.

 

Ah, you've pretty much answered my post as I was typing it! Just from experience, the less steps / buttons to press for the user to log in, the better. If you can somehow give the IT admin a choice of, say, "just Google logins", then instead of having to show the user a "enter username/password" box and give them a "log in with Google" button you can go straight to the Google login workflow. Cloudflare do this quite nicely with their zero-trust tunnel gateway, our remote desktop users just follow a link straight from a menu page, if they're already logged in with the Google account the "log in with Google" page just whizzes past, I don't think most of them even realise they're logging in with their 2FA-protected Google account.

[Lee989]

Ah, you've pretty much answered my post as I was typing it! Just from experience, the less steps / buttons to press for the user to log in, the better. If you can somehow give the IT admin a choice of, say, "just Google logins", then instead of having to show the user a "enter username/password" box and give them a "log in with Google" button you can go straight to the Google login workflow. Cloudflare do this quite nicely with their zero-trust tunnel gateway, our remote desktop users just follow a link straight from a menu page, if they're already logged in with the Google account the "log in with Google" page just whizzes past, I don't think most of them even realise they're logging in with their 2FA-protected Google account.

 

Yeah I think one thing i've already realised from being forced to look outside-in, is we need to do more pre-setup with IT admins. People who know what we're asking for. I suspect because passwords are so ubiquitous a teacher is asked the "how do you want pupils to login" and "password" is just the obvious, no thinking required, "i use passwords all the time" choice.

I also need to setup some kind of non-intrusive comms channel with our schools' IT admins, where I can ask for feedback and thoughts on stuff. I've always taken the view of it being pointless, they're too busy to bother responding to you, but it's the usual "don't ask, don't get".

[dhicks]

I also need to setup some kind of non-intrusive comms channel with our schools' IT admins, where I can ask for feedback and thoughts on stuff.

 

I guess so, although if that's simply you sending out an email it'll probably just get ignored along with the other not-immediately-important emails.

 

A handy feature I've wanted several times is for login-with-Google / Microsoft functionality to work right away without needing the IT admin to set anything up / sync any data. Most schools will have a Google / Microsoft domain, so all their logins will be of the form "[email protected]" or similar, so if on setup you can just allow any login from the "theirschool.sch.uk" domain, maybe just assigning them the most basic pupil account, that might the getting started process a bit smoother.

[Lee989]

I guess so, although if that's simply you sending out an email it'll probably just get ignored along with the other not-immediately-important emails.

A handy feature I've wanted several times is for login-with-Google / Microsoft functionality to work right away without needing the IT admin to set anything up / sync any data. Most schools will have a Google / Microsoft domain, so all their logins will be of the form "[email protected]" or similar, so if on setup you can just allow any login from the "theirschool.sch.uk" domain, maybe just assigning them the most basic pupil account, that might the getting started process a bit smoother.

 

Wouldn't work for everyone, we have quite a few schools with the same domain, but yeah it's an idea we could allow the IT admin to say they have a unique school domain and to allow automated access from it. Hash the email on first login to act as a username (because i'm not storing pupil email addresses... ever!). I've already put it on my list to investigate further

[mavhc]

Oauth/login with google/microsoft is only step 1, true, you also want to find out who's a teacher vs student, what class they're in etc

 

Also a way for the admin to restrict data transfer and export/search/delete all/some data for the domain

[psydii]

Maybe as part of the pre-sales->customer pipeline the sales team could ask "does your school use Google or 365 for sign-on" with a fall back to "gmail or outlook for the kids?" for those who look at them blankly, from them arrange to speak with the IT team/DPO to make the on-boarding smooth. You'd get brownie points from me for asking to chat with the DPO

 

I fear though that perhaps the experience of your company is actually representative, and the responses here not so much, because here we all know SSO is the correct answer and we are all in a position to make it happen.

[Lee989]

Maybe as part of the pre-sales->customer pipeline the sales team could ask "does your school use Google or 365 for sign-on" with a fall back to "gmail or outlook for the kids?" for those who look at them blankly, from them arrange to speak with the IT team/DPO to make the on-boarding smooth. You'd get brownie points from me for asking to chat with the DPO

I fear though that perhaps the experience of your company is actually representative, and the responses here not so much, because here we all know SSO is the correct answer and we are all in a position to make it happen.

 

On the back of this thread, I've already started wireframing an IT admin setup wizard that I think could be used during onboarding. It's pretty clear now that we need to do better onboarding and not just throw it all on a teacher to deal with. The first screen being "this bit needs completing by your IT admin" and "here's a fact sheet to help fill in the most common DPIA questions, contact dpo@ if you need anything else" and includes questions like login type, SSO setup, a web filter test to check our app & cdn domain isn't blocked, confirming device platforms used in school (web vs native app). Get all the technical stuff out of the way before a member of staff starts the product configuration & setup.

 

I'll see how it goes down with the rest of the team, but I can't see their being objections to providing a better first impression!

 

Thanks to all who commented, diverted off topic, but really insightful. Hopefully I can make your lives easier if you ever come across us in the wild

[Primus]

Yes I think you could help everyone by explicitly prompting them to involve their IT team!