Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:THIS IS A FARCE (Score 1) 510

by Ire (#31980668) Attached to: Mass. Data Security Law Says "Thou Shalt Encrypt"

You don't need to search by name? As I understand the law, (which may be very incorrect) First and Last name, or other identifying information is what makes a record sensitive, under the law.

That is incorrect. Name combined with any number of those other pieces of information is what makes the record sensitive. The pieces by themselves is not considered sensitive.

Also, searching by TIN, is very useful when finding accounts.

What's wrong with name, address, phone number, account number, invoice number, PO number, support record number or the like?

If they have none of those, you really have no business pulling up the account for them. If they do have them, you don't need the index on the sensitive information.

Comment: Re:THIS IS A FARCE (Score 2, Insightful) 510

by Ire (#31977382) Attached to: Mass. Data Security Law Says "Thou Shalt Encrypt"

Simple solution. Encrypt the sensitive information before storing it in the database. Leave all of the other information unencrypted. You don't need to search by the sensitive fields anyway, so the inability to index them doesn't matter.

Use filesystem/os level support for locking down the key on the system that needs to be able to decrypt it so that only the account/application authorized to access it can. That limits the vulnerabilities a single system. Even once on that system it is limited to "root" and the actual application.

Now you may safely let any number of insecure systems query your database. You can use trivial database backup schemes with no additional encryption. You don't need to worry about the physical security of those backups. Since you only need to backup the key when you first generate it, there is never any danger of the key and backup data being lost together in transit.

There is no speed penalty anywhere in the system except the sensitive parts.

Comment: Shortfall is self inflicted (Score 2, Interesting) 480

by Ire (#16757571) Attached to: IT Worker Shortages Everywhere
Companies outsource the entry level positions and only direct hire senior level positions.

The problem is that without the junior level positions, you'll not increase the number of senior level workers. As technology changes, new senior level positions are created and the existing senior level people move to it. So now you have the same senior level people filling both the old jobs and the new jobs but no new senior level people being created.

No company wants to do the training, because it costs them a lot of money. They don't even save money when the employee is more experienced since they have to give them significant raises to keep them from going elsewhere. Every company thinks they can save on training by hiring away these people, but since nobody is willing to train them in the first place, they just don't exist.

Lack of qualified workers? That just means that the company is trying to skimp on training.

[Crash programs] fail because they are based on the theory that, with nine women pregnant, you can get a baby a month. -- Wernher von Braun