Industry:DOJ Nondiscrimination on the Basis of Disability - Revision history

Afry at 23:47, 30 November 2010

2010-11-30T23:47:53Z

Afry at 23:46, 30 November 2010

2010-11-30T23:46:12Z

Afry: /* Submission Response */

2010-11-30T23:43:58Z

‎Submission Response

Afry: /* Final version */

2010-11-30T23:43:36Z

‎Final version

Afry at 23:29, 30 November 2010

2010-11-30T23:29:42Z

Afry: /* Final version */

2010-11-29T16:45:20Z

‎Final version

Afry: /* Draft Text version 2 */

2010-11-08T22:40:17Z

‎Draft Text version 2

Afry: /* Draft Text version 2 */

2010-11-08T22:38:32Z

‎Draft Text version 2

Afry: /* Draft Text version 2 */

2010-11-08T22:33:03Z

‎Draft Text version 2

Afry at 21:35, 8 November 2010

2010-11-08T21:35:48Z

@@ Line 35: / Line 35: @@
 * 12 Nov 2010 - Circulate to OWASP chapters and GIC mailing lists
 * 19 Nov 2010 - Prepare final version
-* 30 Nov 2010 - Submitted to regulations.gov; Comment Tracking Number: 80ba98d3
+* 30 Nov 2010 - Submitted to http://www.regulations.gov; Comment Tracking Number: 80ba98d3
   |-
   | style="width:25%; background:#7B8ABD" align="center"| '''Status'''

@@ Line 35: / Line 35: @@
 * 12 Nov 2010 - Circulate to OWASP chapters and GIC mailing lists
 * 19 Nov 2010 - Prepare final version
-* 30 Nov 2010 - Submit to DOJ
+* 30 Nov 2010 - Submitted to regulations.gov; Comment Tracking Number: 80ba98d3
   |-
   | style="width:25%; background:#7B8ABD" align="center"| '''Status'''
   | colspan="3" style="width:75%; background:#cccccc" align="left"|
-* In Progress
+* Completed
   |-
   | style="width:25%; background:#7B8ABD" align="center"| '''Resources'''

← Older revision		Revision as of 23:43, 30 November 2010
Line 54:		Line 54:
	\|}		\|}

−
−
−	~~== Submission Response ==~~
−
−	~~''Latest first''~~

← Older revision		Revision as of 23:43, 30 November 2010
Line 61:		Line 61:


−	=== ~~Final version~~ ===	+	=== Submission Response ===

	This response is submitted on behalf of the Open Web Application Security Project (OWASP) by the OWASP Global Industry Committee. OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a U.S. recognized 501(c)(3) not-for-profit charitable organization that ensures the ongoing availability and support for our work at OWASP.		This response is submitted on behalf of the Open Web Application Security Project (OWASP) by the OWASP Global Industry Committee. OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a U.S. recognized 501(c)(3) not-for-profit charitable organization that ensures the ongoing availability and support for our work at OWASP.

@@ Line 35: / Line 35: @@
 * 12 Nov 2010 - Circulate to OWASP chapters and GIC mailing lists
 * 19 Nov 2010 - Prepare final version
-* 22 Nov 2010 - Submit to DOJ
+* 30 Nov 2010 - Submit to DOJ
   |-
   | style="width:25%; background:#7B8ABD" align="center"| '''Status'''

@@ Line 63: / Line 63: @@
 === Final version ===
-''tbc''
+This response is submitted on behalf of the Open Web Application Security Project (OWASP) by the OWASP Global Industry Committee. OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a U.S. recognized 501(c)(3) not-for-profit charitable organization that ensures the ongoing availability and support for our work at OWASP.
 === Draft Text version 2 ===

@@ Line 98: / Line 98: @@
 Session Timeout
-One such standard is enforcing a session timeout.  Session tokens that do not expire on the HTTP server can allow an attacker unlimited time to guess or brute-force a valid authenticated session token.  If a user’s cookie file is captured or brute-forced, then an attacker can use these static session tokens to gain access to that user’s web account for that site.  OWASP recommends that idle session time out for highly protected web applications are set at 5 minutes and no more than 20 minutes for low risk applications.
+:One such standard is enforcing a session timeout.  Session tokens that do not expire on the HTTP server can allow an attacker unlimited time to guess or brute-force a valid authenticated session token.  If a user’s cookie file is captured or brute-forced, then an attacker can use these static session tokens to gain access to that user’s web account for that site.  OWASP recommends that idle session time out for highly protected web applications are set at 5 minutes and no more than 20 minutes for low risk applications.
 Passwords
-OWASP Recommends that website security policy for passwords include the following:
+:OWASP Recommends that website security policy for passwords include the following:
 :*Password change frequency
 :*Enforcement of a minimum password length
@@ Line 111: / Line 111: @@
 Strong Authentication
