Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > several years ago, we did a survey of corporate databases for security > issues ... one was a field by field analysis of types of information > and the vulnerability. for instance ... any information where we could > find a business process that made use of that information for > authentication ... was labeled as having an "id theft" > vulnerability. several business processes made use of knowledge about > date-of-birth for authentication purposes ... and therefore > date-of-birth was given an id-theft attribute (we made claims at the > time about being able to do semantic semantic analysis rather than > purely syntactic security analysis).
the semantic analysis was with regard to how could birth dates be used in various ways 1) authentication .... can you supply the matching value 2) grouping ... adult, child, senior citizen 3) current age ... say for life insurance in cases #2 & #3 we claimed that answers could be returned w/o returning the actual birth date. the problem is fundamental share-secret issues http://www.garlic.com/~lynn/subpubkey.html#secrets security guidelines tend to mandate that a unique shared-secret is required for every unique security domain. The vulnerability is somebody with the access to the shared-secret in one security domain can perform authentication impersonation fraud in another security domain (say your local neighborhood garage isp and your online banking operation). for some people this has led to them having to manage and administer scores of unique shared secrets. at the same time, it has been recognized that people have a hard time remembering even one or two such pieces of data ... so many infrastructures (for a long time) have used personal information as authentication shared-secrets (birth date, mother's maiden name, SSN#, place of birth, etc). this puts the infrastructures that expect people to manage and administer scores of unique shared secrets quite at odds with the infrastructures that recognize such a task is fundamentially out-of-synch with long years of human nature experiece ... and have chosen instead to use, easier to remember personal information for authenticatin shared-secrets. the problem with personal information authentication shared-secrets is that the same information tends to crop up in lots of different security domains. as a result, any personal information that might be used in any domain as personal information authentication shared-secret ... becomes identity theft vulnerable. we had been asked to come in and consult on something (that was going to be called e-commerce) with this small client/server company in menlo park that had this technology called ssl http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 amoung other things we eventually went around and did some end-to-end business walkthrus with this organizations called certification authorities about something called an ssl domain name certificate http://www.garlic.com/~lynn/subpubkey.html#sslcerts now they were leveraging this basic business processed called public keys. basically there is this cryptography stuff called asymmetric cryptography ... where keys used to decode stuff are different than the keys used to encode stuff. A business process is defined using this technology called public keys. Basically a business process defines one of a key-pair as being "public" and is freely available and the other of a key-pair is designated "private" and kept confidential and never divulged. The is an adjunct authentication business process called digital signature authentication .... where the private key is used to encode a hash of a message. The relying party can calaculate a hash of the same message and use the corresponding public key to decode the digital signature to come up with the originally calculated hash. If the two hashes are the same, it demonstrates that the message hasn't been altered and authenticates the originator. from three factor authentication http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are digital signature verification is a form of "something you have" authentication, demonstrating that the originator has access to and use of a specific private key. possibly somewhat because of early work on SSL and digital signatures, we were brought in to work on both the cal. and fed. digital signature legislation ... minor refs http://www.garlic.com/~lynn/aepay11.htm#61 HIPAA, privacy, identity theft http://www.garlic.com/~lynn/aepay12.htm#4 Confusing business process, payment, authentication and identification http://www.garlic.com/~lynn/aadsm17.htm#23 PKI International Consortium http://www.garlic.com/~lynn/aadsm17.htm#24 Privacy, personally identifiable information, identity theft http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda there were these other business operations interested that have been frequently referred to as trusted-third party certificate authorites (TTP CAs) which were interested in a business case that involves $100/annum certificate for every person in the US (basically $20b/annum revenue flow). Now possibly the most prevalent internet authentication platform is RADIUS ... used by majority of ISPs for authenticating client service. This was originally developed by Livingston for their modem pool processors (long ago and far away, I once was involved in putting together a real RADIUS installation on a real Livingston box). http://www.garlic.com/~lynn/subpubkey.html#radius a couple recent radius related postings http://www.garlic.com/~lynn/2005i.html#2 Certificate Services http://www.garlic.com/~lynn/2005i.html#3 General PKI Question http://www.garlic.com/~lynn/2005i.html#4 Authentication - Server Challenge http://www.garlic.com/~lynn/2005i.html#23 The Worth of Verisign's Brand http://www.garlic.com/~lynn/2005i.html#27 REPOST: Authentication, Authorization TO Firewall http://www.garlic.com/~lynn/2005i.html#28 REPOST: Authentication, Authorization TO Firewall RADIUS has since become an ietf standard and there are some number of freely available RADIUS implementations. The default RADIUS primarily used shared-secret based authentication. However, there are implementations that simply upgrade the registration of a shared-secret with the registration of a public key ... and perform digital signature verification ("something you have" authentication) instead of shared-secret matching. There are lots of infrastructures that it would be possible to preserve and leverage their existing relationship management and administrative infrastructures (handling both authentication and authorization information) by simply replacing shared-secret registration with public key registration. http://www.garlic.com/~lynn/subpubkey.html#certless However, there is lots of publicity about TTP CA-based PKI infrastructures, possibly because it has represented a $20b/annum revenue flow to the TTP-CA PKI industry. By comparison, upgrading an existing relationship administrative and management infrastructure represents a cost factor for relying party infrastructures (as opposed to the motivation of a $20b/annum revenue flow for the TTP CA-based PKI industry). In the case, of freely available RADIUS implementations there is little or no revenue flow involved to motivate stake-holders for widely deployed digital signature authentication (leveraging existing business practices and relationship management and administration infrastructures; other than it represents a big impact on harvesting of shared-secrets for the authentication fraud flavor of identity theft). The issue is especially significant for infrastructures that rely heavily on widely available shared-secret information as a means of authentication (in many cases common personal information). Another flavor is transactions-based operations where the authentication informaction is part of the transactions and therefor part of long-term transaction logs/files ... an example from security proportional to risk posting: http://www.garlic.com/~lynn/2001h.html#61 -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
