You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Passwords are hashed by applying a single round of SHA-512 to the cleartext
password and the salt. Attackers who have obtained the hashed passwords can
therefore calculate the cleartext passwords within a very short amount of
time, using massively-parallel computing (such as cloud computing) and GPU,
ASIC, or FPGA hardware.
OpenSlides should use an algorithm designed for password hashing, such as
Argon2.
Summary: Password validation vulnerable to timing attacks
To validate passwords, the code compares the hashes with the JavaScript ===
operator. The runtime of the operator depends on the position of the first
different characters in the compared strings. An attacker can exploit this
side channel by observing the timing behavior of the password validation,
thereby reconstructing the password hash.
OpenSlides should use a comparison function the runtime of which does not
depend on the data, such as crypto.timingSafeEqual, which is specifically
intended for this use case.
Summary: Weak password hashing
Passwords are hashed by applying a single round of SHA-512 to the cleartext
password and the salt. Attackers who have obtained the hashed passwords can
therefore calculate the cleartext passwords within a very short amount of
time, using massively-parallel computing (such as cloud computing) and GPU,
ASIC, or FPGA hardware.
OpenSlides should use an algorithm designed for password hashing, such as
Argon2.
Reference: https://github.com/OpenSlides/openslides-auth-service/blob/ef817d2de9cb54652f053042a4216b101737f46f/auth/src/api/services/hashing-service.ts
Summary: Password validation vulnerable to timing attacks
To validate passwords, the code compares the hashes with the JavaScript ===
operator. The runtime of the operator depends on the position of the first
different characters in the compared strings. An attacker can exploit this
side channel by observing the timing behavior of the password validation,
thereby reconstructing the password hash.
OpenSlides should use a comparison function the runtime of which does not
depend on the data, such as crypto.timingSafeEqual, which is specifically
intended for this use case.
Reference: https://github.com/OpenSlides/openslides-auth-service/blob/ef817d2de9cb54652f053042a4216b101737f46f/auth/src/api/services/hashing-service.ts
Thanks to @mdickopp for finding and reporting these issues.
Both are already fixed by #167
The text was updated successfully, but these errors were encountered: