Attitude makes all the difference. I enjoy finding the bad guys who are actually maliciously doing something bad and stopping them. It's rewarding to pull up a list of things you've accomplished and say, "See? I stopped these guys who stole a thousand dollars a day from us!" Do I care what kind of people they were? No. Do I care why they were stealing? No. Do I care what crap happens to their lives after being convicted of theft? Not really. Once someone has crossed that line of stealing from the company, I have zero sympathy. I even take it a little personally: they're stealing value from my stocks, from my retirement, and they're causing higher prices for our non-thieving customers.
And yes, sometimes you will get sucked into seeing the worst of humanity. A friend of mine is occasionally involved in investigating some seriously sick crap, but again he has to look at it from a different viewpoint: "Did he stop a pedophile? Did he help a child?"
Focus on the good things your job is accomplishing. You're keeping the network safer. You're protecting the integrity of your data. You're keeping thieves out of the honey jar. You're protecting your company's good name and image. Those are accomplishments to be proud of.
A platform with infinite flight time, but zero payload capability is of no use..
You're probably too young to remember seeing them, but the Echo series of communications satellites were simply 100 foot diameter mylar balloons. They were passive -- they had no payload at all -- but NASA was able to bounce radio signals off of them.
A stationary "mirror in the sky" might make for a good way to bounce radio signals into and out of a hostile area without the power requirements needed for satellite communications.
Just because there is no apparent practical application doesn't mean there will never be one. I am frequently amazed at what people can do with the simplest things.
Spring steel? Bah! 1060 is crap for weapons, too. Do you want the blade to go dull before you finish sharpening it? You want a good high carbon shock resistant tool steel that's had the edges properly heat treated.
What would be interesting is if somebody bothered to get the opinions of everyone before going out and stating their position on an issue. Would that be so hard to do?
Because that's not how it always works.
I want politicians who have their own views on issues, and state them up front. I then pick the candidate whose position on the issues align most closely with my priorities.
If a candidate makes an about-face based on the results of popular opinions, as opposed to making solid decisions based on facts, then I'm voting for someone who is promising to flap with the wind. In Kansas, that would mean a politician might bow to the numerically-superior-but-intellectually-flawed Intelligent Design thugs, and that's the very last thing I would want.
Now, if a candidate doesn't have a strong opinion on a particular issue, then a poll of his potential constituents is probably a good place to form one. But those usually aren't the issues I care about.
I think that's how a lot of logging starts out, but you should learn from "the lazy programmer" lesson here. If you're going back to cull out the logging statements, comment stuff out, whatever, it's time to plan out a more advanced logging system.
About eight years ago we got sick of the "go back and edit the printf()" philosophy, and created a set of macros that wrapped our tracing. The original design goal was to make our TRACE macro have the same syntax and flexibility as printf(), while giving us the ability to set detail levels and log errors. We ended up with a pretty simple logging API wrapped in a.h file. Keeping it simple was key to getting people to use it instead of printf(). Once we had been using that for a few years, we went back and replaced the guts of the tracing code with more efficient, controllable code. We added a dynamically loaded module that uses an in-memory trace queue with a threaded backend that does the actual disk I/O, it responds in real-time to changes in logging levels, does the log file maintenance, and in general performs fast in all kinds of situations. All while keeping to the same simple API as the original TRACE macro stuff, so everything is fully backward compatible.
It only took a little while to create the original API, and it certainly took more time to replace the engine with a more efficient model. But the end results are consistent, controllable, high performance tracing. The static API is as thin as it can be to avoid recompiling other components. The dynamically loaded engine gets upgraded every so often as new requirements come along. And the API even allows the program to continue to run if the tracing engine can't be loaded, following the idea that application uptime is more important than tracing.
Total cost? Less than the time we've saved fixing the bugs we've found with it. If we had to do it again, I'd rather use a common component such as log4xxx than to roll my own, but I'd still want to isolate it behind my own wrapper to meet our requirements. Actually, with our design, I could replace our tracing object with a log4xxx type component without changing our application code (but I'd still have to recompile.)
While I agree with just about everything you mentioned, I would separate out audit trails and accounting/billing from the same class of logging as health monitoring and troubleshooting. Accounting and billing are functional requirements (and auditing is close behind that, especially with regulatory compliance,) whereas health monitoring and troubleshooting are non-functional requirements. Accounting and billing typically have their own specs, and really are deserving of their own feed. They shouldn't be mixed in with the support requirements for identifying problems, or developer requirements for determining root causes and fixing the bugs.
I'm not saying that your troubleshooters won't be looking at the accounting data, but that the accountants will have no need for the typical "Created BillingObject / Destroying BillingObject" kind of logging.
We have a computer rack installed at each of our many satellite locations, and a main data center. The satellite racks are now filled with individual application servers and networking gear, and the tiny closets where they are installed are maxed out as far as energy consumption and cooling. We are fast approaching physical limits for how much code we can afford to add to these remote sites, and inefficient code makes the problem worse.
Calling MythTV impractical and irrelevant is overly pessimistic.
Calling MythTV practical and relevant may be overly optimistic. Sure, you may be just a computer, a tuner, and a few clicks away from a Myth box, but to my 70-year-old in-laws, it's as unreachable as the moon.
Strangely enough, they had no problems replacing their TV with an HD TV, or using the DVR built into their satellite receiver. And they love it! The signal is crystal clear. My mother-in-law records her soap operas during the day and watches them at night. They pause TV to answer the phone. They use the grid to find shows to watch, and no longer have a paper TV Guide laying around.
I certainly wouldn't have guessed that my in-laws would have adopted "modern technology" -- after all, they don't now and may never own a computer. But to them this is just a "new TV" and I think every American, regardless of age, is genetically predisposed to being able to figure out how to watch TV.
Most of you have only yourselves to blame for this because the vast majority are gladly buying into HDMI. VGA works good, digital-out works best. And guess what? No drm!!
HDMI is not the problem. HDCP is the problem. HDMI supports HDCP, but by itself it is not a DRM enforcer.
By placing the memory only under control of a cryptographic processor on the smart card, and by burning a private key into each card, you can build a secure end device, which results in an effective smart card system. Home satellite dishes fought this battle 10 years ago, and are fairly successful at stopping piracy today.
That is not the way the MiFare cards work, of course.
The drawback to an effective system is that you need to distribute both private and public keys all over the place: the cards need keys and the buses need keys. It's theoretically possible to distribute a unique key per card, and to have a list of all outstanding valid cards public keys on each bus, and then update each bus every night. But it's a lot easier to simply have one private key in all your system's cards and trust that nobody's broken it, which is what most practical systems do today.
Of course there's another aspect that everyone's ignoring with this whole shebang: what is the value of what they are protecting? Are they looking at stopping $100 per month lost due to hacked cards? $10,000 per month? If thieves don't exploit this, spending ten million dollars to replace the current system is hardly worth it.
Simple smart card technology can include some write-once memory that burns a fusible link, preventing it from being rewritten. Old pay-as-you-go stored value telephone cards used to use this. They were for use in pay phones. The routine was simple: one bit equaled one unit of value. As the value was used, the pay phone would signal the card to burn out the next bit. Once the bits were all burnt, the card had no value.
Of course this was defeated by hackers, who replaced the card with a computer controlled card simulator. Whatever the phone asked of the card, the simulator gave the proper responses. The "copy protection" consisted of some timing and voltage tests that the simulators still found easy to reproduce.
I hope the method used to capture the debit pins becomes known, I still have retail networks to secure.
As you no doubt are aware, most debit PINs are encrypted using DUKPT for key exchange. But it wasn't until very recently that PCI PED required compliant devices to use 3DES, and not DES. Back when these attacks started showing up in 2004, plain-old DES was still an accepted standard. It's entirely possible that they could have brute forced the BDK with something like a meet-in-the-middle attack.
These guys obviously had access to metric boatloads of computrons. They may even have hijacked the retailer's own computers to run a distributed key cracker!
Add some random salt to the SSN before, and it automagically becomes as secure as any 160-bit hash.
While it will keep the single instance of the SSN secure, it doesn't work as a customer ID because it's not repeatable. If your customer returned tomorrow, you would be unable to arrive at the same hash value because you wouldn't generate the same random salt. And if you don't care what the value is, and you can't reverse it, then why keep it at all? You may as well use nine zeros, or an incrementing sequence number, or just delete the field altogether.
Or did you mean to use a random salt the same way unix crypt uses a salt (keeping the cleartext salt with the hashed data?) Again, it's attackable via dictionary; you just have to dictionary attack each SSN one at a time. Pre-generated rainbow tables won't work, but any particular SSN can be broken in a few hours.
There's yet another salted-hash alternative, which is to generate and distribute one instance of a random salt, then apply it to the hashing of every SSN. It's repeatable, so you can generate the same hash for the same SSN day-after-day. But at that point you have to protect the salt exactly the same as you would protect a symmetric encryption key, otherwise an attacker could learn your salt and build a complete dictionary in short order. In that case, since you're now in the business of keeping secrets, you are better off using reversible encryption such as AES. That way you're not tempted to think the salt isn't as critical as a key.
To prevent this, you might think to construct a "hashing oracle", which would be a service on a protected machine that hashes SSNs while securely protecting the secret salt. But there's a nifty attack against this, too. If the attacker can call your oracle, the attacker doesn't even have to know how your hash works. They can simply use your oracle to build their dictionary. It may not be as fast as generating them locally on my desktop, but it works the same way. (Intrusion detection systems and other monitoring tools can help mitigate this risk.)
Beware. Hashing SSNs is dirt-easy to crack with a dictionary attack. There are only 10^9 possible SSNs. Let's say you hashed them all with SHA-1, which I have personally benchmarked on my crappy 4-year-old desktop machine at 50,000 hashes per second. That means I could test every possible hash of an SSN in 20,000 seconds, or about 5-1/2 hours.
And I have, to prove the point to one of our teams that was proposing this exact same system.
It is "sort-of" possible to do it securely, but your protocols and access to such a system have to be guarded as closely as if you were dealing with the secret encryption key to the real SSN database. You need logged and restricted access to the queries, and you need an intrusion detection system watching for anomalous activity, such as a large number of sequential requests for hashing coming from IP address 10.1.2.3.
No matter what, it's not easy and it's barely secure, even though it sounds great to management: "Hey, boss, I protected all our SSNs using SHA-1 which has 160 bit hashes which Bruce Schneier says are almost unbreakable!"
A much better approach is to ask yourself why you are storing customer SSNs in the first place? Customer SSNs should be treated as transitory data, used for the initial credit application (or whatever) and then discarded. Something else should be used as the long-term "customer number."
The cure has to come from the tip-top, as well. Your company needs a Chief Information Security Officer, meaning an executive with a seat on the board. The CISO needs the support from the board to write these policies, the authority to punish violators (including the UberSalesGuy in marketing,) and the balls to do so when necessary. He also needs to be qualified for the position, and to have a qualified and competent staff working for him.
The best way for that to work is for the CEO to introduce him and sell him to the rest of your shop: "Here's Mr. Smith, he's our new CISO, and he'll be responsible for *anything* relating to information security. That means *everyone* will follow our policies regarding information security, including me. Our company would be sued out of existence if we had a breach like this one (point to random news article about the most recent data breach) and we simply can't afford it.
"He's going to write up some policies that we all must follow, and then he'll be creating Tiger Teams to help you get your laptops cleaned up of sensitive data. Don't worry, we'll fully help and support you in following the policies; but if you bypass them, it will be your job."
And Mr. Smith better be competent. He needs to produce those clear policies quickly, and he needs to get programs in place to begin securing all your info system assets. There's a lot to the job.
I completely agree. I long for a "three strikes" law for congressmen. If you vote "yea" on three bills that have ANY component overturned for unconstitutionality, you lose your pension, federally funded benefits, and even perhaps have to repay your salary and any perks you obtained as a member of congress.
And for the president who signs three laws that are found unconstitutional? Impeachment for violation of their oath to uphold the constitution. Removal of their Secret Service protection. Revocation of their passports. Cut off any taxpayer funded benefits. And revocation of any other laws they signed, because they were an obviously incompetent officeholder.
I want Congress and the president utterly frightened to pass new laws. They shouldn't be able to just "pass something and see how it turns out." They haven't passed any good ones in the last 50 years or so, and I have very low expectations that they'll figure out how to do it better any time soon. So I want something really solid protecting me from them and their special interests.
As for me, Snow Crash is the only reason I buy any of his books.
I've bought every stinking thing Neal has ever written simply because he wrote Snow Crash, and I have this weird, vain hope that he might again someday write a book even half as brilliant. So I'm out a couple hundred bucks, and have a lot of disappointment sitting on shelves in my library, but I'll likely buy Anathem the day it comes out, too.
Just in case it's another Snow Crash. Please let it be another Snow Crash.
My guess is it started as a stupid bar-bet kind of discussion: "how would you get the gold out of the middle of a rock? Heat the stone, and melt the gold!" And Neal replied, "Hey, I bet I can write a story where that's the ending."
Later, he was reading Ross Anderson's page and came across his Van Eck stuff and said, "hey, I just figured out a clever way to defeat this. I bet I can add this to my story!"
Finally, he was reading Schneier's Cryptogram, and discovered the Solitaire cryptosystem. The light came on, and he said "I know exactly where to put this in my story!"
So now he's got three tricks, which he calls a "plot". He throws in a handful of random historical Nazis, some computer geeks, a beautiful girl, a GPS unit, and then starts writing. When he gets to page 915, he stops writing and calls his publisher.
As for my opinion, I think point of sale machines should focus on minimizing the distance between the arms in rest state, versus work state (such as running items over the scanner), and arms in keyboard input state. Eyes move faster than fingers, fingers move faster than hands, hands move faster than arms, arms move faster than legs. The most frequent actions ought to be optimized to use the fastest of those, the least frequent to use the slowest.
That's the basis for some of our time and motion studies: how to keep the cashier's movements to a minimum while permitting them to continue to face the customer AND get the merchandise scanned and bagged. Notice that the register software itself almost doesn't enter into this. The fastest key to hit is the one you don't have to hit at all.
That's why we use audible feedback (beeps) to tell the cashier both "item scanned OK" and "hey, there's a problem, stop scanning and pay attention to the screen." It makes for a somewhat noisy environment, but it permits the cashier to use the system while only having to touch the keyboard once or twice per transaction.
The harder problem with these studies is that they usually end up recommending expensive checkout lane redesigns. New stores will get the benefit, but old stores typically won't see an improved layout until their next remodel, if then.
Point of Sale systems generally follow a user experience model of "hit a function button to tell the register what you are going to do, accept some input, hit another function button telling what you are going to do next, accept more input, repeat as required." Much of this comes from the old days of mechanical tabulators: key an amount, hit sale, when they're done hit total, the bell goes 'ding' and out pops the till, with the amount due displayed in digits at the top of the register. Of course nowadays the scanner reads the barcodes, the register looks up the prices, the customer swipes their card, and the cashier just has to hit total at the end.
Of course, that's the happy path. If the customer wants something different, such as a discount because the package is opened, the cashier now has to figure out how to give them that discount. An old cash register would have a "discount" button. But custom buttons are very expensive, because you're very limited as to how many you can fit on a keyboard. (Modern register applications have hundreds of constantly changing context-sensitive functions.) Instead, current cash register applications display the word DISCOUNT on the screen, with instructions on how to take that discount. On a normal desktop computer, they might display the word DISCOUNT on a button, and the user would click it. If it's a touch screen, the operator simply touches the word. For Dynakeys, the word DISCOUNT would appear with an arrow pointing at the button next to it (Dynakeys are quite similar to the buttons surrounding a Diebold ATM screen.) And if it's keyboard only, the screen might say "Press F1 for DISCOUNT".
So on a touch screen, the operator looks for the word DISCOUNT then touches it. On a keyboard, there are two steps: the operator looks for the words DISCOUNT-F1 and then presses F1. Common sense would make many people expect that two steps would be slower than one, but we demonstrated that wasn't the case. While we all expect experienced operators will eventually learn F1==discount, we didn't expect the act of reaching up and touching the screen would be as slow as the two-step process for the new hires.
The lesson is to perform extensive usability testing before pronouncing anything "extinct" or "victorious". Real users will surprise you every single time.
I believe "track stick" refers to the little rubber eraser-like device mounted in the center of a laptop keyboard. It's that thing that moves the pointer either too slow or too fast around the screen when you're sick of using the crappy trackpad.
Slashdot Mirror
Attitude makes all the difference. I enjoy finding the bad guys who are actually maliciously doing something bad and stopping them. It's rewarding to pull up a list of things you've accomplished and say, "See? I stopped these guys who stole a thousand dollars a day from us!" Do I care what kind of people they were? No. Do I care why they were stealing? No. Do I care what crap happens to their lives after being convicted of theft? Not really. Once someone has crossed that line of stealing from the company, I have zero sympathy. I even take it a little personally: they're stealing value from my stocks, from my retirement, and they're causing higher prices for our non-thieving customers.
And yes, sometimes you will get sucked into seeing the worst of humanity. A friend of mine is occasionally involved in investigating some seriously sick crap, but again he has to look at it from a different viewpoint: "Did he stop a pedophile? Did he help a child?"
Focus on the good things your job is accomplishing. You're keeping the network safer. You're protecting the integrity of your data. You're keeping thieves out of the honey jar. You're protecting your company's good name and image. Those are accomplishments to be proud of.
A platform with infinite flight time, but zero payload capability is of no use..
You're probably too young to remember seeing them, but the Echo series of communications satellites were simply 100 foot diameter mylar balloons. They were passive -- they had no payload at all -- but NASA was able to bounce radio signals off of them.
A stationary "mirror in the sky" might make for a good way to bounce radio signals into and out of a hostile area without the power requirements needed for satellite communications.
Just because there is no apparent practical application doesn't mean there will never be one. I am frequently amazed at what people can do with the simplest things.
don't you just hate that word? it sounds like someone throwing up "blooooooog!"
Actually, I just hate the politics. They make me make that sound.
Spring steel? Bah! 1060 is crap for weapons, too. Do you want the blade to go dull before you finish sharpening it? You want a good high carbon shock resistant tool steel that's had the edges properly heat treated.
:-)
What would be interesting is if somebody bothered to get the opinions of everyone before going out and stating their position on an issue. Would that be so hard to do?
Because that's not how it always works.
I want politicians who have their own views on issues, and state them up front. I then pick the candidate whose position on the issues align most closely with my priorities.
If a candidate makes an about-face based on the results of popular opinions, as opposed to making solid decisions based on facts, then I'm voting for someone who is promising to flap with the wind. In Kansas, that would mean a politician might bow to the numerically-superior-but-intellectually-flawed Intelligent Design thugs, and that's the very last thing I would want.
Now, if a candidate doesn't have a strong opinion on a particular issue, then a poll of his potential constituents is probably a good place to form one. But those usually aren't the issues I care about.
I think that's how a lot of logging starts out, but you should learn from "the lazy programmer" lesson here. If you're going back to cull out the logging statements, comment stuff out, whatever, it's time to plan out a more advanced logging system.
About eight years ago we got sick of the "go back and edit the printf()" philosophy, and created a set of macros that wrapped our tracing. The original design goal was to make our TRACE macro have the same syntax and flexibility as printf(), while giving us the ability to set detail levels and log errors. We ended up with a pretty simple logging API wrapped in a .h file. Keeping it simple was key to getting people to use it instead of printf(). Once we had been using that for a few years, we went back and replaced the guts of the tracing code with more efficient, controllable code. We added a dynamically loaded module that uses an in-memory trace queue with a threaded backend that does the actual disk I/O, it responds in real-time to changes in logging levels, does the log file maintenance, and in general performs fast in all kinds of situations. All while keeping to the same simple API as the original TRACE macro stuff, so everything is fully backward compatible.
It only took a little while to create the original API, and it certainly took more time to replace the engine with a more efficient model. But the end results are consistent, controllable, high performance tracing. The static API is as thin as it can be to avoid recompiling other components. The dynamically loaded engine gets upgraded every so often as new requirements come along. And the API even allows the program to continue to run if the tracing engine can't be loaded, following the idea that application uptime is more important than tracing.
Total cost? Less than the time we've saved fixing the bugs we've found with it. If we had to do it again, I'd rather use a common component such as log4xxx than to roll my own, but I'd still want to isolate it behind my own wrapper to meet our requirements. Actually, with our design, I could replace our tracing object with a log4xxx type component without changing our application code (but I'd still have to recompile.)
While I agree with just about everything you mentioned, I would separate out audit trails and accounting/billing from the same class of logging as health monitoring and troubleshooting. Accounting and billing are functional requirements (and auditing is close behind that, especially with regulatory compliance,) whereas health monitoring and troubleshooting are non-functional requirements. Accounting and billing typically have their own specs, and really are deserving of their own feed. They shouldn't be mixed in with the support requirements for identifying problems, or developer requirements for determining root causes and fixing the bugs.
I'm not saying that your troubleshooters won't be looking at the accounting data, but that the accountants will have no need for the typical "Created BillingObject / Destroying BillingObject" kind of logging.
Mod parent way up.
We have a computer rack installed at each of our many satellite locations, and a main data center. The satellite racks are now filled with individual application servers and networking gear, and the tiny closets where they are installed are maxed out as far as energy consumption and cooling. We are fast approaching physical limits for how much code we can afford to add to these remote sites, and inefficient code makes the problem worse.
Calling MythTV impractical and irrelevant is overly pessimistic.
Calling MythTV practical and relevant may be overly optimistic. Sure, you may be just a computer, a tuner, and a few clicks away from a Myth box, but to my 70-year-old in-laws, it's as unreachable as the moon.
Strangely enough, they had no problems replacing their TV with an HD TV, or using the DVR built into their satellite receiver. And they love it! The signal is crystal clear. My mother-in-law records her soap operas during the day and watches them at night. They pause TV to answer the phone. They use the grid to find shows to watch, and no longer have a paper TV Guide laying around.
I certainly wouldn't have guessed that my in-laws would have adopted "modern technology" -- after all, they don't now and may never own a computer. But to them this is just a "new TV" and I think every American, regardless of age, is genetically predisposed to being able to figure out how to watch TV.
Ever hear of the anal log hole?
Does that mean Sensenbrenner is a "Log Cabin Republican"?
Most of you have only yourselves to blame for this because the vast majority are gladly buying into HDMI. VGA works good, digital-out works best. And guess what? No drm!!
HDMI is not the problem. HDCP is the problem. HDMI supports HDCP, but by itself it is not a DRM enforcer.
By placing the memory only under control of a cryptographic processor on the smart card, and by burning a private key into each card, you can build a secure end device, which results in an effective smart card system. Home satellite dishes fought this battle 10 years ago, and are fairly successful at stopping piracy today.
That is not the way the MiFare cards work, of course.
The drawback to an effective system is that you need to distribute both private and public keys all over the place: the cards need keys and the buses need keys. It's theoretically possible to distribute a unique key per card, and to have a list of all outstanding valid cards public keys on each bus, and then update each bus every night. But it's a lot easier to simply have one private key in all your system's cards and trust that nobody's broken it, which is what most practical systems do today.
Of course there's another aspect that everyone's ignoring with this whole shebang: what is the value of what they are protecting? Are they looking at stopping $100 per month lost due to hacked cards? $10,000 per month? If thieves don't exploit this, spending ten million dollars to replace the current system is hardly worth it.
Simple smart card technology can include some write-once memory that burns a fusible link, preventing it from being rewritten. Old pay-as-you-go stored value telephone cards used to use this. They were for use in pay phones. The routine was simple: one bit equaled one unit of value. As the value was used, the pay phone would signal the card to burn out the next bit. Once the bits were all burnt, the card had no value.
Of course this was defeated by hackers, who replaced the card with a computer controlled card simulator. Whatever the phone asked of the card, the simulator gave the proper responses. The "copy protection" consisted of some timing and voltage tests that the simulators still found easy to reproduce.
I hope the method used to capture the debit pins becomes known, I still have retail networks to secure.
As you no doubt are aware, most debit PINs are encrypted using DUKPT for key exchange. But it wasn't until very recently that PCI PED required compliant devices to use 3DES, and not DES. Back when these attacks started showing up in 2004, plain-old DES was still an accepted standard. It's entirely possible that they could have brute forced the BDK with something like a meet-in-the-middle attack.
These guys obviously had access to metric boatloads of computrons. They may even have hijacked the retailer's own computers to run a distributed key cracker!
Add some random salt to the SSN before, and it automagically becomes as secure as any 160-bit hash.
While it will keep the single instance of the SSN secure, it doesn't work as a customer ID because it's not repeatable. If your customer returned tomorrow, you would be unable to arrive at the same hash value because you wouldn't generate the same random salt. And if you don't care what the value is, and you can't reverse it, then why keep it at all? You may as well use nine zeros, or an incrementing sequence number, or just delete the field altogether.
Or did you mean to use a random salt the same way unix crypt uses a salt (keeping the cleartext salt with the hashed data?) Again, it's attackable via dictionary; you just have to dictionary attack each SSN one at a time. Pre-generated rainbow tables won't work, but any particular SSN can be broken in a few hours.
There's yet another salted-hash alternative, which is to generate and distribute one instance of a random salt, then apply it to the hashing of every SSN. It's repeatable, so you can generate the same hash for the same SSN day-after-day. But at that point you have to protect the salt exactly the same as you would protect a symmetric encryption key, otherwise an attacker could learn your salt and build a complete dictionary in short order. In that case, since you're now in the business of keeping secrets, you are better off using reversible encryption such as AES. That way you're not tempted to think the salt isn't as critical as a key.
To prevent this, you might think to construct a "hashing oracle", which would be a service on a protected machine that hashes SSNs while securely protecting the secret salt. But there's a nifty attack against this, too. If the attacker can call your oracle, the attacker doesn't even have to know how your hash works. They can simply use your oracle to build their dictionary. It may not be as fast as generating them locally on my desktop, but it works the same way. (Intrusion detection systems and other monitoring tools can help mitigate this risk.)
This is not an easily solved problem.
Beware. Hashing SSNs is dirt-easy to crack with a dictionary attack. There are only 10^9 possible SSNs. Let's say you hashed them all with SHA-1, which I have personally benchmarked on my crappy 4-year-old desktop machine at 50,000 hashes per second. That means I could test every possible hash of an SSN in 20,000 seconds, or about 5-1/2 hours.
And I have, to prove the point to one of our teams that was proposing this exact same system.
It is "sort-of" possible to do it securely, but your protocols and access to such a system have to be guarded as closely as if you were dealing with the secret encryption key to the real SSN database. You need logged and restricted access to the queries, and you need an intrusion detection system watching for anomalous activity, such as a large number of sequential requests for hashing coming from IP address 10.1.2.3.
No matter what, it's not easy and it's barely secure, even though it sounds great to management: "Hey, boss, I protected all our SSNs using SHA-1 which has 160 bit hashes which Bruce Schneier says are almost unbreakable!"
A much better approach is to ask yourself why you are storing customer SSNs in the first place? Customer SSNs should be treated as transitory data, used for the initial credit application (or whatever) and then discarded. Something else should be used as the long-term "customer number."
The cure has to come from the tip-top, as well. Your company needs a Chief Information Security Officer, meaning an executive with a seat on the board. The CISO needs the support from the board to write these policies, the authority to punish violators (including the UberSalesGuy in marketing,) and the balls to do so when necessary. He also needs to be qualified for the position, and to have a qualified and competent staff working for him.
The best way for that to work is for the CEO to introduce him and sell him to the rest of your shop: "Here's Mr. Smith, he's our new CISO, and he'll be responsible for *anything* relating to information security. That means *everyone* will follow our policies regarding information security, including me. Our company would be sued out of existence if we had a breach like this one (point to random news article about the most recent data breach) and we simply can't afford it.
"He's going to write up some policies that we all must follow, and then he'll be creating Tiger Teams to help you get your laptops cleaned up of sensitive data. Don't worry, we'll fully help and support you in following the policies; but if you bypass them, it will be your job."
And Mr. Smith better be competent. He needs to produce those clear policies quickly, and he needs to get programs in place to begin securing all your info system assets. There's a lot to the job.
Or dramatically increase the size of beer cans to fit these inside. I'm not interested in "Fun Size" beers.
I always thought "Fun Size" beer went the other direction, like the size of a Foster's oil can.
I thought the next step would be to dramatically decrease the size of beer cans to fit in these miniature refrigerators.
I completely agree. I long for a "three strikes" law for congressmen. If you vote "yea" on three bills that have ANY component overturned for unconstitutionality, you lose your pension, federally funded benefits, and even perhaps have to repay your salary and any perks you obtained as a member of congress.
And for the president who signs three laws that are found unconstitutional? Impeachment for violation of their oath to uphold the constitution. Removal of their Secret Service protection. Revocation of their passports. Cut off any taxpayer funded benefits. And revocation of any other laws they signed, because they were an obviously incompetent officeholder.
I want Congress and the president utterly frightened to pass new laws. They shouldn't be able to just "pass something and see how it turns out." They haven't passed any good ones in the last 50 years or so, and I have very low expectations that they'll figure out how to do it better any time soon. So I want something really solid protecting me from them and their special interests.
As for me, Snow Crash is the only reason I buy any of his books.
I've bought every stinking thing Neal has ever written simply because he wrote Snow Crash, and I have this weird, vain hope that he might again someday write a book even half as brilliant. So I'm out a couple hundred bucks, and have a lot of disappointment sitting on shelves in my library, but I'll likely buy Anathem the day it comes out, too.
Just in case it's another Snow Crash. Please let it be another Snow Crash.
My guess is it started as a stupid bar-bet kind of discussion: "how would you get the gold out of the middle of a rock? Heat the stone, and melt the gold!" And Neal replied, "Hey, I bet I can write a story where that's the ending."
Later, he was reading Ross Anderson's page and came across his Van Eck stuff and said, "hey, I just figured out a clever way to defeat this. I bet I can add this to my story!"
Finally, he was reading Schneier's Cryptogram, and discovered the Solitaire cryptosystem. The light came on, and he said "I know exactly where to put this in my story!"
So now he's got three tricks, which he calls a "plot". He throws in a handful of random historical Nazis, some computer geeks, a beautiful girl, a GPS unit, and then starts writing. When he gets to page 915, he stops writing and calls his publisher.
Did I miss anything?
As for my opinion, I think point of sale machines should focus on minimizing the distance between the arms in rest state, versus work state (such as running items over the scanner), and arms in keyboard input state. Eyes move faster than fingers, fingers move faster than hands, hands move faster than arms, arms move faster than legs. The most frequent actions ought to be optimized to use the fastest of those, the least frequent to use the slowest.
That's the basis for some of our time and motion studies: how to keep the cashier's movements to a minimum while permitting them to continue to face the customer AND get the merchandise scanned and bagged. Notice that the register software itself almost doesn't enter into this. The fastest key to hit is the one you don't have to hit at all.
That's why we use audible feedback (beeps) to tell the cashier both "item scanned OK" and "hey, there's a problem, stop scanning and pay attention to the screen." It makes for a somewhat noisy environment, but it permits the cashier to use the system while only having to touch the keyboard once or twice per transaction.
The harder problem with these studies is that they usually end up recommending expensive checkout lane redesigns. New stores will get the benefit, but old stores typically won't see an improved layout until their next remodel, if then.
Point of Sale systems generally follow a user experience model of "hit a function button to tell the register what you are going to do, accept some input, hit another function button telling what you are going to do next, accept more input, repeat as required." Much of this comes from the old days of mechanical tabulators: key an amount, hit sale, when they're done hit total, the bell goes 'ding' and out pops the till, with the amount due displayed in digits at the top of the register. Of course nowadays the scanner reads the barcodes, the register looks up the prices, the customer swipes their card, and the cashier just has to hit total at the end.
Of course, that's the happy path. If the customer wants something different, such as a discount because the package is opened, the cashier now has to figure out how to give them that discount. An old cash register would have a "discount" button. But custom buttons are very expensive, because you're very limited as to how many you can fit on a keyboard. (Modern register applications have hundreds of constantly changing context-sensitive functions.) Instead, current cash register applications display the word DISCOUNT on the screen, with instructions on how to take that discount. On a normal desktop computer, they might display the word DISCOUNT on a button, and the user would click it. If it's a touch screen, the operator simply touches the word. For Dynakeys, the word DISCOUNT would appear with an arrow pointing at the button next to it (Dynakeys are quite similar to the buttons surrounding a Diebold ATM screen.) And if it's keyboard only, the screen might say "Press F1 for DISCOUNT".
So on a touch screen, the operator looks for the word DISCOUNT then touches it. On a keyboard, there are two steps: the operator looks for the words DISCOUNT-F1 and then presses F1. Common sense would make many people expect that two steps would be slower than one, but we demonstrated that wasn't the case. While we all expect experienced operators will eventually learn F1==discount, we didn't expect the act of reaching up and touching the screen would be as slow as the two-step process for the new hires.
The lesson is to perform extensive usability testing before pronouncing anything "extinct" or "victorious". Real users will surprise you every single time.
I believe "track stick" refers to the little rubber eraser-like device mounted in the center of a laptop keyboard. It's that thing that moves the pointer either too slow or too fast around the screen when you're sick of using the crappy trackpad.