Deprecate/remove support for sha1 authentication

[DorianCoding]

Minetest should drop support for SHA1 authentication as it is not secure and allows downgrade attacks. This requires:

• A migration path to force users to upgrade to SRP
• /setpassword to generate SRP not SHA1 passwords
• Some form of deprecation to stop clients authenticating with SHA1 without warning
• Eventually, complete removal

Hello,

After few researches, it seems this function is used to hash password.
However there is no salt (just the username) and it is using an outdated algorithm to hash password (SHA1)*.
A strong hash should be used each time and the use of SHA2, SHA3, Blake should be preferred and keep SHA1 for backward compatibility (when the user types its password, the server automatically changes the password hash).
It could avoid brute-force attacks when password are leaked, especially when users use the same password on different servers.

It also seems SHA2 is already implemented.

Thank you.

• : There are many attacks possible on this algorithm that will be opt out in 2030.

[rubenwardy]

Hi, we use Secure Remote Password (SRP) for authentication, not SHA1. SRP is a password-authenticated key exchange algorithm (PAKE), it allows the client to prove they know the password without ever sending it or a hash to the server

[SmallJoker]

What you found is in fact the backwards compatibility code to support logins of users that registered and/or last set their password before SRP was introduced.

[DorianCoding]

What you found is in fact the backwards compatibility code to support logins of users that registered and/or last set their password before SRP was introduced.

Yes I've found SRP functions that I've not found when doing small checks. This is good news. SRP is way more protective than SHA1, as long as 2016 functions are maintained.

[rubenwardy]

We should still drop support for SHA1 at some point, as it allows a downgrade attack

[DorianCoding]

We should still drop support for SHA1 at some point, as it allows a downgrade attack

I cannot agree more. But maybe what can be done is something like :

• If SRP cannot be done due to a server, alert the user about it and allow him to quit (or move to SHA2 or SHA3, less secure than SRP but way more secure than SHA1).
• If SRP cannot be done due to client, proceed (or use SHA2/SHA3).
• If SRP is due to an old connection, just as done now, replace the old password with SRP validation.

And before 2030 (date is up to the risk), drop SHA1 completely, as requested by RFC.

[rubenwardy]

Luckily, we've supported SRP for a long time. sha1 is only used if the server tells the client that their password in the auth database is sha1. In practice, this will only be because the admin has done /setpassword in the past. But this could also be done by a malicious server to get access to a weaker hash that they could crack to get the password.

For an upgrade path, we should make it so the client automatically changes their password using srp if it joins using sha1.

As for the deprecation, it's tricky as lots of users won't log in for a while, so straight up removing it would lock them out of their account. So you might need to add a warning dialogue to the client or disable sha1 on the client using a setting

[DorianCoding]

Luckily, we've supported SRP for a long time. sha1 is only used if the server tells the client that their password in the auth database is sha1. In practice, this will only be because the admin has done /setpassword in the past. But this could also be done by a malicious server to get access to a weaker hash that they could crack to get the password.

Yes actually setpassword sends the raw password to the server in an (unencrypted?) form. So this means any sniffer could eavesdrop the password easily as no secure protocol like HTTPS is used. And of course, the server gets the password even before it is hashed. So it is a nonsense if the server is malicious as whatever hash is used, the password is sent. But it can just be moved to SHA2 or even SHA3 so backward compatibility can still be maintained, without huge security compromise. And of course, it also allows admins to change password.

For an upgrade path, we should make it so the client automatically changes their password using srp if it joins using sha1.

If it's not the case today, yes it is a very good idea.

As for the deprecation, it's tricky as lots of users won't log in for a while, so straight up removing it would lock them out of their account. So you might need to add a warning dialogue to the client or disable sha1 on the client using a setting.

There is no need for deprecation if it can be moved to SHA2 and SHA3 but for very old users, SHA1 verification can be maintained for 7 more years, it should be way enough to ensure those accounts won't ever be used in the future.

[rubenwardy]

Yes actually setpassword sends the raw password to the server in an (unencrypted?) form. So this means any sniffer could eavesdrop the password easily as no secure protocol like HTTPS is used. And of course, the server gets the password even before it is hashed. So it is a nonsense if the server is malicious as whatever hash is used, the password is sent. But it can just be moved to SHA2 or even SHA3 so backward compatibility can still be maintained, without huge security compromise. And of course, it also allows admins to change password.

I wasn't taking about /setpassword when I mentioned malicious servers - I was talking about authentication and joining the server. A malicious server could tell all clients to use sha1 for authenticating, this would be a downgrade attack.

