Generating 'reasonably secure' printable passwords - Linux

This is a discussion on Generating 'reasonably secure' printable passwords - Linux ; A Weird Web-Interface[tm] I (among other things) occasionally work on needs to generate user access passwords. These passwords must be printable but 'easy to remember' is not a requirement. I am presently using the (PHP-)routine below to generate them. 1) ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Generating 'reasonably secure' printable passwords

  1. Generating 'reasonably secure' printable passwords

    A Weird Web-Interface[tm] I (among other things) occasionally
    work on needs to generate user access passwords. These passwords must
    be printable but 'easy to remember' is not a requirement. I am
    presently using the (PHP-)routine below to generate them.

    1) Using /dev/random is not an option because the code must
    not block for an indeterminate time.

    2) Error checking is purposely (not yet) implemented.

    3) CHARS is a string of 64 different, printable characters.

    4) I know that 'reading only as much data as actually used'
    is somewhat of a mannerism.

    function generate_passwd()
    {
    $urandom = fopen('/dev/urandom', 'r');
    $in = fread($urandom, 6);
    fclose($urandom);

    $rem_shift = 6;
    foreach (unpack('C*', $in) as $byte) {
    $remain |= ($byte & 0xc0) >> $rem_shift;
    $rem_shift -= 2;

    $out .= substr(CHARS, $byte & 0x3f, 1);

    if (!$rem_shift) {
    $out .= substr(CHARS, $remain, 1);

    $remain = 0;
    $rem_shift = 6;
    }
    }

    return $out;
    }

    Suggestions or comments?

  2. Re: Generating 'reasonably secure' printable passwords

    > needs to generate user access passwords. These passwords must
    > be printable but 'easy to remember' is not a requirement.


    > 1) Using /dev/random is not an option because the code must
    > not block for an indeterminate time.


    head -c 8 < /dev/urandom | mimencode

    /dev/urandom does not block. It uses a pseudo-random generator
    to fulfill the output if /dev/random does not have enough entropy.

    --

  3. Re: Generating 'reasonably secure' printable passwords

    Rainer Weikusat writes:
    > Suggestions or comments?


    PASSWORD=`head -c 8 /dev/urandom | tr '\0-\377' 'a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9@@@@####'`
    --
    John Hasler
    john@dhh.gt.org
    Dancing Horse Hill
    Elmwood, WI USA

  4. Re: Generating 'reasonably secure' printable passwords

    On Tue, 06 May 2008 12:57:03 -0500, John Hasler wrote:

    > Rainer Weikusat writes:
    >> Suggestions or comments?

    >
    > PASSWORD=`head -c 8 /dev/urandom | tr '\0-\377'
    > 'a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9@@@@####'`


    Thanks!



    --
    Tayo'y Mga Pinoy

  5. Re: Generating 'reasonably secure' printable passwords

    Baho Utot writes:

    > On Tue, 06 May 2008 12:57:03 -0500, John Hasler wrote:
    >
    >> Rainer Weikusat writes:
    >>> Suggestions or comments?

    >>
    >> PASSWORD=`head -c 8 /dev/urandom | tr '\0-\377'
    >> 'a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9@@@@####'`

    >
    > Thanks!


    Note that while his scheme is really nice, it could be better if
    you're looking at sites that can handle *all* printable characters
    (including spaces and punctuation). That would be a trivial mod to
    his tr line.


  6. Re: Generating 'reasonably secure' printable passwords

    John Reiser writes:
    >> needs to generate user access passwords. These passwords must
    >> be printable but 'easy to remember' is not a requirement.

    >
    >> 1) Using /dev/random is not an option because the code must
    >> not block for an indeterminate time.

    >
    > head -c 8 < /dev/urandom | mimencode
    >
    > /dev/urandom does not block. It uses a pseudo-random generator
    > to fulfill the output if /dev/random does not have enough entropy.


    I am not exactly certain what this posting is supposed to communicate.
    I was using /dev/urandom in the code I posted for precisely the reason
    you stated above. All of the other code is PHP, so the password
    generation routine should be PHP, too, although a shell pipeline could
    technically be integrated into it. The pipeline has a 13 character
    output and I need eight. It always (determined by testing, I haven't
    looked into the BASE64 definition) contains a trailing equal
    sign. While I could live with potentially wasting 16 random
    bits, I need them for other things, too (that warrant use of
    /dev/random itself), so I would rather avoid it. Lastly, the letter O
    should be avoided because it is too easily confused with 0 and the
    underscore because it is a SQL wildcard (same goes for %, but that
    isn't in the BASE64 alphabet). As a shell pipeline, this could be

    head -c 6
    starting no less than four processes to avoid a 23-line (text)
    subroutine. (and copying all of the data through the kernel five
    times).

    What I would have been looking forward to would have been either
    something regarding the actual algorithm I implemented or the
    PHP-implementation itself. I use this language only now and then and I
    am therefore not entirely confident in my ability to avoid 'obviously
    stupid' use of it (eg the string concatenation implementation could be
    'known' to be very expensive and the same could be true for using
    substr to extract single characters from a string).

  7. Re: Generating 'reasonably secure' printable passwords

    Joe Pfeiffer writes:
    > Baho Utot writes:
    >> On Tue, 06 May 2008 12:57:03 -0500, John Hasler wrote:
    >>
    >>> Rainer Weikusat writes:
    >>>> Suggestions or comments?
    >>>
    >>> PASSWORD=`head -c 8 /dev/urandom | tr '\0-\377'
    >>> 'a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9@@@@####'`

    >>
    >> Thanks!

    >
    > Note that while his scheme is really nice, it could be better if
    > you're looking at sites that can handle *all* printable characters
    > (including spaces and punctuation). That would be a trivial mod to
    > his tr line.


    This would mean less than one bit of additional entropy in the
    generated password at the expense of massively complicating all code
    which may need to parse lines of text containing passwords and other
    data items. It would be impossible to write such a password down in a
    way which cannot be easily misread (How much space is 'a space'
    exactly, as opposed to variance in inter-character spacing?). Using
    this for any existing codebase without a detailed audit would at best
    be 'risky'. Depending on the people who added to it in the past and
    the people who may add to it in future(!), 'asking for trouble' or 'sheer
    lunacy' could be two appropriate descriptions, too.

  8. Re: Generating 'reasonably secure' printable passwords

    Bernhard Agthe writes:
    > you could also fill a buffer of bytes with input from /dev/random in the
    > background and use that for your application, but how do you guarantee
    > there's always enough in the buffer?
    >
    >> underscore because it is a SQL wildcard (same goes for %, but that

    >
    > You do a md5hash on the password before importing it into SQL and the
    > user entered password before comparing it with the saved hash. This way
    > *all* wildcards or other SQL code gets removed...
    >
    >> What I would have been looking forward to would have been either
    >> something regarding the actual algorithm I implemented or the
    >> PHP-implementation itself. I use this language only now and then and I

    >
    > In PHP you can easily execute some shell pipe like given here, so you
    > got the actual code as PHP-usable line. You don't have to learn a
    > different language or other? If you worry about performance, see above
    > (fill a buffer in the background), if you worry about security, use
    > md5hash, if you worry about the implementation, the actual code is given
    > in this thread?


    By me. Twice.


  9. Re: Generating 'reasonably secure' printable passwords

    Hi,

    >> /dev/urandom does not block. It uses a pseudo-random generator


    you could also fill a buffer of bytes with input from /dev/random in the
    background and use that for your application, but how do you guarantee
    there's always enough in the buffer?

    > underscore because it is a SQL wildcard (same goes for %, but that


    You do a md5hash on the password before importing it into SQL and the
    user entered password before comparing it with the saved hash. This way
    *all* wildcards or other SQL code gets removed...

    > What I would have been looking forward to would have been either
    > something regarding the actual algorithm I implemented or the
    > PHP-implementation itself. I use this language only now and then and I


    In PHP you can easily execute some shell pipe like given here, so you
    got the actual code as PHP-usable line. You don't have to learn a
    different language or other? If you worry about performance, see above
    (fill a buffer in the background), if you worry about security, use
    md5hash, if you worry about the implementation, the actual code is given
    in this thread?

    Good luck ;-)


  10. Re: Generating 'reasonably secure' printable passwords

    On Tue, 06 May 2008 21:44:50 -0600, Joe Pfeiffer wrote:

    > Baho Utot writes:
    >
    >> On Tue, 06 May 2008 12:57:03 -0500, John Hasler wrote:
    >>
    >>> Rainer Weikusat writes:
    >>>> Suggestions or comments?
    >>>
    >>> PASSWORD=`head -c 8 /dev/urandom | tr '\0-\377'
    >>> 'a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9a-zA-Z0-9@@@@####'`

    >>
    >> Thanks!

    >
    > Note that while his scheme is really nice, it could be better if you're
    > looking at sites that can handle *all* printable characters (including
    > spaces and punctuation). That would be a trivial mod to his tr line.


    Even so I do very much like his solution. Easy and elegant.

    --
    Tayo'y Mga Pinoy

  11. Re: Generating 'reasonably secure' printable passwords

    Baho Utot writes:
    >>
    >> Note that while his scheme is really nice, it could be better if you're
    >> looking at sites that can handle *all* printable characters (including
    >> spaces and punctuation). That would be a trivial mod to his tr line.

    >
    > Even so I do very much like his solution. Easy and elegant.


    Oh, I wasn't suggesting otherwise, just mentioning a possible
    enhancement (and he responded with some good points about being *sure*
    the system could really handle extra characters).

+ Reply to Thread