OWASP - User contributions [en]

Talk:OWASP Initiatives Global Strategic Focus/website project

2016-07-22T13:04:05Z

Lbriner: Clarify mock ups/comparisons and what they are for.

== Thoughts on look and feel ==

The Needs Assessment report has a good analysis of the current web site and provides a lot of valuable ideas for improvements. The mock-ups mostly look attractive. However, I disagree with some of the underlying assumptions:
* Wikipedia-style is derided. However, this style is wholly appropriate for the OWASP style IMHO. The OWASP web site could do worse than emulate Wikipedia '''more''' faithfully. Run towards Wikipedia, not away from it!
* The (ISC)^2 web site is put forward as a style to aspire to. I beg to differ: the current OWASP web site looks a lot more attractive to me than (ISC)^2's. The former is much easier on the eye. (ISC)^2 may draw attention through the use of striking colors and more graphic material. However, no additional useful information is conveyed. The net result is a feeling of weariness: my brain has to work hard to take in all these stimuli and I get very little in return. Remember that web sites are not competing for attention like billboards: unlike billboards, you visit web sites one by one. A good web site conveys its message while minimising collateral damage through information fatigue.
* Agree with both of the above. ISC2 is not a "competitor" and whilst the report has much to offer, focusing on ISC2, ISACA, ISA for comparisons seems a bit lazy. These other organisations are not like OWASP in terms of objectives, audience or membership. I remember being asked during an interview for this "shouldn't OWASP be the primary source of information" and I said no, OWASP's role is to promote application security - not promote itself. AppSec info appearing on other websites is a win - not a negative.
* The importance of the (ISC)^2 website is not that (ISC)^2 is a direct competitor or the colors they used but that they inhabit the same "space" as OWASP and that their decisions about organization make their website easier for new people to use.
*The suggestion is not necessarily to do away with the wiki but to clean it up and change a few key landing pages to be easier to follow.
* On p28 of the report, there is a recommendation to make the projects more consistency. I disagree, let projects lay out their content however they want - the audiences vary massively, and projects vary a lot too. OWASP is not ISC2 and I suspect never wants to be. ISC2 keeps getting used as an example - what about other community sites rather than commercial sales-orientated vendors like ISC2? At least OWASP has a memorable/writable name.
* Agree, a breadcrumb trail mentioned on p31 would be useful, but is still a challenge to define what the hierarchy might be
* Peer analysis on p32 is flawed. The organisation mentioned are not peers.
* Fascinating, p37 says "OWASP has the highest Alexa ranking"... err so why do we have to change so much?
* The "bounce rate" is mentioned as a negative here but fails to understand how some people use the site. The high number of "single page visitors" was also lauded by the report's authors as awful during the telephone interview, but they did not realise that some people use OWASP as a reference document, and use Google to search for "XSS cheat sheet" for example, then go to that page, use the information and then get on with their lives. There is no analysis of robots anywhere in this report, so the analysis of information presented about visitors is guesswork.
* The wikimedia style is arguably very good for ''some'' things but not others. I think the confusion is between consumers and contributers. Consumers want a site where navigation is easy and hierarchy is obvious, contributers want something where changes can quickly and easily be made and discussions had interactively. Remember that wikpedia encourages citations to backup information, something that is much less common in Development, especially AppSec where the "right" answer is often opinion rather than fact.

== Thoughts on Platform Selection ==

* p48 states there are two purposes for the OWASP website.... (1 Organisation visibility and membership promotion/participation and 2 Improve application security visibility...). Although this is stated within what is called "Option A", it seems to apply to all three options. But more importantly, "Organisation visibility and membership promotion/participation" is not one of OWASP's objectives, values, purposes or principles. Who said that self-promotion is one of the website's purposes? If the only purpose is instead "Improve application security visibility...", then the arguments for the 3 options need to be revisited e.g. the report says "These 2 purposes are at odds with each other".

== Thoughts on Information Architecture ==

* The proposed top level navigation on p50 is inward looking, and doesn't consider the site's audiences and their needs
* The "OWASP Podcast" is no longer updated - it is called "OWASP 24/7"
* The proposed design for the home page on p53 is not compatible with OWASP's activity level and ability to generate content frequently, specifically:
** Blog post frequency is typically 2-4 per month which would give the impression not much is happening
** Not sure how "latest news" is different to what appears on "blog" or "podcast" or "events" - the Global Connector is the most regular OWASP output, but that content also appear on the blog and OWASP 24/7
** OWASP 24/7 frequency is quite variable. Excellent content but old dates might put people off
** The events diary has never represented all the chapter and other local meetings going on, and therefore suggests OWASP is not active in many places when it actually is - most events listed on the current home page calendar are not OWASP events, but security sector events
** "AppSec feed" hasn't existed for many years now - it was extremely good at the time, but a spot on the home page with no content will look terrible
* The earlier section of the report suggests that most visitors want the Top 10, ASVS and Cheat Sheets. they are not mentioned anywhere on the proposed design
* Project drop down on p56 is OWASP-centric instead of audience-centric - who cares how OWASP categorises its own projects? It's important, but shouldn't be the prime way to find information.
* Project page mock-ups lack inspired thought
* How is "recent activity" on the projects page updated and who does it?
* The project wiki article page suggestion on p57 looks boring, and throws away lots of content on many project pages
* Breadcrumb trail and other things were mentioned as missing in the report discussion, but lots of those recommendations don't appear in the proposed designs - why not?
* The mockups and comparisons to "competitors" are possibly contentious because the description is not abstracted to a high enough level. For example, it should not be a case of ISC2 does navigation this way and they are ''competitors'' so we could/should do it this way or even 'their way looks better'. The correct abstraction is ''what is it about OWASPs navigation'' that is not working and does the way that ISC/others do navigation solve the problem. This is important because there are several ways to achieve what you want as long as you are asking the correct question.

