In <[log in to unmask]> [log in to unmask] writes:

> I also mentioned that I would bet that none of them have configured their
> INETDSEC files to allow or disallow anyone. It's not only the kind of thing
> that most businesses don't tend to do, it would also be an enormous bother to
> keep current. As empirical evidence to further that contention, I've always
> been able to get right in, as soon as they've given me their IP addresses --
> and they certainly have never asked me my origination IP address.

I'd also bet that given a hostname or IP address for their machines, that
even a novice hacker could probably find a user/account on that system with
no password (or a well known password). Did you know that there are even
hacker pages on the web now that list accounts to try for breaking into
HP3000s? They list the basic manager.sys, mgr & field.telesup, and even a
couple well known vendor accounts (adager/robelle/etc).

inetdsec isn't an easy one... I remember when we set ours up, we had to hunt
for the info (a while back; I don't know if it's better now - though I doubt
it). It should be right in there on page 1 of the inetd/telnet setup
instructions. It's *not* hard to setup; for 99% of sites, it's hardly ever
going to change.

[snip]

> PASSWORD ENCRYPTION
>
> On a second subject, in response to Ken Sletten's repeating his concerns about
> passwords being transmitted in plain text accross a network, several people
> wrote me privately about the subject. Surprisingly, every one of the
> correspondents proposed putting the encryption into the telnet transport.
>
> While whatever form of encryption is adopted has to be done cooperatively both
> in the terminal emulator and MPE itself, I don't believe that telnet is the
> place to do it. Rather, it should be in MPE and in the terminal emulator,
> without regard to the communication mode (direct wire connect, dial-up, NS/VT,
> or telnet).

[snip]

Agree, mostly... ;-)

>       o The HP3000, either from the MPE FOS, just before an account/group/user
> password was to be entered, or from an application, would request terminal
> capabilities (an "Esc*s<x>^" is the form of the sequence that initiates a
> capabilities request).
>
>       o If the terminal emulator responded in the affirmative that encryption
> and compression capabilities are present in the emulator, the HP3000 would
> then ask for a similar (but newly defined) capabilites request that would
> outline the form of encryption and compression algorithms supported by the
> emulator.
>
>      o The HP3000 would then select the most appropriate form of encryption,
> based on what capabilities are available to it and command the terminal
> emulator to now transmit all further transmissions under encryption.
>
>      o Once a password, or a dialog, has been completed, the HP3000 would then
> command the terminal emulator to return to plain text transmissions.
>
>       o If, on the other hand, the terminal (including a real terminal) had no
> capability to encrypt or compress data transmissions, the HP3000 would
> recognize that fact from the returned capability bytes -- and all
> communications would occur as they do now, and we'd be no worse off than we
> are.
>
> Putting this form of negotiation into the standard terminal dialog is the
> right place to do this. Further, it allows encryption & compression
> capabilities to be completely independent of the form of the communication
> medium (wire, dialup, ns/vt, or telnet). It would work as well in any one of
> these as any of the others.

Here I disagree; the *ideal* means of securing a connection between HP3000
and a "termulator" (and potentially even a terminal connected via a DTC)
would be an SSL type connection between client and HP3000 (or between DTC
and HP3000). The SSL library is industry standard, can be very secure,
can be implemented easily (merely have the 3000 listen on a new tcp port for
SSL NSVT or SSL telnet connections; this leaves the underlying protocols
completely alone/intact). It would certainly be somewhat slower, but the
choice could easily be made by the client (or enforced on the host by
disabling the non-secure port). Indeed, even by a logon UDC that checks
the CIVar set denoting the incoming port# used for the connection.

Remember that alot of the "secure" information you're likely to send over a
network connection isn't just the initial logon... you have application
passwords, *data*, maybe you're a system manager or account manager and
happen to do a :LISTUSER ;PASS, or print a job stream with passwords of some
type in it....etc. The host isn't gonna know when to go into/out of "secure"
mode...

Plus, with SSL you now only secure the data path across the wire, it can also
be the basic for strong authentication of just WHO is at the other end of that
connection (logon) on the 3000.

Also, I suspect that SSL could likely be implemented (via an upgrade) in most
modern DTCs, allowng the potential for SSL-encrypted sessions over the
"shared wire" portion of the connection between dumb-terminal/serial-connected
pc and the 3000.

 -Chris Bartram