Password Generator

Hi,

I've just created a password generator beta, and would be interested in
getting feedback on it. It's JSP/Java-based, and can be found at
http://devhed.com/password-creator.

The "About" page has a quick survey on it for you to fill out.

Thanks,

Walter Gildersleeve
Freiburg, Germany

subscriptions@easypeas.net wrote:
> I've just created a password generator beta, and would be interested in
> getting feedback on it. It's JSP/Java-based, and can be found at
> http://devhed.com/password-creator.

A web based password creator cannot be used. Passwords must be generated
locally.

Yours,
VB.
--
If class libraries are compared to animals, MFC is the slime-warts toad.

Well, of course you can--what you mean is that it's an insecure method
to get passwords, cause:

1) you can't trust the source, and
2) the passwords are transmitted in plain text.

I can't do a thing about the first problem, which may in fact be the
bigger concern (for you, not for me ;->). I could post a letter from
my priest, mother, third-grade teacher and so forth, but maybe I forged
them. In any case, I hereby promise that I'm a nice guy.

I've been thinking of ways to solve the second aspect. My idea right
now is to have the client (ie, user's) computer generate a random
private/public key pair. It would transmit the public key to the
server, which would encrypt the passwords; the client computer could
then decode them and display them to the user.

My main problem is the specifics. I wanted to get away from using
plugins like Java or scripts like JavaScript, but I guess I'm stuck
with it. Probably I'll do this with an applet in the home page,
something like that.

Anyway, that'll make it into the release. We're only at beta stage
right now.

Walter

subscriptions@easypeas.net wrote:
> My idea right
> now is to have the client (ie, user's) computer generate a random
> private/public key pair. It would transmit the public key to the
> server, which would encrypt the passwords; the client computer could
> then decode them and display them to the user.

Why shouldn't the client computer generate the passwords itself?

Yours,
VB.
--
If class libraries are compared to animals, MFC is the slime-warts toad.

Perfectly acceptable, and there are plenty of stand-alone password
generators out there. I've made an online one, though. My reasons for
doing so are several:

1) people are always using the latest version
2) it's relatively large, as it's based on word libraries
3) I'm currently interested in server-side programming,
and undertook this for practise
4) i18n is more dynamic and complete

among others.

The reason for point two is described on the website, but briefly: the
service generates passwords using adjective/noun pairs, making them
easier to remember while remaining difficult to break. The libraries
together are comprised of over 40,000 words, and are several hundred
kbyte, making a web-start program a little large. Moreover, I'd like
to add the possibility for adverb/verb pairs (etc.), plus non-English
password creation, British English password creation, and so on.

In any case, this is currently an RFC beta. I may migrate it to
stand-alone in the end, or at least provide a stand-alone version, if
people are interested.

Walter

subscriptions@easypeas.net wrote:
> Perfectly acceptable, and there are plenty of stand-alone password
> generators out there. I've made an online one, though.

Yes. But the problem just is not solvable, that passwords have to be
generated locally, because secrets may not be stored or transmitted but
from the local terminal into the head of the user.

Or they're no secrets.

Yours,
VB.
--
If class libraries are compared to animals, MFC is the slime-warts toad.

subscriptions@easypeas.net wrote:
> Well, of course you can--what you mean is that it's an insecure method
> to get passwords, cause:
>
> 1) you can't trust the source, and
> 2) the passwords are transmitted in plain text.
>
> I can't do a thing about the first problem, which may in fact be the
> bigger concern (for you, not for me ;->).

> I've been thinking of ways to solve the second aspect. My idea right
> now is to have the client (ie, user's) computer generate a random
> private/public key pair. It would transmit the public key to the
> server, which would encrypt the passwords; the client computer could
> then decode them and display them to the user.
>
> My main problem is the specifics. I wanted to get away from using
> plugins like Java or scripts like JavaScript, but I guess I'm stuck
> with it. Probably I'll do this with an applet in the home page,
> something like that.

Not that the first concern should not be fatal, but...

The second concern is easily solved by TLS. That's what it's for, no?

Joachim

But you haven't said why--you cannot keep repeating the same precept
like a mantra, and expect others to accept it as truth.

Look: I transmit passwords (secrets, if you will) from my head
throughout the internet every day. Doing this does not make the
passwords invalid or insecure, assuming that the transaction is safe.
Safety is ensured not by the location of the password, but via
encryption, secure connections and the like. What percentage of your
passwords remain local to your computer?? 10%? 25%?

So again, *why* do you believe what you do? This conversation can only
be meaningful if you explain yourself better.

Yrs, Walter

subscriptions@easypeas.net wrote:
["don't generate passwords remotely"]
> So again, *why* do you believe what you do?

If I want to use a password, I don't want you, the owner of the
generator, to know it. I even don't want you to have the possibility
to know it, if you're wanting to know it or not.

This is, because a password is a secret. Only if this is not avoidable,
secrets are shared secrets. If it is avoidable, they have to be no
shared secrets at all. Most of the password implementations don't request
sharing a password at all BTW. Think about hashes, and why they're better.

But offering someone to know a password, who is not needing this at all,
is just a design flaw with secrets.

So a remote password generator for sure is just a design flaw.

Yours,
VB.
--
If class libraries are compared to animals, MFC is the slime-warts toad.

In the Usenet newsgroup comp.security.misc, in article
<1128758300.197463.114480@g49g2000cwa.googlegroups .com>,
subscriptions@easypeas.net wrote:

>Perfectly acceptable, and there are plenty of stand-alone password
>generators out there.

Yes, people are always trying to reinvent the wheel - usually poorly.
Have you run this past news://sci.crypt yet? READ before posting
there if you don't want to get flamed.

> 1) people are always using the latest version

which doesn't make it 'better' or 'worse'

> 2) it's relatively large, as it's based on word libraries

and as such would fail the common password checkers.

> 3) I'm currently interested in server-side programming,
> and undertook this for practise

which is why I suggested 'sci.crypt' - this comes up often enough.

>The reason for point two is described on the website, but briefly: the
>service generates passwords using adjective/noun pairs, making them
>easier to remember while remaining difficult to break.

And you have some numbers to back this up? Yes, paired words are
infinitely better than single words - but on a scale of 0 to 10,
you're still talking well below a "1".

>The libraries together are comprised of over 40,000 words, and are
>several hundred kbyte,

Last month in 'sci.crypt' - the thread is titled "All known english words".
The dictionaries that come with spell checkers, such as 'aspell'

960949 aspell-af 13618538 aspell-bg 507379 aspell-br
3767806 aspell-ca 22349143 aspell-cs 4085301 aspell-cy
7001683 aspell-da 5358607 aspell-de 7209764 aspell-el
1970041 aspell-en 7131153 aspell-es 1675829 aspell-fo
9583367 aspell-fr 3668008 aspell-ga 192957 aspell-gd
8149992 aspell-gl 2377111 aspell-hr 144516 aspell-id
1772364 aspell-is 12094145 aspell-it 3557813 aspell-nl
3941813 aspell-no 21507509 aspell-pl 5417579 aspell-pt
2008710 aspell-sv

(that's a compressed size BTW) are perhaps a bit more extensive. One of
the BSD adherent pointed out...

Welcome to web2 (Webster's Second International) all 234,936 words worth.

That's 'EN-US' by the way, and there are actually only 235,882 words in the
web2 file.. The URL is also in that thread on sci.crypt.

Oh, and if you are going to post to more that one newsgroup (I see another
copy of your "announcement" in alt.computer.security), learn to put all of
the newsgroup names (comma separated) in the single posting.

Old guy