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 

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 

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 

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.



The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to