You've gotten some great ideas so far in this thread. But really it is going to be next to impossible for an attacker to predict your session IDs-- especially if they are tied to another piece of information, like user ID.

There is no such thing as perfect security. What you have to do is manage risks in a meaningful way. In this case, you've automatically expired the IDs, they are (presumably) tied to a specific login, and you're checking to ensure that you are not issuing a duplicate.

The real question isn't "can an attacker figure out the next one"? The real question is, "can an attacker try all the possible keys in a useful amount of time?". If I can submit requests to your server with a valid login, and a "test" key fast enough, I might stumble upon one that is "open" (that is, in the valid list on the server) by sheer force.

The basic dictionary crack is still one of the biggest vulnerabilities in any online system because the attacker can automate the attack and do it at a distance. However, if the target moves faster (thanks again to automation) than I can execute my dictionary crack then the odds of getting a hit by chance are a lot worse. If you're looking to enhance security, either make the key a *lot* longer (maybe something like 256 random characters-- if it's in a cookie this really isn't going to create that much more overhead-- and still, to mess with predictability, I'd salt with the time() at authentication, since then you're not relying solely on the random number generator for unpredictability) or add a feature that disables a login when that login attempts more than X number of accesses with an invalid key.

FWIW, key length is the basic principle protecting things like PGP or other PKI schemes-- not that they've stumbled on some magical formula that makes numbers indecipherable to those who aren't supposed to look at them. The keys are huge (added: and yes, they interact in interesting ways to cause PKI, but it all comes down to key length). I've seen estimates are that it would take all of the computers currently on the planet working until the sun burns out to brute force crack some of the longer keys in use. Additionally they've thrown in the "secret passphrase", but that's mostly to make it harder to use a secret key even if it's compromised (that is, you've found my key-bearing floppy or CD, but unless you know my passphrase you still can't use my key), it doesn't make the keys more or less strong in the brute force arena.

In reply to (ichimunki) Re: Secure Session ID values by ichimunki
in thread Secure Session ID values by Hero Zzyzzx

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.