By supporting the manufacturers who use Linux or other open source technologies, you encourage their adoption. By spending money on proprietary systems, you don't. It's called "voting with your wallet."
And while a purchase like this ends up where each users contributes an almost negligible amount of support, it's the concept of millions of users that builds a strong base.
Linux is already big in the embedded OS world so it's not likely to go away any time soon, but there are those of us who think it should get bigger, not smaller.
I love the idea of using fingerprints as authentication in addition to identification. In no other security system in the world does every user walk around leaving their permission behind on telephones, doorknobs, keyboards, drink glasses or glossy magazines. The person who thought of this must have been a freakin' genius, and everyone who buys such a system is a security wizard.
You can certainly take a little responsibility for your own security. You don't have to write down the whole password, or you can obscure it in some way that you remember. If your password is aRgLeBaRgLe123 you can just write down "aRgLeBaRgLe" and remember that you glue 123 to the end of all your passwords, or write down "arglebargle123" knowing that you always cApItAlIzE eVeRy oThEr lEtTeR. For most people, the people who have physical access to their screens are less likely to be sophisticated attackers than your average network hacker.
Of course you still have to make sure that nobody learns any of your passwords, because they'll easily figure out your simple obscuration scheme.
Years ago I had all my various credit card PINs written and stored in my wallet with the cards, but I knew I had an offset to add to each before using it. The offset was the PIN for my main bank card, so it was something I already remembered. (I have since divested myself of all those extra cards, so I don't have the paper any more.)
All that said, I still don't write down or save my secure work or banking passwords. I'll write down stupid web site passwords, but not anything that puts me or the company I work for at risk.
Unless the security camera is a foot or two from the post-it, or if the password is written in 1/4" black magic marker, it won't be visible. I saw this used in a real (not TV) court case where the defendant claimed he wasn't the perpetrator in the video because his tattoos weren't visible in the security camera footage. (His were fine blue lines that looked like home-made or prison tats.) Investigators recreated the scene in the convenience store using calibrated lines and demonstrated to the jury that lines the size of those on the defendant's arm weren't visible on that camera at that distance. Guy went to jail for a very long time.
Another problem with that idea is that you could locate a camera pointed at a specific identifiable target. Just because you know a password doesn't mean you know the user ID, nor what system it's used to log in. I know someone's password is "KermitTF" -- but I can't tell you which computer it's good on.
And malware doesn't walk in the door and look. That's one of the very few advantages of having the criminal attackers located on a different continent.
The complex-but-written-down password is still excellent defense against network hackers. How you choose to secure the paper determines the rest of the security.
Regular password changes don't help decrease the likelihood of a system being compromised, they just offer some mitigation in the event that it has been compromised. However, given that an attacker probably will need only a few hours or days to slurp plenty of information or do plenty of damage, rotating passwords monthly isn't even likely to mitigate the compromise much.
Many of the really big credit card attacks (TJX, Network Solutions) took place over several months (or years), harvesting on-line transaction data. We have no way of knowing if the passwords were rotated during the course of the attack if that would have shut down the attackers. Network Solutions was PCI DSS rated, which means they had a password rotation policy in place, and their attack continued from March through June. We can probably assume the attackers seized the first opportunity to create a back door that they could use in the event the passwords were changed, so a rotating password would have had no effect on them.
In TFA the author complains about "sunflowers", people who have passwords on post-its stuck around their monitor frame. The thing about post-its is that 89% of last year's credit-card breaches originated from sources outside the companies. And there is no malware possible that can read what's written on a post-it note.
"Rupert Murdoch is a Persian cat and a monocle away from being the villain in a James Bond movie." - Dennis Miller
OK, so his original joke was about Bill Gates, and Elliot Carver was actually the name of the character portraying Rupert Murdoch in "Tomorrow Never Dies", but it's all the same sad-but-true joke anyway. Rupert Murdoch really is trying to take over the world.
If you actually read the installer, it gives you instructions so as to not install the toolbar. There is one tickbox on the page with the picture, and one on the next. It's not really "slimy" it's just making sure you know how to read.
No, it's really slimy. Malware is malware, regardless of whether or not you agree to it. Fscking with your browser is a behavior of malware. Period.
If I wanted a browser "helper" I would have Googled for one.
How can technologically engineered food with 20% real ingredients for taste and 80% cheap filler be good?
Because it feeds people who would otherwise starve, it doesn't provide a disgusting taste experience to the people it sustains, and it does so at a very affordable price. I'd say those are all "good" things.
And how do they propose that Limewire prevent sharers from sharing government secrets?
You could do it by embedding a copy of all government secrets in every distro of Limewire. Then, when it's about to share a file, it compares it against the current database of secret stuff, and if it's already in there, it refuses to share it. Problem solved.:-)
The funny part is that the U.S. Army doesn't really trust those roots anyway. Soldiers have to download and install a set of specific root certificates in order to use the Army's portal.
That said, the U.S. Armed Services are really quite modern with their PKI. The soldier's smart cards have their private keys on them, and they can only be unlocked and used with the correct password. I haven't seen many details other than helping a relative follow the installation instructions (available on the public.mil site, I doubt they're classified.) Those cards are apparently their key to all kinds of things: meals, payroll, PX, etc.
I'm guessing you were trying to make some kind of joke here but there is a very legitimate answer. They have two million employees and contractors wanting to communicate with them.
The problem is that if someone can create a false certificate, someone else can forge a criminally useful certificate.
Let's say I bank at Bank of the West, which is at https://www.bankofthewest.com./ And I get a piece of phishing spam, telling me to reset my PIN at Bank of the West, and their link goes to https://www.bankofthevvest.com./ If the spammer was able to create their own certificate, I would get no warning that I was going to a false site. By the time any supposed "ratings" came out, the victims have already been phished. The spammer could even set up a "false community" blessing the certificate in advance of the phishing attack, making it more resistant to downmodding of the ratings.
Of course, that supposes that Verisign will only sign legitimate requests, and we all know they would sign a freshly-shat turd if you gave them $100. But preventing forgeries is the idea behind not allowing community created certificates.
I suspect you haven't read a single book on Soviet-era history, on the repression of dissidents, or any of the histories that have been revealed since the fall of the Iron Curtain. Pick up a book by Mitrokhin, and start reading about the actual history of the KGB as recorded in the KGB archives. It's amazing how well it confirms much of the supposed "CIA propaganda" about repression inside the USSR.
Then start reading some of the Venona decrypts. Hayes has an excellent book that tracks Soviet propaganda activity through the U.S., confirming the Soviets planted counterclaims, and pushed the idea of "CIA propaganda". Finally, start checking the stories out in the KGB's own words in books like Spy Handler by Cherkashin.
Or, if you just like reading stories about ordinary people being made miserable by a thuggish regime, pick up One Day In The Life of Ivan Denisovich.
Oh, yeah, it's all just propaganda. Sorry for my cruel, cruel joke.
American tourist: Of course our technology is better than yours. Why in America, if we need the police on the telephone, we just dial 911 from anywhere.
Russian: We have you beat! In Russia, we don't even have to dial!
And I think you're proposing that if I want to know if my data is in there, I'd execute test = hash(canonicalize(name) + TIN + acct x + acct y + secret ); and look up test in the table. And in part #4, you're proposing storing multiple rows containing permutations, where one row would have stuff + acct #1 + acct #2, the next would have stuff + acct #2 + acct #3, the next would have stuff + acct #1 + acct #3, the next would have stuff + acct #2 + acct #1, the next would have stuff + acct #1 + acct #2 + acct #3, etc.
But it's still not secure, because the data in the table will likely have only the one credit card number per victim that was stolen. So your table will have many rows that contain exactly one acct # and the above attack will still find them. The only way this database would be more secure is if every victim had two or more stolen account numbers in it, and that's pretty nonsensical!
The guy running the table doesn't have extra secret data to add to the mix. He can't arbitrarily add personal data, like
row = hash( canonicalize(name) + TIN + acct #1 + canonicalize( mother's maiden name ) + canonicalize ( city of birth ) + birth date + secret );
because he doesn't know any of this extra data. He just has what has been reported stolen.
You could add complexity: for every name you generate salt and store it in another table kept elsewhere. Then, your stored data would be:
salt = random( );
store hash( canonicalize(name) ) as index, salt;
row = hash( canonicalize(name) + TIN + salt + acct #1 [ + acct #2 [... + acct #n ] ] + secret );
and the lookup would be the inverse:
lookup salt using hash( canonicalize(name) ) as index;
test = hash( canonicalize(name) + TIN + salt + acct #1 [ + acct #2 [... + acct #n ] ] + secret );
Now the attacker has to have both tables, plus the secret, and the understanding of how they all work together. It's more work, but that's not much different than if he stole one table plus the code in the first place. If he has all that information the attack still stands: he can brute force guess a million account numbers and if that victim has only the one leaked account number in his row, he's guessed it.
You could increase security by increasing the size of the database. For every victim you add, you could add a million random hashes. So if someone stole the database, they'd have to attack a million rows before they might find one single real piece of data. So now instead of 44 million rows, you have 44 quadrillion rows. This is not quite as crazy as it sounds: storage is cheap. Of course the birthday paradox would come into play, and you'd probably be generating some false positives so you'd want a bigger hash than 160 bits, and indexing and administering a table of that size would be psychotic. But it would certainly help security. (I suppose you could accomplish roughly the same feat by running the hash algorithm one million times per row.) Either way, lookups wouldn't be too bad because they'd be limited in volume, but building the database in the first place is going to be slow.
I think the best way to secure this is traditional: separate the tables across distinct machines, and use HSMs to guard the keys, secrets, and hashing operations. Then your biggest threat comes from insiders, and it's back to the case for physically securing the data center and all that ordinary security stuff. Crypto cannot provide the magic bullet in this case.
Please don't get me wrong: I like your idea of combining the name plus number, because it does turn the name into an effective salt. The reason you can't salt a number used as an index is that if you don't know what the salt is in advance, you can't do the hash before doing the lookup. But with your method, the victim's name can serve as the "known salt" protecting the rest of the data. The "+salt" I added above would need to be kept secret, essentially turning it into an encryption key.
I've studied credit card attacks against various hashing schemes rather a lot, which is why I quoted such a seemingly ridiculously low sounding number. While my argument is based on American credit cards and networks, the principles hold true across most of the spectrum.
At first look, you might think 16 digit account numbers means that it requires 10^16 guesses to brute force one. But credit card numbers are a lot more structured than that. We can reduce the search space considerably by thinking about the nature of the data.
The first six digits of a credit card number are the BIN - Bank Identification Number. A bank may have anywhere from one to a dozen or more BINs assigned to it. A cursory glance at a card might reveal the logo of a well-known bank. Employees frequently belong to their employer's credit unions, which have unique BINs. Federal employees would have just a few BINs for their credit unions. Or people living or shopping in Peoria might be expected to bank at the First National Bank of Peoria. The point is those first six digits might be reduced to just a few educated guesses, and you'd be right roughly 10% of the time. Those are certainly good enough odds: for a thief who's stolen a million encrypted account numbers, ending up with 100,000 is still a good haul.
The last four digits are almost never kept secret. They are printed on cash register receipts, billing statements, or in emailed transaction confirmations. There is often a way to harvest those digits from a specific victim. They are even commonly kept in databases in cleartext for convenient, quick identification.
Finally, the Luhn algorithm is a check digit algorithm that can be used to recover any one unknown digit from any guessed account number. You can mathematically compute the correct digit required to pass. If that doesn't seem right to you, think of it another way: by using the Luhn algorithm you can avoid running a full (expensive) hash test against any guess that doesn't pass the simple check digit test.
So 16 digits minus the 6 digit BIN, minus the last 4 digits, minus the check digit yields 5 unknown digits, or a search space of 100,000 guesses. Even if your BIN guesses are off 90% of the time, that's still a search space of only a million tests -- barely enough computrons to raise the core temperature of an i7 chip, or of a graphics card running a cracker with CUDA.
That's why it's not safe to assume account number data is secure, even when encrypted or hashed. There are just not enough possible numbers in which to hide the valuable ones.
You haven't eliminated the problem of a small search space, you've just found a salting mechanism.
Let's say you store the records as hash(Name+TIN+Salt). If I've stolen the database, I might conceivably have stolen the codebase, too, which would include the salt. (An HSM would be a wise investment here, but then why not simply encrypt the records with it?) So now to perform the attack I have to cycle through 100 million hashes per name. That's still not a big deal, not with modern hardware and modern criminal technology.
If I were this dirty, I'd go all the way and partner with a botnet operator to run the cracks. A bot could easily perform 100,000 hashes per minute. 1000 bots and you're cracking a record per minute. And I wouldn't start with JOHN SMYTHE, either. To maximize profit I'd be starting with GORDON BROWN, and working my way through the list of celebrities and millionaires.
It's still breakable. Where it would start to get tough would be to add another piece of data: hash(Name+TIN+creditcard+Salt). Now a brute force would have to cycle through an additional 100,000 tests per TIN (using additional external information that might be publicly available.) Not impossible, but it would slow down the attack considerably.
So if your telescope was gathering a degree instead of a minute, that would improve your chances by a factor of 3600 from my original math. That increases it to about a 1 in 20,000 chance you'd be pointed in the same direction as the meteor, which is a number much more consistent with your observation of meteor trails in images. And a lot more plausible if you're deliberately trying to capture a meteor on camera.
The best approach is to maximize your viewing time. Observe every single night, and even if it's partly overcast you should still go out and point your telescope in the direction of clear sky. More telescopes increase your chances. More time increases your chances. Keep the camera shutters running.
Now, I've never seen a "meteor trail every minute or so" except during a meteor shower. I consider myself lucky when I see one in an hour, so I'd question that particular figure. But I still think you'd be lucky to get one picture of a meteor in a month. And you'd still have to win the lottery to get a shot of a bolide.
"its basically almost impossible to do. especially a meteor like this."
I don't understand why it's nearly impossible, is it JUST because "you'd need to take a lot of pictures before statistically expecting to capture one meteor" as one commenter said?
Nor do I understand how/why he was able to do it.
Could someone please explain?
How about "He got lucky because a meteor happened to pass through his time lapse exposure of Andromeda." Does that explain it better?
Nowhere did the article say he was explicitly trying to photograph a meteor. He was just photographing some sky near Andromeda when the meteor accidentally passed his scope. If you were to try to photograph a meteor, you'd be spending a lot of time outside.
For fun, let's do the math and figure out how hard it would really be to photograph a meteor. First, just suppose his telescope and camera setup could gather light from about 1 arc minute of sky. (Crap, I'm lousy at this math, so I'll post it anyway and let someone correct me.) There are about 3,437 arc minutes in a radian, squared that would be about 11,812,969 arc minutes in a steradian. There are 4 pi steradians in a sphere; given that you can only see half the sky, that leaves 2 pi steradians of sky in which to point your telescope.
Assuming you have a night where you are guaranteed to see one meteor, but you don't know where it will be in the sky, you have a roughly one in 75 million chance that your telescope will be pointing in the right direction when it blasts by. Since meteors are extremely quick little buggers, you'd have no time to aim or even click the shutter upon its arrival. That means you'd have to reduce your chances even further by the time you are NOT spending taking pictures (setting up, between shots, changing batteries, etc.)
Statistically, you have a better chance of winning the lottery than you do of photographing a meteor through a telescope. "Nearly impossible" is pretty accurate.
Ikea have a whole section of their catalogue dedicated to Cable Managment. I have one of their horizontal SIGNUM cable management thingos attached to the under side of my desk.
I didn't have such good luck with their stuff. I bought their vertical cabling system called SIGHUP
I think the other piece is that nuclear technology is driven by engineers and scientists. I trust engineers to do the right thing much more than politicians or corporations. They're typically much better educated than politicians, and have less incentive to cut corners than corporations.
Nuclear power instills a kind of "I am playing with God's Own Fire" level of respect. Decisions are exquisitely deliberate. Material properties are not just studied and understood, they are almost ingrained into their fiber. Their safety devices have fail-safe interlocks, and those interlocks have monitors and auditors. There isn't a field of applied physics that is as carefully considered.
As a group, those are people I most trust to make the right decisions. And when politicians claim they're wrong, they are seldom equipped to back that challenge with facts -- yet they make the decisions anyway.
The grandparent poster asked *why* people are passionately in favor of nuclear energy. If you want to argue against the points I raised, go to any of the other discussion threads where this particular horse is being beaten to death. Otherwise offer up your own version of "why" you are passionately opposed (if you are actually passionate about the topic.)
Slashdot Mirror
By supporting the manufacturers who use Linux or other open source technologies, you encourage their adoption. By spending money on proprietary systems, you don't. It's called "voting with your wallet."
And while a purchase like this ends up where each users contributes an almost negligible amount of support, it's the concept of millions of users that builds a strong base.
Linux is already big in the embedded OS world so it's not likely to go away any time soon, but there are those of us who think it should get bigger, not smaller.
I love the idea of using fingerprints as authentication in addition to identification. In no other security system in the world does every user walk around leaving their permission behind on telephones, doorknobs, keyboards, drink glasses or glossy magazines. The person who thought of this must have been a freakin' genius, and everyone who buys such a system is a security wizard.
You can certainly take a little responsibility for your own security. You don't have to write down the whole password, or you can obscure it in some way that you remember. If your password is aRgLeBaRgLe123 you can just write down "aRgLeBaRgLe" and remember that you glue 123 to the end of all your passwords, or write down "arglebargle123" knowing that you always cApItAlIzE eVeRy oThEr lEtTeR. For most people, the people who have physical access to their screens are less likely to be sophisticated attackers than your average network hacker.
Of course you still have to make sure that nobody learns any of your passwords, because they'll easily figure out your simple obscuration scheme.
Years ago I had all my various credit card PINs written and stored in my wallet with the cards, but I knew I had an offset to add to each before using it. The offset was the PIN for my main bank card, so it was something I already remembered. (I have since divested myself of all those extra cards, so I don't have the paper any more.)
All that said, I still don't write down or save my secure work or banking passwords. I'll write down stupid web site passwords, but not anything that puts me or the company I work for at risk.
Unless the security camera is a foot or two from the post-it, or if the password is written in 1/4" black magic marker, it won't be visible. I saw this used in a real (not TV) court case where the defendant claimed he wasn't the perpetrator in the video because his tattoos weren't visible in the security camera footage. (His were fine blue lines that looked like home-made or prison tats.) Investigators recreated the scene in the convenience store using calibrated lines and demonstrated to the jury that lines the size of those on the defendant's arm weren't visible on that camera at that distance. Guy went to jail for a very long time.
Another problem with that idea is that you could locate a camera pointed at a specific identifiable target. Just because you know a password doesn't mean you know the user ID, nor what system it's used to log in. I know someone's password is "KermitTF" -- but I can't tell you which computer it's good on.
And malware doesn't walk in the door and look. That's one of the very few advantages of having the criminal attackers located on a different continent.
The complex-but-written-down password is still excellent defense against network hackers. How you choose to secure the paper determines the rest of the security.
Regular password changes don't help decrease the likelihood of a system being compromised, they just offer some mitigation in the event that it has been compromised. However, given that an attacker probably will need only a few hours or days to slurp plenty of information or do plenty of damage, rotating passwords monthly isn't even likely to mitigate the compromise much.
Many of the really big credit card attacks (TJX, Network Solutions) took place over several months (or years), harvesting on-line transaction data. We have no way of knowing if the passwords were rotated during the course of the attack if that would have shut down the attackers. Network Solutions was PCI DSS rated, which means they had a password rotation policy in place, and their attack continued from March through June. We can probably assume the attackers seized the first opportunity to create a back door that they could use in the event the passwords were changed, so a rotating password would have had no effect on them.
In TFA the author complains about "sunflowers", people who have passwords on post-its stuck around their monitor frame. The thing about post-its is that 89% of last year's credit-card breaches originated from sources outside the companies. And there is no malware possible that can read what's written on a post-it note.
"Rupert Murdoch is a Persian cat and a monocle away from being the villain in a James Bond movie." - Dennis Miller
OK, so his original joke was about Bill Gates, and Elliot Carver was actually the name of the character portraying Rupert Murdoch in "Tomorrow Never Dies", but it's all the same sad-but-true joke anyway. Rupert Murdoch really is trying to take over the world.
If you actually read the installer, it gives you instructions so as to not install the toolbar. There is one tickbox on the page with the picture, and one on the next. It's not really "slimy" it's just making sure you know how to read.
No, it's really slimy. Malware is malware, regardless of whether or not you agree to it. Fscking with your browser is a behavior of malware. Period.
If I wanted a browser "helper" I would have Googled for one.
How can technologically engineered food with 20% real ingredients for taste and 80% cheap filler be good?
Because it feeds people who would otherwise starve, it doesn't provide a disgusting taste experience to the people it sustains, and it does so at a very affordable price. I'd say those are all "good" things.
And how do they propose that Limewire prevent sharers from sharing government secrets?
You could do it by embedding a copy of all government secrets in every distro of Limewire. Then, when it's about to share a file, it compares it against the current database of secret stuff, and if it's already in there, it refuses to share it. Problem solved. :-)
The funny part is that the U.S. Army doesn't really trust those roots anyway. Soldiers have to download and install a set of specific root certificates in order to use the Army's portal.
That said, the U.S. Armed Services are really quite modern with their PKI. The soldier's smart cards have their private keys on them, and they can only be unlocked and used with the correct password. I haven't seen many details other than helping a relative follow the installation instructions (available on the public .mil site, I doubt they're classified.) Those cards are apparently their key to all kinds of things: meals, payroll, PX, etc.
For the bonus round, you can earn extra TPS cover sheets.
I'm guessing you were trying to make some kind of joke here but there is a very legitimate answer. They have two million employees and contractors wanting to communicate with them.
The problem is that if someone can create a false certificate, someone else can forge a criminally useful certificate.
Let's say I bank at Bank of the West, which is at https://www.bankofthewest.com./ And I get a piece of phishing spam, telling me to reset my PIN at Bank of the West, and their link goes to https://www.bankofthevvest.com./ If the spammer was able to create their own certificate, I would get no warning that I was going to a false site. By the time any supposed "ratings" came out, the victims have already been phished. The spammer could even set up a "false community" blessing the certificate in advance of the phishing attack, making it more resistant to downmodding of the ratings.
Of course, that supposes that Verisign will only sign legitimate requests, and we all know they would sign a freshly-shat turd if you gave them $100. But preventing forgeries is the idea behind not allowing community created certificates.
I suspect you haven't read a single book on Soviet-era history, on the repression of dissidents, or any of the histories that have been revealed since the fall of the Iron Curtain. Pick up a book by Mitrokhin, and start reading about the actual history of the KGB as recorded in the KGB archives. It's amazing how well it confirms much of the supposed "CIA propaganda" about repression inside the USSR.
Then start reading some of the Venona decrypts. Hayes has an excellent book that tracks Soviet propaganda activity through the U.S., confirming the Soviets planted counterclaims, and pushed the idea of "CIA propaganda". Finally, start checking the stories out in the KGB's own words in books like Spy Handler by Cherkashin.
Or, if you just like reading stories about ordinary people being made miserable by a thuggish regime, pick up One Day In The Life of Ivan Denisovich.
Oh, yeah, it's all just propaganda. Sorry for my cruel, cruel joke.
You remind me of this old cold-war era joke:
American tourist: Of course our technology is better than yours. Why in America, if we need the police on the telephone, we just dial 911 from anywhere.
Russian: We have you beat! In Russia, we don't even have to dial!
And I understand your system, too. The table only contains hashes, and each hash represents the full set of data for a victim:
row = hash( canonicalize(name) + TIN + acct #1 [ + acct #2 [ ... + acct #n ] ] + secret );
And I think you're proposing that if I want to know if my data is in there, I'd execute test = hash(canonicalize(name) + TIN + acct x + acct y + secret ); and look up test in the table. And in part #4, you're proposing storing multiple rows containing permutations, where one row would have stuff + acct #1 + acct #2, the next would have stuff + acct #2 + acct #3, the next would have stuff + acct #1 + acct #3, the next would have stuff + acct #2 + acct #1, the next would have stuff + acct #1 + acct #2 + acct #3, etc.
But it's still not secure, because the data in the table will likely have only the one credit card number per victim that was stolen. So your table will have many rows that contain exactly one acct # and the above attack will still find them. The only way this database would be more secure is if every victim had two or more stolen account numbers in it, and that's pretty nonsensical!
The guy running the table doesn't have extra secret data to add to the mix. He can't arbitrarily add personal data, like row = hash( canonicalize(name) + TIN + acct #1 + canonicalize( mother's maiden name ) + canonicalize ( city of birth ) + birth date + secret ); because he doesn't know any of this extra data. He just has what has been reported stolen.
You could add complexity: for every name you generate salt and store it in another table kept elsewhere. Then, your stored data would be:
salt = random( ); ... + acct #n ] ] + secret );
store hash( canonicalize(name) ) as index, salt;
row = hash( canonicalize(name) + TIN + salt + acct #1 [ + acct #2 [
and the lookup would be the inverse:
lookup salt using hash( canonicalize(name) ) as index; ... + acct #n ] ] + secret );
test = hash( canonicalize(name) + TIN + salt + acct #1 [ + acct #2 [
Now the attacker has to have both tables, plus the secret, and the understanding of how they all work together. It's more work, but that's not much different than if he stole one table plus the code in the first place. If he has all that information the attack still stands: he can brute force guess a million account numbers and if that victim has only the one leaked account number in his row, he's guessed it.
You could increase security by increasing the size of the database. For every victim you add, you could add a million random hashes. So if someone stole the database, they'd have to attack a million rows before they might find one single real piece of data. So now instead of 44 million rows, you have 44 quadrillion rows. This is not quite as crazy as it sounds: storage is cheap. Of course the birthday paradox would come into play, and you'd probably be generating some false positives so you'd want a bigger hash than 160 bits, and indexing and administering a table of that size would be psychotic. But it would certainly help security. (I suppose you could accomplish roughly the same feat by running the hash algorithm one million times per row.) Either way, lookups wouldn't be too bad because they'd be limited in volume, but building the database in the first place is going to be slow.
I think the best way to secure this is traditional: separate the tables across distinct machines, and use HSMs to guard the keys, secrets, and hashing operations. Then your biggest threat comes from insiders, and it's back to the case for physically securing the data center and all that ordinary security stuff. Crypto cannot provide the magic bullet in this case.
But they have to be careful to keep current. It won't stay smooth sailing forever.
Please don't get me wrong: I like your idea of combining the name plus number, because it does turn the name into an effective salt. The reason you can't salt a number used as an index is that if you don't know what the salt is in advance, you can't do the hash before doing the lookup. But with your method, the victim's name can serve as the "known salt" protecting the rest of the data. The "+salt" I added above would need to be kept secret, essentially turning it into an encryption key.
I've studied credit card attacks against various hashing schemes rather a lot, which is why I quoted such a seemingly ridiculously low sounding number. While my argument is based on American credit cards and networks, the principles hold true across most of the spectrum.
At first look, you might think 16 digit account numbers means that it requires 10^16 guesses to brute force one. But credit card numbers are a lot more structured than that. We can reduce the search space considerably by thinking about the nature of the data.
The first six digits of a credit card number are the BIN - Bank Identification Number. A bank may have anywhere from one to a dozen or more BINs assigned to it. A cursory glance at a card might reveal the logo of a well-known bank. Employees frequently belong to their employer's credit unions, which have unique BINs. Federal employees would have just a few BINs for their credit unions. Or people living or shopping in Peoria might be expected to bank at the First National Bank of Peoria. The point is those first six digits might be reduced to just a few educated guesses, and you'd be right roughly 10% of the time. Those are certainly good enough odds: for a thief who's stolen a million encrypted account numbers, ending up with 100,000 is still a good haul.
The last four digits are almost never kept secret. They are printed on cash register receipts, billing statements, or in emailed transaction confirmations. There is often a way to harvest those digits from a specific victim. They are even commonly kept in databases in cleartext for convenient, quick identification.
Finally, the Luhn algorithm is a check digit algorithm that can be used to recover any one unknown digit from any guessed account number. You can mathematically compute the correct digit required to pass. If that doesn't seem right to you, think of it another way: by using the Luhn algorithm you can avoid running a full (expensive) hash test against any guess that doesn't pass the simple check digit test.
So 16 digits minus the 6 digit BIN, minus the last 4 digits, minus the check digit yields 5 unknown digits, or a search space of 100,000 guesses. Even if your BIN guesses are off 90% of the time, that's still a search space of only a million tests -- barely enough computrons to raise the core temperature of an i7 chip, or of a graphics card running a cracker with CUDA.
That's why it's not safe to assume account number data is secure, even when encrypted or hashed. There are just not enough possible numbers in which to hide the valuable ones.
You haven't eliminated the problem of a small search space, you've just found a salting mechanism.
Let's say you store the records as hash(Name+TIN+Salt). If I've stolen the database, I might conceivably have stolen the codebase, too, which would include the salt. (An HSM would be a wise investment here, but then why not simply encrypt the records with it?) So now to perform the attack I have to cycle through 100 million hashes per name. That's still not a big deal, not with modern hardware and modern criminal technology.
If I were this dirty, I'd go all the way and partner with a botnet operator to run the cracks. A bot could easily perform 100,000 hashes per minute. 1000 bots and you're cracking a record per minute. And I wouldn't start with JOHN SMYTHE, either. To maximize profit I'd be starting with GORDON BROWN, and working my way through the list of celebrities and millionaires.
It's still breakable. Where it would start to get tough would be to add another piece of data: hash(Name+TIN+creditcard+Salt). Now a brute force would have to cycle through an additional 100,000 tests per TIN (using additional external information that might be publicly available.) Not impossible, but it would slow down the attack considerably.
So if your telescope was gathering a degree instead of a minute, that would improve your chances by a factor of 3600 from my original math. That increases it to about a 1 in 20,000 chance you'd be pointed in the same direction as the meteor, which is a number much more consistent with your observation of meteor trails in images. And a lot more plausible if you're deliberately trying to capture a meteor on camera.
The best approach is to maximize your viewing time. Observe every single night, and even if it's partly overcast you should still go out and point your telescope in the direction of clear sky. More telescopes increase your chances. More time increases your chances. Keep the camera shutters running.
Now, I've never seen a "meteor trail every minute or so" except during a meteor shower. I consider myself lucky when I see one in an hour, so I'd question that particular figure. But I still think you'd be lucky to get one picture of a meteor in a month. And you'd still have to win the lottery to get a shot of a bolide.
"its basically almost impossible to do. especially a meteor like this."
I don't understand why it's nearly impossible, is it JUST because "you'd need to take a lot of pictures before statistically expecting to capture one meteor" as one commenter said? Nor do I understand how/why he was able to do it.
Could someone please explain?
How about "He got lucky because a meteor happened to pass through his time lapse exposure of Andromeda." Does that explain it better?
Nowhere did the article say he was explicitly trying to photograph a meteor. He was just photographing some sky near Andromeda when the meteor accidentally passed his scope. If you were to try to photograph a meteor, you'd be spending a lot of time outside.
For fun, let's do the math and figure out how hard it would really be to photograph a meteor. First, just suppose his telescope and camera setup could gather light from about 1 arc minute of sky. (Crap, I'm lousy at this math, so I'll post it anyway and let someone correct me.) There are about 3,437 arc minutes in a radian, squared that would be about 11,812,969 arc minutes in a steradian. There are 4 pi steradians in a sphere; given that you can only see half the sky, that leaves 2 pi steradians of sky in which to point your telescope.
Assuming you have a night where you are guaranteed to see one meteor, but you don't know where it will be in the sky, you have a roughly one in 75 million chance that your telescope will be pointing in the right direction when it blasts by. Since meteors are extremely quick little buggers, you'd have no time to aim or even click the shutter upon its arrival. That means you'd have to reduce your chances even further by the time you are NOT spending taking pictures (setting up, between shots, changing batteries, etc.)
Statistically, you have a better chance of winning the lottery than you do of photographing a meteor through a telescope. "Nearly impossible" is pretty accurate.
Ikea have a whole section of their catalogue dedicated to Cable Managment. I have one of their horizontal SIGNUM cable management thingos attached to the under side of my desk.
I didn't have such good luck with their stuff. I bought their vertical cabling system called SIGHUP
NO CARRIER
I think the other piece is that nuclear technology is driven by engineers and scientists. I trust engineers to do the right thing much more than politicians or corporations. They're typically much better educated than politicians, and have less incentive to cut corners than corporations.
Nuclear power instills a kind of "I am playing with God's Own Fire" level of respect. Decisions are exquisitely deliberate. Material properties are not just studied and understood, they are almost ingrained into their fiber. Their safety devices have fail-safe interlocks, and those interlocks have monitors and auditors. There isn't a field of applied physics that is as carefully considered.
As a group, those are people I most trust to make the right decisions. And when politicians claim they're wrong, they are seldom equipped to back that challenge with facts -- yet they make the decisions anyway.
The grandparent poster asked *why* people are passionately in favor of nuclear energy. If you want to argue against the points I raised, go to any of the other discussion threads where this particular horse is being beaten to death. Otherwise offer up your own version of "why" you are passionately opposed (if you are actually passionate about the topic.)