More on Visual J#.Net - Page 3


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 5 FirstFirst 12345 LastLast
Results 31 to 45 of 65

Thread: More on Visual J#.Net

  1. #31
    Jason Guest

    Re: More on Visual J#.Net


    >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!


  2. #32
    Mike Mitchell Guest

    Re: More on Visual J#.Net

    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

  3. #33
    Mike Mitchell Guest

    Re: More on Visual J#.Net

    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

  4. #34
    Zane Thomas Guest

    Re: More on Visual J#.Net

    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.

  5. #35
    David Bayley Guest

    Re: More on Visual J#.Net

    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.




  6. #36
    Jason Guest

    Re: More on Visual J#.Net


    >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

  7. #37
    Jason Guest

    Re: More on Visual J#.Net


    >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.

  8. #38
    David A. Rothgery Guest

    Re: More on Visual J#.Net

    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

  9. #39
    W.E. (Bill) Goodrich, PhD Guest

    Re: More on Visual J#.Net

    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 *
    *-----------------------*--------------------------------------------*

  10. #40
    Bob Guest

    Re: More on Visual J#.Net

    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

  11. #41
    Jason Guest

    Re: More on Visual J#.Net


    >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. :-)

  12. #42
    Mark Jerde Guest

    Re: More on Visual J#.Net

    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



  13. #43
    Jason Guest

    Re: More on Visual J#.Net


    >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!

  14. #44
    Bob Guest

    Re: More on Visual J#.Net

    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

  15. #45
    Jason Guest

    Re: More on Visual J#.Net


    >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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center