Enhance Bahmni security with 2FA or TFA

Software Bahmni
, ,
1

Bahmni using basic authentication (username, password) from OpenMRS so far. But always good to have additional security mechanism so that user is protected from fraudulent act. So, we are planning to introduce 2FA in Bahmni.

The following options are considered.

  • SMS verification (ex: OTP)

  • MDM (Mobile Device Management solutions)– no good open source solution available.

  • Giving the Android app administrator privileges – cannot do 2FA and also this will not be a generic approach because we may want to use 2FA from laptops as well.

The option chosen was SMS verification.

High level design:

The high level view of the design looks as shown in the figure below. The idea is to provide an abstraction layer on top of different service providers (ex: Rapidpro, Twilio, Kannel) and SMS aggregators. This ensures that Bahmni talks to a single endpoint on the abstraction layer. This layers takes care of providing custom connectors to specific service providers or aggregators.

For heavily resource constrained settings where we cannot use aggregators, we can choose to use an Android phone to send SMS to the devices. One of the options of achieving this is to use Android Channel provided by RapidPro.

Pasted image875×473 46.8 KB

There was a OpenMRS talk about pluggable authentication. The current design proposal of OpenMRS is not using Spring Security. @angshuonline had a suggestion of using Spring Security to make the development more simpler. There was a design call with OpenMRS on this and notes can be found here.

Because of the timelines, we would not be going ahead with making changes in OpenMRS at this time. But, we will make necessary changes in Bahmni to realize this two-factor authentication.

We are happy to have suggestion on this and will try to fit it in current development or will schedule for near future.

2
  1. Can you also please paste the Mingle links for this feature, so that community members can track when its completed?
  2. Do we know when this feature will be available (approximately) for preview?
  3. Which SMS gateway will we integrate with as a starter?
  4. How is OTP being generated / stored so that others can’t predict it? Is there some publicly available library being used? For instance: https://github.com/aerogear/aerogear-otp-java, or this https://github.com/kamranzafar/libotp. The first one seems to support google authenticator. We could also use something like that, instead of SMS, so that people don’t need to be in a place with mobile connectivity to enter an OTP.
1 Like
3

I realise that the drawback of GoogleAuth is that you need a smartphone, which may not be really available everywhere. So, SMS first, and GAuth maybe later.

4

Please check the mingle card for details.

Initial version is proposed to be available with the release of Bahmni 0.83

As the APIs exposed by different gateways may not be similar, the proposal is to build a solution such that it is easy to build a custom connector for specific gateways based on deployments.

Regarding OTP generation @vinkesh will be able to provide more details.

5

You may also want to consider adding support for FIDO Universal 2nd Factor (U2F). U2F is the successor to OTP. It’s a stronger level of encryption and less vulnerable to social engineering attacks.

This is an example of a FIDO U2F Security Key. You can also use your Android phone over NFC. It does not rely on external connectivity. The process is:

Links:

6

Thanks @tomgriffin for the pointer. We are thinking of using spring security for 2FA where we can plug different plugins for different types 2nd Factor authentication.

Also Right now our main target users might not have access to smart phone. So we are thinking of SMS based OTP as a first cut for 2nd Factor.

7

@vinkesh: Thanks! I’m happy to help.

Most companies who have implemented U2F provide employees with a two factor auth (2FA) usb dongle that hangs from their keychain. It does not require a smartphone and would work in locations without external connectivity.

Below are three popular keys used in U2F deployments:

1 Like
8

Whatever you DO NOT use SMS – EVER. Yubikeys are pretty good. Support Google Authenticator as well.

See this article for why SMS is bad.

9

@shanmugam, what are some of our common representative use cases? E.g. what types of facilities in what types of environments are asking for this feature first?

10

@darius, Bangladesh implementation (which currently has 2 Bahmni installations at sub district level) may be the first one to try this feature. We are also enabling 2FA for offline app as well.

11

@shanmugam, I mean: what type of user are we talking about? Have we chosen the SMS approach because we think they’re carrying a dumb phone?

12

@darius, Yes, mostly the users will have basic phone not the smart phone.

13

Problem is not the phone, but data connectivity, which is not really that reliable.

14

