"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
