Face base authentication proxy

From Organic Design wiki
Revision as of 00:12, 14 October 2010 by Infomaniac (talk | contribs) (Created page with '{{stub}} category:Half-baked ideas I was reading the [http://groups.google.com/group/diaspora-discuss/browse_thread/thread/e9fa0db196454a19 Google/Diaspora forum] and came a...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Cone.png This article or section is a stub. Stubs are articles that have not yet received substantial attention from the authors. They are short or insufficient pieces of information and require additions to further increase the article's usefulness. The project values stubs as useful first steps toward complete articles.

I was reading the Google/Diaspora forum and came across this discussion about why it's too hard to implement GPG e2ee in Diaspora, and was reminded of an old, half-baked idea I have put out in various places (but since, have forgotten where), so here goes again:

The essential problem with mass adoption of GPG is that there is no way to securely store the private key and that storing it on a USB thumb drive is also undesirable, as it can be lost and compromised. Furthermore, once a person has lost or forgotten his private key, there is no way to recover it, rendering data encrypted with it forevermore inaccessible.

The following idea would not work for the visually impaired, for reasons that shall soon be obvious.

It is well known that humans are able to remember a face after only one meeting, and recognize that face many years later without reinforcement. This ability to recognize a face - even of unknown persons - is the basis of a login proxy service that resides in the DHT space and stores an encrypted copy of login and authentication that cannot be retrieved unless the user is able to correctly identify a series of faces out of a large number of candidates.

Suppose, for example, upon registering for the proxy, one must undergo a fairly light training phase, where the user is introduced to a series of six faces, chosen randomly from a large database of nameless faces (possibly submitted by existing users as a condition of membership, and supplemented by another large database of faces from the public domain).

After the introduction, the faces are replayed with other faces that are not members of the user's login set, presented in a series of six, 6x6 matrices, until it is confidently demonstrated that the user has selected all six faces of his set without error. This set of six faces is indexed in such a way as to form a hash that can unlock the user's private login data after authentication. In each 6x6 matrix, only one of the faces is a member of his login set.

One 6x6 matrix consists of 36 possibilities, one of which is correct. Six matrices consists of 216 faces presented per login attempt, but the total number of possible combinations out of the database is astronomically large, making it possible to have a very robust key.

certain precautions are necessary to prevent analysis and exploitation of correct face selections:

  • the connection must be SSL
  • the face images should never be presented in the same binary form twice, that is, they should undergo various filters to modify the size, hue, bit and color resolution, etc.
  • the face images should be conjoined into one large image on the server side rather than sent individually. this is to make analysis more difficult.
  • the users own face shall not become part of his own key; therefore if asked to submit his face to the database, it shall be done after the registration process.
  • a feedback alert should be presented to identify bogus images (since there should be millions of them) and flag them for removal from the database, during the registration process.

there are two possible ways to send feedback to the authentication server:

  • the user clicks on the face, returning imagemap coordinates
  • the user selects by row and column labels of alphanumeric characters, using the keyboard. this method is preferable, since it is more difficult for someone standing over the user's shoulder to identify which faces are chosen

now we have a "password" that is nearly impossible to be forgotten and is impossible to write down or otherwise conveyed verbally. the only risk is for a user to actively teachanother person his login series - but why would he do that?