-Strong authentication (such as tokens, certificates, etc) provides a higher level of security than username and passwords. The generalized form of strong authentication is “something you know, something you hold”. Therefore, anything that requires a secret (the “something you know”) and authenticator like a token, USB fob, or certificate (the “something you hold”) is a stronger control than username and passwords (which is just “something you know”) or biometrics (“something you are”).
+:Strong authentication (such as tokens, certificates, etc) provides a higher level of security than username and passwords. The generalized form of strong authentication is “something you know, something you hold”. Therefore, anything that requires a secret (the “something you know”) and authenticator like a token, USB fob, or certificate (the “something you hold”) is a stronger control than username and passwords (which is just “something you know”) or biometrics (“something you are”).
 OWASP recommends strong authentication for certain applications:
@@ Line 120: / Line 120: @@
 CAPTCHA
-OWASP does not recommend the use of CAPTCHA. Instead OWASP recommends that Website owner provide another method to sign up or register for a website offline or via another method.  Site should use a “no follow” tag. Another option is to limit privileges of a newly signed up account or similar until a positive validation has occurred.
+:OWASP does not recommend the use of CAPTCHA. Instead OWASP recommends that Website owner provide another method to sign up or register for a website offline or via another method.  Site should use a “no follow” tag. Another option is to limit privileges of a newly signed up account or similar until a positive validation has occurred.
 ) Given that most websites today provide significant amounts of services and information in a dynamic, evolving setting that would be difficult, if not impossible, to replicate through alternative, accessible means, to what extent can accessible alternatives still be provided? Might viable accessible alternatives still exist for simple, non-dynamic Web sites?

@@ Line 70: / Line 70: @@
 This response is submitted on behalf of the Open Web Application Security Project (OWASP) by the OWASP Global Industry Committee. OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a U.S. recognized 501(c)(3) not-for-profit charitable organization that ensures the ongoing availability and support for our work at OWASP.
 OWASP has previously submitted responses to related standards and guidance:
-•	BS 8878:2009 Web accessibility. Building accessible experiences for disabled people DPC
+:*BS 8878:2009 Web accessibility. Building accessible experiences for disabled people DPC
-•	W3C Mobile Web Application Best Practices Working Draft and NIST documents such as NIST SP 800-37 (Rev 1), SP 800-53 (Rev 3), SP 800-122 and IR 7628.
+:*W3C Mobile Web Application Best Practices Working Draft and NIST documents such as NIST SP 800-37 (Rev 1), SP 800-53 (Rev 3), SP 800-122 and IR 7628.
 ) Should the Department adopt the WCAG 2.0s "Level AA Success Criteria" as it's standard for Web site accessibility for entities covered by Titles II and III of the ADA? Is there any reason why the Department should consider adopting another success criteria level of the WCAG 2.0?
 From a website security point of view, WCAG 2.0s "Level AA Success Criteria" is not inconsistent with having a secure website. Conformance levels A, AA and AAA all require additional considerations for security due to the use of:
-•	input, storage and output of additional text
+:*input, storage and output of additional text
-•	alternative forms of CATCHA
+:*alternative forms of CATCHA
-•	input, storage and output of additional files
+:*input, storage and output of additional files
-•	third-party services
+:*third-party services
-•	additional client-side scripting
+:*additional client-side scripting
-•	flexible session timeouts
+:*flexible session timeouts
-•	enforcing code validity
+:*enforcing code validity
 These can all be achieved using secure development practices, but the additional requirements increase complexity. There is one aspect in the more stringent "Level AAA Success Criteria" which would be difficult to achieve in a secure manner:
-•	re-authentication recovery
+:*re-authentication recovery
 Reference: "Can an accessible web application be secure? Assessment issues for security testers, developers and auditors", Colin Watson, OWASP AppSec Europe 2009, http://www.owasp.org/images/2/22/AppSecEU09_owasp_appsec_eu09_colin_watson_2.ppt
@@ Line 102: / Line 102: @@
 Passwords
 OWASP Recommends that website security policy for passwords include the following:
-•	Password change frequency
+:*Password change frequency
-•	Enforcement of a minimum password length
+:*Enforcement of a minimum password length
-•	No maximum password length limits
+:*No maximum password length limits
-•	Previous passwords should not be allowed to be chosen
+:*Previous passwords should not be allowed to be chosen
-•	Password lock out policy
+:*Password lock out policy
-•	Password complexity requirements
+:*Password complexity requirements
-•	Password lock out
+:*Password lock out
 Strong Authentication
@@ Line 114: / Line 114: @@
 OWASP recommends strong authentication for certain applications:
-•	for high value transactions
+:*for high value transactions
-•	where privacy is a strong or legally compelled consideration (such as health records, government records, etc)
+:*where privacy is a strong or legally compelled consideration (such as health records, government records, etc)
-•	where audit trails are legally mandated and require a strong association between a person and the audit trail, such as banking applications
+:*where audit trails are legally mandated and require a strong association between a person and the audit trail, such as banking applications
-•	administrative access for high value or high risk systems
+:*administrative access for high value or high risk systems
 CAPTCHA

@@ Line 32: / Line 32: @@
   | style="width:25%; background:#7B8ABD" align="center"| '''Deadlines'''
   | colspan="3" style="width:75%; background:#cccccc" align="left"|
-* 9 Nov 2010 - Complete first draft response
+* 9 Nov 2010 - Complete second draft response
 * 12 Nov 2010 - Circulate to OWASP chapters and GIC mailing lists
 * 19 Nov 2010 - Prepare final version