G Suite security policies


(Tanner Filip) #1

I’ve mentioned this a few times, but never posted it here. We really need to enforce 2FA on G Suite admins. We might also want to have some password requirements, but imo that’s not as important as 2FA. Here’s what I propose:

  • By August 26, 2018, all admins must have 2FA enabled.
  • Admins who don’t have it enabled at this time will have their admin permissions removed until they turn it on.
  • Physical security key (such as Yubikey) is recommended, but OTP (e.g., Google Authenticator) is acceptable.

Feedback?


(Syamkumar) #2

that’s a great proposal.
why wait till August 26. When we can enforce it now.


(Tanner Filip) #3

Because we would lock people out otherwise.


(Syamkumar) #4

What about a deadline that’s more close.


(Tanner Filip) #5

You’re right. How about August 6th? That gives us enough time to reach out to those that don’t have it enabled and for them to take care of it.


(Syamkumar) #6

Also we can ask community managers to enable 2fa on new mail boxes they create.


#7

I prefer the original timeline. We have the OVH eol to deal with yet and that should take priority.

Let’s flesh out the plan and then set dates. We need to draft a communication and schedule sending it. Then we need to schedule follow up actions.

I’d say two weeks is realistic. Give admins a week after receiving the communication to act.


#8

2fa is a pain. I wouldn’t make it mandatory across the board.


(Syamkumar) #9

Just a suggestion if we are gunning for more security


(developer11) #10

Its far from being pain. Fact that you stated this publicly makes you look miserable in the eyes of any TA (Technical Admin) that takes their job seriously…

I understand what you meant :: necesity of providing either authenticator code or one-time code, I agree that it can be hard, but it was developed for the reason of being hard

Try to stop/Experience one or two, gigascaled DDoS(es) and you will quickly realise how naive was your statement.

====

In fact I think that 2FA should be enabled by default on any serious web-services (GSuite being the one), and admins shouold not be able to disable it.


#11

I didn’t mean that it was hard. I would have used the word hard, or difficult if that’s what I meant.

How secure it is doesn’t change whether or not it’s a pleasant experience for the end user. We actually have one or two Mozillans who don’t have a mobile phone to use 2fa, certainly an edge case, but for those users it’s an extra pain. People also lose their phones and run the risk of being locked out.

Are we at risk for a gigascaled ddos if we don’t require regular inbox users to use 2fa? I would be happy to be enlightened as to why there is a reasonable risk to justify the trade off in user experience.

Also to be clear, I’m expressing my opinion, which is not the same thing as making a decision.


(developer11) #12

Thats simply not true.
Loosing access to your phone doesnt lofck you out of your account. Dont owning/forgeting/loosing phone is also not a problem with 2FA as there are always a printed codes to make use when you do not have access to your phone…So your remark was pointless.

Laugh me out, but yes. Dont requiring 2FA does 2 things:: greatly increases chances of being DDoSed, but also minimalizes your chances of full, quick recovery from, said DDoS.

Study security little bit… Its really really obvious.


(David Ross - Mozilla Rep & UK Community) #13

@developer11 I’m coming in again to ask you to please show respect in this forum. As a participant of Mozilla’s Discourse you are expected to observe Mozilla’s Community Participation Guidelines.

I see that you’re a new user here, so you may have missed it’s contents. I’d appreciate if you’d take the time to immediately read that document.


(rugk) #14

As for users without a phone, there are many (even more secure) ways of 2FA that use hardware keys. E.g. the well-known YubiKeys or NitroKeys – or any other vendor.


#15

Yes Tanner did mention those. I suppose it would be interesting to explore whether Mozilla would be willing and able to supply the community with them as needed.

Though a point missed by my critic is that we’re talking about normal people who do lose things. Hard drives die or are wiped, machines get replaced without everything being migrated over.

My personal opinion is that regular end users shouldn’t have to carry an undue burden. For example my grandfather’s memory is starting to go. He’ll forget his password and reset it to get in to his accounts. However Google doesn’t let you use the same password as it used to be, so he can’t set it back to the password he remembers. For a little while he was stuck resetting it regularly because he would fix it on his phone then forget it by the time he had to reenter it on his desktop so he’d reset it again and then forget it by the time his phone asked for it again. But each time he’d have to change it to something totally new and the chances of him forgetting it increased. It was basically a form of dos and the solution ended up being to get him to write it down and tell it to other people. It was less secure than letting him reuse a password.

The physical keys sound interesting for someone like him, he isn’t prone to losing his keys, but they could be a disaster for many people with ADHD. I suppose it depends on the recovery options.

I think it is fair to expect someone who is managing a technical resource to be able to manage the extra steps, and I appreciate that access to certain information justifies any extra burden while there are not better options. But by nature any security measure is a barrier to participation and I don’t believe it is Mozilla’s way to use them just because they exist. The risk needs to be weighed against the cost to participation.

So the first thing I’d want to understand is what are the risks of a regional community member’s inbox only being secured with a password?