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 



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 majord...@metzdowd.com

Reply via email to