This supposed "Super-DMCA" is nowhere on the list of house or private members bills. The government never gets through its order of business anyways, so if this thing is supposed to get tacked onto the end of the list at some future date, it's unlikely to even get a reading during this session of parliament.
Sure smells like fear-mongering, rather than anything serious..
Disk encryption is all well and good, but in an enterprise setting it can be a tad expensive to deploy and support. Keep in mind that the disk is typically encrypted using a key unlocked using or derived from a pre-boot-authentication password.
A big problem that comes up again and again is that users forget their PBA password at the most inopportune of times. Imagine a user off in the middle of nowhere, calling a central help desk on his satellite phone or some such, asking for help because he forgot his PBA password.
A smart vendor has workarounds for this, such as single-use override passwords to unlock the workstation until the user can "come in from the cold." An even smarter vendor enables access to this using a phone plus an automated IVR system, so that said user can self-authenticate (example: voice print) and fix his own problem.
This is a big deal because help desk calls cost money (typically $20 to $50 per call), and in an enterprise (the RFP calls for 50k users minimum), we're talking tens of thousands of such calls annually.
I know that at least one vendor handles this stuff right (PointSec). Not sure about the others, but it's a very important consideration...
I've been involved in hundreds of password management system deployments, so perhaps I can make some helpful observations:
* Users who are required to comply with a strong password
policy, and must change their password often, will sometimes
be unable to think of a new, compliant password, and will
appreciate the random passwords offered.
* Randomly-generated passwords should be pronounceable, to help
users remember them. Otherwise, you're just asking for sticky notes.
* There are good random number generators in all modern OSes.
These take entropy inputs from the network, keyboard, etc. and
are basically impossible to defeat. "Randomness" is not a
realistic problem.
* If users will have to choose strong passwords, and to change their
passwords often (all good things), then the requirements should
be clearly communicated, both ahead of time and when the user
must choose a password. Don't tell the user "pick a hard to guess
password" -- tell him "pick a password with minimum N chars,
including letters, digits and punctuation marks, mixed case, that
is not derived from a dictionary word or an old password,..."
* Do require periodic password changes -- this is your only defence
against compromised passwords and weak password stores.
* You can see some of these features here (Flash demo):
http://psynch.com/overview/presentation-demo/04.ht ml
I work for a company that specifically
fixes this problem for a living.
It's not that
hard to enforce strong password rules at
the time of password change.. and consequently
our customers require always-new passwords, enforce dictionary checks, and can even apply regular expression rules.
Funny.. I was talking to Doug Miller on the
phone (really - he called to ask about Linux
use in our organization), and as we spoke I was
fighting with a WinNT install on a brand new laptop. This was following total failure to install Win2K on the same machine.
I later installed Linux on the same laptop, with no problems.
My synopsys, shared with Doug Miller, was:
"If the vendor pre-installs the OS, then
no problem, regardless of OS. Otherwise,
without vendor support, Linux is much easier
than WinNT / Win2K to install."
I wonder if he got different information from others?
As a software vendor, I can describe what we actually do, and why:
(1) We build HTML and PDF using LaTeX (single source is important). (2) HTML goes on our WWW site (3) PDF goes on both our WWW site and our shipping software, which incidentally is also delivered electronically. (4) Most customers print one or two copies of the PDF docs.
This means that we (the software vendor) only produce electronic docs, but customers can have as many printed ones as they like. PDF really is just as good as printed copy -- just print it to get beautiful output.
There are major advantages to this approach:
(1) No printing cost to the ISV (minor to the user) (2) No or lower shipping cost (3) No documentation inventory. This is a big problem if you have a rapid development cycle. (4) Much faster delivery of current docs.
I simply can't imagine why anyone would want to receive bulky paper manuals! If you want it printed (and I can relate), just print as many copies as you like from a nicely formatted PDF..
IMHO, the best way to remember lots of passwords is to synchronize them. First, you select a hard to guess value. Select 2 or 3 if you access some systems that you are afraid might be compromised (e.g., local servers vs. public WWW sites). Then, apply that password to every account you have. voila - you don't have to remember a million passwords.
with this in mind, we make / sell a commercial package for synchronizing passwords: http://www.psynch.com
Factoring 512-bit rsa is known to be doable, and has been done in public before (recently, I think).
Using quantum computing to implement massive parallelism is also possible, at least in theory.
If these guys are for real, then 1024-bit RSA may also be vulnerable, and in fact larger keys which are feasible to calculate on a conventional computer may also break soon.
So... the bottom line is that either this is a hoax, or else it's not only plausible, but actually true, in which case the computer security world is about to be turned on its head!
We run a couple of Oracle instances on a small Linux box, with several hundred megs each. While I can't give comparative numbers (don't use NT or Solaris), I'd say it performs well, and has been quite robust.
We *did* have a corrupt disk block a while ago. That was our only downtime. I'm not sure if it was Oracle or Linux or hardware. I tend to blame hardware in this case.
Why not give it a try? I imagine that performance is dominated by I/O and memory, rather than O.S. in this case, so if you like Linux, go for it. Just get a suitable box.
Agreed. Terminating just the offending code makes more sense. The question of jurisdiction still remains, however. Any thoughts? Perhaps IBM's home in New Jersey?
I think IBM means well here. What they need is an alternate way to protect themselves against patent infringement violations and the resulting liability.
Perhaps something along the lines of:
"if a party other than IBM is found by a (what jurisdiction?) court to hold a patent which applies to this software, then that party may require IBM to pay fees for use thereof. In this case, IBM may elect to terminate this license."
This reduces the problem by:
1) Eliminating IBM itself from being the hypothetical antagonist. 2) Requiring a court to demonstrate that IBM is in violation before proceeding.
I think that realistically (1) is unlikely since IBM is sincerely contributing to the open source community.
(2) Allows IBM to get out of a tough situation where they inadvertently violated someone else's patent. I don't think (2) is likely to happen.
Slashdot Mirror
If you're running Linux on IA32 then you can only address 4GB. Swap just extends your physical memory, so physical + swap cannot be more than 4GB.
So ... if you have 2GB of RAM, up to 2GB of swap could conceivably be useful. If you have 4GB Of RAM, then there's no point in swap at all.
These considerations go away if you use a 64 bit OS, of course.
The Parliament posts its order of business .. here:
http://www2.parl.gc.ca/HousePublications/Publication.aspx?Pub=status&Language=E&Mode=1&Parl=39&Ses=2
This supposed "Super-DMCA" is nowhere on the list of house or private members bills.
The government never gets through its order of business anyways, so if this thing is supposed
to get tacked onto the end of the list at some future date, it's unlikely to even
get a reading during this session of parliament.
Sure smells like fear-mongering, rather than anything serious..
Disk encryption is all well and good, but in an enterprise setting it can be a tad
expensive to deploy and support. Keep in mind that the disk is typically encrypted using a key
unlocked using or derived from a pre-boot-authentication password.
A big problem that comes up again and again is that users forget their PBA password
at the most inopportune of times. Imagine a user off in the middle of nowhere, calling
a central help desk on his satellite phone or some such, asking for help because he
forgot his PBA password.
A smart vendor has workarounds for this, such as single-use override passwords to
unlock the workstation until the user can "come in from the cold." An even smarter
vendor enables access to this using a phone plus an automated IVR system, so that
said user can self-authenticate (example: voice print) and fix his own problem.
This is a big deal because help desk calls cost money (typically $20 to $50 per call),
and in an enterprise (the RFP calls for 50k users minimum), we're talking tens of
thousands of such calls annually.
I know that at least one vendor handles this stuff right (PointSec). Not sure about
the others, but it's a very important consideration...
-- Idan
I've been involved in hundreds of password management system
..."
t ml
deployments, so perhaps I can make some helpful observations:
* Users who are required to comply with a strong password
policy, and must change their password often, will sometimes
be unable to think of a new, compliant password, and will
appreciate the random passwords offered.
* Randomly-generated passwords should be pronounceable, to help
users remember them. Otherwise, you're just asking for sticky notes.
* There are good random number generators in all modern OSes.
These take entropy inputs from the network, keyboard, etc. and
are basically impossible to defeat. "Randomness" is not a
realistic problem.
* If users will have to choose strong passwords, and to change their
passwords often (all good things), then the requirements should
be clearly communicated, both ahead of time and when the user
must choose a password. Don't tell the user "pick a hard to guess
password" -- tell him "pick a password with minimum N chars,
including letters, digits and punctuation marks, mixed case, that
is not derived from a dictionary word or an old password,
* Do require periodic password changes -- this is your only defence
against compromised passwords and weak password stores.
* You can see some of these features here (Flash demo):
http://psynch.com/overview/presentation-demo/04.h
Cheers,
-- Idan
sellinabox.com
It's not that hard to enforce strong password rules at the time of password change .. and consequently
our customers require always-new passwords, enforce dictionary checks, and can even apply regular expression rules.
(psynch.com if you're really curious).
I later installed Linux on the same laptop, with no problems.
My synopsys, shared with Doug Miller, was:
"If the vendor pre-installs the OS, then no problem, regardless of OS. Otherwise, without vendor support, Linux is much easier than WinNT / Win2K to install."
I wonder if he got different information from others?
As a software vendor, I can describe what we
actually do, and why:
(1) We build HTML and PDF using LaTeX (single source is important).
(2) HTML goes on our WWW site
(3) PDF goes on both our WWW site and our shipping software, which incidentally is also delivered electronically.
(4) Most customers print one or two copies of the PDF docs.
This means that we (the software vendor) only
produce electronic docs, but customers can
have as many printed ones as they like. PDF
really is just as good as printed copy -- just
print it to get beautiful output.
There are major advantages to this approach:
(1) No printing cost to the ISV (minor to the user)
(2) No or lower shipping cost
(3) No documentation inventory. This is a big
problem if you have a rapid development
cycle.
(4) Much faster delivery of current docs.
I simply can't imagine why anyone would want to receive bulky paper manuals! If you want it printed (and I can relate), just print as many copies as you like from a nicely formatted PDF..
:-)
-- Idan
IMHO, the best way to remember lots of passwords
is to synchronize them. First, you select a
hard to guess value. Select 2 or 3 if you
access some systems that you are afraid might
be compromised (e.g., local servers vs. public
WWW sites). Then, apply that password to every
account you have. voila - you don't have to
remember a million passwords.
with this in mind, we make / sell a commercial
package for synchronizing passwords:
http://www.psynch.com
-- Idan
Factoring 512-bit rsa is known to be doable,
.... ;-)
and has been done in public before (recently,
I think).
Using quantum computing to implement massive
parallelism is also possible, at least in theory.
If these guys are for real, then 1024-bit
RSA may also be vulnerable, and in fact larger
keys which are feasible to calculate on a
conventional computer may also break soon.
So... the bottom line is that either this is
a hoax, or else it's not only plausible, but
actually true, in which case the computer security
world is about to be turned on its head!
Interesting times
-- Idan
We run a couple of Oracle instances on a small
Linux box, with several hundred megs each. While
I can't give comparative numbers (don't use NT
or Solaris), I'd say it performs well, and has
been quite robust.
We *did* have a corrupt disk block a while ago.
That was our only downtime. I'm not sure if it
was Oracle or Linux or hardware. I tend to
blame hardware in this case.
Why not give it a try? I imagine that performance
is dominated by I/O and memory, rather than O.S.
in this case, so if you like Linux, go for it.
Just get a suitable box.
Regards,
-- Idan
Agreed. Terminating just the offending code
makes more sense. The question of jurisdiction still remains, however. Any thoughts? Perhaps IBM's home in New Jersey?
-- Idan
I think IBM means well here. What they need
is an alternate way to protect themselves
against patent infringement violations and
the resulting liability.
Perhaps something along the lines of:
"if a party other than IBM is found by a
(what jurisdiction?) court to hold a patent
which applies to this software, then that
party may require IBM to pay fees for use
thereof. In this case, IBM may elect to
terminate this license."
This reduces the problem by:
1) Eliminating IBM itself from being
the hypothetical antagonist.
2) Requiring a court to demonstrate that
IBM is in violation before proceeding.
I think that realistically (1) is unlikely
since IBM is sincerely contributing to the open
source community.
(2) Allows IBM to get out of a tough situation
where they inadvertently violated someone else's
patent. I don't think (2) is likely to happen.
Any thoughts?
-- Idan
Agreed. Canadians, myself included, should buy
our blank media elsewhere.
Perhaps the companies that sell media will make
lobby to drop this nonsense when their revenues
dry up!
-- Idan