On 8 September 2010 16:45, <f...@mail.dnttm.ro> wrote: > > 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.
Well, you can't always get what you want. What I do in Nigori for this is use DSA. Your private key, x, is the hash of the login info. The server has g^x, from which it cannot recover x, and the client does DSA using x. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