== Thoughts on Back Office and Infrastructure Architecture ==
This should certainly be a priority. It is difficult to volunteer for projects and efforts since work needed is not centralized. Additionally, communication seems to always go out of band to email which reduces overall teamwork and transparency. While the groups are very successful, we are losing volunteer work due to an inability to locate it.

== Thoughts on Gamification ==

* The pool of active contributors is not large enough to make gamification meaningful

== Thoughts on Features and Release Roadmap ==

* The report says on p64 that "[content on] MediaWiki older than 2 years and have not been accessed frequently should fall under the archive". No thanks, the test should be whether the content is still relevant or useful. Not sue the report authors understand what OWASP's mission is about.
* "Automated scoring and badging" - no thanks

== Thoughts on Search Functionality ==

* Did I miss something - "search" doesn't seem to be mentioned in the report's recommendations, or "features and release roadmap"

== Another topic... ==

Talk:OWASP Initiatives Global Strategic Focus/website project

2016-07-22T12:59:04Z

Lbriner: Add comment about site trying to serve two separate audiences.

== Thoughts on look and feel ==

The Needs Assessment report has a good analysis of the current web site and provides a lot of valuable ideas for improvements. The mock-ups mostly look attractive. However, I disagree with some of the underlying assumptions:
* Wikipedia-style is derided. However, this style is wholly appropriate for the OWASP style IMHO. The OWASP web site could do worse than emulate Wikipedia '''more''' faithfully. Run towards Wikipedia, not away from it!
* The (ISC)^2 web site is put forward as a style to aspire to. I beg to differ: the current OWASP web site looks a lot more attractive to me than (ISC)^2's. The former is much easier on the eye. (ISC)^2 may draw attention through the use of striking colors and more graphic material. However, no additional useful information is conveyed. The net result is a feeling of weariness: my brain has to work hard to take in all these stimuli and I get very little in return. Remember that web sites are not competing for attention like billboards: unlike billboards, you visit web sites one by one. A good web site conveys its message while minimising collateral damage through information fatigue.
* Agree with both of the above. ISC2 is not a "competitor" and whilst the report has much to offer, focusing on ISC2, ISACA, ISA for comparisons seems a bit lazy. These other organisations are not like OWASP in terms of objectives, audience or membership. I remember being asked during an interview for this "shouldn't OWASP be the primary source of information" and I said no, OWASP's role is to promote application security - not promote itself. AppSec info appearing on other websites is a win - not a negative.
* The importance of the (ISC)^2 website is not that (ISC)^2 is a direct competitor or the colors they used but that they inhabit the same "space" as OWASP and that their decisions about organization make their website easier for new people to use.
*The suggestion is not necessarily to do away with the wiki but to clean it up and change a few key landing pages to be easier to follow.
* On p28 of the report, there is a recommendation to make the projects more consistency. I disagree, let projects lay out their content however they want - the audiences vary massively, and projects vary a lot too. OWASP is not ISC2 and I suspect never wants to be. ISC2 keeps getting used as an example - what about other community sites rather than commercial sales-orientated vendors like ISC2? At least OWASP has a memorable/writable name.
* Agree, a breadcrumb trail mentioned on p31 would be useful, but is still a challenge to define what the hierarchy might be
* Peer analysis on p32 is flawed. The organisation mentioned are not peers.
* Fascinating, p37 says "OWASP has the highest Alexa ranking"... err so why do we have to change so much?
* The "bounce rate" is mentioned as a negative here but fails to understand how some people use the site. The high number of "single page visitors" was also lauded by the report's authors as awful during the telephone interview, but they did not realise that some people use OWASP as a reference document, and use Google to search for "XSS cheat sheet" for example, then go to that page, use the information and then get on with their lives. There is no analysis of robots anywhere in this report, so the analysis of information presented about visitors is guesswork.
* The wikimedia style is arguably very good for ''some'' things but not others. I think the confusion is between consumers and contributers. Consumers want a site where navigation is easy and hierarchy is obvious, contributers want something where changes can quickly and easily be made and discussions had interactively. Remember that wikpedia encourages citations to backup information, something that is much less common in Development, especially AppSec where the "right" answer is often opinion rather than fact.

== Thoughts on Platform Selection ==

* p48 states there are two purposes for the OWASP website.... (1 Organisation visibility and membership promotion/participation and 2 Improve application security visibility...). Although this is stated within what is called "Option A", it seems to apply to all three options. But more importantly, "Organisation visibility and membership promotion/participation" is not one of OWASP's objectives, values, purposes or principles. Who said that self-promotion is one of the website's purposes? If the only purpose is instead "Improve application security visibility...", then the arguments for the 3 options need to be revisited e.g. the report says "These 2 purposes are at odds with each other".