I see a lot of discussion going back and forth - but to me, there are three core non-functional requirements that must be met (without compromise):

  • it must be secure against known vulnerabilities
  • it must work in areas with no connectivity to the outside world
  • it must be cheap, i.e., it cannot require a smart phone and durable

It Must Be Secure…

  • SMS-based 2FA (and SMS in general) is a major attack vector for targeted attacks.

  • The security industry responded to this threat with Universal 2nd Factor (U2F). it both strengthens and simplifies the user experience for adding a second step to authentication.

  • Please take a minute to watch this video I put together of how easily someone’s account can be hijacked if it’s being protected by SMS: http://grif.io/16205

It Must Not Require External Connectivity…

  • An SMS-based solution requires external connectivity. Workarounds to this constraint add new security challenges to the mix.

  • Universal 2nd Factor (U2F) works anywhere - regardless of whether there is connectivity to the outside world.

It Must Be Cheap and Durable…

  • An SMS-based solution at minimum requires a phone and some type of connection.

  • Universal 2nd Factor can be implemented by providing each user with a USB security key. A popular model from Yubico is $18 each. It will survive all sorts of conditions.

I apologize if I seem more direct than usual - but this is important. It would be a shame for us to spend time implementing a security protocol that is already outdated. It would be worse if that decision contributed to a breach.

15

Google Authenticator has a Chrome extension. This is one of the only secure ways to do it. Beyond using yubikeys or another U2F authentication mechanism. SMS is bad as @tomgriffin has pointed out.

16

I’d sleep better if it was a hardware-based token. I know that the browser extensions and desktop applications provide a more streamlined user experience - but it does so at the expense of the very security we are trying to provide.

It’s game over if a workstation is compromised. An attacker would have captured keystrokes, login credentials, and access to generate the verification code. It’s a single point of failure.

All that said, I’m operating under the assumption that if an implementation was compromised, it would likely be from a targeted attack versus someone who got lucky. And a good chunk of targeted attacks are carried out by insiders with access to the machine.

I think an action item we should take away from this discussion is we need an analysis of the overall security posture of the platform. Where we are now and where we want to be 6m, 12m, 18m out. a common understanding of what were working with in our future goals would help significantly in decision-making.

17

Me too…but keep in mind this is operating in a resource-constrained environment. I’m sure we could (probably) get Yubikeys donated

18

Am I correct in assuming that in a typical implementation:

  • workstations are shared across users
  • users may move between workstations

I was thinking about this in the context of handling the generation of the 2FA code in a browser extension or desktop application versus something external to the workstation.

It seems like an administration nightmare…Do you agree?

and then there is the user experience drawbacks… if we make it more complicated to login they will justified to not implement the additional security.

Is it worthwhile starting a conversation with a supplier of U2F keys to see if we can strike a deal? And what do you think @vinay/@shanmugam/@darius? Is there anything @r0bby and I are missing in terms of unmet requirements or dev complexity?

1 Like
19

I can see now reason why Yubico would not want to help you out. I cannot however speak for them.

20

I saw that couple of places where Bahmni was deployed, people had pasted the password on a piece of paper on the table that held the computer. Now, that is of course BAD. In another place, the password had some simple scheme like UserID_EmpID. Which is also BAD. But, its difficult I guess for us to be able to educate everyone on basic password hygiene.

In another place, some new nurses took almost 20 minutes to just get past the login page (during training), because they found the combination of upper/lower/special characters too difficult to type. Again in such cases, I suspect someone will come up with a common / simpler password.

So, if this is the real world, and we want to make life simple for people, yet secure, one possible solution is that you attach the Second Auth factor to a person’s phone. Now, people may share their passwords, or put one up on the table, but they can’t share OTP generating devices and will most likely not hand over / tape their phones to a desk. This way, a much more increased level of security is achieved than the one described in para1 and para2 above. A hardware token like yubikey is good – but in this case too, someone can just attach the yubi key to a string, next to the computer, like you see “staplers” hanging next to the printer, or will just simply keep it plugged into the computer. No one does that with a phone!

So, I would still bet on a phone based solution for some time, over a hardware based token whose sole purpose is OTP, even though the hardware token is technologically far superior in security than phone… because in the end, the phone process provides us a higher guarantee of security, than the hardware token does – by virtue of the phone being “unsharable” in comparison to a hardware token.

I would +1 supporting GAuth though, besides SMS, maybe via using this java library: