search

SORMAS-Foundation / SORMAS-Project

SORMAS (Surveillance, Outbreak Response Management and Analysis System) is an early warning and management system to fight the spread of infectious diseases.
https://sormas.org
GNU General Public License v3.0
291 stars 142 forks source link

Investigate ways to improve the default Authentication Mechanism Password Hashing #4569

Open vidi42 opened 3 years ago

vidi42 commented 3 years ago

Problem Description

At the moment SORMAS uses a rather vulnerable Password Hashing algorithm as a standalone Authorization Mechanism.

More details about the current implementation PasswordHelper.java

Proposed Change

Improve the Hashing Algorithm while still supporting the current one for a few versions until we can be sure that instances have migrated their users to the new Password Hashing Algorithm.

The new algorithm should be one supported in Java and PostgreSQL equal and higher then 9.6, due to user import script #4513.

Possible Alternatives

Consider also current password length. Is it still ok to keep it or does it make sense to increase/decrease/make it variable?

https://github.com/hzi-braunschweig/SORMAS-Security/issues/34

JonasCir commented 3 years ago

@vidi42 This is a credible reference

JonasCir commented 2 years ago

@markusmann-vg @vidi42

While doing my analysis for crypto writeup, I stumbled over this issue and we really need to improve the situation here. The current implementation does not adhere to any common security practices in this domain at all. Proposed steps:

This likely implies a key rotation for all users still using this login mechanism instead of Keycloak, but we can't continue with the current approach.

Alternatively we could ditch this completely and only use Keycloak.

General position of @MartinWahnschaffe , @vidi42 (IIRC) was to phase out the legacy login and use keycloak exclusively. I'm also in favor of this.

MartinWahnschaffe commented 2 years ago

Just revisited this one: I'm in favor of keeping the standalone login mechanism, because it's very convenient not to have the keycloak dependency for dev systems and for minimal SORMAS instances.

We should follow what Alex and Jonas already pointed out above:

  1. Pick a secure hashing algorithm. It must have an existing implementation for Java and Postgres
  2. Keep the legacy password in a separate field to allow users to still login using it
  3. Use the new hash algorithm for any newly created user or reset password