RE: Repost: Re: User authentication over the web (was: Secure Password in database)

From: Matt Block (blockdev@blockdev.net)
Date: 10/10/01


From: "Matt Block" <blockdev@blockdev.net>
To: "'Pavel Kankovsky'" <peak@argo.troja.mff.cuni.cz>
Subject: RE: Repost: Re: User authentication over the web (was: Secure Password in database)
Date: Wed, 10 Oct 2001 05:48:14 -0400
Message-ID: <008e01c15170$b4683600$6400000a@internal.home.blockdev.net>

Perhaps it wasn't clear that the session authentication token is a
cryptographic hash of the current datestamp and the current page (last
page requested). If two individuals make requests of the server,
the server refuses both:

    REAL USER SERVER ATTACKER
---------------------------------------------------------------------
1. sends login info ------ --------
2. ---------------- Sends back page and --------
                          token
3. sends next request, ------ sends request,
   including token including snooped token
4. ---------------- Cancels sessions and --------
                          returns an error

As long as the REAL USER is actively using his session, it becomes
very difficult for the ATTACKER to hijack the session. The only real
danger is if the ATTACKER hijacks the session while the REAL USER
is idling (having left the site altogether). If the site has an
aggressive logout procedure, this won't be a huge issue.

As you said, the ATTACKER has full access to the data passing back
and forth- this scheme doesn't attempt to address that at all. The
ATTACKER, however, is very limited in his ability to act as the
REAL USER.

  -- Matt

> -----Original Message-----
> From: Pavel Kankovsky [mailto:peak@argo.troja.mff.cuni.cz]
> Sent: Tuesday, October 02, 2001 1:52 PM
> To: Matt Block
> Cc: secprog@securityfocus.com
> Subject: RE: Repost: Re: User authentication over the web
> (was: Secure Password in database)
>
>
> On Tue, 25 Sep 2001, Matt Block wrote:
>
> > The goal of decent user authentication is, in part, to make session
> > hijacking difficult or impossible.
>
> How does the proposed scheme make session hijacking difficult or even
> impossible? The only real difficulty I see is the limited lifetime of
> cookies. The limit on IP address(es) allowed to use a cookie
> is not very
> efficient--when you can sniff the cookie sent by a client, you can
> probably create spoofed connections using the client's IP address as
> well.
>
> --Pavel Kankovsky aka Peak [ Boycott
> Microsoft--http://www.vcnet.com/bms ]
> "Resistance is futile. Open your source code and prepare for
> assimilation."
>
>



Relevant Pages

  • Re: Session Hijacking over HTTP
    ... yahoo.com protect their users from session hijacking when they use ... the server-side session. ... This way when an attacker hijacks the session he should also spoof ... Another nice thing to do is to alert the real user that there were ...
    (Pen-Test)
  • Re: Reality Check: Session Hijacking
    ... > authentication information in the session. ... Hijacking is independend of data contained in a session. ... > hidden form fields between each page, on forms that POST over https. ... Someone with a packet sniffer could ...
    (comp.lang.php)
  • Re: Cant seem to detect if session_id isset.
    ... if I can just get the basics to work. ... generating and isset script. ... figure out the right way for it to detect an existing session. ... hijacking" as if it's a common thing (e.g.: ...
    (comp.lang.php)
  • Re: Cant seem to detect if session_id isset.
    ... if I can just get the basics to work. ... figure out the right way for it to detect an existing session. ... Session hijacking is not the ... there is a LOT of garbage on the internet! ...
    (comp.lang.php)
  • Re: Cant seem to detect if session_id isset.
    ... if I can just get the basics to work. ... figure out the right way for it to detect an existing session. ... Session hijacking is not the problem some people make it out to be. ... You need to know enough to separate the garbage from the real security issues. ...
    (comp.lang.php)