Re: Access control on a commercial website.

Rik wrote:
On Sun, 05 Aug 2007 17:02:31 +0200, The Natural Philosopher <a@xxx> wrote:

Randy Webb wrote:

Everything on the client side is "utterly insecure". Security has to be managed on the server. Use Sessions and Timeouts and your chances increase.


Yes, but how?

Its all fine to use a password, but every new web page is a new session..

No, it shouldn't, it should be a continued session, identified by a suitable large random string that has got nothing to do with either the user, his location, his rights, or any other data.

how can I be sure it comes from a previously logged in person, not a random spoofer?

Because, on the server you have a list of sessions which _have_ identified themselves. In PHP, I thought the 'standard' id for a session was a string of 32 alphanumeric characters, which is somehere in the neighbourhood of 36^32 => 6.3e49 possible id's. How many id's of that do you actually expect to be logged in at any time? Chances someone magically guesses the id of a currently logged in user is very, very small. Brute force it may be possible to cycle through all id's untill you got something that works (keep in mind authenticated sessions time out, so they might be unlucky also).

Use HTTPS, a session-cookie, a suitable fast timeout, and some mechanism to prevent brute force attacks (count failed logins/random id's from an address and institute a time-out comes to mind).

OK, With Marcs link I had just about got there before I read your post.

You have confirmed the basic approach clearly tho, for which many thanks are due.



Session-hijacking is possible, but very rare (well, if you use HTTPS instead of HTTP). Ask a username/password again for any major alterations/highly classified material, and you'll be fine.

There is no '100%' security, but 99,999% is quite possible.

This has got nothing to do with javascript anymore BTW.


Nope. I suspected i wouldn't have anyway, but rightly, I suspected someone here would have the complete answer,so lets consider it case closed, many thanks issued to Marc and yourself, and back to the Mysteries of InnerHTML etc. etc.


.

Relevant Pages

  • Re: Access control on a commercial website.
    ... Use Sessions and Timeouts and your chances increase. ... Its all fine to use a password, but every new web page is a new session.. ... Chances someone magically guesses the id of a currently logged in user is very, ... Use HTTPS, a session-cookie, a suitable fast timeout, and some mechanism to prevent brute force attacks. ...
    (comp.lang.javascript)
  • Re: The weather has just f@cked Nadals Chances
    ... I hate weather! ... pm. Chances are there will be no issue completing the QFs today. ... session started on time. ...
    (rec.sport.tennis)
  • Re: pppd oopses current linus git tree on disconnect
    ... > The chances of this happening increase with the speed and ... > continued use of the serial port. ... Your original report showed ... > a lengthy PPP session. ...
    (Linux-Kernel)
  • Re: How PHP Session ID is proved to be unique?
    ... I've never used the PHP sessions. ... microtime, and PID, and then to spinlock until the microtime changes. ... You might very well find that the chances of accidentically creating the ...
    (comp.lang.php)
  • Re: Dropped session variables tied to SSL pages? Or Redirect?
    ... between HTTP and HTTPS for the same application path. ... > "Mark Schupp" wrote in message ... >> session cookie can only go to one application. ... >>> I also commented that some of the Session variables stayed intact. ...
    (microsoft.public.inetserver.asp.general)