Re: Split passwords

From: aruck (ruck_at_are.field)
Date: 06/29/05 

Date: Wed, 29 Jun 2005 16:58:51 -0400

In article <1120064001.547706.197000@f14g2000cwb.googlegroups.com>,
jh113355@hotmail.com says...
>
>
> aruck wrote:
> > 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.
> >
>
> So, help me understand this. I enter a password and you generate some
> random numbers. You combine my password with your random numbers,
> convert to ASCII characters, and display the result so I can cut it
> into the clipboard (or write it down).
>
> (Example: You generate a string of random numbers and HMAC the string
> using the password I gave you to produce the "real password").
>
> So far, I have a big secure password. At this point, two usability
> problems come to mind, both of which adversely impact security.
>
> (1) Once I cut it into the clipboard, I have to be sure it gets erased.
>
>
> (2) I have to write it down, which defeats the security afforded by
> keeping the two parts separate. If I don't write it down, I have to
> find some removeable medium on which to write the random number and
> there are an increasing number of systems out there that don't permit
> access to removable media. Worse, in my case, that medium might have
> to be readable by 5 different O/S's. Also, if I don't write it down,
> your regenerator program has to run on every O/S where I might need to
> use the password.

The biggest problem that I don't know how to solve, yet, is that the
user can write down the string or copy it to a text file. Those
activities pretty much defeat the whole point of the scheme.

The program can be written in C, with conditionals to make it compile on
most any OS you want. The trick will be making sure the program
interprets data correctly; e.g., sometimes integers are 16 bits long,
sometimes they are 32 bits long, and the program would have to make
appropriate adjustments. Other issues arise with regard to how the OS
handles raw terminal or console I/O, and what functions are available
for reading the system clock in increments of thousandths (or smaller)
of a second. But that's really just a programming exercise.

I hadn't thought of the lack of removable media. Most computers have a
floppy drive or support those little USB drives, but they are only
accessible if you have physical access to the system. The only thing I
can think of is to have the program automatically encrypt the data file
so that it can be stored on a hard drive or in NVRAM or whatever the
system provides for file storage.

> It's not a bad idea. There are a lot of things to like about it. I
> have some doubts about its practical usability. Maybe with a little
> more development ... ;-)

I have a little prototype that technically works with the few Windows
programs I tried it with. It's not exactly convenient, and it doesn't
address the issues raised above, and it's only secure if I follow a
strict set of procedural rules (like not copying the string to the
clipboard, and keeping the USB drive in an office safe).

I have a feeling that I'm going to be the only one using this scheme, at
least in the near future, and then only for times when it's practical
and I think it's necessary.

Relevant Pages