More on Visual J#.Net

[Jason]

>Now if someone would
>just develop a tree like object browser to document that big API, I would
>really be sold.

I second that motion!

Max, remember, this thing is still in Beta. Even though it is already pretty
useful and surprisingly solid (no, I don't work for Microsoft), it is still
not feature complete. Considering that Microsoft is putting all the people
from all of its language development efforts together to do .NET, I expect
we will have a lot of neat things to look forward to!

[Mike Mitchell]

On 15 Oct 2001 16:03:48 -0700, "Jason"
<jason@creative_nospam_corp.com> wrote:

>No, really, Max's question was a valid one. VB6 is still a useful tool,
>and will be for years down the road. I will be supporting a lot of VB6 code
>I have written over the last couple of years, until customers are willing
>to pay to have it rewritten (usually for business-logic reasons, not because
>they want a new technology that does the same thing).

Even after Microsoft has incinerated all the VB source code (lest the
competition should get its hands on it) and classic VB is just a stain
on the Redmond carpet tiles, business people will still want an
easy-to-use, quick-to-adopt tool that they can use for building rapid
solutions without the bloatware and without having to re-mortgage
their houses to pay for the humungous hardware people will try to sell
us. VB6 may be dead, but there are many outfits around who are slowly
realising just what a license to print money a VB lookalike product
would represent. And you can be sure that they are working on it! If
C# is generally accepted to be a ripoff of Java, but still doesn't
rattle Sun's cage, well, a product with the simplicity and
accessibilty of VB wouldn't have to look too different to avoid a
Microsoft posse of legal eagles turning up at one's door. After all,
there is PowerBASIC, GFA Basic, RealBasic and so on - all much more
akin to proper Basic than VB.NET. It's just a matter of time.

>The thing is, the .NET platform can do a few things that SIMPLY CANNOT BE
>DONE BY C++ OR VB.

Like what, f'rinstance?

> It's kind of like the difference between JScript and
>C. In JScript, which is an interpreted language, you can create a string
>that contains code and evaluate it directly.

You can do that already in VB using the script control. You can paste
your code into a text box while the app is running and have it execute
live. Admittedly this is a bit of a kludgy approach, but it shows at
least that classic VB could be developed to properly allow it as a
basic feature.

>Interpreted code can be a lot more expressive than a statically compiled
>language is capable of being. The price you pay is that interpreted code
>is 10 to 100 times slower than compiled code (depending on the language).

Maybe, but who cares nowadays with the super-fast machines we now have
on our desks? If my customer has a client who walks in and orders a
ticket to Maryland and I can process that client in real time in a
matter of seconds, should I care whether the program is written in C,
C++, Assembler, or plain old classic VB? If it's fast enough in VB,
why does it need to be any faster? Okay, so I can get a 100-character
string to pass from one computer to another in, say, 100 milliseconds
in VB, 70 milliseconds in C, and 5 milliseconds in Assembler. Again,
so what, if it's still gonna take the guy at the other end three
seconds to read it?

>THICK CLIENT PROGRAMMERS, READ!

Ah, we're not that stupid to be taken in by this!

>OKAY, think of this...
>
>Remember VBA? You drop it into your application, and it lets programmers
>use VB to customize a document. But it was kind of targeted to a certain
>type of application, and you had to pay royalties...
>

[snip]

>Are you excited yet? VBA is a thing of the past!

Tell that to the myriad companies like Autodesk who have embedded VBA
into their products! I'm pretty sure they are totally pissed off at
Microsoft for forcing them to rewrite their entire product ranges.
Alternatively, VBA could be kept on indefinitely, just for them...

>Just by writing your application for .NET and providing the right hooks,
>you can let users customize the application in any language .NET supports!
> Now if that does not excite you, I really don't know what else I can say.

Sure, if you equate excitement with sheer, unadulerated horror, I'm
ecstatic!

MM

[Mike Mitchell]

On 15 Oct 2001 14:34:10 -0700, "Sean Scally" <seanscally@nospam.net>
wrote:

>I'm afraid that if you're trying to preach .NET to Mike, you're wasting your
>time. He can't claim ignorance any more, as much as his opinions may prove
>to the contrary. No, unfortunately, he knows all this and hates .NET anyways,
>because nothing new is ever good.

It's not that I do not like anything new. But I only like things which
are truly new. Things which will really make a difference, like
non-injected insulin treatments, or Bluetooth, or that solar wing the
Americans have been testing, or Viagra. What you see with so much
stuff touted as "new" isn't new at all. It's just the same idea
repackaged in a glitzy box, sold with fanfares and special offers and
generally tarted around like a hooker at a frat party. Of *course*,
people are going to be interested! People, that is, who can't see
beyond their own noses, who only see as far as the glitz and glitter
and refuse to pose even the simplest of questions, like "why?". This
is how propaganda and clever advertising works. They play upon our
baser instincts, knowing exactly which buttons to press. They are
seductive and the promises are many. Plus, the downside of not playing
ball, of not being one of the gang is too great for many to
contemplate. They just cannot be seen by their peers to divert from
the yellow brick road, for fear of being excluded from the crowd and
ostracised by their erstwhile friends. The path of agreement is always
the easiest to take. It's always easier to join in with the stoning,
rather than risk the others turning their aim on you.

If Microsoft had introduced a replacement for classic VB that was 99%
backward compatible, but a LOT easier than even classic VB, plus they
would target it at users and not developers, selling it on ease of use
and not 5000 classes, then I might be a little more persuaded to look
at such a product. But VB.NET is such a gigantic step backwards in
furthering RAD technology that it leaves me gasping for breath over
the sheer chutzpah of Microsoft for foisting such a cumbersome chimera
on to the world of business. Especially now, in these times of
trouble, where businesses need to be effective quickly, with rapid
turnaround of new ideas and faced with changing markets, the last
thing they want is (a) to have to adapt to a completely different
programming environment like .NET and (b) to have all their VB
developers forced to become OOP-aware and (c) to rewrite anything they
might have that already works. Not much of a ROI, in my view, whereas
backward compatibility would have given them all of the future, and
kept all of the past.

MM

[Zane Thomas]

On Tue, 16 Oct 2001 20:53:43 GMT, kylix_is@hotmail.com (Mike Mitchell)
wrote:

>VB6 may be dead, but there are many outfits around who are slowly
>realising just what a license to print money a VB lookalike product
>would represent. And you can be sure that they are working on it!

Cite?


--
When freedom is outlawed
only outlaws will be free.

[David Bayley]

max caber wrote in news:3bcb9be4$1@news.devx.com...

> Now if someone would
> just develop a tree like object browser to document that big API, I would
> really be sold.

The SDK's Framework Reference documentation provides exactly that. If you
were impressed by Java's flat web pages, then you'll be in heaven with the
..NET documentation (treeview TOC, index, and search panes).

--
David.

[Jason]

>If Microsoft had introduced a replacement for classic VB that was 99%
>backward compatible, but a LOT easier than even classic VB, plus they
>would target it at users and not developers, selling it on ease of use
>and not 5000 classes, then I might be a little more persuaded to look
>at such a product. But VB.NET is such a gigantic step backwards in
>furthering RAD technology that it leaves me gasping for breath over
>the sheer chutzpah of Microsoft for foisting such a cumbersome chimera
>on to the world of business. Especially now, in these times of
>trouble, where businesses need to be effective quickly, with rapid
>turnaround of new ideas and faced with changing markets, the last
>thing they want is (a) to have to adapt to a completely different
>programming environment like .NET and (b) to have all their VB
>developers forced to become OOP-aware and (c) to rewrite anything they
>might have that already works. Not much of a ROI, in my view, whereas
>backward compatibility would have given them all of the future, and
>kept all of the past.
>
>MM

Well, except for VB6, they are backwards compatible. And you can always
package your VB6 code into a DLL and use it from .NET, or even package your
.NET code as a DLL and use it from VB6. VB6 will be directly supported for
at least a few years, and will probably work long beyond that. Does anyone
know if 16 bit VB4 is still working these days?

(a) If you cannot adapt, you should get out of this business. This won't
be the last time you will have to do it.

(b) If you cannot figure out OO from the stuff VB already has in it, you
should get out of this business. OO is very important when dealing with
complexity, and programs are getting more complex, not simpler.

(c) You can always maintain the old VB6 code in a DLL.


>...But VB.NET is such a gigantic step backwards in
>furthering RAD technology that it leaves me gasping for breath over
>the sheer chutzpah of Microsoft for foisting such a cumbersome chimera
>on to the world of business...

Actually, Microsoft went so far the other way with VB6, hiding as much of
the complexity as possible, that it was often more difficult to get things
done. Now they have put together a complete framework that you can use from
any .NET language. You get the full power of Windows instead of the dumbed-down
version, but you also get a lot of help from the Visual Studio tools.

To me, it looks simpler to do a good program with the .NET stuff than it
would be with VB6. VB6 has become a twisted maze of weird rules and exceptions
to those rules, with some not-quite-there-yet features and some things that
have needed an overhaul for years. For new programmers, it is actually easier
to learn a language like Java than it is to learn VB, because the language
has so many weird features. Java is a clean language, and VB needed cleaning
up really badly. Of course, building a GUI is easier in VB, but then building
a GUI in .NET is just as easy, and the resulting code is a lot cleaner.

Hey, I've got an idea...instead of hating .NET because it is put out by the
evil Microsoft empire, just try it out. If you don't like it, hey, it was
free in the first place. Or maybe you are afraid you will really like it
a lot... :-P

[Jason]

>Why would you want to allow the bad bug to continue running through
>the transition period?

Usually that is not what you would want to do. But if you wanted to roll
a new feature into production, you could do it without taking down the service.
You could also do it without recompiling (assuming the service automatically
compiles the code on demand, which is something ASP does). The ability to
have multiple revisions of the same object running under one service really
is a big deal, and it is something that COM libraries don't lend themselves
to very well.


>And it is also a very large problem, in that it creates both the
>perception and the reality of a chance that somebody malicious can use
>the same mechanism to induce a "bad bug". The perception is important
>in the current (and forseeable) business climate, with worries about
>cyberterrorism, sabotage, and the like. The reality is that password
>protection is a limited barrier - one which Micro$oft has had problems
>with in the past.

Well, if you can get write access to the file system, you can do this anyway,
even with COM, though the opportunities would be more rare if the file were
locked so that even administrators could not overwrite it. What you are
talking about is not security, it is a painful way to do server programming.

Password protection is not a limited barrier, unless you use stupid passwords
like "born2run" or "helloworld." If you use a password generator that makes
truely random passwords, based on things like the time between keystrokes
as you type, and you use 8 or more characters (maybe more depending on the
character subset used), you can make passwords virtually uncrackable. The
problem is that no one uses random passwords, so most of them are crackable.
This is not a problem with password protection, it is a problem with lazy
admins.


>The big threat (perceived and real) is not the "crash immediately and
>spectacularly" scenario (which is bad enough), but less obvious
>changes to transactions and other business records. If undetected long
>enough, such attacks can destroy even major corporations. Aside from
>the more obvious fund diversions, there are such possibilities as
>creating the "records" of illegal transactions, tax violations, etc.

This can be introduced innocently or maliciously. You still have to go through
a test and release phase, but at least with .NET you will be able to release
painlessly. No technology can protect you from bad programmers and bad methodology.


>The threat need not come over the internet (although the setup allows
>it). Operatives and opportunists within the facilities (including
>contractors, maintainence and security personnel, etc. as well as
>disgruntled employees and the like) can use the mechanism with much
>less risk of detection. The "take the system down to install"
>requirement starts looking like a security measure in such a climate.

Tell Yahoo or Amazon that you are going to have to take down their machines
to install a minor bug repair. Won't be able to do it until next Tuesday
at 3:00am. In the meantime, the president of the company is breathing down
your neck for a fix.

Even better, you are doing online aircraft maintenance manuals. There is
a problem in the field that requires a small fix on the server, but until
you do it, no one can fix a 737. Of course, if you take down the server,
all the manuals for 757s and 777s are down too. There are passengers on
the concourse waiting for a lightbulb to be replaced on a 737, and it can't
be done until the mechanic can check off all the steps of the procedure,
and his manual is broken. But if you take down the server, all repairs on
all planes all over the world will stop for a period of at least 15 minutes,
maybe longer. And God forbid you should have to do a reboot, because there
are another half dozen services running off that same server that are completely
mission critical to the airline.

Again, having to take down the service to do an installation is NO FORM OF
SECURITY! If your security has been breached far enough to overwrite files,
there are all sorts of things you can do to a system that don't require you
to overwrite a DLL.


>> NET is a BIG DEAL.
>
>But not necessarily a good deal.

If you think that preventing a DLL from being overwritten constitutes any
form of security whatsoever, you really need to rethink your security policies.
Nothing on your machine is any more secure than your least secure password,
and in the case of things like Code Red, even that won't buy you anything.

[David A. Rothgery]

Jason <jason@creative_nospam_corp.com> wrote:

> Password protection is not a limited barrier, unless you use stupid passwords
> like "born2run" or "helloworld." If you use a password generator that makes
> truely random passwords, based on things like the time between keystrokes
> as you type, and you use 8 or more characters (maybe more depending on the
> character subset used), you can make passwords virtually uncrackable. The
> problem is that no one uses random passwords, so most of them are crackable.
> This is not a problem with password protection, it is a problem with lazy
> admins.

obNitpick: Truly random passwords are not used because humans find them
difficult to remember. About the best you can ask of people under normal
circumstances (i.e. you're not working with classified data) is to pick
something that's obscure for most people and easy to remember for them.
It isn't just lazy admins.

--
Dave Rothgery
Picking nits since 1976
drothgery@alum.wpi.edu
http://drothgery.editthispage.com

[W.E. (Bill) Goodrich, PhD]

In article <3bcccfc2@news.devx.com>,
"Jason" <jason@creative_nospam_corp.com> writes:

> >Why would you want to allow the bad bug to continue running through
> >the transition period?

> Usually that is not what you would want to do.

Well, it was your example - not mine.

> But if you wanted to roll a new feature into production, you could
> do it without taking down the service.

And without attracting much notice. Thus the problem.

> You could also do it without recompiling

Which is something we have always been able to do before .NET. But
the compilation issues surrounding VB.NET are somewhat different than
those of ASP.NET.

> (assuming the service automatically compiles the code on demand,
> which is something ASP does).

> The ability to have multiple revisions of the same object running
> under one service really is a big deal, and it is something that
> COM libraries don't lend themselves to very well.

But it's not something you are going to want to commonly do.

> >And it is also a very large problem, in that it creates both the
> >perception and the reality of a chance that somebody malicious can
> >use the same mechanism to induce a "bad bug". The perception is
> >important in the current (and forseeable) business climate, with
> >worries about cyberterrorism, sabotage, and the like. The reality
> >is that password protection is a limited barrier - one which
> >Micro$oft has had problems with in the past.

> Well, if you can get write access to the file system, you can do
> this anyway, even with COM, though the opportunities would be more
> rare if the file were locked so that even administrators could not
> overwrite it. What you are talking about is not security, it is a
> painful way to do server programming.

In large part I am talking about the perception of (in/)security, and
also about risk management. What you seem to be moving toward is
ignoring such issues entirely, in favor of the convenience of the
server programmers. After recent events - on and off the 'net - that
view is becoming unpopular in many corporate circles.

> Password protection is not a limited barrier, unless you use stupid
> passwords like "born2run" or "helloworld." If you use a password
> generator that makes truely random passwords, based on things like
> the time between keystrokes as you type, and you use 8 or more
> characters (maybe more depending on the character subset used), you
> can make passwords virtually uncrackable.

Nonsense. Unless you are constantly (several times a day) changing the
password, anything less than a 20 character randomized password can be
practically cracked by someone willing to expend the resources. And if
you do change them that often, you make the job of the system
programmers virtually impossible.

There are also potential issues with the ways the passwords are managed
and checked, but it is best not to discuss them too openly just now.

> The problem is that no one uses random passwords, so most of them
> are crackable. This is not a problem with password protection, it
> is a problem with lazy admins.

David A. Rothgery <drothgery@alum.wpi.edu> addressed this point fairly
well.

> >The big threat (perceived and real) is not the "crash immediately
> >and spectacularly" scenario (which is bad enough), but less obvious
> >changes to transactions and other business records. If undetected
> >long enough, such attacks can destroy even major corporations.
> >Aside from the more obvious fund diversions, there are such
> >possibilities as creating the "records" of illegal transactions,
> >tax violations, etc.

> This can be introduced innocently or maliciously. You still have to
> go through a test and release phase,

No you don't. For legitimate changes it is ADVISABLE to do so, but
there is no OS mechanism which enforces any such requirement.

> but at least with .NET you will be able to release painlessly. No
> technology can protect you from bad programmers and bad methodology.

Protection is not an all or nothing proposition. And your little side
trip into the issue of inadvertent programmer errors is entirely
irrelevant to the issues of the perception and the reality of increased
exposure to malicious change. There is no such thing as a single,
monolithic, absolute security measure. Security is achieved by a
combination of measures, each of which impedes some unauthorized
actions. The fact that any single element does not confer ABSOLUTE
security is irrelevant to the impact of that element on the overall
security of the system. Measures like requiring physical access to
the hardware and taking the hardware off line in order to make any
operational change are not absolute barriers to malicious change,
but they each increase security somewhat in combination with other
measures. And each can be modified to increase their potential impact,
such as by locking the "computer room" (thus making access to the
hardware more difficult). And removing those barriers decreases
security in the same way.

> >The threat need not come over the internet (although the setup
> >allows it). Operatives and opportunists within the facilities
> >(including contractors, maintainence and security personnel, etc.
> >as well as disgruntled employees and the like) can use the
> >mechanism with much less risk of detection. The "take the system
> >down to install" requirement starts looking like a security measure
> >in such a climate.

> Tell Yahoo or Amazon that you are going to have to take down their
> machines to install a minor bug repair.

You mean tell them that they are still subject to the operational
limitations they already face? And perhaps we should ALSO tell them
that the price of reducing that difficulty is a significantly
increased potential for malicious modification of their systems.

They don't run on a single, central server - for that very reason. In
such situations, they can take the systems down one at a time and make
the switch while the others are running. And they do, regularly.

> Won't be able to do it until next Tuesday at 3:00am.

More of your rhetorical nonsense. Yet more SNIPped...

[...]

> Again, having to take down the service to do an installation is NO
> FORM OF SECURITY!

Nonsense. It is not a "complete" form of security in and of itself,
but it is a very effective element of both perceived and real security.
One of the biggest parts of that is the fact that it requires physical
access to the hardware (which, as you have pointed out, is not the case
with your "easier" .NET "updates"). Another is the fact that a system
going down for some period of time - even a brief one - is far more
likely to be noticed than your "zero-impact installation."

> If your security has been breached far enough to overwrite files,
> there are all sorts of things you can do to a system that don't
> require you to overwrite a DLL.

But that doesn't make it "harmless" to create new potential avenues
for such malicious changes. Nor does it diminish the perception of
increased vulnerability associated with such a channel for "zero-impact
installation."

> >> NET is a BIG DEAL.

> >But not necessarily a good deal.

> If you think that preventing a DLL from being overwritten constitutes
> any form of security whatsoever, you really need to rethink your
> security policies.

That is not the issue. But I do find it interesting that you keep
trying to reduce the potential changes to nothing more than "rewriting
a DLL". The increased vulnerability extends to all of the modules.

If you think that removing a requirement for physical access to the
hardware has no adverse impact on security whatsoever, you really need
to rethink your security policies.

> Nothing on your machine is any more secure than your least secure
> password,

That rather depends on what other security measures are in place. And
what you are trying to secure against. A good, solid door with a strong
(and consistently used) lock can be a significant barrier to actions
which require physical access.

> and in the case of things like Code Red, even that won't buy you
> anything.

So companies shouldn't even TRY to increase their system security? I'm
sure Corporate America will find that a relief. NOT. Any system that
is designed to allow - even encourage - remote changes to its
operational software should be viewed as a significant security risk
and treated accordingly. And any system that allows such an update
without direct, affirmative operator intervention is even more of a
risk. Code Red (both) and Nimda exploited such openings, and future
attacks are no less likely to.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

[Bob]

In article <MPG.16368590c610ecac9896ed@news.devx.com>,
drothgery@alum.wpi.edu says...
> Jason <jason@creative_nospam_corp.com> wrote:
>
> > Password protection is not a limited barrier, unless you use stupid passwords
> > like "born2run" or "helloworld." If you use a password generator that makes
> > truely random passwords, based on things like the time between keystrokes
> > as you type, and you use 8 or more characters (maybe more depending on the
> > character subset used), you can make passwords virtually uncrackable. The
> > problem is that no one uses random passwords, so most of them are crackable.
> > This is not a problem with password protection, it is a problem with lazy
> > admins.
>
> obNitpick: Truly random passwords are not used because humans find them
> difficult to remember. About the best you can ask of people under normal
> circumstances (i.e. you're not working with classified data) is to pick
> something that's obscure for most people and easy to remember for them.
> It isn't just lazy admins.
>

Actually, VMS has a very nice password generator. It generates phonetically
pronounceable but, meaningless phrases. For example, it might generate
'gorfpluma' when asked for a 9 character password. It would present the user
with a list of these passwords and let the user pick one or tell it to
generate another list. This would be repeated until the user found one they
liked.

Bob

[Jason]

>obNitpick: Truly random passwords are not used because humans find them
>difficult to remember. About the best you can ask of people under normal

>circumstances (i.e. you're not working with classified data) is to pick

>something that's obscure for most people and easy to remember for them.

>It isn't just lazy admins.

If humans find it easy to remember, then that is because it contains less
information and is thus easier to hack. "Obscure" usually equates to "insecure."
Humans like passwords that are short and easy to remember. This compromises
security. You can either pick a very short random password, or you can pick
a much longer one that is easy to remember.

You are arguing the human side of the problem, but what you are saying, essentially,
is that passwords are not secure now, and passwords can never be secure because
humans won't tolerate secure passwords.

HOWEVER, the ONLY line of defense you have against hackers getting into your
machine is your password. If you pick an easy one, you may get hacked, depending
on what access the hacker has to your machine.

The problem as I see it is that most admins and most people in general do
not know how many bits of security they are getting from a particular password.
They don't know how password length relates to security (one more character
makes your password at least 36 times harder to break, maybe 63 times if
you use upper and lower case and numerical), how the character set you choose
affects the difficulty of breaking your password, and how non-random passwords
are much easier to guess than random ones.

Most people would be better off using a 5 digit random alphanumeric password
(single case) than the password they are currently using. Most people would
have no problem remembering 5 letters, and it would certainly be much faster
to type. Such a password would give you about 29 bits of security. This
could be hacked on a PC if you had a cleartext hash, but it would be nearly
impossible to guess without the hash. Add a 6th digit, and you get about
34 bits of security - much more difficult to guess. Go to 8 digits, and
you are starting to get into the passwords that require arrays of computers
to break in a reasonable time.

I doubt that the common "obscure" passwords, like "born2win" or "run2you",
encode more than 20 bits of security, which wasn't secure on a PC 10 years
ago (with the right guessing heuristic). They certainly are not secure now.

I said it before, and I will say it again: if someone can guess your password,
they can do all sorts of things to your machine. It does not matter that
one DLL is locked down by IIS - your whole machine is an open book to that
person.

Thus, the fact that IIS tends to lock down DLLs until you reboot is not a
security feature at all. It does absolutely nothing to protect you. It
is an annoyance though. :-)

[Mark Jerde]

Jason,

> The problem as I see it is that most admins and most people in general do
> not know how many bits of security they are getting from a particular password.

What's your solution for people who have 20+ passwords or 50+ passwords to
remember?

-- Mark

[Jason]

>Nonsense. Unless you are constantly (several times a day) changing the
>password, anything less than a 20 character randomized password can be
>practically cracked by someone willing to expend the resources. And if
>you do change them that often, you make the job of the system
>programmers virtually impossible.

A 20 character randomized password using single case alphanumerics encodes
about 61 bits of information, which is not hackable without a lot of resources.
But even an 8 character password encodes more than 40 bits of information,
which, until recently, was the maximum key size for encryption the US government
considered exportable. 40 bits is not impossible to break if you have the
hash code, but pretty secure otherwise.

>No you don't. For legitimate changes it is ADVISABLE to do so, but
>there is no OS mechanism which enforces any such requirement.

For that matter, you don't HAVE to eat. No one forces you to. Your built
in biological operating system ADVISES you to do so, but it can't force you
to.

In the organizations I work with, there is a change control process in place,
and you HAVE to publish code to test before you publish to production. Well,
again, you don't have to. You could choose to be fired instead. The fact
that the operating system does not mandate this is irrelevant. The operating
system also does not mandate that you feed it only bug-free code.

>There is no such thing as a single,
>monolithic, absolute security measure. Security is achieved by a
>combination of measures, each of which impedes some unauthorized
>actions. The fact that any single element does not confer ABSOLUTE
>security is irrelevant to the impact of that element on the overall
>security of the system. Measures like requiring physical access to
>the hardware and taking the hardware off line in order to make any
>operational change are not absolute barriers to malicious change,
>but they each increase security somewhat in combination with other
>measures. And each can be modified to increase their potential impact,
>such as by locking the "computer room" (thus making access to the
>hardware more difficult). And removing those barriers decreases
>security in the same way.

And locking down a single DLL that I have to recompile and update by taking
down the service helps my security how? The original post was implying that
the fact that IIS locks down a custom DLL might be some sort of security
measure.


>Nonsense. It is not a "complete" form of security in and of itself,
>but it is a very effective element of both perceived and real security.

>One of the biggest parts of that is the fact that it requires physical
>access to the hardware (which, as you have pointed out, is not the case

>with your "easier" .NET "updates"). Another is the fact that a system
>going down for some period of time - even a brief one - is far more
>likely to be noticed than your "zero-impact installation."

Man, you are right! You had better tell Sun all about this before it is
too late! Obviously, Java services have this same problem, and Sun needs
to redesign Java so that it requires a compilation or nobody is ever going
to consider it for secure applications again! What were those people thinking???
Have you seen the Java stuff that automatically updates Java apps on your
machine - right over the web? And all this time I thought Sun was big on
security... ;-)



>That is not the issue. But I do find it interesting that you keep
>trying to reduce the potential changes to nothing more than "rewriting
>a DLL". The increased vulnerability extends to all of the modules.

Exactly, so getting back to the point of the *original post* and my response,
why the heck does the fact that IIS locks down one DLL confer any security
at all? It is an annoyance, not something you can rely on to provide any
measure of security, as the original post had implied.

As far as I am concerned, you can put the changes on a floppy, walk it over
to the target machine, and drop the files there. That is plenty secure,
don't ya think? But in no case do I want to HAVE TO SHUT DOWN THE IIS SERVICE
to do the install.

That is what the original post was about.


>So companies shouldn't even TRY to increase their system security? I'm
>sure Corporate America will find that a relief. NOT. Any system that
>is designed to allow - even encourage - remote changes to its
>operational software should be viewed as a significant security risk
>and treated accordingly. And any system that allows such an update
>without direct, affirmative operator intervention is even more of a
>risk. Code Red (both) and Nimda exploited such openings, and future
>attacks are no less likely to.

You are saying, then, that if I have 500 computers, I should be required
to go to each computer with a CD and install and configure the software at
the console? Just so I understand where you are coming from. You think
that, aside from passing information around, computers should otherwise be
completely isolated from the internet, and no programs should be passed around
or installed over a network. Is that correct?

In some cases, this is the correct way to do things. I don't agree that
it is the solution in all cases, particularly because it costs a lot of manpower
and red tape to maintain such a system. For many purposes, a really good
password mechanism provides enough security to keep password hacks at bay
indefinitely. Other types of hacks can be successful, and I would not connect
a computer containing nuclear secrets to the internet no matter how good
the security appeared to be!

[Bob]

In article <VA.00000032.0188c061@spicedhamverizon.net>,
mark.jerde@spicedhamverizon.net says...
> Jason,
>
> > The problem as I see it is that most admins and most people in general do
> > not know how many bits of security they are getting from a particular password.
>
> What's your solution for people who have 20+ passwords or 50+ passwords to
> remember?
>
> -- Mark
>
At one time I managed about a dozen systems, all requiring different 15+
character passwords, and my solution was to write them down in a lightly
encrypted form with no indicator as to which string went with which system.

Bob

[Jason]

>Actually, VMS has a very nice password generator. It generates phonetically

>pronounceable but, meaningless phrases. For example, it might generate
>'gorfpluma' when asked for a 9 character password. It would present the
user
>with a list of these passwords and let the user pick one or tell it to
>generate another list. This would be repeated until the user found one they

>liked.
>
>Bob

I remember that! In fact, I still remember the password it generated for
me years ago. I won't divulge the password because I still use a minor variation
of it at times.