tipthepizzaguy has asked for the wisdom of the Perl Monks concerning the following question:

I'm wondering what you guys think about this idea and if it will be secure.

Once the user logs in, assign the user a random number that will go in the URL with the GET method. Create a small temp file that contains the username, random number, and user IP. When someone loads a page, check for user IP and random number, and compare with the file information. Overwrite the temp file with a new random number (and maybe new IP) every time the user logs in. (You could add a sign-out function that will delete the temp file.)

How secure will that method be?

Replies are listed 'Best First'.
Re: Is this a secure way to handle login?
by davis (Vicar) on Mar 27, 2002 at 10:03 UTC
    Hi,
    There are several problems with this method:
    • Many users live behind a proxy, sometimes multiple rotating proxies.
    • Assigning a random isn't necessarily a bad idea - as long as they aren't reused.
    • Passing a random number around a site using the GET method - you'd have to remember to do this everywhere.
    • It is possible to predict random numbers

    I'd recommend looking at some of the prebuilt (and already very round) methods for implementing sessions, such as CGI::Session, Apache::Session, and Apache::AuthCookie. (You are using apache, aren't you? :) ).
    Hope this helps
    davis
    Is this going out live?
    No, Homer, very few cartoons are broadcast live - it's a terrible strain on the animator's wrist
[reply]
      The solution proposed in the original post looks like regular session management to me, and you could probably implement it without running into any problems. I don't know why you need to log the IP, though.

      However, I second davis suggestion that you should go with a prebuilt module. Apache::Session totally rocks, and will let you store not only usernames and passwords, but any Storable object in you session variables. You have the choice of storing data in regular files, DB_File or several different databases, and the best part is that you don't need Apache; it will happily run under most web servers.

      Also, you don't have to bother with generating random numbers for session ID's, as Apache::Session will do all this for you.

      Cheers,
      --Moodster

[reply]
        The numbers generated by Apache::Session are not random enough to be considered truly secure. If you really don't want people to forge session IDs you should use some kind of hashing scheme to generate a digest that you send out with your session ID. Then you can use that to verify that the ID has not been tampered with. This technique has been described in other threads here about session handling.
[reply]

        Hello.

        The method described here is not the same as regular session management. In the regular session management, the session id stays still during the session. Here, it is supposed to change on every page load.

        Update: It seems I'm the one who misunderstood the method. However, I think my method (creating a new ID on every page load) would be a bit more secure.

        --
        Alper Ersoy

[reply]
Re: Is this a secure way to handle login?
by cjf (Parson) on Mar 27, 2002 at 10:09 UTC
[reply]
Re: §Is this a secure way to handle login?
by o(o_o)o (Scribe) on Mar 27, 2002 at 16:27 UTC

    one way you can get round the predict random numbers thing, is to:

  • Create a dictionary file of words, or use a portion of /usr/dict/words.
  • Create a random number however you wish
  • use the random number to index a word in the dictionary file
  • perform a hash function on the word
  • use that hash as the ID

    i think what would be alright, as long as you log all the currently "in use" hashes, then the hash can't be predicted even if someone predicts the random number used, because they don't know what dictionary file you use(because you havn't used a predictable part of the file eg. the first thousand), and also what hash function.

    well.. i think that'd work

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    i would slit my wrists for you
[reply]
      One non-obvious addition. Don't use /usr/dict/words verbatim. Apache and most other web servers will announce what they are and what os they're on. With that piece of info, someone could find the same version of /usr/dict/words that you have and only have to guess your initial random number and hash function (because you'd probably be using one of the standard ones) to replicate your hash. Use a randomized version of /usr/dict/words. That way you have two random elements in play.

      /\/\averick
      perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

[reply]

      Just wondering, have you ever tried to implement this on a system which is hit a lot? To first view it looks as if it'd scale very badly, especially if the /usr/dict/words/or/whatever is read in and parsed on a per-request basis.

      I suspect the MD5 hash method would probably be easier and scale better?

[reply]
Re: Is this a secure way to handle login?
by kodo (Hermit) on Mar 27, 2002 at 15:49 UTC
    Well I would say it depens on where you want to use it. If it's in your company for example and people have no dynamic IPs it would be a good thing I think. I've done the same thing already and just did a module which is called by every Website and then check's ID etc. But I would suggest you to use a "LOGOUT" Function so that noone else can use that one for sure any more. But if it's for a website out there somewhere, use Apache::Session; is a really good idea for the reasons the others already mentioned. But nothing is "really" secure...you know that :)
[reply]
Re: Is this a secure way to handle login?
by ehdonhon (Curate) on Mar 27, 2002 at 18:13 UTC

    Depends on how secure you need it to be.

    Any person that is able to sniff the get query (to obtain the session id) and can spoof the IP of the the machine that made the original query would be able to circumvent your security.

[reply]
      I know a hacker can sniff the session ID from the URL, so that's the reason for a random number. I don't see how they can spoof the user IP. That comes from the environment variable. Both are needed for security. There will be a new random number assigned the next time the same user logs in. It will also record a new user IP (some users have dynamic IPs.)
[reply]
        Now I'm wondering if I the session ID# is redundant. Why not just save the user IP (environment variable) to a temp file when they login? Compare that to the user IP (environment variable) upon page load.
[reply]

        It is possible to spoof an IP address, do a websearch for 'IP spoofing' and you'll find a fair few pages about it.. you may not know how to do it, but intruders sure do. You can't trust anything you receive, so it's often a good idea to make sure anything you want to be truly secure is protected by a HTTPS layer.

        Without HTTPS assume anything that's sent can be intercepted, and anything incoming can be forged.

        Don't forget also that one user may have multiple sessions running concurrently, or use 'Open In New Window/New Tab' to 'split' the user path, thus limiting the usefulness of changing numbers on a per-request basis.

        This is a significantly non-trivial task, using a prebuilt is generally far, far easier.. especially if your own security knowledge is limited.
[reply]

Back to Seekers of Perl Wisdom