lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
From: raju at linux-delhi.org (Raju Mathur)
Subject: Counseling not to use Windows (was Re:
 Anonymoussurfing my ass\!)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Ron" == Ron DuFresne <dufresne@...ternet.com> writes:

    Ron> [snip]

    Ron> You hit on the duality of the issue<s> beofre trying to
    Ron> refine it into a plurality issue.  The *real* problem is
    Ron> vendors relasing bugy code with insecure defaults which
    Ron> *promotes* users remaining clueless.  take a look at the
    Ron> wireless issues spewing into the airwaves now, and look at
    Ron> not only the default installs of the products available for
    Ron> playing with wireless toys and trikets, but, take a serious
    Ron> look at the documentation and how much is devoted to the
    Ron> issue of securing the toys.
    Ron> [more snip]

I agree that vendors are responsible for security issues to quite an
extent.  As far as I can see, there are three real issues for security
from the vendor point of view:

1.  Insecure defaults.  Many vendors will sacrifice security in favour
of usability.  This, for some reason, seems to be even more true in
the Windows world than in Linux/*BSD/Unix, where vendors try to at
least make things usable but with as good an underlying security layer
as possible.  Redmond doesn't appear to give a d*mn about end-user
security, as long as the user has a `clean, comfortable, easy usage
experience'.  Definitely the vendor's responsibility.

2.  Insecure design and coding.  IMO open source/free software has an
edge here, since most of the developers don't have to work against
release deadlines, unlike the proprietary software vendors.  I don't
accuse MS (or anyone else) of deliberately making insecure software.
I do accuse them of bowing to marketing pressure and hence sacrificing
due diligence in making software secure.

Further, the free software model encourages reuse of components, and
my uneducated guess is that as time passes the more secure components
automatically float to the top of the heap whenever reuse becomes
necessary.

Of course, this conveniently ignores the remote exploit in AIM which
AOL itself exploited to remotely upgrade users' AIM's whenever they
(AOL) upgraded the protocol (i.e. whenever someone else managed to
reverse engineer the protocol and bring out a compatible III-party
client :-)

3.  Retrofitting security.  It's is completely impossible to envisage
two scenarios when designing and developing software:

- - How it is going to be used
- - How it is going to be attacked

I'm a software writer from time to time, and all I can do as a
developer is *try* to ensure that the software and protocols I develop
are secure, to the best of my vision and ability.  This problem is not
new: earlier it was said that it was impossible to make software
idiot-proof, since idiots are so smart; today I'd say that it is
impossible to make software and protocols crack-proof, since crackers
are too smart and varied.

Until it becomes possible to project in advance all possible scenarios
in which a software could be used we will never see a `secure' product
or environment.  Instances of security being retrofitted in this sort
of situation abound: AUTH and STARTTLS extensions to SMTP, the
uncountable patches from software and OS vendors, HTTPS extentions to
HTTP, encryption extensions to IPv4, etc.

The depressing conclusion I come to is that it will become
increasingly difficult to lock down applications, protocols and
operating systems; we will just have to learn to live in insecure
environments.

Regards,

- -- Raju
- -- 
Raju Mathur          raju@...dalaya.org           http://kandalaya.org/
                     It is the mind that moves
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/>

iEYEARECAAYFAj0zfAQACgkQyWjQ78xo0X95+QCgl46cqfviPVDMoH55o96WDpWk
B1wAni0wxt/AMiiSI5Lva8HshIdc0QET
=Q7bh
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