A2 Broken Authentication - mismatch between "Threat"-->"Vulnerability"-->"Prevention" #233
Comments
|
Also please note that the credential stuffing risk only addresses a tiny fraction of the massive topic of authentication. It also a hot vendor topic.
Something about this focus does not feel right.
… On Oct 23, 2017, at 6:02 AM, sumitagarwalusa ***@***.***> wrote:
"A2 Broken Authentication" focuses heavily on credential stuffing. Both the "Threat" and "Am I Vulnerable" sections open with explanations of credential stuffing. The Example Attack Scenario also begins with credential stuffing.
However, the bullets listed in "How do I prevent this" only begin to address credential stuffing in the last two bullets, and those two bullets do not reference OWASP's own guidance on how to think about defending against credential stuffing.
I suggest considering the following:
Consider re-ordering the "How Do I Prevent This" so those recommendations loosely track the order of threats and Vulns listed in this section (i.e. the last two bullets would be the first two).
Consider referencing OWASP's Automated Threats Handbook, as this deals with credential stuffing in more detail and is a pre-existing OWASP resource.
Consider more directly identifying credential stuffing as an automated attack. Currently, credential stuffing is listed alongside automated attacks, and is mixed in with brute forcing (which is dealt with quite differently). Properly identifying credential stuffing as an automated attack may help application developers select the right defenses.
Consider removing "rate limiting" as a concept in the "Example Attack Scenario". Rate limiting does not work against credential stuffing, as the basic structure of a credential stuffing attack involves hundreds of thousands of IPs, thousands of user agents, etc. In other words, there is very little upon which to implement a rate limit.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Jim - I work for Shape Security (a vendor). I offer up these comments for public review as I have offered up comments on the mailing list in the past. I focus my suggestions on issues like automation and credential stuffing because I have some experience in those areas (and not so much in other areas). I welcome your feedback on these suggestions. 1 is a suggestion to organize the information in a more logical and consistent way. 2 is an easy & effective technique, requires no vendor product, and is already in use at many very large websites. However, it is not yet as widespread as it should be. 3 is about using pre-existing OWASP work which pertains to this topic. 4 is a suggestion to tie some of these issues to the OWASP work in item 3, in the hopes of giving application developers more guidance. 5 is a suggestion that OWASP not recommend a very frequently-used but very ineffective control (which may be useful in other contexts, but not as much in this one). If you have time to share which ones don't feel right to you, perhaps I can improve/revise them. Thanks. |
|
What feels wrong is to focus on credential stuffing in the Top Ten. It’s just one of •many, many• application risks around Authentication.
Bias is also important to avoid. I prefer to see folks work on this material who are not vendors in this specific area. And please, I often get in trouble for these kinds of statements. I am not trying to comment on your integrity, I am stating these things as general principles.
This principle applies to the current situation.
We need to avoid vendor bias. When a vendor who makes a credential stuffing product contributes lots of OT10 credential stuffing information, it could harm all of our goals. This is the third tier of OT10 checklist that I talked about (with John Steven) in our OWASP keynote.
Regards,
--
Jim Manico
@manicode
… On Oct 23, 2017, at 7:11 AM, sumitagarwalusa ***@***.***> wrote:
Jim - I work for Shape Security (a vendor).
I offer up these comments for public review as I have offered up comments on the mailing list in the past. I focus my suggestions on issues like automation and credential stuffing because I have some experience in those areas (and not so much in other areas).
I welcome your feedback on these suggestions.
#1 is a suggestion about organizing the information in a logical and consistent way.
#2 is easy & effective, requires no vendor product, and is a technique already in use at many very large websites. However, it is not yet as widespread as it should be.
#3 is about using pre-existing OWASP work which pertains to this topic.
#4 is a suggestion to tie some of these issues to the OWASP work in #3, in the hopes of giving application developers more guidance.
#5 is a suggestion that OWASP not recommend a very frequently-used but very ineffective control.
Which ones don't feel right, and why?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Very excited to see the new top 10 and good feedback already coming in. I'm particularly interested in credential stuffing as it's an issue I deal with often during my day job and I've also found it to be a topic that seems not well understood by the overall security community*. Glad we have a change to change that! While I certainly am on board for vendor neutral approaches, we shouldn't dismiss valid feedback just because it comes from someone who is at a vendor. Critique on A2 My feedback
1.1 The "How do I prevent this" section only mentions multi-factor auth as a suggested defense. However, there are actually a few suggestions in the Credential Stuffing Prevent Cheat Sheet https://www.owasp.org/index.php/Credential_Stuffing_Prevention_Cheat_Sheet 1.2 Of more concern, the "Example Attack Scenarios #1" mentions rate limiting as a defense for credential stuffing attacks. This is just poor guidance and will lead to a false sense of security. That should be removed. 1.3 I do agree that it would be helpful to reference OWASP's existing material on Automated threats, specifically Credential Stuffing OAT-008 (https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications There are likely other ways we can enhance the A2 Broken Authentication guidance; however, the specific feedback for Credential Stuffing should be considered and incorporated. *Leaders list discussion on password reuse attacks aka credential stuffing |
|
While I certainly am on board for vendor neutral approaches, we shouldn't dismiss valid feedback just because it comes from someone who is at a vendor.
Michael, I do not think we should dismiss anyones feedback. But when vendors write about vendor things, we clearly need to ensure that non-vendor eyes review such material closely. It’s also important that folks state their biases clearly. I know you worked for Shape in the past and that may effect your perspective on this as well.
A good way to avoid bias is to recuse oneself from issues where they financially or otherwise benefit from participation. So I’d ask Shape folks or folks with Shape equity to politely encourage discussion on this topic but not directly author such material. This is not dismissive of credential stuffing or Shape folks, I am trying to protect both OWASP and Shape. What will it look like after we publish the OT10 and folks express concern that Shape authored extensive credential stuffing material in the T10 and also have financial benefit from doing so? This is not an attempt to harm or try to impugn anyones reputation. I am trying to protect you, Shape and OWASP.
And last, I read your comments below. You obviously have great expertise in this area and I find your perspective to be astute and helpful.
…--
Jim Manico
@manicode
On Oct 24, 2017, at 7:13 AM, Michael Coates ***@***.***> wrote:
Very excited to see the new top 10 and good feedback already coming in. I'm particularly interested in credential stuffing as it's an issue I deal with often during my day job and I've also found it to be a topic that seems not well understood by the overall security community*. Glad we have a change to change that!
While I certainly am on board for vendor neutral approaches, we shouldn't dismiss valid feedback just because it comes from someone who is at a vendor.
Critique on A2
To Jim's point, there are a variety of ways Authentication can be broken. To Sumit's point, the current A2 is heavily geared towards credential stuffing and brute force (it seems to be the primary factor for the Exploitability rating and are the first two items mentioned in "Am I Vulnerable"
My feedback
If we are going to talk about credential stuffing (which A2 does), then we certainly shouldn't give bad/incorrect guidance.
1.1 The "How do I prevent this" section only mentions multi-factor auth as a suggested defense. However, there are actually a few suggestions in the Credential Stuffing Prevent Cheat Sheet https://www.owasp.org/index.php/Credential_Stuffing_Prevention_Cheat_Sheet
From personal experience and from feedback from peers at other large companies I'd also say the Credential Stuffing Prevent Cheat Sheet could use a refresh with some newer defenses too.
1.2 Of more concern, the "Example Attack Scenarios #1" mentions rate limiting as a defense for credential stuffing attacks. This is just poor guidance and will lead to a false sense of security. That should be removed.
1.3 I do agree that it would be helpful to reference OWASP's existing material on Automated threats, specifically Credential Stuffing OAT-008 (https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications
and https://www.owasp.org/images/3/33/Automated-threat-handbook.pdf)
There are likely other ways we can enhance the A2 Broken Authentication guidance; however, the specific feedback for Credential Stuffing should be considered and incorporated.
*Leaders list discussion on password reuse attacks aka credential stuffing
http://lists.owasp.org/pipermail/owasp-leaders/2016-June/016879.html
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Our Automated Threats Handbook lists many web application threats events. The ones tagged as "commonly misusing" authentication data are OAT-007 Credential Cracking, OAT-008 Credential Stuffing, OAT-009 CAPTCHA Defeat, OAT-011 Scraping, OAT-012 Cashing Out, OAT-019 Account Creation and OAT-020 Account Aggregation. If payment cardholder data are also considered to be authentication data OAT-001 Carding and OAT-010 Card Cracking might also be relevant here. We have 21 threats identified in total, so our project is certainly not all about A2 in 2017 RC2, but there is some overlap, and as project co-leader would welcome the Top 10's readers being pointed towards the much wider list of countermeasures we have identified for each of these. Also of note, I wonder how many attempted and successful attacks are the result of a single breach of authentication credentials and/or personal information elsewhere (e.g. the loss of data from Equifax)? Despite the seriousness of the issue to Equifax relating to 145 million US citizens, 700,000 UK citizens, 8,000 Canadian citizens, etc, I imagine that there has been a much larger effect on - perhaps thousands or tens of thousands of other web applications have since been attacked, and many individuals (hundreds of thousands, millions?) had data compromised as a result. |
|
Nice list. Thank you for pointing it out!
I think it would make this risk category more clear if we list the totality of AuthN risks as opposed to just digging deep into one of them. AuthN is one of the most complex layers to build, verify and defend. I suggest that A2 makes that point clear.
… On Oct 24, 2017, at 10:03 AM, clerkendweller ***@***.***> wrote:
Our Automated Threats Handbook lists many web application threats events. The ones tagged as "commonly misusing" authentication data are OAT-007 Credential Cracking, OAT-008 Credential Stuffing, OAT-009 CAPTCHA Defeat, OAT-011 Scraping, OAT-012 Cashing Out, OAT-019 Account Creation and OAT-020 Account Aggregation. If payment cardholder data are also considered to be authentication data OAT-001 Carding and OAT-010 Card Cracking might also be relevant here.
We have 21 threats identified in total, so our project is certainly not all about A2 in 2017 RC2, but there is some overlap, and as project co-leader would welcome the Top 10's readers being pointed towards the much wider list of countermeasures we have identified for each of these.
Also of note, I wonder how many attempted and successful attacks are the result of a single breach of authentication credentials and/or personal information elsewhere (e.g. the loss of data from Equifax)? Despite the seriousness of the issue to Equifax relating to 145 million US citizens, 700,000 UK citizens, 8,000 Canadian citizens, etc, I imagine that there has been a much larger effect on - perhaps thousands or tens of thousands of other web applications have since been attacked, and many individuals (hundreds of thousands, millions?) had data compromised as a result.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@jmanico - Thanks Jim. Glad we're getting good data points and feedback on the issue. I of course whole heartily agree with arriving at a neutral and balanced set of information/recommendations without undo bias from any angle - vendor approach, consultant approach, cross your fingers and hope approach :) . To your suggestion about avoid directly authoring, I think we're all good there. Everyone here is suggesting data points and critiques and none of us are direct authors. But, it does sound like there "rules of engagement" for the top 10 are not clear if you and I are trading suggestions and feedback on who should be able to participate and how within an individual github issue. I'll reach out to you out of this channel so we can work together with the Top 10 leadership team to clarify any concern and perhaps get an approach published that everyone can reference as needed. Thanks! |
|
Great discussion! I'd like to talk this over with the other leaders on Friday, so hang in there, but if you keep discussing it to arrive at a nice place, that will help a lot |
|
@vanderaj Andrew if there's any feedback from the discussion you had with the other leaders last Friday, I'd be happy to continue the dialogue and add some more comments here. |
|
Andrew is looking for a set of minimal changes (it's very late in the process) that we can make to this section to incorporate the issues. He will look for feedback as he progresses. |
|
Accepted; will work on this to improve the recommendations and remove the scenario rate limiting. Will touch base with folks once the change is in place. |
|
I've re-ordered the post Issue #252 changes to fix the first point of ordering (which is valid) For Michael's feedback, I've re-worded the rate limiting for credential stuffing. I've also reworked the example, and taken on board Dirk's feedback for the automated threats. Please review @sumitagarwalusa @clerkendweller @mwcoates @jmanico |
|
Here's the latest A2 for your review |
|
HI Andrew, thanks! To me it appears sill confusing as it lists -- looking at the headline and at the risk factors -- Broken authentication. Then -- what I appreciate in general -- appear below session management issues. My points is this appears for the reader "all of a sudden". If you want to revert the changes I would also try to be more consequent. I know that it is difficult for space reasons . Thus my proposal:
Authentication is to me the process of getting access, It is not a lock which has a fixed setting but it is configurable either in the code or per setting (a couple of weeks ago I saw a yaml file where the developers left it to the costumer which pw policy they want to enable.). The line
Those two lines e.g. would help to make a bit space for session management. |
|
In
|
|
Remove "weak or well-known" passwords. IMO this can be also a security
configuration. It needs to be mentioned over there though.
This is a core authentication control described by NIST 800-83-3 and is
more commonly referred to as "rejecting commonly used passwords". This
is not at all configuration (Ie: I would not add this to an app config
file it would be something more core to my application) and is in fact
one of the most important controls that dev's need to implement around
Authentication. So I suggest it stay in A2.
- Jim
…On 11/12/17 8:37 AM, Dirk Wetter wrote:
HI Andrew,
thanks!
To me it appears sill confusing as it lists -- looking at the headline
and at the risk factors -- Broken authentication. Then -- what I
appreciate in general -- appear below session management issues. My
points is this appears for the reader "all of a sudden".
If you want to revert the changes I would also try to be more
consequent. I know that it is difficult for space reasons . Thus my
proposal:
* remove default passwords -- that appears to me "Security
Miscofiguration". Tt is also mentioned there)
* Remove "weak or well-known" passwords. IMO this can be also a
security configuration. It needs to be mentioned over there though.
Authentication is to me the process of getting access, It is not a
lock which has a fixed setting but it is configurable either in the
code or per setting (a couple of weeks ago I saw a yaml file where the
developers left it to the costumer which pw policy they want to enable.).
The line |Permits default, weak or well-known passwords, such as
"Password1" or "admin/admin“.| is then not necessary.
|Uses plain text, encrypted, or weakly hashed passwords (see
A3:2017-Sensitive Data Exposure).| says also it is mentioned in A3. So
IMO there shouldn't be a need to crunch it in here too, no?
Those two lines e.g. would help to make a bit space for session
management.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#233 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AAgcCdZnSAWpiAs5uJ1evVyID1VGLqSPks5s1xDHgaJpZM4QCS_K>.
--
Jim Manico
Manicode Security
https://www.manicode.com
|
|
Also, please note that most of these issues could neatly fit into
several categories. :)
…On 11/12/17 8:37 AM, Dirk Wetter wrote:
HI Andrew,
thanks!
To me it appears sill confusing as it lists -- looking at the headline
and at the risk factors -- Broken authentication. Then -- what I
appreciate in general -- appear below session management issues. My
points is this appears for the reader "all of a sudden".
If you want to revert the changes I would also try to be more
consequent. I know that it is difficult for space reasons . Thus my
proposal:
* remove default passwords -- that appears to me "Security
Miscofiguration". Tt is also mentioned there)
* Remove "weak or well-known" passwords. IMO this can be also a
security configuration. It needs to be mentioned over there though.
Authentication is to me the process of getting access, It is not a
lock which has a fixed setting but it is configurable either in the
code or per setting (a couple of weeks ago I saw a yaml file where the
developers left it to the costumer which pw policy they want to enable.).
The line |Permits default, weak or well-known passwords, such as
"Password1" or "admin/admin“.| is then not necessary.
|Uses plain text, encrypted, or weakly hashed passwords (see
A3:2017-Sensitive Data Exposure).| says also it is mentioned in A3. So
IMO there shouldn't be a need to crunch it in here too, no?
Those two lines e.g. would help to make a bit space for session
management.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#233 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AAgcCdZnSAWpiAs5uJ1evVyID1VGLqSPks5s1xDHgaJpZM4QCS_K>.
--
Jim Manico
Manicode Security
https://www.manicode.com
|
|
Dirk, I'll try and introduce session management in the top boxes as well. As much as I would like to stick to DRY principles, the reality is in many enterprises I work in, the IDAM team is commonly completely separate from the developers, who are forced to re-use a federated SSO environment of varying quality, often unable to enforce basic password controls and with limited or no detection or risk based / MFA authentication. I'm looking for something that represents some of the worst authentication issues to ensure that the IDAM team can't say "that's not my problem" at the risk of repeating ourselves. We can't really remove them. |
|
Okay, I've revised the PPTX to introduce session management in the Exploitability and Prevalence top boxes. That way it will not be a surprise to the reader. Anything more will have to come after GM release. |
|
okay, makes sense. Just thought to save space |
|
Should we delete 'Log all failures and alert administrators when credential stuffing, brute force, other attacks are detected.' |
|
Perhaps we could use the space to add something like |
for example. Also this place can be taken by something from Session Management |
|
<OT>: Just searched to suggested s.th.: Wasn't there a RC2 branch? |
|
@sslHello Same error message is covered by the bullet point for account enumeration, which is more than just error messages, it's also potentially timing attacks, different REST error codes, etc. We just don't have room for everything. I really need detectability to be high here, as credential attacks are probably the most prevalent issue for actual breaches. I'm not going to remove it from this version. I think we need to close this down as we need to provide balance between how authentication is being actively exploited with billions of loose valid credentials against the much less likely session management attacks. |
"A2 Broken Authentication" focuses heavily on credential stuffing. Both the "Threat" and "Am I Vulnerable" sections open with explanations of credential stuffing. The Example Attack Scenario also begins with credential stuffing.
However, the bullets listed in "How do I prevent this" only begin to address credential stuffing in the last two bullets, and those two bullets do not reference OWASP's own guidance on how to think about defending against credential stuffing.
I suggest considering the following:
Consider re-ordering the "How Do I Prevent This" so those recommendations loosely track the order of threats and Vulns listed in this section (i.e. the last two bullets would be the first two).
Consider a specific prevention recommendation to monitor the login form for "login failure rate" (i.e. the % of attempted logins that fail). This number will normally hover in a relatively narrow range for a given application (perhaps 5-15%), but almost always jumps during a credential stuffing attack (often as high as 80% even for applications with 10M logins per day).
Consider referencing OWASP's Automated Threats Handbook, as this deals with credential stuffing in more detail and is a pre-existing OWASP resource.
https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications
Consider more directly identifying credential stuffing as an automated attack. Currently, credential stuffing is listed alongside automated attacks, and is mixed in with brute forcing (which is dealt with quite differently). Properly identifying credential stuffing as an automated attack may help application developers select the right defenses.
Consider removing "rate limiting" as a concept in the "Example Attack Scenario". Rate limiting does not work against credential stuffing, as the basic structure of a credential stuffing attack involves hundreds of thousands of IPs, thousands of user agents, etc. In other words, there is very little upon which to implement a rate limit.
The text was updated successfully, but these errors were encountered: