[Zope] - Cryptography... and the absurdity of things

Christopher G. Petrilli petrilli@amber.org
Wed, 30 Dec 1998 23:16:14 -0500


On Thu, Dec 31, 1998 at 04:50:15AM +0100, Andreas Kostyrka wrote:
>
> The crypto stuff came into play when someone tried to sell the planned FTP
> interface as a replacement, and I mentioned that I do not like to send
> plaintext passwords over the Internet. Especially not if the password
> ``means'' something like the ability to edit a website. (A password to
> access some paysite may be ok to send in cleartext. That depends upon your
> goals ;) )

I agree that "identification" is an important goal, the whole concept of
reusable identification tokens (ney passwords) is counter to any normal
security ideology.  This however, is the best we can do with what's out
ther in many people's hands, so it should remain.  That doesn't mean we
shouldn't work harder to produce something else more capable for those
who desire/need it, and who can support the ncessary infrastructure (see
below).

> Now to summerize my only ``difference'' with the Z Zen ;). Z uses BoboPOS
> to activate/deactivate objects. IMHO, this is one of the shortcut hacks,
> that make Python what it is. *g*

I'd not call it a hack, but that's irrelevent.

> I strongly prefer to have an explicit activation/deactivation. Why?
> Because this much stronger spells out what is stored/done/etc. in the
> object, compared to some implicit activation/deactivation.

This to me is counter to the principle of persistent storage of objects.
I'm sure Jim would be more than happy to expound on how it IS explicit
at some level, perhaps you just want more control over THAT level,
which is an entirely different question.

> Additionally, I prefer to use more ``traditional'' storage forms (kind of
> HTML documents usually belong onto a filesystem, or into a document
> managment system, ``data'' belongs into a SQL system.), I know this is
> pain in the beginning, but in the long run it's got the best
> maintainibility.

This has been discussed elsewhere and is ignored for this discussion.

> > cryptographer's hat on (didn't you wonder what I did for money?) and rip
> > it to shreds... the reality is that at this point, in this poltical
> > climate, with the current available resources, it's just not an
> > intellegent move.  
> I've never suggested that I want seriously implement such a beast. I'm
> quite happy with BoboHTTPServer running on internal loopback alias,
> protected by some additional levels of paranoia ;), being served to the
> world by Apache/SSL ;)

THis currently is about the "best" as one can do... but read on, the
future isn't as bleak as one might think... with a little understanding
of what's possible.

> Before I found the ``solution'' (hack is probably the better naming) with
> Apache/mod_rewrite/mod_proxy/BHS, I've considered (not too seriously) to
> use SSLeay to enhance BHS. Knowing that I'm not a crypto guru *g* (they
> teach here around not to much crypto to CS majors :( ), I'd considered
> much more strongly to patch pcgi to work better to my liking ;)

The core of the problem comes from where you want "authentication" to
happen... if it's at the web server level, and you trust that, then
that's cool, it can be done using the current system, but if you want
something stronger, it's necessary to rethink how authentication
credentials are handled/verified.

> > Security (of which cryptography may or may not be a component of) is a
> Correctly. I'd just rather say, that with an unsecure communication
> channel, cryptography is rather a good idea (I know S/key, etc., but it's
> all in some way poor substitute to secure channel, isn't it?)

As is often the case, people confuse privacy with other things.
Encrypting the channel is only one factor, to me it's more imporatnt to
protect the identification stage, which is a different issue than the
privacy fo the information.  While this is also an issue (as perhaps
could be non-repudiation and tamper-detection), it's a different one,
and honestly trivial to solve... the identification problem is the
complex one.

> So I'm quite wary of security experts, being it individuals or companies.
> But I managed to manage (or co-manage) Linux (and for a short time HP/UX,
> but that were unexposed boxes) boxes on the Internet for 6 years, without
> being hacked to often. Actually it happened once on my home box with modem
> dialup, and since then I've learned that even Modem dialup boxes that come
> in contact with the Internet have to be secured properly.

The core to good security is an understanding of risk management, threat
analysis and policy development, anything else avoids the necessary
understanding of the underlying issues, and simply throws a blanket over
them.  

> > You need to define WHAT you're trying to accomplish before you reach
> That's quite easy. (Actually you are right, it's not that easy.)
> 
> -) Running websites without exposing the server to hacking, even
>    considering that it is located in a highrisk area of the net (colocated
>    at a ISP on one huge ethernet segment, and the ISP seems not to have a
>    policy against turning one's ethernet device into promiscious mode,
>    ...)

Impossible, someone's always smarter than anyone else can be.  You can
mitigate the risk and make it unattractive so hackers move elsewhere,
but you can NOT eliminate the risk for any sum of money---short of
unplugging the machine.  Period, end of story.

> -) Asorted other typical tasks. Again without being compromised.

Again, see above about risk mitigation.  People need to learn to think
in the concepts of risk containment and mitigation, and not absolutes.
Absolutes do not exist.

> So is the mission goal clear enough.

Clear as mud, still... avoid stating things so vaguely... Are you
concerned with privacy or authentication more?  If so, what restrictions
are you willing to place on the user to support it? Digest
authentication would HELP (a small amount), but it's not supported last
I checked in Netscape or IE or Opera.

> ``security'' becomes VERY HARD to achieve without cryptography.

Define security in this context.  Cryptography comes in many forms, hash
algorithsm are all you need for dealing with the basics of
identification, block/stream ciphers are used for privacy (I know, let's
not get into the details of symetric crypto signing systems).

> And the Internet is an insecure channel. Admittingly it comes in different
> shades, ranging from threat area to insanely high threat area.

