Re: [SC-L] Secure Application Protocol Design

2006-06-06 Thread Gunnar Peterson
"There is a well understood best practice in software development that
developers should not attempt to write their own cryptographic algorithms
because of the complexity, lack of peer review, and value of that which the
cryptographic functions are protecting. Developers, in contrast, routinely
write one-off identity solutions that are never peer reviewed by a wider
audience. This identity information is propagated and integrated throughout
software systems and used as a basis for making security decisions about
access control to critical resources and the confidentiality of personal and
business data."
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/assemb
ly/207.html?branch=1&language=1

Even if the crypto is implemented correctly, there are usually problems in
the identity implementation which is the basis for access control decisions,
anyhow. So developers should not write that either.

-gp


On 6/5/06 1:20 PM, "McGovern, James F (HTSC, IT)"
<[EMAIL PROTECTED]> wrote:

> Would love to see Gary address a couple of behaviors I have seen in my travel
> amongst architect types in corporate America especially the practice of secure
> application protocol design that isn't so secure. Is anyone writing/blogging
> deeply on this aspect?
> 
> Likewise, there are many folks in corporate America that have not yet
> acknowledged that they shouldn't be playing part-time cryptographer and don't
> have the competency to design cryptographic primitives such as hash functions
> and algorithms to protect data. Does anyone know of any "friendly" articles
> that speak to this problem space?
> 
> 
> *
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *
> 
> 
> ___
> Secure Coding mailing list (SC-L)
> SC-L@securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php


___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


[SC-L] Secure Application Protocol Design

2006-06-06 Thread McGovern, James F (HTSC, IT)
Would love to see Gary address a couple of behaviors I have seen in my travel 
amongst architect types in corporate America especially the practice of secure 
application protocol design that isn't so secure. Is anyone writing/blogging 
deeply on this aspect?

Likewise, there are many folks in corporate America that have not yet 
acknowledged that they shouldn't be playing part-time cryptographer and don't 
have the competency to design cryptographic primitives such as hash functions 
and algorithms to protect data. Does anyone know of any "friendly" articles 
that speak to this problem space?


*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*


___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php