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

> For some reason, almost all of the messages we get regarding QCTerm tend to be
> private rather than public. That's a complete reversal from when we were
> building the poster two years ago. Nobody seemed to consider that project as
> proprietary :-).

Here's a public one for ya. ;-)

> > One thing that I see seriously missing from any
> > current HP3000 terminal emulator is password encryption.  Something like the
> > F-Secure Secure Shell that we use on our Unix systems.  In these days of
> > networked systems, and especially in a college/university system where you
> > have lots of students with nothing better to do than play with packet
> > sniffers (<grin>), it is worrisome that our administrative user's passwords
> > are floating around on the network in clear text format.  This is probably
> > too big a project to be included in the initial versions of QCT, but
> > hopefully is something that can at least be placed on a "future
> > considerations" list.
>
> I too consider this to be a serious problem. Unfortunately, we can't just go
> and willy-nilly encrypting passwords. There has to be a matching decoding
> routine built into MPE.
>
> Nonetheless, let me say now that we're ready and pleased to put whatever form
> of encryption is judged adequate into QCTerm. I fully realize that the problem
> is going to grow more serious as time goes on and the world becomes
> increasingly more networked, but in this case it takes two to tango. Like most
> things HP3000, a long line of people mentioning this requirement at the
> HPWorld management roundtable might be the best way to get it to rise closer
> to the top of the list.

  I would agree that some method of secure password-passing to the 3000 is a
valid (and long overdue) goal. Having just completed a similar project with
our POP3 server, I would even offer a quick-and-easy way of doing it.

  Pop3 mail retrieval also has a "login" process where the client sends a
mailbox/userid and the mailbox password - normally in cleartext- over the
network. The folks that developed the Pop3 standard weren't happy with this
scenario either, and came up with an easy-to-implement solution. They called
it the "APOP" authentication method. Basically it works like this:

 Client makes connection to server

   Server responds with a banner/initial response - which includes the current
   date and time in the string

Client generates a hash code from a combination of the welcome banner and the
(mailbox) password. It uses the "MD5" hash code, which is now public domain,
and available free. [The md5 source compiles easily on MPE and we were able
to easily integrate it with our Pop3 server]. Client sends the user name and
the hash code to the server.

   Server reads the user name, retrieves the password, and generates a hash
   using the same welcome message and the mailbox password. If the hash code
   generated by the server matches the code provided by the client, the
   password is authenticated.

------------------
Advantages:
 -md5 is free, public domain, and easily useable on the 3000 (we got that
  code working and integrated with our Pop3 server in less than 24 hours)

 -md5 is a good hash (cryptographically). It's not foolproof (and there are
  published attacks that can potentially break it) but it'll certainly
  defeat casual sniffers (and most hackers) (It may be breakable, but it
  takes alot of machine-horsepower dedicated to the task, which not everyone
  has, or is willing to devote to cracking a single password)

 -the process is simple and could be integrated by HP on the server side and
  any termulators with a minimum of effort and cost

 -it doesn't require the sophisticated key-management processes required by
  kerberos and other public-key/strong-encryption methods

Cons:
 -md5 is NOT unbreakable; while it provides "good" security, it's not a fit
  for high-security installations. The higher the risk, the higher the cost...

 -as with most hash/encryption methods (or security in general) the shorter
  the password, the less secure the encryption is

 -unlike better validation processes (like kerberos) the validation process
  with md5 proves only that the client knows the proper password; there is
  no certificiation of access-levels or other privilieges. Still, it's
  better than what we have now. :-)

And finally, an obligatory <plug> :-)

Yes, the 3k Pop Server currently supports the "APOP" secured authentication
method. It's been shipping since May 12.
</plug>

                      -Chris Bartram


______________________/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_
  Chris Bartram        Sales (US):   800 Net-Mail    Fax:+1 703 451-3720
   ______                         +1 703 569-9189    mailto:sales at 3k.com
  /__ |  \__________   Sales (Europe):+44(1480)414131 Fax:+44(1480)414134
 /  / | / ________     Sales (Pacific):+61 3 9489 8216 Fax:+61 3 9482 5124
|  /_ |<  ______       Tech Support:+1 703 569-9189  Fax:+1 703 451-3720
 \ __)| \ ___          mailto:support at 3k.com       Me: rcb at 3k.com
  \______/Associates,  6901 Old Keene Mill Rd Suite 500 Springfield VA 22150
_________________Inc._/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_
Gopher: gopher.3k.com   Anon-FTP: ftp.3k.com  WWW: http://www.3k.com/