Outdated & insecure password hashing functions

[mjsir911]

Hi,

softether is using very outdated hashing functions, both sha0 & md4 have been recommended against for at least a decade.

sha0 has been outdated since it's inception in 1995 & md4 has had proven preimage attacks since 2008.

Using a combination of both hashing functions only makes the use of them marginally more secure, as brute forcing the passwords is trivial and a sufficiently motivated attacker could combine the preimage generation methods of both sha0 & md4 to generate accepted passwords

• https://en.wikipedia.org/wiki/SHA-1#SHA-0
• https://en.wikipedia.org/wiki/MD4#Security

Openssl has completely removed sha0 from it's codebase at this point.

[filamento]

Sir,

But is this a problem that could be exploited remotely? I believe that SoftEther uses Digest authentication for passwords. Digest (RFC 2069) normally uses MD5, no?

[shipitsin-ilia]

@filamento , please provide repro steps of remote exploit. it is sirius

[domosekai]

Hash algorithms like SHA-0 (or even SHA-1) are outdated in terms of collision resistance. What it means is that an attacker can forge a fake message that produces the same hash. It does not matter in password authentication where the attacker does not have access to the hash. Once it has the access, no algorithm is safe.

[mjsir911]

It does not matter in password authentication where the attacker does not have access to the hash

This is correct

Once it has the access, no algorithm is safe.

This is not. Leaked hashes can result in preimage attacks for unauthorized access to softether even if the host system has not been completely compromised (one could imagine read-only access to the configuration file due to misconfiguration), and more modern hashing algorithms prevent this issue.

[domosekai]

The hash is the only thing that a server knows about the password. If an attacker has it, it has the same knowledge as the server. There is no remediation no matter what the algorithm is.

[qupfer]

There is no remediation no matter what the algorithm is. Thats wrong or at least depends of the implementation/attac situtation.

Worst case: the "hash" is the plain-text password. Then it can be used directly. If the "hash" is just the cross-sum, the attacker can't use the "hash" directly, but can calculate an other input wuth the same cross-sum --> authenticated If the "hash" is a weak one, its possible he found an input with the same hash. If the hash is not a weak one, its (nearly) impossible, an attacker found an matching input. (assuming the password was a good one too)

A "good" algorithm avoid logins with (stolen) password hashes.

[domosekai]

No, the attacker does not need to work out the plain password. A hash can be used directly.

[qupfer]

That means, softether is sending somewhere the plain hash as a kind of access token???

[domosekai]

That means, softether is sending somewhere the plain hash as a kind of access token???

You seem to be not understanding how hashing works. Read some code.

[qupfer]

I‘m pretty sure I know enough about hashing. That’s the reason why I can’t imagine an scenario/implementation there the hash can used directly except the hash is calculated on the attacker/client side and used directly. But that would mein, the hash is sended directly, what you deny.

Or with other words: Can you explain how the hash can used directly, if it’s not sended directly? And if the password is sended as a string (through an encrypted channel) and the hash is calculated on server side, the algorithm does matter and old/weak one would be a risk.

I think both explanations sounds not good and I‘m really hoping there is a third one, but I can‘t imagine it.

[domosekai]

OK. You don't want passwords to be sent in clear text, nor do you want the hashes to be sent. Then how can authentication take place? Please describe your algorithm.

[qupfer]

OK. You don't want passwords to be sent in clear text, nor do you want the hashes to be sent.

That was not the question. I sad either the hash is directly sended (client-side hashing) OR the algorithm matter (client-side hashing). For me it sounds like you denied both. Thats what I'm talking about.

If the hash is calculaded on client side, it can be used directly. Yes. But nevertheless a more modern hash algorithm would be usefull because it make it harder/nearly impossible to get a real password, which may be used for other services too. However, this does not matter for Softether login itself as you can easy modify the code to send the hash directly instead derive it from an input.

Please describe your algorithm. I don't have to, as I don't think the "algorithm" is bad. However I would prefer the sensitive data is stored a bit more secure.

Regardless of the current implementation (have not look at it) I would do it like most of the "internet" does. Create an encrypted channel, send the password and hash it server-side. Compare to stored value.