Re: Emerald Questions

Greg Boehnlein ( )
Thu, 6 Mar 1997 10:37:19 -0500 (EST)

On Wed, 5 Mar 1997, Dale E. Reed Jr. wrote:

> Greg Boehnlein wrote:
> >
> > What about the question that I posed regarding some sort of encryption on
> > the Exported Account Info? This is a SERIOUS PROBLEM in my humble opinion
> > and is causing me to re-think my strategy of using Emerald to
> > automatically create the accounts on my Unix system. This cuts out a large
> > reason for choosing Emerald and will force me to use Humanoids to enter
> > and setup the accounts.
> Humanoids and paper. That is generally just as in-secure.

Our situation would be opening up a SSH session to the machine for
administration and hte humanoids entering the information directly from
Emerald. SSH is encrytped, so snooping on the session won't garner
anything and there is no need to write the password down on paper.

> Clear text passwords? Is it that you don't trust your unix system?

No, but it is utterly retarded to -NOT- take every security precaution
when securing a system. Having Clear-Text passwords ANYWHERE is a bad
Idea. Just like standard Telnet sessions are a bad idea because you can
Packet Sniff the network connection and see everything that is going on. I
know.. I use this technique when we are tracking "problem users" who are
hacking away at things. There is no way to tell WHO may be sniffing
packets on a network.

> There is
> typically only a couple of entries in that file at any time.

Why is this? What if you bring up 200 user accounts a day? If your running
a service where you have an entire state and your entering in data from
multiple cities this isn't at ALL impossible.

> If you can't secure a file, like spasswd or the extends file, then you
> have worse problems to deal with, IMHO.

The shadow password file isn't the problem. The problem is Emerald storing
a plain text passwords on a Unix file-system. Do the terms Race
Condition and File-Pointer Snooping sound familiar to you? An experienced
hacker can exploit any number of conditions to gain access to resouces on
a machine. While we can shore them up one by one, there is no TRUE secure
way to make ANY machine "hacker proof". Even NT.. You do what you can and
take every opportunity to REDUCE the risk of someone gaining access.

In my opinion, plain text passwords are a security problem that are
waiting to explode. This is the reason that NO ONE here uses Telnet. NO
ONE sends a password to a client over a Clear Text network.

> The md5 routines will be available shortly in Emerald, and we could
> make a secure export, if that would make you feel any more confortable.

Yes. This would be very much appreciated.

> > I would propose, also, that in some future versions of the software an
> > "Export" module be included that would allow you to select specific fields
> > to be exported and the format of the Export File. There are times when a
> > Comma Delimited file would be easier to deal with. There are also times
> > when only a pair of fields might be neccessary. Having the control would
> > be an excellent selling point.
> Command Delimited files, unless quote wrapped, are not that useful,
> although
> not bad. Tab delimited (our current format) is much easier to parse,
> and
> almost all import engines support it. I agree about the export, but
> unfortunately, we are talking about a feature only about 2% of the
> Emerald
> customer base would ever use. Weigh that against many of the requests
> we
> are asked by moe that 90% of the users, and it seems difficult on our
> part to jusitfy.

Understood. However, I've noticied some inconsistency in the way that
EmerUX is "supposed" to handle the export file and the way that the
Export file is actually being written.

For example, the way that I read the PERL code, each line in the export
file is supposed to start with a command.

One of..


And then each specific command will have it's own set of parameters being
passed to it. EG, the ADD command has the following structure, consisting
of 9 different parameters.

struct import_add
char command[17]; /* ADD, DEL, EXT, CHG */
char emerlogin[33]; /* Emerald Login ID */
char expiredate[9]; /* Date of Account Expiration */
char password[13]; /* Authentication Password */
char login[41]; /* UNIX Login */
char name[51]; /* Combined First / Last Name */
char region[16]; /* Locale or POP */
char software[16]; /* Type of Software */
char accounttype[16]; /* PPP, E-mail, Whatever */

Why then, am I getting entries like this in my Export file?

Obviously, either something is misconfigured, or Emerald is just not
spitting out the correct information... Or I just don't understand what
the hell the author of the Emerux code was doing. (EmerUX, by the way,
crashes horribly here on the export files in .88).

Notice the last 8 entries in the file? What are they? Extends? Adds?

I am willing to write a C based, extensible parsing program if you'll work
with me. I'll even include the MD-5 code in it for the de-cryption of the
"secure" exports, if you will work with me. But to do that, I will need a
complete set of documentation on how / what Emerald exports, and why it
does thigns the way it does them. Yes, it may be obvious to you, but I
want a fully remote manageable facility in place before I take Emerald
online full force here. It's not difficult to do, just takes the knowledge
up front to get it done.

> We are not turning our backs to the issue, by any means, we just have to
> be careful about resources and time consumption.

Again, I understand this issue, but if the Export Feature does not meet my
needs, then it severly limits the extra functionality of Emerald. Other
programs such as Internet Billing -HAVE- working Intergration and Remote
Unix Management code that works.

> > I assume that you are simply exporting the output from an SQL query?
> "simply" is an under-statement. There are many rules to take into
> consideratin for the export that can complicate things. I do not
> think it would be that difficult for someone to write a quick interface
> to do the export, either. Getting the data out of Emerald is the easy
> part. What is done with it on the other end, is generally the
> challenge.

Which brings me to my next step.. If I can't get anything done with the
export module in Emerald, then I'll need to write my own interface to the
Database and pull the data myself. MS-SQL drivers for Unix are available.
Not cheap, but available..

--      President of New Age Consulting Service, Inc.  Cleveland Ohio             SLIP/PPP/Unix Shell   28.8k / ISDN / Leased Line    (216)-524-8414