Comments (20)
Hi, @sohsatoh ,
we had a long discussion over it here: #1772
What to keep in mind - from the ASVS requirement structure point of view:
- The requirement should be independent and "usable out of context" - no references to other requirements
- The requirement must be positive (what must be done) not negative (what must not be done)
I agree that we should abstract the precise limit out with the actual goal - to provide defense against Denial of Service attack. Also, as I pointed out in #1772, the requirement 2.1.2 contains 2 parts - one is for password length for end-user and another is for storage. The storage part is section 2.4:
# | Description | L1 | L2 | L3 | CWE | NIST § |
---|---|---|---|---|---|---|
2.4.1 | [MODIFIED] Verify that one of the following password hashing functions is used when storing the user's password for the application: argon2id, scrypt, bcrypt or PBKDF2. | ✓ | ✓ | 916 | 5.1.1.2 | |
2.4.3 | [MODIFIED] Verify that if PBKDF2 is used, the iteration count should be a minimum of 1,300,000 iterations with PBKDF2-HMAC-SHA1, a minimum of 600,000 iterations using PBKDF2-HMAC-SHA256, or with a minimum of 210,000 iterations with PBKDF2-HMAC-SHA512. | ✓ | ✓ | 916 | 5.1.1.2 | |
2.4.4 | [MODIFIED] Verify that if bcrypt is used, the work factor is a minimum of 10 and password size is limited to 72-bytes due to bcrypt's input limit. | ✓ | ✓ | 916 | 5.1.1.2 | |
2.4.6 | [ADDED] Verify that if argon2id is used, there should be a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism. | ✓ | ✓ | 916 | 5.1.1.2 | |
2.4.7 | [ADDED] Verify that if scrypt is used, the configuration should be a minimum work factor of (2^17), a minimum block size of 8 (1024 bytes), and a parallelization parameter of 1. | ✓ | ✓ | 916 | 5.1.1.2 |
Instead of giving rules and limits for every used and accepted hashing function, we should abstract out the entire section with the message (not a wording proposal!) "Verify that accepted method is used, it is used and configured according to the latest spec or recommendations, such as to have enough iterations and limitation to max input length against denial of service attacks". Then it is more future-proof as well. We should modify the current 2.4.1 for that.
One option is also to provide those limits in the chapter text: "When releasing the ASVS version v5.0, accepted limits per used function were ..." + links to resources, from where to get the latest ones.
from asvs.
Hi @sohsatoh, thanks for the input and working to keep OWASP projects consistent :)
Instead of giving rules and limits for every used and accepted hashing function, we should abstract out the entire section with the message...
I agree with this concept @elarlang and I think we will need to trim 2.4 to make ASVS more usable.
However, I think that the denial of service risk will apply to all cases and password length is also a strong candidate for staying as a separate requirement (but I am open to discussing that separately).
As such, for now I would agree with Jim's suggestion.
# | Description | L1 | L2 | L3 | CWE | NIST § |
---|---|---|---|---|---|---|
2.1.2 | [MODIFIED] Verify that passwords of at least 64 characters are permitted, and that passwords above a certain max length (such as 128 or more characters) are denied. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |
@elarlang @sohsatoh further thoughts?
from asvs.
I wrote something about the DoS risk: Long passwords don't cause denial of service when using proper hash functions.
The first step a password-hashing algorithm does is hashing the password and then processing that hash further. So only the first hashing step depends on the length of the password, and subsequent operations are performed on a fixed-length hash. The length of the password does not severely influence the execution time. As such, I think a password length upper limit is not needed.
"128 characters" does not seem to be based on any theoretical basis
I agree, this is just some number someone picked, and that doesn't make for a strong requirement. One possible solution is to adopt the limit of some other system, such as bcrypt (72 bytes) or WordPress (4096 bytes).
from asvs.
Elar, this comment from the OP concerns password length and is related but separate from 2.4.x. Can you please separate your password storage comments into a separate issues, please?
from asvs.
Hey @sohsatoh I agree NIST does not demand that passwords not exceed a 128 character max. But I still would like to add it in as a suggestion.
How about:
Verify that passwords of at least 64 characters are permitted, and that passwords above a certain max length (such as 128 or more characters) are denied.
from asvs.
Elar, this comment from the OP concerns password length and is related but separate from 2.4.x. Can you please separate your password storage comments into a separate issues, please?
I'll do it when this issue is solved without solving 2.4. (my recommendation to solve this issue was to cover it in 2.4, so it is related).
from asvs.
If it is not against the hashing method and denial of service attack, what risk do you mitigate with limiting "too long" passwords? (it may make sense to re-read #1772)
from asvs.
Maybe I didn't explain myself clearly. I think all the approved hashing methods are necessarily slow and are therefore exposed to a DoS risk which is why this applies in all cases and why I think we should still mention it.
from asvs.
The underlying reason to have max length for password is not to make the user-chosen password more secure and it's not a defense against user-impersonation vector as the entire section "V2.1 Password Security" is.
Maybe I didn't explain myself clearly. I think all the approved hashing methods are necessarily slow and are therefore exposed to a DoS risk which is why this applies in all cases and why I think we should still mention it.
And as you agree, the problem to solve is "the safe usage of hashing methods" and that is why I proposed (#1923 (comment)) to cover the problem in section 2.4.
from asvs.
I would rather see this requirement here with the other password rules. I do not think the password storage section is the right place add a max-length password rule.
from asvs.
I would rather see this requirement here with the other password rules. I do not think the password storage section is the right place add a max-length password rule.
I try to be patient... but well, I'm not.
@jmanico , please, FACTS and arguments!
First, why do we need this (max length for user-chosen passwords) requirement at all, and what risk it mitigates? Do we need this requirement? And if we need to, then we going to choose the correct section for that, based on the area which is impacted (password hashing functionality in this case).
Note: I'm ok to keep the requirement itself as part of the current requirement, the main priority is to clarify the need for that based on facts. At the moment it seems to be too random.
from asvs.
Ok, having read back through the most recent comments, I agree that '"128 characters" does not seem to be based on any theoretical basis'. I also read back through #756 for a little more context.
I think the aim here was to provide a simple requirement. There is no reason in the world to allow a regular password of longer than 128 chars and maybe we could even shorten that. That isn't science it is just common sense. Maybe it would be even more sensible to restrict to 70 max to avoid the bcrypt issue. Again, not science, just trying to avoid footguns.
The alternative is that we reframe this requirement:
Verify that the application is protected against a denial of service attack caused by processing an overly long password.
Thoughts @Sjord @ThunderSon @jmanico @elarlang @sohsatoh
from asvs.
There is no reason in the world to allow a regular password of longer than 128
It is not a reason to have a requirement in the ASVS.
.. and we reach close to my proposal:
Instead of giving rules and limits for every used and accepted hashing function, we should abstract out the entire section with the message (not a wording proposal!) "Verify that accepted method is used, it is used and configured according to the latest spec or recommendations, such as to have enough iterations and limitation to max input length against denial of service attacks".
Denial of Service attack is just one thing to address with max-length, with bcrypt the issue is truncation.
from asvs.
Ensure that your application is protected against denial of service attacks caused by processing too long passwords.
I agree with removing the "128 character" limit and implementing this in itself.
There is no reason in the world to allow a regular password of longer than 128 chars and maybe we could even shorten that. That isn't science it is just common sense. Maybe it would be even more sensible to restrict to 70 max to avoid the bcrypt issue. Again, not science, just trying to avoid footguns.
I think you are right, as long as the password has sufficient entropy.
As for bcrypt, I don't see the need to apply this across the board, since it is a restriction of the bcrypt hashing algorithm itself. (I think we can all agree on this)
from asvs.
So I still think we should mention the denial of service issue separately as it applies to all algorithms. Algorithm specific details like bcrypt 72 bytes we should leave for the cheatsheet.
from asvs.
Note that the denial of service from long password is not even mentioned in the password storage cheat sheet.
from asvs.
Following discussion with Elar
- Split 2.1.2 so that the "long password" requirement is in 2.4.
- This requirement should be like: "Verify that the application is protected against a denial of service attack caused by processing an overly long password."
- This requirement should be level 2
- Collapse 2.4.1-2.4.7 down to a single requirement talking in general about approved storage algorithms.
- Make sure the note at the start of 2.4 is up to date.
from asvs.
Note that I also fixed the missing tags on 2.4.2 and 2.4.5 as I think that practically speaking these requirements were not correct because the correct response would be to use the right algorithms and the provisions which they provided.
from asvs.
Opened #1930
from asvs.
https://www.sjoerdlangkemper.nl/2021/07/02/long-password-denial-of-service/ is a solid argument. I am ok with dropping this requirement.
from asvs.
Related Issues (20)
- Proposal: the application must belong/covered to the HSTS preload list (probably level 3) HOT 43
- Do we want V7.4 to get moved to V10? HOT 3
- Minor V7 changes HOT 2
- Italian Translation HOT 1
- V11 rework by @jmanico HOT 16
- update 50.2.1 (v4.0.3-14.4.3) and/or split requirement for content-security-policy HOT 13
- move or merge 8.3.5 to V7 HOT 3
- URL Safety HOT 23
- proposal/discussion: OAuth - disallow web application to be OAuth public client (and to have direct communication with OAuth token endpoint)
- proposal/discussion: OAuth - (for 1st party usage) only used (by the client) communication options must be allowed by authorization server HOT 3
- proposal/discussion: OAuth - separate requirement for redirect_uri string-match registration and handling HOT 6
- discussion: OAuth - using OAuth just for authentication HOT 4
- proposal/discussion: JWT - 3.5.6 add "type", and rephrase it to describe the goal HOT 6
- proposal/discussion: OAuth: requirement for refresh_token lifetime
- V51: Additional OAuth/OIDC proposals HOT 6
- discussion OAuth/OIDC: accepted flows and grants HOT 6
- 4.3.1 and 4.3.3 HOT 6
- Password Storage Algorithms 2.4.1 revisited HOT 3
- Make 2.1.14 easier and more simplified HOT 7
- Implement Requirement for Anomalous Behavior Detection HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asvs.