Remove SHA-1 (once and for all)

[randomstuff]

According to #2500 (comment), shall we disallow any usage of SHA-1?

• remove HMAC-SHA-1 from approved hash algorithms
• revert 6.6.1, remove mention of SHA-1 #2546

Related:

• Crypto appendix: allow HMAC-SHA-1 #2399

@unprovable

[randomstuff]

SHA-1 is still allowed (but phased out) by NIST until 2030.

NIST Retires SHA-1 Cryptographic Algorithm:

As today’s increasingly powerful computers are able to attack the algorithm, NIST is announcing that SHA-1 should be phased out by Dec. 31, 2030, in favor of the more secure SHA-2 and SHA-3 groups of algorithm

keylength.com → According to keylength.com, SHA-1 is still allowed by NIST until 2030 (and beyond?) for HMAC, KMAC, key derivation functions and random bit generation.

[randomstuff]

Options for SHA-1:

1. disallowed altogether;
2. discouraged legacy usage for HMAC-SHA-1 only (what we have in the current version of the draft);
3. discouraged legacy usage for HMAC-SHA-1 and some other things only (aligned with NIST AFAIU).

[elarlang]

A general point of view for the legacy support - ASVS v5.0 does not need to support or "legalize" old technologies if those provide a practical attack surface.

For the requirement, the point of view should be - if you start building a new application today, what kind of requirements (and not just recommendations) do you need to apply for that?

And for legacy systems - is the requirement that critical and important, that legacy systems must update themselves, otherwise there is a vulnerability.

[randomstuff]

Here are the exact status from NIST SP 800-131A Rev. 2:

Here are the exact status from NIST SP 800-131A Rev. 3 (Initial Public Draft):

[...] The use of SHA-1 is deprecated through December 31, 2030, for applying protection in
non-digital signature applications and disallowed thereafter. [...]
The use of SHA-1 is acceptable for processing already-protected information through
December 31, 2030, and allowed for legacy use thereafter [...]

[jmanico]

You applications will be future proof and more secure if you keep away from SHA-1. The advances in quantum computing, quantum networking and high speed computing in just the last few months is remarkable.

[tghosth]

@randomstuff what would this change in V6 (or elsewhere?)

[unprovable]

This would remove HMAC-SHA1 which in all honesty, it probably should be gone now. LEaving MD5/SHA-1/any broken hash or cipher in a standard should be for backwards compatibility and verification of old hashes ONLY, in general.

[jmanico]

Perhaps the solution here is to have three sets of crypto guidance.

1. Never use, ever
2. Use for new development
3. Legacy only support, do not use in new development

I really do not want to encourage any new development with SHA-1, and I feel we would be irresponsible if we did. But I do realize legacy use of it, in some cases, is not always a security violation, at least not yet, even if it may be in the near future.

[randomstuff]

@jmanico, Yes, maybe. Actually, I suggested this here #2398 (comment) :)

[randomstuff]

Quoting myself on SHA-1:

Note: some notable impact which may not be immediately apparent, is the use of HMAC-SHA-1 as the default mechanism for HOTP and TOTP. This is currently used in many/most recent TOTP I've been using.

[jmanico]

Fair point @randomstuff

PS: WebAuthN and FIDO2 use HMAC-256/512.

But I am more concerned about new web and API development not standards and protocol developement. Dev's are not likely at all to to build their own TOTP solution from scratch in web development. So if I was to release a secure coding standard for Web devs that will likely be around for 3-5 years like the last version of ASVS, I'd suggest eliminating all SHA1 for future proofing.

ASVS 5 will likely be around as NIST starts to deprecate even HMAC-SHA1 in a few years.

[randomstuff]

@jmanico, Yes. My TOTP/HOTP comment maye be seen as an argument for mentioning HMAC-SHA-1 as allowed for "legacy"/compatibility.

[unprovable]

Perhaps the solution here is to have three sets of crypto guidance.

1. Never use, ever
2. Use for new development
3. Legacy only support, do not use in new development

I really do not want to encourage any new development with SHA-1, and I feel we would be irresponsible if we did. But I do realize legacy use of it, in some cases, is not always a security violation, at least not yet, even if it may be in the near future.

This is how I've written cryptography standards before, and it's painfully necessary. 😅

[jmanico]

Thank you @unprovable and @randomstuff

I saw a recent PR dropping HMAC-SHA1. Are we all in agreement and can we close this out?

[randomstuff]

This snippet is still there event if HMAC-SHA-1 is not listed as allowed:

Note that while SHA-1 should not be used in general, the usage of HMAC-SHA-1 is currently not considered to be problematic
(NIST SP 800-57).

I'll remove this.

Moreover something should be done along in the allowed/disallowed/legacy direction but that can be done as part of #2398

[tghosth]

Hi @randomstuff, is there anything else to do for this issue after merging PR #2561?

[randomstuff]

@tghosth, if we follow the route of having approved/legacy/disapproved levels, we should add SHA-1 back "as legacy with restrictions".

[tghosth]

Ok so you do you want us to merge #2561, close this issue and track the levels thing with #2398?

[randomstuff]

Yes OK!