The problem/use-case that the feature addresses

Background: due to advances in algorithms, compute power, and quantum research, finding SHA-1 collisions is increasingly feasible (and has already been done since years ago), and now within the budget of not only nation states but well-resourced hackers.

Because redis ACLS can be used to give different users distinct permission sets, including whether they can run EVALSHA or SCRIPT LOAD, there is some risk in multiuser scenarios where a subset of users is allowed to use 'SCRIPT LOAD', while a different subset of users is allowed to use 'EVALSHA'.

Therefore redis should support a more secure, possibly SHA-2 based, script hashing command set.

Observation: Actually, EVALSHA command, SCRIPT EXISTS, and so on can distinguish different hash-types by the length of the hash code -- so they could also just be enhanced to allow working with both SHA-1 and other hash codes, such as SHA-2.

Description of the feature

Proposal: * SCRIPT LOAD can continue to load scripts as now, and index them by both SHA1 and SHA2 hash values. * SCRIPT LOAD continues to return the SHA1 hash by default, for backward compatibility with clients who do SHA1 hash computations and/or sanity check the return value * SCRIPT LOAD can take an optional parameter telling it to return the SHA2 hash value instead. An additional command SCRIPT LOADSHA2 could also be added for the same purpose, and command renaming can optionally be used by people who want to change the behavior of existing services doing SCRIPT LOAD to a more secure behavior, in a way that is nonbreaking for applications that treat the hash values as opaque strings. * EVALSHA command would lookup scripts by either the SHA1 or SHA2 hash, by autodetecting depending on the length of the submitted hash.

Also, a server-level config option 'allow-insecure-sha1=no' can be added that completely blocks usage of SHA-1 for script indexing. In this case scripts will ONLY be indexed by SHA2, and SCRIPT LOAD will only return SHA2 hashes. In this mode, EVALSHA, SCRIPT EXISTS, and so on, will return an error if passed a SHA-1 hashcode.”

Alternatives you've considered

You can vary this proposal in several ways, such as * choice of new hash code function. SHA2 is an obvious possible choice but there may be superior alternatives * whether you do it in a way that is non-breaking for old clients calling SCRIPT LOAD. I personally strongly feel a non-breaking approach is preferred. * whether to have a server-level configuration option or not. I personally feel a server level configuration option is a useful thing to have because it allows an 'easy auditable switch' for ensuring your redis server is running with a 'most secure' or best practice configuration that does not use SHA1 at all. Its going to be quite hard to verify such a thing, if you rely only on an unbounded set of clients, written with custom code, which may or may not happen to mention the word 'SHA' 'hash' or 'sha1' anywhere, for enforcing rules that SHA1 hash algorithm must not be used!

Additional information

SHA1 is considered broken level insecure. Businesses with mission critical workloads need to phase out usage of insecure algorithms such as SHA1 everywhere it could have security impact.

In redis it can have security impacts, especially when not all clients are fully trusted admins.

Comment From: oranagra

Hi, I briefly reviewed the description above and i think it makes sense. I don't think any interface changes are needed, and i'd even argue that i'm not sure that changing the return value of SCRIPT LOAD is considered a breaking change.

p.s. I personally don't think the server config you suggested is very useful, in cases where the hosting / admin is a different person than the author of the application, i'm not sure it can be safely used, and in the other case, i'm not sure it's needed.