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...
iang
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
