Secure Application Protocol Design

[gunnar at arctecgroup.net (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)"
<James.McGovern at thehartford.com> 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 at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php