== Thoughts on Information Architecture ==

* The proposed top level navigation on p50 is inward looking, and doesn't consider the site's audiences and their needs
* The "OWASP Podcast" is no longer updated - it is called "OWASP 24/7"
* The proposed design for the home page on p53 is not compatible with OWASP's activity level and ability to generate content frequently, specifically:
** Blog post frequency is typically 2-4 per month which would give the impression not much is happening
** Not sure how "latest news" is different to what appears on "blog" or "podcast" or "events" - the Global Connector is the most regular OWASP output, but that content also appear on the blog and OWASP 24/7
** OWASP 24/7 frequency is quite variable. Excellent content but old dates might put people off
** The events diary has never represented all the chapter and other local meetings going on, and therefore suggests OWASP is not active in many places when it actually is - most events listed on the current home page calendar are not OWASP events, but security sector events
** "AppSec feed" hasn't existed for many years now - it was extremely good at the time, but a spot on the home page with no content will look terrible
* The earlier section of the report suggests that most visitors want the Top 10, ASVS and Cheat Sheets. they are not mentioned anywhere on the proposed design
* Project drop down on p56 is OWASP-centric instead of audience-centric - who cares how OWASP categorises its own projects? It's important, but shouldn't be the prime way to find information.
* Project page mock-ups lack inspired thought
* How is "recent activity" on the projects page updated and who does it?
* The project wiki article page suggestion on p57 looks boring, and throws away lots of content on many project pages
* Breadcrumb trail and other things were mentioned as missing in the report discussion, but lots of those recommendations don't appear in the proposed designs - why not?

== Thoughts on Back Office and Infrastructure Architecture ==
This should certainly be a priority. It is difficult to volunteer for projects and efforts since work needed is not centralized. Additionally, communication seems to always go out of band to email which reduces overall teamwork and transparency. While the groups are very successful, we are losing volunteer work due to an inability to locate it.

== Thoughts on Gamification ==

* The pool of active contributors is not large enough to make gamification meaningful

== Thoughts on Features and Release Roadmap ==

* The report says on p64 that "[content on] MediaWiki older than 2 years and have not been accessed frequently should fall under the archive". No thanks, the test should be whether the content is still relevant or useful. Not sue the report authors understand what OWASP's mission is about.
* "Automated scoring and badging" - no thanks

== Thoughts on Search Functionality ==

* Did I miss something - "search" doesn't seem to be mentioned in the report's recommendations, or "features and release roadmap"

== Another topic... ==

Talk:Password length & complexity

2015-11-16T11:53:07Z

Lbriner: Added other topic based on KoreLogic video.

Several proposals for addition into article:
# Add threat model and a role of password complexity as possible mitigation:
#* Online guessing attacks
#* Offline guessing attacks
#* Breadth vs. targeted attacks
#* Relation between password storage and effectiveness of password policy[1]
# Psychology acceptance issues
#* If account is important for a system (e.g. staff vs. customer accounts, privileged vs. unprivileged, etc).
#* If service is important for a user (e.g. personal backup vs. bulletin board vs. movie ranking site vs. banking service, etc).
#* Theoretical limit for memorable passwords entropy per user/site, per user/all sites he use.
#* Password entering usability concerns (mobiles vs. desktop).
#* Presence of multiple factors of AuthN.
# Password policy implementations considerations
#* Preference length over "complexity" [link needed]
#* Gamification is a friend [link needed]
#* Heuristic-based over formal polices [2,3]
#* Known password blacklists
#* The pitfalls of "password strength meters"[2] ([[User:Lbriner|Luke Briner]])
# List of approved password polices
#* Strong polices: passwdqc, zxcvbn
#* Liberal polices?
#* libpathwell?
# Other aspects of password policy
#* Password expiration (pros and cons) [links needed]
#* Password history (pros and cons)
#* Client-side vs server-side
# Password generation
#* Link to entropy of random passwords on Wikipedia
#* Pronounceable passwords
# Something else?

Btw, Wikipedia's [https://en.wikipedia.org/wiki/Password_strength Password Strength] page is good enough but have no direct recommendations for developers. It is rather good compilation of different opinions and researches. At least links are very useful.

Materials:

* [1] [http://research.microsoft.com/apps/pubs/?id=227130 An Administrator’s Guide to Internet Password Research] by Dinei Florencio ˆ, Cormac Herley, and Paul C. van Oorschot
* [2] [https://www.youtube.com/watch?v=zUM7i8fsf0g Your Password Complexity Requirements are Worthless] by KoreLogic
* [3] [http://password-policy-testing.wikidot.com/results Testing Password Polices] by adedov@

--[[User:Adedov|Adedov]] ([[User talk:Adedov|talk]]) 06:05, 14 November 2015 (CST)
----

The overall content is correct, but I have the following remarks :

1. I corrected some syntactical errors in the text. For example, "is" was missing in the sentence "it is the most common form", in the introduction.

2. The introduction could insist on the idea that passwords are basically a means of authenticating users of a Web application, among other means, and that the choice of passwords or a stronger means like two-factors authentication really depends on the security needs of an application, based on risk evaluation and security specifications in the conception phase.

3. In the introduction about the "Pros" and "Cons" of passwords, I would add in the "Cons" that we all suffer from having to manage and remember too many passwords. For a new Web application, one should consider the possibility of relying on a more global identity management system (such as some sort of "single sign on" or "reduced sign on" set for all or at least many applications in the corporation), instead of trying to generate yet another password.

4. I think the details of password length, password complexity and password history should not be fixed too precisely, because it really depends on the security policies of each organization. The main point in general is that in security policies, there must be rules for password length (a minimum length should be defined), password complexity (the minimum complexity of passwords should be described) and password history (the minimum number of old passwords to check should be defined).

5. I would not present managing the history of passwords as a "nice to have" feature, but rather as a mandatory feature.

Philippe Curmin

== How to avoid similar passwords? ==

In order to hinder users from using similar passwords or passwords with simple counters ("test1" -> "test2") it would be nice to implement the [http://en.wikipedia.org/wiki/Levenshtein_distance Levenshtein Distance] for the change of passwords and only allow those with at least a minimum distance.

The problem with the distance function is that I need to know the old password, which I shouldn't. If I save passwords as hashes the function doesn't work anymore.

Is there already an algorithm to compare passwords without saving them as plain text? I can imagine something like a function that saves the structure of the phrase, i.e. "test1" consists of 4 alphabetical lowercase signs and one number - the same as in "test2". But also in "ak9Me". So it needs to be a bit more sophisticated.

Any ideas?

The linked KoreLogic video considers this in a much more straight-forward manner. Based on research of NTLM hashes which are easy to crack, it was noticed that all a password policy does is to make people use a capitalised word, a couple of numbers and perhaps a punctuation mark e.g. Denver2014! and this massively reduces the amount of brute-forcing required. The suggestion is to blacklist certain patterns (or you could at least warn the user that their pattern is weak) such as ullllldds and ullllldddds etc. What you can also do with that approach is to not allow the user to have the same pattern twice in a row, which would prevent things like test1 -> test2.

It is not in use anywhere obvious on the web but is based on the latest real-world threat model from hackers.
--[[User:Lbriner|Luke Briner]] ([[User talk:LBriner|talk]]) 11:38, 16 November 2015 (UTC)

== Password lifetime criteria ==

Is there any advice or direction on how often a system should require a password to be changed?

Passwords that change too often are much less likely to be committed to memory, which leads to more use of the dreaded sticky note on the monitor.
For instance, if a system typically has monthly access from users, and has a 90 day password change policy, this would lead to each password only being used ~3 times before requiring change.

Dave Elton

Not that much hard and fast direction (is there ever?)

The question is about the threat model that password changing is supposed to prevent. Firstly, it can help mitigate using the same password across multiple web sites since passwords wouldn't all change at the same time. Secondly, it would require an attacker to crack a password within the password change frequency in order to make use of it (this is based on certain assumptions such as not changing password1 to password2 and the fact that the user has not used the password elsewhere in which case you are only as safe as the least safe site!). I used to work for a very large security company and their (corporate) policy required a change every 3 months. I think they assumed that the chances of a leak were fairly low with all their other measures in place. I'm also sure that plenty of people would say that there is no major value in the policy since unless you use a password manager, it becomes almost impossible to manage and if you do, you might as well just generate such a strong and unique password that it is unlikely to be cracked and won't be shared anywhere else which means there is no point changing it!
--[[User:Lbriner|Luke Briner]] ([[User talk:LBriner|talk]]) 11:22, 16 November 2015 (UTC)

Talk:Password length & complexity

2015-11-16T11:47:51Z

Lbriner: /* Password lifetime criteria */

Several proposals for addition into article:
# Add threat model and a role of password complexity as possible mitigation:
#* Online guessing attacks
#* Offline guessing attacks
#* Breadth vs. targeted attacks
#* Relation between password storage and effectiveness of password policy[1]
# Psychology acceptance issues
#* If account is important for a system (e.g. staff vs. customer accounts, privileged vs. unprivileged, etc).
#* If service is important for a user (e.g. personal backup vs. bulletin board vs. movie ranking site vs. banking service, etc).
#* Theoretical limit for memorable passwords entropy per user/site, per user/all sites he use.
#* Password entering usability concerns (mobiles vs. desktop).
#* Presence of multiple factors of AuthN.
# Password policy implementations considerations
#* Preference length over "complexity" [link needed]
#* Gamification is a friend [link needed]
#* Heuristic-based over formal polices [2,3]
#* Known password blacklists
# List of approved password polices
#* Strong polices: passwdqc, zxcvbn
#* Liberal polices?
#* libpathwell?
# Other aspects of password policy
#* Password expiration (pros and cons) [links needed]
#* Password history (pros and cons)
#* Client-side vs server-side
# Password generation
#* Link to entropy of random passwords on Wikipedia
#* Pronounceable passwords
# Something else?

Btw, Wikipedia's [https://en.wikipedia.org/wiki/Password_strength Password Strength] page is good enough but have no direct recommendations for developers. It is rather good compilation of different opinions and researches. At least links are very useful.

Materials:

* [1] [http://research.microsoft.com/apps/pubs/?id=227130 An Administrator’s Guide to Internet Password Research] by Dinei Florencio ˆ, Cormac Herley, and Paul C. van Oorschot
* [2] [https://www.youtube.com/watch?v=zUM7i8fsf0g Your Password Complexity Requirements are Worthless] by KoreLogic
* [3] [http://password-policy-testing.wikidot.com/results Testing Password Polices] by adedov@

--[[User:Adedov|Adedov]] ([[User talk:Adedov|talk]]) 06:05, 14 November 2015 (CST)
----

The overall content is correct, but I have the following remarks :

1. I corrected some syntactical errors in the text. For example, "is" was missing in the sentence "it is the most common form", in the introduction.

2. The introduction could insist on the idea that passwords are basically a means of authenticating users of a Web application, among other means, and that the choice of passwords or a stronger means like two-factors authentication really depends on the security needs of an application, based on risk evaluation and security specifications in the conception phase.

3. In the introduction about the "Pros" and "Cons" of passwords, I would add in the "Cons" that we all suffer from having to manage and remember too many passwords. For a new Web application, one should consider the possibility of relying on a more global identity management system (such as some sort of "single sign on" or "reduced sign on" set for all or at least many applications in the corporation), instead of trying to generate yet another password.

4. I think the details of password length, password complexity and password history should not be fixed too precisely, because it really depends on the security policies of each organization. The main point in general is that in security policies, there must be rules for password length (a minimum length should be defined), password complexity (the minimum complexity of passwords should be described) and password history (the minimum number of old passwords to check should be defined).

5. I would not present managing the history of passwords as a "nice to have" feature, but rather as a mandatory feature.

Philippe Curmin

== How to avoid similar passwords? ==

In order to hinder users from using similar passwords or passwords with simple counters ("test1" -> "test2") it would be nice to implement the [http://en.wikipedia.org/wiki/Levenshtein_distance Levenshtein Distance] for the change of passwords and only allow those with at least a minimum distance.

The problem with the distance function is that I need to know the old password, which I shouldn't. If I save passwords as hashes the function doesn't work anymore.

Is there already an algorithm to compare passwords without saving them as plain text? I can imagine something like a function that saves the structure of the phrase, i.e. "test1" consists of 4 alphabetical lowercase signs and one number - the same as in "test2". But also in "ak9Me". So it needs to be a bit more sophisticated.

Any ideas?

The linked KoreLogic video considers this in a much more straight-forward manner. Based on research of NTLM hashes which are easy to crack, it was noticed that all a password policy does is to make people use a capitalised word, a couple of numbers and perhaps a punctuation mark e.g. Denver2014! and this massively reduces the amount of brute-forcing required. The suggestion is to blacklist certain patterns (or you could at least warn the user that their pattern is weak) such as ullllldds and ullllldddds etc. What you can also do with that approach is to not allow the user to have the same pattern twice in a row, which would prevent things like test1 -> test2.

It is not in use anywhere obvious on the web but is based on the latest real-world threat model from hackers.
--[[User:Lbriner|Luke Briner]] ([[User talk:LBriner|talk]]) 11:38, 16 November 2015 (UTC)

== Password lifetime criteria ==

Is there any advice or direction on how often a system should require a password to be changed?

Passwords that change too often are much less likely to be committed to memory, which leads to more use of the dreaded sticky note on the monitor.
For instance, if a system typically has monthly access from users, and has a 90 day password change policy, this would lead to each password only being used ~3 times before requiring change.

Dave Elton

Not that much hard and fast direction (is there ever?)

The question is about the threat model that password changing is supposed to prevent. Firstly, it can help mitigate using the same password across multiple web sites since passwords wouldn't all change at the same time. Secondly, it would require an attacker to crack a password within the password change frequency in order to make use of it (this is based on certain assumptions such as not changing password1 to password2 and the fact that the user has not used the password elsewhere in which case you are only as safe as the least safe site!). I used to work for a very large security company and their (corporate) policy required a change every 3 months. I think they assumed that the chances of a leak were fairly low with all their other measures in place. I'm also sure that plenty of people would say that there is no major value in the policy since unless you use a password manager, it becomes almost impossible to manage and if you do, you might as well just generate such a strong and unique password that it is unlikely to be cracked and won't be shared anywhere else which means there is no point changing it!
--[[User:Lbriner|Luke Briner]] ([[User talk:LBriner|talk]]) 11:22, 16 November 2015 (UTC)

Talk:Password length & complexity

2015-11-16T11:41:44Z

Lbriner: /* How to avoid similar passwords? */

Several proposals for addition into article:
# Add threat model and a role of password complexity as possible mitigation:
#* Online guessing attacks
#* Offline guessing attacks
#* Breadth vs. targeted attacks
#* Relation between password storage and effectiveness of password policy[1]
# Psychology acceptance issues
#* If account is important for a system (e.g. staff vs. customer accounts, privileged vs. unprivileged, etc).
#* If service is important for a user (e.g. personal backup vs. bulletin board vs. movie ranking site vs. banking service, etc).
#* Theoretical limit for memorable passwords entropy per user/site, per user/all sites he use.
#* Password entering usability concerns (mobiles vs. desktop).
#* Presence of multiple factors of AuthN.
# Password policy implementations considerations
#* Preference length over "complexity" [link needed]
#* Gamification is a friend [link needed]
#* Heuristic-based over formal polices [2,3]
#* Known password blacklists
# List of approved password polices
#* Strong polices: passwdqc, zxcvbn
#* Liberal polices?
#* libpathwell?
# Other aspects of password policy
#* Password expiration (pros and cons) [links needed]
#* Password history (pros and cons)
#* Client-side vs server-side
# Password generation
#* Link to entropy of random passwords on Wikipedia
#* Pronounceable passwords
# Something else?

Btw, Wikipedia's [https://en.wikipedia.org/wiki/Password_strength Password Strength] page is good enough but have no direct recommendations for developers. It is rather good compilation of different opinions and researches. At least links are very useful.

Materials:

* [1] [http://research.microsoft.com/apps/pubs/?id=227130 An Administrator’s Guide to Internet Password Research] by Dinei Florencio ˆ, Cormac Herley, and Paul C. van Oorschot
* [2] [https://www.youtube.com/watch?v=zUM7i8fsf0g Your Password Complexity Requirements are Worthless] by KoreLogic
* [3] [http://password-policy-testing.wikidot.com/results Testing Password Polices] by adedov@

--[[User:Adedov|Adedov]] ([[User talk:Adedov|talk]]) 06:05, 14 November 2015 (CST)
----

The overall content is correct, but I have the following remarks :

1. I corrected some syntactical errors in the text. For example, "is" was missing in the sentence "it is the most common form", in the introduction.

2. The introduction could insist on the idea that passwords are basically a means of authenticating users of a Web application, among other means, and that the choice of passwords or a stronger means like two-factors authentication really depends on the security needs of an application, based on risk evaluation and security specifications in the conception phase.

3. In the introduction about the "Pros" and "Cons" of passwords, I would add in the "Cons" that we all suffer from having to manage and remember too many passwords. For a new Web application, one should consider the possibility of relying on a more global identity management system (such as some sort of "single sign on" or "reduced sign on" set for all or at least many applications in the corporation), instead of trying to generate yet another password.

4. I think the details of password length, password complexity and password history should not be fixed too precisely, because it really depends on the security policies of each organization. The main point in general is that in security policies, there must be rules for password length (a minimum length should be defined), password complexity (the minimum complexity of passwords should be described) and password history (the minimum number of old passwords to check should be defined).

5. I would not present managing the history of passwords as a "nice to have" feature, but rather as a mandatory feature.

Philippe Curmin

== How to avoid similar passwords? ==

In order to hinder users from using similar passwords or passwords with simple counters ("test1" -> "test2") it would be nice to implement the [http://en.wikipedia.org/wiki/Levenshtein_distance Levenshtein Distance] for the change of passwords and only allow those with at least a minimum distance.

The problem with the distance function is that I need to know the old password, which I shouldn't. If I save passwords as hashes the function doesn't work anymore.

Is there already an algorithm to compare passwords without saving them as plain text? I can imagine something like a function that saves the structure of the phrase, i.e. "test1" consists of 4 alphabetical lowercase signs and one number - the same as in "test2". But also in "ak9Me". So it needs to be a bit more sophisticated.

Any ideas?

The linked KoreLogic video considers this in a much more straight-forward manner. Based on research of NTLM hashes which are easy to crack, it was noticed that all a password policy does is to make people use a capitalised word, a couple of numbers and perhaps a punctuation mark e.g. Denver2014! and this massively reduces the amount of brute-forcing required. The suggestion is to blacklist certain patterns (or you could at least warn the user that their pattern is weak) such as ullllldds and ullllldddds etc. What you can also do with that approach is to not allow the user to have the same pattern twice in a row, which would prevent things like test1 -> test2.

It is not in use anywhere obvious on the web but is based on the latest real-world threat model from hackers.
--[[User:Lbriner|Luke Briner]] ([[User talk:LBriner|talk]]) 11:38, 16 November 2015 (UTC)

== Password lifetime criteria ==

Is there any advice or direction on how often a system should require a password to be changed?

Passwords that change too often are much less likely to be committed to memory, which leads to more use of the dreaded sticky note on the monitor.
For instance, if a system typically has monthly access from users, and has a 90 day password change policy, this would lead to each password only being used ~3 times before requiring change.

Dave Elton

Talk:Password Storage Cheat Sheet

2015-11-16T11:22:38Z

Lbriner:

1) It is not clear that the slow hash is preferred over an HMAC storage format and why you would choose HMAC over slow hash.
2) Ideally, some mention should be made of the bcrypt-style storage format where cost, salt and hash are all stored together, which permits a very easy way to increase cost over time without breaking existing hashes. I am unsure of the scrypt format and I don't think PBKDF2 stores it this way by default. The format should be recommended since it then allows the contingency work mentioned further down.

--[[User:Lbriner|Luke Briner]] ([[User talk:LBriner|talk]]) 11:22, 16 November 2015 (UTC)
----

Suggest take in account planned/actual scale of a system to protect. Bigger systems probably need more layers of defense, like additional authN server + secret salt (local parameters) + traditional KDF for storage. See Solar Designer's [http://openwall.com/presentations/YaC2012-Password-Hashing-At-Scale/ slides] from Yac 2012 (unfortunately, there is no English video).

--[[User:Adedov|Adedov]] ([[User talk:Adedov|talk]]) 07:28, 13 November 2015 (CST)
----

Increasing work factor with PBKDF2 etc. can result in an application-level DoS vector. This can be abused in a passively distributed manner by inducing CSRF authentication attempts and hence standard CSRF mitigation should be applied to authentication systems too. Mitigating automated DoS attacks on this vector can be achieved with CAPTCHA but which users should be required to complete a CAPTCHA isn't as simple; linking it to a session and failed authentication attempts will not work as an automated attack can simply request a new session token. Perhaps it should be linked to IP or subnet?

--[[User:Arran Schlosberg|Arran Schlosberg]] , 19 Feb 2014 (UTC)
----

Setting a unlimited length for passwords can be an easy DOS vector. http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

--[[User:jmanico|Jim Manico]] , 16 Sept 2013 (UTC)
----

More on the previous dicussions on secret salts. They are usually referred to as pepper on practice. The advantage of having a pepper for the passwords is that you can keep them on the web server. Thus, if the hacker has access to the database data and he has access to all hashed passwords (doesn't matter if they are created using PBKDF2, bcrypt or scrypt, or even simple salt+sha2), he still needs to also hack the web server to obtain the pepper, or fixed salt. It isn't cryptographically significant, but it adds yet another layer to the information the hacker has to obtain before starting to do the brute force.
I think it would be nice if it was possible to add it to the cheat sheet.

--[[User:Manuel Aude Morales|Manuel Aude Morales]] , 18 March 2013 (UTC)
----

I was considering adding bcrypt to the article. I checked previous versions and noticed it was in it on January, but it was taken out during editions in March. From my knowledge, bcrypt is still a widely recommended adaptative hashing function. While it has limitations (particularly, a 55 bytes limitation) and doesn't protect to all hardware accelerated attacks, it does protect against GPU and works as good as PBKDF2 for most cases. Also, scrypt hasn't existed for nearly as much as bcrypt, and thus it isn't as widely tested or supported by platforms.

Would it be ok to add a table making a comparison between PBKDF2, bcrypt and scrypt, with suggestions on when to use (and clarifying that the three are valid options)?
--[[User:Manuel Aude Morales|Manuel Aude Morales]] , 18 March 2013 (UTC)
----

Is there any utility in incuding credential data in the input to the protective function? I don't understand what it adds, given a sufficiently random salt. [[User:James Sanderson|James Sanderson]] ([[User talk:James Sanderson|talk]]) 17:25, 2 July 2014 (CDT)

Password Storage Cheat Sheet

2015-11-16T11:19:14Z

Lbriner: Tidy up the phrasing of the second sentence.

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

Media covers the theft of large collections of passwords on an almost daily basis. Media coverage of password theft discloses the password storage scheme, the weakness of that scheme, and often discloses a large population of compromised credentials that can affect multiple web sites or other applications. This article provides guidance on properly storing passwords, secret question responses, and similar credential information. Proper storage helps prevent theft, compromise, and malicious use of credentials.
Information systems store passwords and other credentials in a variety of protected forms. Common vulnerabilities allow the theft of protected passwords through attack vectors such as SQL Injection. Protected passwords can also be stolen from artifacts such as logs, dumps, and backups.

Specific guidance herein protects against stored credential theft but the bulk of guidance aims to prevent credential compromise. That is, this guidance helps designs resist revealing users’ credentials or allowing system access in the event threats steal protected credential information. For more information and a thorough treatment of this topic, refer to the Secure Password Storage Threat Model here [http://goo.gl/Spvzs http://goo.gl/Spvzs].

= Guidance =

== Do not limit the character set and set long max lengths for credentials ==

Some organizations restrict the 1) types of special characters and 2) length of credentials accepted by systems because of their inability to prevent SQL Injection, Cross-site scripting, command-injection and other forms of injection attacks. These restrictions, while well-intentioned, facilitate certain simple attacks such as brute force.

Do not allow short or no-length passwords and do not apply character set, or encoding restrictions on the entry or storage of credentials. Continue applying encoding, escaping, masking, outright omission, and other best practices to eliminate injection risks.

A reasonable long password length is 160. Very long password policies can lead to DOS in certain circumstances[http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/].

== Use a cryptographically strong credential-specific salt ==

A salt is fixed-length cryptographically-strong random value. Append credential data to the salt and use this as input to a protective function. Store the protected form appended to the salt as follows:

<code>[protected form] = [salt] + protect([protection func], [salt] + [credential]);</code>

Follow these practices to properly implement credential-specific salts:

* Generate a unique salt upon creation of each stored credential (not just per user or system wide);
* Use cryptographically-strong random [*3] data;
* As storage permits, use a 32bit or 64b salt (actual size dependent on protection function);
* Scheme security does not depend on hiding, splitting, or otherwise obscuring the salt.

Salts serve two purposes: 1) prevent the protected form from revealing two identical credentials and 2) augment entropy fed to protecting function without relying on credential complexity. The second aims to make pre-computed lookup attacks [*2] on an individual credential and time-based attacks on a population intractable.

== Impose infeasible verification on attacker ==

The function used to protect stored credentials should balance attacker and defender verification. The defender needs an acceptable response time for verification of users’ credentials during peak use. However, the time required to map <code><credential> → <protected form></code> must remain beyond threats’ hardware (GPU, FPGA) and technique (dictionary-based, brute force, etc) capabilities.

Two approaches facilitate this, each imperfectly.

=== Leverage an adaptive one-way function ===

Adaptive one-way functions compute a one-way (irreversible) transform. Each function allows configuration of ‘work factor’. Underlying mechanisms used to achieve irreversibility and govern work factors (such as time, space, and parallelism) vary between functions and remain unimportant to this discussion.

Select:

* PBKDF2 [*4] when FIPS certification or enterprise support on many platforms is required;
* scrypt [*5] where resisting any/all hardware accelerated attacks is necessary but support isn’t.
* bcrypt where PBKDF2 or scrypt support is not available.

Example protect() pseudo-code follows:

<code>return [salt] + pbkdf2([salt], [credential], c=10000); </code>

Designers select one-way adaptive functions to implement protect() because these functions can be configured to cost (linearly or exponentially) more than a hash function to execute. Defenders adjust work factor to keep pace with threats’ increasing hardware capabilities. Those implementing adaptive one-way functions must tune work factors so as to impede attackers while providing acceptable user experience and scale.

Additionally, adaptive one-way functions do not effectively prevent reversal of common dictionary-based credentials (users with password ‘password’) regardless of user population size or salt usage.

==== Work Factor ====

Since resources are normally considered limited, a common rule of thumb for tuning the work factor (or cost) is to make protect() run as slow as possible without affecting the users' experience and without increasing the need for extra hardware over budget. So, if the registration and authentication's cases accept protect() taking up to 1 second, you can tune the cost so that it takes 1 second to run on your hardware. This way, it shouldn't be so slow that your users become affected, but it should also affect the attackers' attempt as much as possible.

While there is a minimum number of iterations recommended to ensure data safety, this value changes every year as technology improves. An example of the iteration count chosen by a well known company is the 10,000 iterations Apple uses for its iTunes passwords (using PBKDF2)[http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf](PDF file). However, it is critical to understand that a single work factor does not fit all designs. Experimentation is important.[*6]

=== Leverage Keyed functions ===

Keyed functions, such as HMACs, compute a one-way (irreversible) transform using a private key and given input. For example, HMACs inherit properties of hash functions including their speed, allowing for near instant verification. Key size imposes infeasible size- and/or space- requirements on compromise--even for common credentials (aka password = ‘password’).
Designers protecting stored credentials with keyed functions:

* Use a single “site-wide” key;
* Protect this key as any private key using best practices;
* Store the key outside the credential store (aka: not in the database);
* Generate the key using cryptographically-strong pseudo-random data;
* Do not worry about output block size (i.e. SHA-256 vs. SHA-512).

Example protect() pseudo-code follows:

<code>return [salt] + HMAC-SHA-256([key], [salt] + [credential]); </code>

Upholding security improvement over (solely) salted schemes relies on proper key management.

== Design password storage assuming eventual compromise ==

The frequency and ease with which threats steal protected credentials demands “design for failure”. Having detected theft, a credential storage scheme must support continued operation by marking credential data compromised and engaging alternative credential validation workflows as follows:

# Protect the user’s account
## Invalidate authentication ‘shortcuts’ disallowing login without 2nd factors or secret questions.
## Disallow changes to user accounts such as editing secret questions and changing account multi-factor configuration settings.
# Load and use new protection scheme
## Load a new (stronger) protect(credential) function
## Include version information stored with form
## Set ‘tainted’/‘compromised’ bit until user resets credentials
## Rotate any keys and/or adjust protection function parameters (iter count)
## Increment scheme version number
# When user logs in:
## Validate credentials based on stored version (old or new); if old demand 2nd factor or secret answers
## Prompt user for credential change, apologize, & conduct out-of-band confirmation
## Convert stored credentials to new scheme as user successfully log in

= References=

* [1] Morris, R. Thompson, K., Password Security: A Case History, 04/03/1978, p4: http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps
* [2] Space-based (Lookup) attacks: Space-time Tradeoff: Hellman, M., Crypanalytic Time-Memory Trade-Off, Transactions of Information Theory, Vol. IT-26, No. 4, July, 1980 http://www-ee.stanford.edu/~hellman/publications/36.pdf Rainbow Tables -http://ophcrack.sourceforge.net/tables.php
* [3] For example: [http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html SecureRandom.html].
* [4] Kalski, B., PKCS #5: Password-Based Cryptography Specification Version 2.0, IETF RFC 2898, September, 2000, p9 http://www.ietf.org/rfc/rfc2898.txt
* [5] Percival, C., Stronger Key Derivation Via Sequential Memory-Hard Functions, BSDCan ‘09, May, 2009 http://www.tarsnap.com/scrypt/scrypt.pdf
* [6] For instance, one might set work factors targeting the following run times: (1) Password-generated session key - fraction of a second; (2) User credential - ~0.5 seconds; (3) Password-generated site (or other long-lived) key - potentially a second or more.

= Authors and Primary Editors =

John Steven - john.steven[at]owasp.org (author)<br/>
Jim Manico - jim[at]owasp.org (editor)

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]