Security suggestion concering SSH and port forwarding.

[Ben Lindstrom]

On Mon, 19 Jan 2004, Carson Gaspar wrote:

> --On Monday, January 19, 2004 3:58 AM -0600 Ben Lindstrom
> <mouring at etoh.eviladmin.org> wrote:
>
> > What is wrong with using public keys?
>
> Users will use a NULL passphrase on the public key (or a trivial password).
> Then we'll get hacked when they loose their laptop. Unless you're using
> smart cards (and using them very carefully), public key auth just isn't
> very secure with "normal" users. This is what led me to do the auth vector
> work way back when.
>

People pick shitty system passwords also.  Your point?  As SSH clients are
integrated into ftp cleints, OS etc, more and more of those shitty
passwords are "stored" clear text or cheaply scrambled method.  All so the
user does not have to reenter it day in and day out.

So the same risks occur.

Do you know how much crap IE/Mozilla exposes for user/pass they store
that users blindly use?

CuteFTP along with 99% of every other FTP clients don't really encrypt
their user/pass.  Guess what?  Security breah.

ODBC is HORRIBLE also.  How many badly written database applications have
"backend passwords" that require ODBC passwords saved away in hidden
places on the drive.

Are we seeing why your argument is worthless?  If you can't teach your
users to do good security pratice then nothing will save you.

[Side note:  I've not played with it, but I like OS/X encrypted
filespace concept.  Also the keyring is also encrypted decently.
Why more OSes don't do this is beyond me.]

> Which makes me think... if I extended the authorized key mechanisms to
> match against a username instead of (or in addition to, if applicable...) a
> key, is there a chance that would get merged in? The current functionality
> is pretty good, but only if you use pubkey auth. It would be nice to get
> the same functionality regardless of auth mechanism.
>

Not sure I see a point.  How does this improve anything?

- Ben