Well it was a rather belts and suspenders plan. The platters were also encrypted, but we preferred to have as much plausible deniability as possible to avoid the 5$ wrench attack against crypto. (http://xkcd.com/538/) The exec REALLY wanted to avoid the 5$ wrench attack. :)

Min

Lack of a single identifying number is not an insolible problem.

Take Canada for example. We have a social insurance number (SIN - way better acronym :)). It is ILLEGAL to require it for anything other then tax purposes (in effect that means your employer and your bank if you have a savings account for most people).

If you go to buy a car, and they want to pull a CB on you, you can say no. If you refuse to provide a SIN, they will match you based on a compound key. (Name, address, telephone, previous address etc).

Ya, some times you get a mismatch, but those are relativity rare and usually resolvable if the person who happens to generate a mismatch isn't attempting fraud. I doubt requiring that SIN would improve things, it'd just provide more opportunities for it to be stolen, as we see in the US.

Does fraud happen? Yep, or I'd be out of a job. Is it common? Nope.

Min

I have in the past provided the following instructions to an exec:

1) Go to local computer store
2) Purchase off the shelf hard drive with this model:xxx-xxxx-xxx - pay with local cash
3) Purchase philips screw driver
4) Remove HDD (more details here on how to remove a HDD) and replace with local drive.
5) Drive over old HDD with rental SUV. Repeat until fragments. Ensure HDD platters are fragments.
6) drop into at least 3 random trash bins in tourist areas
7) If questioned during exit, inform them that the computer crashed and that IT had you take it to a local repair shop but it's not working still.

Such is life in the odd world we live in.

Min

"Good for Apple to show contempt for them"

I think this word will feature prominently in the judge's reaction too.

Min

Who needs a back door when you have a range of security vulnerabilities to choose from.

Here's the slide deck from the talk on Huawei talk at Defcon 20 this year. At the end of the talk the presenter addressed the topic of backdoors by saying (my paraphrase) given the state of the code, who knows if a given hole is a backdoor or unintential security vulnerability.

The deck is worth a read if only for the fortune cookie slides, which contain actual quotes from the object code:
http://phenoelit.org/stuff/Huawei_DEFCON_XX.pdf

Min

I'm 39(!) now so I did the school thing in the 80s mostly.

My elementary had C-64s, mostly due to fund raising efforts by the Parents Auxiliary (PTA/School Council/etc.) In the first few grades the teacher's didn't know much, and most of my 'education' came in giving tech support to the teachers as I had one at home.

Mostly they were running software from the Commodore educational software bundle. (Oregon trail! Never mind that we're Canadian students and the Chilkoot trail would have been more topical) Also I remember playing quiet a bit of artillery duel.

That continued to about grade 6 where I met a teacher who had actually decided that this was interesting stuff. He got deeply into Logo, and taught us all the basics of procedural programming using it.

This continued until highschool where we moved to PS/2 systems, and the wonders of Netware. By this time computers had become more mainstream and the games were being traded in the halls. None in the computers at school tho.

One of my teachers had a rule - if he caught you playing games in class, he'd take your 3.5" floppy and stab it with a pin about 10 times. If it still worked, you could use it.

Of course I gamed that system. Brought in two identical floppies. One pre-holed, formatted to map out the bad blocks and games installed after bad blocks were marked out. The other was pristine. When the teacher caught me and stabbed the disk, I swapped it with the working one, and miracually it worked.

I suspect I got away with it because the teacher knew full well he wasn't teaching me anything (by this point I was running a fidonet node (if you don't know what it is, look it up you whippersnapper :)) and using material from the echomail in school reports, with proper attribution of course :). Was always cool when I could include in a current affairs report the viewpoints of people living through the events.

In typing class we were still using C-64s. My big irritation there was that the software they were using disabled the backspace key and COUNTED HITTING IT AS AN ADDITIONAL TYPO. Because typewriters don't have backspace keys.

Fortunately the software was written in C-64 basic so I found the code and 'fixed the bug for them'... I may not have asked for recognition for my work tho! :).

Next up was Grade 10/11 Comp sci. Here we met Turbo Pascal. Again I outpaced and discovered Advance Placement Comp Sci which is how I finished my high school CS classes.

Min

> open mailbox
OK.
> mail absentee ballot
OK.
> wait
Nothing changes.

The future is dark.
You are eaten by a guru.

Waitaminute... immoral?

We're talking about someone choosing to give up their PII as a consensual act.

That's my right to choose to trade information about myself.

Ill advised? Arguable. Immoral? No.

Min

Disclaimer: I work in the field, but do not have nearly enough information on your particular situation, jurisdiction, etc to provide detailed recommendations. What follows is basic best practice stuff based on my jurisdiction and market sector.

* First, any sensitive information you are collecting, ask if you really REALLY REALLY need it. This stuff is toxic waste. Your first and best defense is not to store it if you don't need it.

* A hash of something like a SSN, Telephone number, etc is worthless in terms of protecting you. Hashes are only useful if the search space is large enough to make the full space search computationally unfeasible. 1 billion SHAs is not computationally unfeasible. Also typically hashes are only useful if what you want to do is compare two values, e.g. passwords. If you're trying to anonymize, hashing a PII (personally identifiable information) element doesn't anonymize the data as it doesn't break the PII link.

* DON'T WRITE YOUR OWN ENCRYPTION. EVER. Unless you have a deep deep background in crypto and submit your alg for peer review for years before using it, just don't.

* Consult a good lawyer. There can be pits in here that you might not think of, particularly if you don't have a security dept with someone who spends their time dealing with privacy issues. A good lawyer won't say "You can't do that" a good lawyer will outline the risks that you will be running and let you accept them - just like a good risk mgmnt dept will

* Use the security controls in your database. If your client doesn't need to access the hashes because they're being computed by a stored procedure then the user your client accesses the database shouldn't have access to the hashes. Same goes for salts only more so. I've seen too many apps written using one user for everything. Don't do this.

Hope some of that helps you.

Min

You might also check out http://www.canadawebhosting.com/. I've been involved in several projects using them and been happy with the results.

Min

Wow - Mod this one +1 Honest :)

Min

Typically people don't TYPE their VoiP conversations... and usually you don't use a mic to bug a keyboard and get keystrokes...