On 11/09/10 6:45 PM, f...@mail.dnttm.ro wrote:

Essentially, the highest risk we  have to tackle is the database. Somebody  
having access to the database, and by this to the authentication hashes against 
which login requests are verified, should not be able to authenticate as 
another user. Which means, I need an algorithm which should allow the 
generation of different hashes for which it can be verified that they stem from 
the same login info, without being able to infer this login info from a hash. 
This algorithm is the problem I haven't solved yet. Other than that, I see no 
way of protecting against a dictionary attack from somebody having direct 
access to the database.

I don't recall the full discussion, but what you described is generally handled by public key cryptography, and it is built into HTTPS.

Here's my suggestion:

1. In your initial account creation / login, trigger a creation of a client certificate in the browser.

1.b.  record the client cert as the authenticator in the database.

2. when someone connects, the application examines the cert used, and confirms the account indicated. If an unknown cert, transfer to a landing page. 2.b note that there is no login per se, each request can as easily check the client cert listed by Apache.

3. you just need some way to roll-over keys from time to time. Left for later.
3.b  There are some other bugs, but if the approximate scheme works...


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to