Split passwords

From: aruck (are_at_stable.form)
Date: 06/29/05

  • Next message: Jean-Luc Cooke: "Re: Split passwords" 
    Date: Wed, 29 Jun 2005 11:50:12 -0400

    An idea that I've been batting around...

    User enters a password. It can be long or short, weak or strong,
    whatever the user wants. As the user types, random numbers are
    collected. The program then combines the random numbers with the
    password, hashes that, and displays the hash values as base 36 numbers
    (so it looks like one long string of letters and numbers). The user can
    then cut-n-paste the string into the "password" field of another
    program.

    The program would obviously need to save the random numbers to a file
    that the user must secure in a safe or something (since the same random
    numbers would be needed to regenerate the same string).

    The end result is a long, random "password" based partly on what the
    user entered and partly on a string of random bytes.

    PROS

    (a) The string will be random and possibly quite long. A SHA256 result
    would yield a string of around 50 characters. A long, random password
    is very strong.

    (b) The user can choose a short, weak password and it won't adversely
    affect security in a measurably significant way.

    (c) If the user's password is leaked, then the user's data will remain
    secure as long as the file of random data remains secure. This guards
    against users who write down their passwords, and affords some
    protection against being forced to reveal a password.

    CONS

    (a) User has to run a little program to get the string. Clearly, the
    user cannot use this method for a login password.

    (b) User must protect the random data. This means keeping it on a
    floppy or USB drive, stored in a safe place. It also means wiping (not
    just deleting) extra copies.

    (c) User must remember which data file is associated with which
    password.

    (d) The string must be displayed on screen, where others may see it.

    (e) The string exists in RAM until the program ends and the user clears
    the screen. The OS might swap out that part of RAM and inadvertently
    record the string on disk. An OS with bad security might permit another
    process to read the program's memory space.

    (f) User will probably have to cut-n-paste the string, since it may be
    too long and complex to type accurately. Some programs may not permit a
    user to paste a string into a password field.

  • Next message: Jean-Luc Cooke: "Re: Split passwords"

    Relevant Pages

    • Re: New form of recursive compression tested and proven. Now how do I market it?
      ... >> Tom, my claim is that I can recursively reduce random data. ... > bit can only represent half as many values as a 2-bit string. ... > So now that I've disproven that ANY FORM of random data compressor is ...
      (comp.compression)
    • Re: Split passwords
      ... Generate a passkey and save to a file. ... > (so it looks like one long string of letters and numbers). ... > secure as long as the file of random data remains secure. ... An OS with bad security might permit another ...
      (sci.crypt)
    • Re: Fastest way to search a string for the occurance of a word??
      ... Performing thousands of tests over random data, ... You may have read somewhere that quicksort has Operformance in the ... > fairly early in the string, which is where String.IndexOf does better. ... > checking that this really is the performance bottleneck, ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: New form of recursive compression tested and proven. Now how do I market it?
      ... bit can only represent half as many values as a 2-bit string. ... I'm beginning to believe that there is no such thing as Random Data. ... that simply emits all 1024-bit integers will need to have at least ... determine the output which means you either can't compress all N-bit ...
      (comp.compression)
    • Re: [Full-disclosure] URI handling woes in Acrobat Reader, Netscape, Miranda, Skype
      ... probably a content-type/file association/command string handling problem. ... padding and added IO checking of a very secure app. ... secure programming language or framework. ... hyperventalating over the security of your own code will ever make it ...
      (Full-Disclosure)