Forum OpenACS Q&A: Usage of SHA-1 in OpenACS

Hi

I must confess that this is an area outside my expertise, so I'm hoping for some guidance here. We recently got a query questioning the usage of SHA-1 in our OpenACS application, and it is apparently no longer recommended. However, Wikipedia tells me that it's still secure for HMAC, and I note that it's still widely using in latest OpenACS versions.

My questions are:
1. in the context of OpenACS, is the usage of SHA-1 still secure?
2. if it's no longer a good idea to use ns_sha1, what is the recommended alternative?

many thanks
Brian

The general question is quite wide, there are usages where sha1 (and md5) are perfectly fine, but other cases, where it should not be used. The usage of sha1 and md5 is strongly discouraged for certificates - but this happens under the hood, when connecting to OpenACS via HTTPs.

The main problem with early days hash algorithms cam with the advent of using GPUs for computing hashes; it is actually not recommended anymore to use salted passwords with any kind of SHA* algorithm, since the computing these hashes became too fast. An attacker with an standard GPU (videocard) can compute billions of hashes per second and try these. So, newer algorithms were developed to actually slow hash computation (and therefore password computation) to make it either CPU-hard or memory hard (or both).

When NaviServer is compiled with a recent version of OpenSSL (alpha releases of OpenSSL 3.0) it supports scrypt [1], one of the recommended algorithms (RFC 7914), which is a modern replacement for crypt and bcrypt. There is as well a PR for Argon2 for OpenSSL, but that will come after the release of OpenSSL 3).

So, using these good new hash algorithms can already be used in OpenACS when compiled with recent versions of NaviServer (4.99.19, released Jan 2020) and OpenSSL. The main work for using these algorithms for password protection in general OpenACS is to manage existing user accounts, since users with "old" hash computations have to be converted to the new algorithms, which can't be done without knowing the password (so the user has to log in). So, in essence, one has to extend the datamodel to support many algorithms at the same time and to migrate the passwords gradually, while these are in use. No rocket science, but some work.

If you need just newer hash algorithms, use "ns_md" in NaviServer, which supports currently not only sha1, but as well the following message digest algorithms:

blake2b512 blake2s256 md4 md5 md5-sha1 mdc2 ripemd160 sha1 sha224 sha256 sha3-224 sha3-256 sha3-384 sha3-512 sha384 sha512 sha512-224 sha512-256 shake128 shake256 sm3 whirlpool

Hope this helps. ... but i have to feeling the question was not asked out of curiosity.

[1] https://naviserver.sourceforge.io/n/naviserver/files/ns_crypto.html#13
[2] https://naviserver.sourceforge.io/n/naviserver/files/ns_md.html

The biggest sha1-based threat are the password hashes, which can result in identity theft. This happens typically via a dictionary attack, where the attacker knows (a) the hash, (b) the salt and computes based on a kind of dictionary hash values, and when the result is identical with the password hash, the password is regarded as cracked. Salts are used to make the hashes different even when the plain text of the password is the same. Some systems use a small set of salts (e.g the original Unix crypt() uses a 12 bit salt), which is not the case for OpenACS (uses as 128bit salt).

... SHA-1 for password encryption in OpenACS

The passwords are not encrypted with SHA1, just hashes of the passwords are saved - but also not in all OpenACS installations. Many large OpenACS sites do not store passwords at all (our university is using the OpenACS based LEARN environment Kerberos authentication) - so there is absolutely no thread on this. So, one cannot deduce a security threat by there mere usage of sha1.

Notice that the password hashes never leave the system on regular use, so the attacker has to get it. When the hash is saved in the DB, an attacker needs access to these tables (via system intrusion, or SQI, ...) to attack the hashes. Therefore security pretty much depends on the site security. There is a security thread, when e,g. arbitrary users get access to these database tables, ... but then, one is already in big troubles, so the hash is probably not the biggest concern. One has to be careful, when old disks are replaced, or etc. So, it is certainly better to use modern password suited hashes. Using sha2 or sha3 is no real improvement.

If you are using a version of OpenACS older than 5.9.1 then there are much more things to worry about than using sha1. The biggest thread are usually site-specific packages, which were developed many years ago, at a time, where people are primarily concerned about functionality, and not about security. My recommendation is to use tools like Acunetix to check the web security in a first step. We use on every release step in LEARN.

The commit [1] introduces stronger password hashes for OpenACS, targeted for the OpenACS 5.10.1.

This change introduces the possibility to use either the classical OpenACS password hash algorithm "salted-sha1" or the SCRAM password function "scram-sha-256". The latter can be used by (a) using the most recent version of NaviServer (from Sept 28, 2021 or newer) and (b) by configuring the password hash preferences via Kernel package parameter "PasswordHashAlgorithm". The package parameter can contain a list of multiple hash algorithms in preference order. The most preferred available algorithm is chosen.

By default, the "PasswordHashAlgorithm" is "salted-sha1", and the behavior is as before. After upgrading to the new version of acs-tcl and acs-kernel, the preference list can be configured. When a user logs in and the preferred available algorithm is different from the previously used algorithm, the upgrade is performed for the user automatically.

The usage of SHA1 in OpenACS is easily target of security audits. The biggest danger is that if somebody gets full access to the "users" table (e.g. when decommissioning a hard disk). In this case the hashes can be attacked with dictionaries by using some crypto hardware (when someone gets raw access to the DB, one has usually some other big problems). However, by using the "scram-sha-256" hash function this danger is substantially reduced. This function computes a password hash using PBKDF2 (Password-Based Key Derivation Function 2). This function is used to reduce vulnerabilities of brute-force
attacks against password hashes. The hash function of SCRAM is PBKDF2 [RFC2898] with HMAC as the pseudo-random function (PRF) and with dkLen == output length of HMAC == output length of the digest function. So, it uses a better hash algorithm (sha-256 vs. sha1) and applies this a high number of times (15K times for a password hash computation).

NaviServer supports as well the even better SCRYPT algorithm, but this is only available when NaviServer is compiled with OpenSSL 3.0 or newer. On the contrary, scram-sha-256 actually PKCS5_PBKDF2_HMAC) is available since OpenSSL 1.0.0 (2015).

All the improved hash functions require NaviServer with its tight integration to the crypto functions of OpenSSL.

[1] https://cvs.openacs.org/changelog/OpenACS?cs=oacs-5-10%3Agustafn%3A20210928124647