Difference between revisions of "Face base authentication proxy"
Infomaniac (talk | contribs) m (redundant redundancy) |
Infomaniac (talk | contribs) m (typo) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{stub}} [[category:Half-baked ideas]] | {{stub}} [[category:Half-baked ideas]] | ||
| − | I was reading the Google/Diaspora | + | I was reading the Google/Diaspora forum and came across [http://groups.google.com/group/diaspora-discuss/browse_thread/thread/e9fa0db196454a19 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 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. | ||
| Line 20: | Line 20: | ||
*the "face base"will have to be supplemented by another large database of faces from the public domain (using only faces submitted by users as a condition of membership gives only n*n possible combinations, where n is the number of registered users - even 10,000 users gives 100 million permutations, which probably isn't robust enough) | *the "face base"will have to be supplemented by another large database of faces from the public domain (using only faces submitted by users as a condition of membership gives only n*n possible combinations, where n is the number of registered users - even 10,000 users gives 100 million permutations, which probably isn't robust enough) | ||
*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 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 users own face shall not become part of his key; therefore if asked to submit his face to the database, it shall be done after the registration process. | |
| − | *the users own face shall not become part of his | ||
*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. | *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. | ||
| Line 28: | Line 27: | ||
*the user clicks on the face, returning imagemap coordinates | *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 | *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 | ||
| + | |||
| + | in either of the above, the feedback sent to the server has an infinitesimal possibility of being the same, twice. | ||
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 ''teach'' another person his login series - but why would he do that? | 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 ''teach'' another person his login series - but why would he do that? | ||
Latest revision as of 19:52, 16 October 2010
|
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.
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.
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 base"will have to be supplemented by another large database of faces from the public domain (using only faces submitted by users as a condition of membership gives only n*n possible combinations, where n is the number of registered users - even 10,000 users gives 100 million permutations, which probably isn't robust enough)
- 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 users own face shall not become part of his 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
in either of the above, the feedback sent to the server has an infinitesimal possibility of being the same, twice.
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 teach another person his login series - but why would he do that?
