Hashing algorithm needed

[flj at mail.dnttm.ro]

Hi.

So many answers, so little time to answer :-/

First, thanks to all who gave me an answer. I'll try to answer all posts I got on the subject in one large mail.

I may be a bit cheeky, for a new subscriber, so I apologize in advance. I think at least some of the answers I got are derailed in the direction of security. I'm in no way a security specialist, but I think we have done our homework regarding security, and architected the  app as good as it can be, given what browsers and app servers provide, what effort we can invest, what the security requirements are and what the security-related risks are. My initial post was aimed more specifically at one particular cryptographic problem we haven't solved yet. Nevertheless, I'll do my best in answering to security related comments too.

The app we develop is not an internet app, it's intended for intranet use. Users won't be taught to login by the app itself, but by their employer. Does this count towards diminishing the phishing risk?

The reason why a browser add-on/plugin is not a good solution for this app is that it has to require zero installation on the client side, other than a functional browser with JavaScript enabled.

"Little code" vs. "fast": right, my bad. Nevertheless, both are requirements. Small but slow code impacts performance, large but fast code decreases maintainability.

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.

Unsecured connection: I meant we don't want to secure the connection from the JavaScript running in the browser/the Java running on the server, not that we do not want to secure the connection at all. This is a concern/responsibility outside the scope of the app. The app will most probably be provided via https to the users in the intranet, and maybe over a VPN connection for external users. I can even think of customers running it over VPN on machines situated in the intranet. Does this clear up  things a bit, regarding connection security?

As such, in all other architectural decisions we assume the connection is secured. All requests over this secured connection are JSON-RPC requests, including the login request. The mechanism works like this: the initial request has to be a login request. It is the only which is responded to even if it does not contain an ID of an already authenticated session. The answer to this request is a session ID, which is almost all session info kept both on the server and the client. Any other request is simply discarded, if it does not contain an ID of an authenticated session. Should an attacker be able to obtain such a session ID, it would allow him to do requests on behalf of the user logged into this session only until the legitimate user explicitly logs out of the app, or the session times out, neither of which is much of a concern. However, given that we assume the connection to be secure, obtaining this session ID is theoretically impossible.

The main concerns in my app are two: the clear text password is never allowed to travel over the wire, be known to the server or written to a database, and the hash used for authentication should change from one session to the next one. Keeping the same hash in use for an entire session isn't that much of a concern, since it travels only once over the wire - to authenticate the session. In fact, the hash is not even kept alive, neither on  the client nor the server, once a session has been authenticated. In fact, even a changing hash from one session to another isn't that much of a requirement, I just somehow feel insecure if I think of a hash that's being reused - it's not much difference in my mind than sending the clear text password all the time, IMO - an attacker having access to the database could simply use the hash stored in the database to authenticate as another user, if I wasn't requiring a different hash than the one stored in the database.

As said, once the app is loaded in the browser, the only communication with the server happens via JSON-RPC, so in theory we could provide encryption from Javascript, to make the connection secure from within the app. However, some requests are maybe in excess of 10 MB. This works reasonably fast over intranet connections, but I doubt that encryption using PKI from within Javascript would be fast enough to encrypt/decrypt such requests. This is why we have to leave connetion security out of the Javascript & Java code, and use what browsers and app servers provide instead.

Right now, there's only one server. Essentially, unless using a distributed database, the app could be run off a cluster, however - all requests are stateless, there's no state info kept on the server aside from the authenticated session info. However, the hash sent by the client has  to be verified against a hash stored in the database, created when the user was first added to the system - also via the browser. So essentially any server being able to access the database would need to be able to verify the authentication hash.

Once again, thanks a lot to all who have taken time to help me out. I got quite a bit of information, and lots of things to study, mostly  stuff that's completely new to me. So it'll take a while until I can say something more about the issue. I'll report back, however, to tell you all what we finally did.

br,

flj

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