Hashing algorithm needed

[Ian G]

On 11/09/10 6:45 PM, flj at 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...



iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com