One of the considerations of our auth system is that servers should not be trusted - a lot of users will reuse passwords, servers shouldn't get the plaintext password like a web server would. The SHA1 auth method hashes passwords on the client, not the server, for this reason. Obviously, there's a lot of flaws with this which is why we switched to SRP.

But yes, /setpassword is inherently insecure as it sends passwords unencrypted when ran from inside Minetest, and sends passwords in plaintext to the server. But it's also for use by the server staff not by general users. /setpassword will need to be changed to use SRP.

There is no need for deprecation if it can be moved to SHA2 and SHA3 but for very old users, SHA1 verification can be maintained for 7 more years, it should be way enough to ensure those accounts won't ever be used in the future.

We won't be moving to SHA2 or SHA3 as a PAKE like SRP is best for our usecase. Doing that would still require deprecation anyway as you'd want to stop the downgrade attacks.

[Desour]

IIRC, the client never sends the pure sha1 hash of the password anymore. Instead, if an old sha1 entry is found in the auth db, the server automatically does the srp registration (including the computations usually done by the client) itself, using the hash as password, and then uses this for srp authentication.
Edit: See also AUTH_MECHANISM_LEGACY_PASSWORD.

[DorianCoding]

I wasn't taking about /setpassword when I mentioned malicious servers - I was talking about authentication and joining the server. A malicious server could tell all clients to use sha1 for authenticating, this would be a downgrade attack.

Okay so you need just responding to TOSERVER_INIT_LEGACY and get the hashed password?

One of the considerations of our auth system is that servers should not be trusted - a lot of users will reuse passwords, servers shouldn't get the plaintext password like a web server would. The SHA1 auth method hashes passwords on the client, not the server, for this reason. Obviously, there's a lot of flaws with this which is why we switched to SRP.

You are totally right. A web server is protected by HTTPS and transmission is secure and most-known websites are very secure. But websites MUST not store passwords in plain, hashing password using Argon2id or another high-demanding computing hashing protocol. This way, a hash that tooks around 15 ms (on a 1Gb server) with SHA1 will rise up to 500 ms (for classic Argon). And with proper salt per user, brute forcing passwords would take years in case of a data-breach.

However hashing solutions are used to hash on the server. Hashing on the client does not bring anything in terms of security. A password-derive function would be better suitable (like PBKDF2) on the client, so the computational would be much higher to bruteforce on the server and the client does not transmit the password. But that does not solve unencrypted channel issue (NDLR: send the already computed password to the server ) but that's another problem.

This is why using a PAKE algorithm is a good idea indeed.

But yes, /setpassword is inherently insecure as it sends passwords unencrypted when ran from inside Minetest, and sends passwords in plaintext to the server. But it's also for use by the server staff not by general users. /setpassword will need to be changed to use SRP.

Yes indeed it should. Moreover, it could mitigate eavesdropping on the unencrypted channel. Even if I doubt SRP gives sufficient warranties against OPAQUE/cPACE for instance (which are still in paperwork though).

We won't be moving to SHA2 or SHA3 as a PAKE like SRP is best for our usecase. Doing that would still require deprecation anyway as you'd want to stop the downgrade attacks.

I never said you should remove SRP. But SHA2/SHA3 should replace SHA1 if an hashing function needs to stay. SHA2/SHA3 are not a good solution yet but they are not deprecated, unlike SHA1.

[sfan5]

But SHA2/SHA3 should replace SHA1 if an hashing function needs to stay.

That's the point, a hashing function does not need to stay. Any effort providing an upgrade path from SHA1 to another hash would be wasted.

We use SHA256 with SRP btw.

Instead, if an old sha1 entry is found in the auth db, the server automatically does the srp registration (including the computations usually done by the client) itself, using the hash as password, and then uses this for srp authentication.

I am fairly sure that this is not possible at all. You definitely need the original password to authenticate with SRP.

[rubenwardy]

I am fairly sure that this is not possible at all. You definitely need the original password to authenticate with SRP.

If I understand Desour correctly, he's saying the SHA1 hash is used as the original password for SRP. This allows the server to effectively migrate all accounts to SRP. Clients will then hash the password before continuing with SRP if the server tells them to. I haven't verified this at all

[DorianCoding]

@Desour is partially right I guess. Here you have the use of the sha1 password in the srp (for the client) and the server needs a sha1 hash to perform it too.
Indeed, the casual srp use the password but the legacy one uses sha1. But if I follows here, the sha1 is indeed transmitted in the legacy version so server can perform the srp.
But well I'm not sure.