Re: New drafts

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

> Yes.  The difficulty of implementation and ugliness of that are why I
> think passwords shouldn't be character strings, but octet strings, with
> character sets brought in only when it's time to type a password.  (Or
> display them, if that's ever done, though I'd hope it wouldn't be.)
>
> This would mean that an ssh client system needs a way for the user to
> enter an arbitrary octet sequence when prompted for a password.  I
> consider that a less serious problem than requiring every Unix
> derivative supporting ssh to either (a) redesign their password systems
> so that passwords become character strings or (b) not support password
> authentication.  If it came down to that choice, I'd unhesitatingly
> pick (b), though more likely I'd implement passwords as arbitrary octet
> strings and ignore the conformance issue.

I would prefer (c), every ssh implementation must either
know (from configuration or natively), or guess, the charset in
use for the password database on the system.

The alternative, is (d), every SSH client on every operating
system, talking to every server on any OS guesses what charset
is in use for passwords on the server, which it knows nothing
about.

This sounds like a recipe for disaster to me.  And just
because a client doesn't explicitly do a translation
doesn't mean it isn't guessing... it is just guessing
the server is the same as it is.... which might work
pretty good in a homogeneous environment, but won't
necessarily be so hot in a heterogeneous environment.

And I'm sorry, but I don't buy that passwords aren't
character strings.  Humans generate and enter passwords,
and humans work in character strings.  (Now I do buy
that some, maybe most, OSes aren't aware of the charset
property of passwords.)

- Joseph