Re: Authentication

Richard Lynch wrote:

Another thing some people use to strengthen their security model is to involve some sort of sequence number in the data that the client sends back. For example, instead of just a session ID, perhaps you have a cookie, URL variable, or whatever that is an encrypted (two-way so you can decrypt it) session ID, sequence number, and anything else you might think of to include. When you decrypt this at the beginning of each script, you make sure the sequence number is not less than the last sequence number sent (which you store on the server),

Unfortunately, that will break the "Back" button :-(

True, we must allow users to step back in sequence (well almost always). Besides, altough I hate this, some sites do work on more than a window at the very same time. This would kill them. I would say that: 1) Sequence control must be disabled when your site does

     not need it. Basically, it should be used only once a customer
     has identified himself with a password and is perfoming
     sequential operations (like CC data input etc). Why should we
     sequencially check track an harmless menu browsing?

2) Sequence control on logged in users disabling MUST be

     possible by a simple change of configuration, never hardwire in
     such risky things. You know, everything happens in life...

3) Log your requests to db, so that you can always fully retrace a

     session and debug the accessibility problem.

Now, suppose you stepped up security level in your code deliberately because you are in a risky context and your security manager gets an out-of-sequence request (no matter how the sequence is determined): 1) remember that this might happen also because of:

       a) the back button (and sometimes you will need to break it
          when treating dangerous sequential form input, but some
          other times there will be no need to limit user freedom)
          Your routine should check this and return you a signal
          about the user stepping back, not just splash out a "U
          F*ing hacker! I got my kalashnikov loaded and I'm
          a-coming to getcha at your IP:port right now!" page.
       b) a legal link executed on a second window/tab/browser by
          the very same legal user. This also may be checked and
          treated by your routine. There are different ways to do
          it. They all imply some risk, as IPs float, jscript might
          not work and cookies may be disabled. They are all exposed
          to a presentation attack.
       c) any future change in technology that will allow multiple
          link request and make your code unusable to normal users.

2) remember that in almost 100% of cases you will be talking

      not to a malicious hacker, but to a computer illiterate user
      which needs explanations like "Doing this would end up in
      having your CC double charged, at www.somesite.com we protect
      our customers! do that in instead: link here"

3) have yourself mailed by the software on your OWN mailbox. The

      amount of user problems should affect you very directly.
      Make sure you understand what security implications are in
      terms of your customers access to site. This mail should
      report all details of user's actions (better the full session
      history), for you to be able to understand what exactly leads
      normal users to the wrong path.

4) Have your site TESTED before releasing it to public. And have

      it tested by people that do not understand what the internet
      is. 10 such testers may tell you more on your site bugs than
      6 months of full-time internal testing. Get yourself 10
      unemployed people and pay them some bucks for them to play
      with your site for a few hours. You'll spend cents and save
      thousands in terms of code testing.

Otherwise, you'll spend hours setting this up, then hours more ripping it out, once the boss starts hearing from their mother-in-law that they can't use the site.

ROTFL!!! Now that's pure gold :)) Alberto Kiev -- @-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@ LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu? lOrD i'M sHiNiNg... YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE tHe TeSt, YeS iT iS ThE tEsT, yEs It Is tHe TeSt, YeS iT iS ThE tEsT, yEs It Is.......