Forum OpenACS Q&A: Usage of SHA-1 in OpenACS
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?
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...
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 , 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.
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!
... SHA-1 for password encryption in OpenACSThe 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.
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.