Hashing algorithm needed

flj at mail.dnttm.ro flj at mail.dnttm.ro
Wed Sep 8 11:45:26 EDT 2010


Hi.

Just subscribed to this list for posting a specific question. I hope the question I'll ask is in place here.

We do a web app with an Ajax-based client. Anybody can download the client and open the app, only, the first thing the app does is ask for login.

The login doesn't happen using form submission, nor does it happen via a known, standard http mechanism.

What we do is ask the user for some login information, build a hash out of it, then send it to the server and have it verified. If it checks out, a session ID is generated and returned to the client. Afterwards, only requests accompanied by this session ID are answered by the server.

Right now, the hash sent by the browser to the server is actually not a hash, but the unhashed login info. This has to be changed, of course.

What we need is a hashing algorithm that:
- should not generate the same hash every time - i.e. should includen something random elements
- should require little code to generate
- should allow verification of whether two hashes stem from the same login data, without having access to the actual login data

We need to implement the hashing algorithm in Javascript and the verification algorithm in Java, and it needs to execute reasonably fast, that's why it has to require little code. None of us is really into cryptography, so the best thing we could think of was asking for advice from people who grok the domain.

The idea is the following: we don't want to secure the connection, we just want to prevent unauthenticated/unauthorized requests. Therefore, we only send a hash over the wire and store it in the database when the user changes his password, and only send different hashes when the user authenticates later on. On the server, we just verify that the stored hash and the received hash match, when an authentication request arrives. Cleartext passwords aren't stored anyway, and don't ever travel over the wire.

However, we could not imagine a reasonable algorithm for what we need until now, and didn't find anything prefabricated on the web. Therefore we ask for help.

br,

flj

PS: reusing the session ID is of course a security risk, since it could allow session hijacking. We're aware of this, but don't intend to do anything about it other than warn customers/users. Since it's a web application, its client code is open, and anybody being able to watch the connection can deduce whatever is needed to hijack the session, no matter what algorithm is used, unless the connection is encrypted right from the start. Connection security is however outside the scope of the web application. We can't encrypt communication in Javascript for efficiency reasons, it has to be done in a lower layer (VPN or SSL, for example). It may in theory work using a preshared key, but it's not reasonable to believe that the application users will be able to cope with such a mechanism.

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



More information about the cryptography mailing list