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

Posted by Brian Fenton on

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

Posted by Frank Bergmann on

I've seen the successor SHA-2 is already available as part of TclLib:


My naive understanding is that you could basically do a find-replace of ns_sha1 with the TclLib version and there shouldn't be any major issues, except that you would have to ask all users to change there passwords...

You would also have to convert users.password and users.salt from character(40) to text or similar...

Maybe it would be interesting to create a ns_sha2 or ns_sha3 function with a C implementation for speed optimization...


Posted by Gustaf Neumann on
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.


Posted by Brian Fenton on
Hi Gustaf and Frank

many thanks for the responses. Yes, your suspicions are correct - this is a concern of one client of ours, who are keen to have an answer.

My takeaway here is that the current usage of SHA-1 for password encryption in OpenACS may be a potential issue, but that there are achievable solutions (involving, as you say, some work).

Apart from that, if I consider OpenACS version 5.91 in its entirety, I can count approx 30 calls to ns_sha1. Not all of these are used for security, I imagine, but do we need to be concerned about any of those 30 calls?

thanks for the help!

Posted by Gustaf Neumann on
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.

Posted by Brian Fenton on
Many thanks Gustaf for the explanation. I see the nuance now, and have a better understanding of the risk profile in the context of OpenACS.

best wishes