> But after rethinking maybe the original poster thought about
> a second login with a *valid* authentication. This would not
> be vulnerable to DoS attack.
That is correct - it has to do with simultaneous 'live' logins/sessions.
> Well, still I'd assume it's bad advice to close all sessions.
> A better approach would be to refuse the second login.
It is a question of context. There is no quick fix - universal solution.
The session handling mechanism must be tuned the both the applications
nature and the environments you expect users to use the applications from.
The security nuances between retail banking and investment banking online
services are just one instance of subtleties in session handling techniques
and simultaneous logins.
With regards to simultaneous logins - granted, you block another login
attempt. But the issue we are addressing at this stage are multiple
instances of the same login. This may be achieved through <CTRL>-N child
browser instances or through hijacking techniques.
In a nut shell, any session handling routine must be tuned to its unique
environment:
1. The sensitivity of the information available through the application.
2. The average technical level of the user (about a third of joe-public has
great trouble with using a mouse and drop-down boxes).
3. The likelihood that the application (or data it contains) would be
targeted.
4. The physical locations users will access the application from (internet
café - are you going to trust the hosts?).
5. The amount of time it would take to brute-force guess 'unique' session
information.
With regards to web-application authentication - I'd suggest that you review
an earlier paper of mine:
http://www.technicalinfo.net/papers/CustomHTMLAUthentication.html
Cheers,
Gunter
Received on Apr 01 2004
Intro