Different PARTS of the Internet are different.  I'd argue that the
threat from the INSIDE of someone's backbone is an order of magnitude
less than the risk from someone on your own segment, or nearby.  All
surveys and analysis indicates that 80% of threats are internal, not
external.

> > about is whether someone can break your 40-bit key by brute force,
> Actually, I'm quite happy with 40-bit keys for website editing. The point
> is to get rid of sniffers. What I like less are 40-bit keys when
> authenticating for a root shell, but then it'd probably do the trick too.
> The point is that if there is enough crypted traffic, the real bad guy
> have much more to decrypt ;)

Key rotation, etc., eliminate this as a concern... The size of keys
protecting national security assets is much smaller than people think.
They're just rotated a LOT.  Again, the issue is, are you worried about
people seeing what you're doing, or are you worried about someone DOING
something... passive/active attack situation.

> > you've done a handy job, but don't delude yourself into thinking that
> > even relevant to most discussions.
> > 
> > The concept of "role based" authentication in ZOPE is wonderful as a
> > first step, there are many more that need to be made... all in good
> > time, as technology and time permit.  I would love ot see a fully
> > trusted, multi-level secure object publishing system, but given we can't
> What do you mean exactly by trusted, multi-level?

Trusted = behaves according to design
Multi-level = compartmentalization of data into distinct "bubbles" that
are isolated from one-another.  Control is implemented to prevent data
floating between layers except in one direction (up).

> > even get a secure WEB SERVER, I'm not holding MY breath for another
> When you mean by trusted, multi-level, secure WEB SERVER something that
> supports UP-write, DOWN-read policies and level separation, I'd rather say
> you are on lost ground, as http as such doesn't support that to well.

The point is that there are billions of threat vectors in the system,
it's necessary, before going all out concentrating on one or another, to
understand which is most important and most vunerable to the kind of
compromise you are most worried about.

> > minute.  One must ask the question, "what are you protecting" and "what
> > is it worht".... so long as the aggregate of what you protect and it's
> > value is less than the effort required to counter your protections, you
> > have succeeded in building a reasonably secure system.
> *nod* But now let's consider virtual website hosting.

This is a nefarious ugly bastard child concept :-)

> These sites quite possibly could contain:
> -) personal data. We've got stupid laws about protecting personal data
>                   here arounds. Beside all the hassle, not complying with
>                   these stupid (actually, personally I consider this law
>                   much to mild, but that's the theoretical point) law is
>                   punished by around USD20000 per incident, ...
>                   Now explain to someone that you did not sell the data,
>                   that it was stolen. (Every data processing facility have
>                   to be able to explain how it got the personal data and
>                   how it acquired it legally, but I personally tend to
>                   provide my personal data often with spelling mistakes
>                   and have a list which mistake was provided where *g*)

Anyone who uses shared resources to store this information has violated
the "good faith" clause of most laws, and at least in the US would be
liable regardless of the other steps they might have taken.

> -) credit card numbers. I don't know what the credit card companies would
>                   do to us, but I'm pretty sure, I would not like it much.
>                   And one thing is sure. They have more money for lawyers.
>                   While we have more fair and sane judicary process here
>                   around than in the land of freedom, it tends still to be
>                   a deciding factor. (Ok, if someone wants to discuss this
>                   claim, explain to me how one can be a murderer, and not
>                   be one at the same time? It's probably my
>                   shallow training in logic as a CS major which makes me
>                   having problems to accept a calcule that defines  
>                   (A and not A) as true ;)

Again, similar problems. The key to processing CC information is to toss
the information "over the wall" into another system which is not
generally publically acessible.  For example, in a previous life, I
built a processing system that tossed PO information through a serial
port to a DOS machine on the other side ... could have been NT or
whatever.  This was a one-way trip, and you couldn't get the information
back.  Retrieval of this information was restricted to console access,
and physical measures were implemented to protect this. 

> -) medical personal information. I'm about to lauch some sites for clients
>                   where doctors will be publishing but also counceling
>                   patients. Don't think that having your data base of
>                   medical inquiries (x@isp.at: Hi, my brother does have
>                   AIDS and I'd like to ask, ...) stolen is a ``good
>                   thing''.

This is something to talk to a lawyer about, as there are all kinds of
seperation issues that have to be maintained in various legal areas...
this is a difficult one like all the above, to answer... but I think
they're all irrelevent in "shared" environments because they all violate
the "good faith" clause...

> > The world is about risk-mitigation, not about absolute security, the
> > latter does not, can not, will not exist, ever, even the NSA understands
> > this concept.
> Absolutly. In my case I just observe:
> -) https (even the bastardized NSA approved key length version) greatly
>          improves the security. (against the threat of sniffing, which in
>          my experience (of six years working with the Internet) is quite
>          often the first breach of usage policies.

It's still a 6 character password, no matter how much you encrypt it...
the only viable solution for this is public-key certifications (client
certificates), which provide orders of magnitude more strength.  They
also provide all kinds of neato side-effects for site customization
because once they are presented you can refer to all kinds of info in
the LDAP directory that's generally used to store them.  Unfortionatly,
no "free" web server support them, and no commercial one is worth a
damn...

> -) https is extremely cheapily to implement. It basically costs:
>          a bit of CPU usage. (With my current hardware, I'll have enough
>                               possibilities to upgrade horsepowers. Coming
>                               from a P100 ANYTHING today is really fast.)
>          If there is a need of a separate certificate, it's about 125USD
>          or so. For editing websites it's obviously not mandatory to do it
>          under the same URL. It's probably ok to edit http://www.xyz.com
>          as https://www.isp.com/xyz/ :)

Again, see above...

Again, I just wanna get this targeted at the underlying issues, rather
than "solutions"... solutiuons are obvious if you understand the
problem.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org