in reply to Is this a secure way to handle login?

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
    • Comment on Re: §Is this a secure way to handle login?
  • Replies are listed 'Best First'.
    Re: Re: §Is this a secure way to handle login?
    by maverick (Curate) on Mar 27, 2002 at 16:58 UTC
      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');"

    Re: Re: §Is this a secure way to handle login?
    by Molt (Chaplain) on Apr 11, 2002 at 13:14 UTC

      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?