Yes, and I'm sure that his hoarding water and ammunition, and warning that the Day of Reconing is upon us, really did a lot to spur all those programmers into action. Right.
What would this solve? First, why would you want to store it as floating point? Floating point numbers incur a loss of precision that you don't want (because once the date gets pretty big, you won't be able to measure small time intervals--try it in C; if you add, say, 4.3 to four billion, you'll get four billion), and in fact instead of rolling over, floating point numbers reach ``infinity''. Second, this still limits the size to whatever your maximum is here (I'm not sure I understand your resolution thing--why measure in less than optimal resolution?). Third, there's no reason to make it, say, 33 bits. You may as well use the entire word, since the rest will probably be wasted, anyway.
I remember this. Talk about hype. I stumbled across a preparedness website a year or two later (one like this) and laughed my ass off. Talk about a throwback to 1999 (notice the animated gifs and scolling text in the status-bar that lend a real air of authority). I think I even e-mailed the writer and asked if he did't feel stupid now.
There was no reply, though. His computer probably thought my letter was from a century ago.
In the past I've mirrored a few things for Slashdot (slashdotted stories, in other words). Granted it's not scientifically accurate, but it's probably as close as you'll get. I don't remember the numbers, but out of a few thousand hits, the vast majority were Windows. Slightly fewer--but still an overwhelming majority--were IE. Then again, maybe some have to use that at work (I use Linux/Mozilla at work, but hey, what do I know?).
Not necessarily. You assume the object being modelled is something that'd be possible to make in clay. This isn't often the case. For organic shapes and creatures, it may make sense; if you've worked in Maya or similar, you know that making the basic polygons for an object can take a while to get right, and doing that part in clay before adding details might be nice.
But many things can't be made in clay. Either they don't support their own weight, or aren't structuers that are easy to make, or are machines or other structures that have to be more precise than what you can easily do by hand. I think being able to do that would be a very nice option, but it wouldn't supplant other means of input. It's just too limiting.
I've seen vulnerabilities in tcpdump, ethereal, and Snort, but I never looked close enough to see if they'd work on a receive-only setup. Just because the initial attack is against a passive listener doesn't mean that it doesn't rely on some response to carry out an exploit (to do more than a DOS, in other words). If I get time (and I won't), I'll check into it. Thanks.
Re:My NOC is my PowerBook.
on
Build Your Own NOC
·
· Score: 3, Insightful
Many large networks with critical infrastructure like to have something that's manned most of the time, though 24/7/265 gets pricey. The reason's pretty obvious. If at 3 AM your network goes down, you don't really want all your customers to be up the creek 'till 9 on Monday.
If you're talking about corporate networks, you're probably right. But if you're talking about hosting companies, ISPs, companies that host their own critical infrastructure (like those you listed above), then the NOC, in some form or another, makes sense, doesn't it?
Probably right. I've wondered about this before, when seeing these statements. But at least you don't have to worry about leaking information or being used as an intermediate host in an attack. Worst case is essentially a DOS. On the other hand, were this a logging host, you could concievably infect it as you mentioned, download to it a simple program (you'd have to hope you download it right, since there won't be any way to do TCP style checksumming, I suppose) and have it grep through the logs to remove entries with your IP address or whatever, all automatically. No? But that'd be a bitch of an exploit, if you could pull it all off all one way.
No, I don't think that's right. There is no secret code here. Challenge-response means that the secret code is the key for this particular card, which is known by both the issuer and the cardholder, but presumably no one else. If you are concerned about someone stealing the key, it's really no different than someone stealing your CC# directly.
Nah. The RFID's are smart-chips here. They're powered by induction from the RFID scanner. I did a little googling and found a description of a similar proximity-card. They'd have to have a power source to do challenge-response, as the article indicates.
Each card has it's own private key. I don't know this for a fact, but it must be so, or, as you said, the challenge-response is so useless they would not bother to implement it.
The weaknesses in challenge-response are reversible hashes and replay attacks (predictable challenges, in other words). These are what you point out, and both are well-known (and easily dealt with).
The first--what you refer to when you mention sending a ``few thousand challenges'' is to simply use a proper strong one-way algorithm like blowfish or MD5. No matter how many responses you capture, you can't reverse it (this is not mathematically proven, but it is thought to be impossible to do anything more efficient than brute-force). Your comment on this indicates ignorance of how cryptosystems work, and I don't really feel like going into it further. Take my word, or do some reading (I'm not trying to be an ass, but I've studied this stuff, and you'll just have to take my word that reversability is not an issue if you have chosen a strong algorithm).
The second, what you refer to in ``pass[ing] along the challenge to an nearby RFID'' assumes only a single private key. This is not, as I said, the case, so it's meaningless. If you are instead referring to a replay attack, the answer is simply proper psuedorandom challenges. If you think you could simply pass the challenge to any nearby card and make it foot the bill instead, you'd be equally wrong. The card holder has to punch in a PIN on a keypad, as discussed in the article (hence my previous comment to RTFA). Either way (I'm not sure which one you mean), the system is plenty secure. Maybe not much more convenient than magnetic strips, but actually more secure.
We consider 128 bit SSL to be OK for credit card transactions. It's not absolute security, but it's secure enough that it doesn't make financial sense to break it just to get credit card numbers, especially when there are far easier methods. I don't really see any issues with the power consumption; presumably the card has enough power to do the 128 bit encryption that Amex said it does.
Old smartcards (maybe they are still like this, I don't know) like the kind used for transit fares and vending machines, had EEPROMS on them that were really just a bunch of memory cells packed together. They way they worked was that the number of ``full'' cells was the number of passes you had left.
Now these ROMS, like many others, were designed to be resettable by exposure to a bit of UV light. They were made this way for convenience; when the cards were first manufactured, to save time, they could all be zapped with a bit of light, set to ``full'', and then sold. Each time it was used, a machine would set one more cell to ``empty''.
The obvious problem, though, is that people found out, and used UV lights to get free transit passes, etc. What I find funny about the story is that you might think they'd build in a different encoding scheme, say, make it so that one or two bits must always be off, or else they know its a fraud (but this would make it take longer to manufacture, of course, and would mean they'd have to rebuild or reprogram their ticketing machines). What they did instead was build them with a little fuse bridge or something, I forget the details, so that if exposed to UV light twice, they blew and the card was junk.
Anyway, so many EEPROMs are designed like described above, to be resettable by UV light. But I imagine they've thought about it here. I think they cover the window, regardless. And X-rays may not be the right wavelength (though I really have no idea).
Yes, let's look at protocols that use challenge-response. Kerberos uses a modified challenge-response method. Windows NT prior to 2K and XP used challenge reponse, now they use a modificaiton of the Kerberos method. VNC uses challenge-response, if I remember right. HTTP digest authentication uses challenge-response. Many mailservers, (POP and IMAP, as well as SMTP) use challenge-response (CRAM MD5). The notion of challenge-response is itself secure, if implemented properly.
Offhand, I can think of two big ways to screw up the implentation:
Replay attacks - if the challenge is consistent through multiple authentication sessions, an attacker can reuse a hash response from a previous session. The solution is simple; better psuedo-randomness (using the date/time is a pretty poor idea, since an attacker can simply challenge the card with a date in the future and retrieve the needed response).
Poor hashing - if the hash used on the response is reversible, the password is right there for the taking. Solution, use something known to be strong, like blowfish or MD5.
Assuming the makers aren't stupid, they have a cryptographically secure system on-hand. You make an assumption based on a few out-of-context or unrelated cases that all security is useless. This is silly; while I don't have a lot of faith in secure systems as a whole, the flaw is rarely in the cryptography backing them, if it is implemented correctly. The reason for this is obvious; cryptography, and computing complexity, are easily-understood enough that developing mathematical models for security is easy. For example, we know--or rather, we believe very fervently, but cannot prove--that factoring large numbers is very, very difficult. Therefore, we trust RSA when implemented properly. Similarly, we know--or at least believe very strongly--that certain algorithms are very, very difficult to reverse. Therefore, we trust that if a bad guy gets our password file, he can only try to find our passwords via brute-force.
The difficulty of sniffing and cracking the protocol used is probably much greater than that of simply getting a waiter at a restaurant to swipe the cards of customers through a skimmer (traditional cards, that is). And security is really not about absolute security; it's simply about making sure that defeating is is more trouble than it's worth (I believe Bruce Schnieder said this, but I could be mistaken).
I'm not an electrical engineer, but Google turns up this page for security proximity cards, which are essentially the same product.
The card is usually passive (without an internal battery) and consists of an antenna and an RFID ASIC
(Application Specific Integrated Circuit). During operation, the transmitter sends out an
electro-magnetic wave to establish a zone of surveillance.
When a card enters this zone, the electromagnetic energy from the reader begins to energize the IC in
the tag.
Once the IC is energized, it goes through an initialization process and begins to broadcast its identity.
So it seems like the cards use induction to get just enough juice from the radio waves to power their internal circuitry. No battery needed.
That's now how challenge/response works. See here.
Basically, the idea is that if both you and the authenticator know the secret password, but you don't want to transmit it, the authenticator sends you some random chunk of data, say message M. You encrypt it using some (presumably one-way) algorithm, using your password as the encryption key to create W. The authenticator also encrypts the same chunk, and, when you send back your W, compares it do his own known-good W. Assuming they match, it means you have the password. The password itself is never sent plaintext.
You seem to be assuming that there is one secret key for the whole system. This would be completely useless, and is obviously not the case. You would need one secret key per person, as I'm sure American Express knows.
American Express makes the RFID reader verify the card's authenticity with a "challenge-response" exchange that depends on 128-bit encryption encoded on the chip. That strength of encryption is considered safe against "brute force" attacks, in which a hacker tries every possible combination.
MasterCard says it uses a different security system but would not provide specifics.
I don't really think they're that stupid. Presumable there's a secure private key on the card (in the AmEx system) that encrypts and spits back some random chunk of data. The credit card company does the same process and verifies that the encrypted chunks match. The key is never transmitted. Perfectly secure (similar to how VNC works, if I remember right, and to Kerberos). There are plenty of alternative methods (I posted a few minutes ago detailing how to do it with PKI), but if you trust the CC company, there's no real reason to use a private key only you have, and challenge/response is perfectly good.
It's not very hard to make this secure. This isn't done with current credit cards, but so long as we're building a new system, make 'em smart cards. Put a chip in them that stores a cryptographically random private key. When sent data (say, some random chunk to prevent a playback attack), it spits out the encrypted version. Then the credit card company can verify against the known public key (or give them a copy of the private key as well, so it's more like challenge-response) to make sure you really have the private key. Perfectly secure (at least until someone perfects quantum computing, or unless the NSA--who really doesn't need to waste time cracking my credit card--develops a way to factor large numbers).
Of course, for traditional use, like online, you could use the traditional CC#.
But, as I pointed out in a response above, if the earth were a perfect hollow sphere, there'd be no effective force of gravity inside the sphere. So the pigs would fly just fine.
Yast is supposed to be good. I've never used SuSe.
Mandrake, as I understand it (I'm speaking from hearsay here, since I've never used Mandrake) simply uses a better frontend. RedHat's biggest issue is clearly the lack of a good frontend more than the poverty of the backend. RedCarpet, up2date, or even apt for RedHat all overcome most, if not all of the problems with RPMs. And just as you'd rarely use dpkg instead of apt, you shouldn't have to use rpm in place of something like apt.
That said, I still have more faith in.debs. I've never had serious issues on a debian machine that a few changes in a sources.list, a few apt-get updates, or, heaven forbid, a dpkg --configure -a wouldn't fix. But RPMs are truly the bane of my existence (once someone screws up one dependency, it seems like the whole system just goes to hell).
I have no serious complaints with RPMs that are properly managed and have a good frontend. It's just that RH never does this, and, regardless, saying that RPMs are better than.debs because they are used by more releases is silly. They may be used by more, but there are few common software packages that aren't available in.deb.
Anyway, we're getting off topic, so I'm gonna shut up now. And you may be right. I was pissed off at the troll more than anything.
Slashdot Mirror
Yes, and I'm sure that his hoarding water and ammunition, and warning that the Day of Reconing is upon us, really did a lot to spur all those programmers into action. Right.
What would this solve? First, why would you want to store it as floating point? Floating point numbers incur a loss of precision that you don't want (because once the date gets pretty big, you won't be able to measure small time intervals--try it in C; if you add, say, 4.3 to four billion, you'll get four billion), and in fact instead of rolling over, floating point numbers reach ``infinity''. Second, this still limits the size to whatever your maximum is here (I'm not sure I understand your resolution thing--why measure in less than optimal resolution?). Third, there's no reason to make it, say, 33 bits. You may as well use the entire word, since the rest will probably be wasted, anyway.
Why do I even bother?
There was no reply, though. His computer probably thought my letter was from a century ago.
Far better than I thought. I should check my logs again; my memory might be off a bit. But MSIE was definitely the most common.
As opposed to nurbs? There's a reason Maya has both, you know.
In the past I've mirrored a few things for Slashdot (slashdotted stories, in other words). Granted it's not scientifically accurate, but it's probably as close as you'll get. I don't remember the numbers, but out of a few thousand hits, the vast majority were Windows. Slightly fewer--but still an overwhelming majority--were IE. Then again, maybe some have to use that at work (I use Linux/Mozilla at work, but hey, what do I know?).
But many things can't be made in clay. Either they don't support their own weight, or aren't structuers that are easy to make, or are machines or other structures that have to be more precise than what you can easily do by hand. I think being able to do that would be a very nice option, but it wouldn't supplant other means of input. It's just too limiting.
I've seen vulnerabilities in tcpdump, ethereal, and Snort, but I never looked close enough to see if they'd work on a receive-only setup. Just because the initial attack is against a passive listener doesn't mean that it doesn't rely on some response to carry out an exploit (to do more than a DOS, in other words). If I get time (and I won't), I'll check into it. Thanks.
If you're talking about corporate networks, you're probably right. But if you're talking about hosting companies, ISPs, companies that host their own critical infrastructure (like those you listed above), then the NOC, in some form or another, makes sense, doesn't it?
I managed to mirror my browser's cache of it, sans a couple of images, here.
Probably right. I've wondered about this before, when seeing these statements. But at least you don't have to worry about leaking information or being used as an intermediate host in an attack. Worst case is essentially a DOS. On the other hand, were this a logging host, you could concievably infect it as you mentioned, download to it a simple program (you'd have to hope you download it right, since there won't be any way to do TCP style checksumming, I suppose) and have it grep through the logs to remove entries with your IP address or whatever, all automatically. No? But that'd be a bitch of an exploit, if you could pull it all off all one way.
No, I don't think that's right. There is no secret code here. Challenge-response means that the secret code is the key for this particular card, which is known by both the issuer and the cardholder, but presumably no one else. If you are concerned about someone stealing the key, it's really no different than someone stealing your CC# directly.
Nah. The RFID's are smart-chips here. They're powered by induction from the RFID scanner. I did a little googling and found a description of a similar proximity-card. They'd have to have a power source to do challenge-response, as the article indicates.
Each card has it's own private key. I don't know this for a fact, but it must be so, or, as you said, the challenge-response is so useless they would not bother to implement it.
The weaknesses in challenge-response are reversible hashes and replay attacks (predictable challenges, in other words). These are what you point out, and both are well-known (and easily dealt with).
The first--what you refer to when you mention sending a ``few thousand challenges'' is to simply use a proper strong one-way algorithm like blowfish or MD5. No matter how many responses you capture, you can't reverse it (this is not mathematically proven, but it is thought to be impossible to do anything more efficient than brute-force). Your comment on this indicates ignorance of how cryptosystems work, and I don't really feel like going into it further. Take my word, or do some reading (I'm not trying to be an ass, but I've studied this stuff, and you'll just have to take my word that reversability is not an issue if you have chosen a strong algorithm).
The second, what you refer to in ``pass[ing] along the challenge to an nearby RFID'' assumes only a single private key. This is not, as I said, the case, so it's meaningless. If you are instead referring to a replay attack, the answer is simply proper psuedorandom challenges. If you think you could simply pass the challenge to any nearby card and make it foot the bill instead, you'd be equally wrong. The card holder has to punch in a PIN on a keypad, as discussed in the article (hence my previous comment to RTFA). Either way (I'm not sure which one you mean), the system is plenty secure. Maybe not much more convenient than magnetic strips, but actually more secure.
We consider 128 bit SSL to be OK for credit card transactions. It's not absolute security, but it's secure enough that it doesn't make financial sense to break it just to get credit card numbers, especially when there are far easier methods. I don't really see any issues with the power consumption; presumably the card has enough power to do the 128 bit encryption that Amex said it does.
Now these ROMS, like many others, were designed to be resettable by exposure to a bit of UV light. They were made this way for convenience; when the cards were first manufactured, to save time, they could all be zapped with a bit of light, set to ``full'', and then sold. Each time it was used, a machine would set one more cell to ``empty''.
The obvious problem, though, is that people found out, and used UV lights to get free transit passes, etc. What I find funny about the story is that you might think they'd build in a different encoding scheme, say, make it so that one or two bits must always be off, or else they know its a fraud (but this would make it take longer to manufacture, of course, and would mean they'd have to rebuild or reprogram their ticketing machines). What they did instead was build them with a little fuse bridge or something, I forget the details, so that if exposed to UV light twice, they blew and the card was junk.
Anyway, so many EEPROMs are designed like described above, to be resettable by UV light. But I imagine they've thought about it here. I think they cover the window, regardless. And X-rays may not be the right wavelength (though I really have no idea).
Offhand, I can think of two big ways to screw up the implentation:
Replay attacks - if the challenge is consistent through multiple authentication sessions, an attacker can reuse a hash response from a previous session. The solution is simple; better psuedo-randomness (using the date/time is a pretty poor idea, since an attacker can simply challenge the card with a date in the future and retrieve the needed response).
Poor hashing - if the hash used on the response is reversible, the password is right there for the taking. Solution, use something known to be strong, like blowfish or MD5.
Assuming the makers aren't stupid, they have a cryptographically secure system on-hand. You make an assumption based on a few out-of-context or unrelated cases that all security is useless. This is silly; while I don't have a lot of faith in secure systems as a whole, the flaw is rarely in the cryptography backing them, if it is implemented correctly. The reason for this is obvious; cryptography, and computing complexity, are easily-understood enough that developing mathematical models for security is easy. For example, we know--or rather, we believe very fervently, but cannot prove--that factoring large numbers is very, very difficult. Therefore, we trust RSA when implemented properly. Similarly, we know--or at least believe very strongly--that certain algorithms are very, very difficult to reverse. Therefore, we trust that if a bad guy gets our password file, he can only try to find our passwords via brute-force.
The difficulty of sniffing and cracking the protocol used is probably much greater than that of simply getting a waiter at a restaurant to swipe the cards of customers through a skimmer (traditional cards, that is). And security is really not about absolute security; it's simply about making sure that defeating is is more trouble than it's worth (I believe Bruce Schnieder said this, but I could be mistaken).
The card is usually passive (without an internal battery) and consists of an antenna and an RFID ASIC (Application Specific Integrated Circuit). During operation, the transmitter sends out an electro-magnetic wave to establish a zone of surveillance. When a card enters this zone, the electromagnetic energy from the reader begins to energize the IC in the tag. Once the IC is energized, it goes through an initialization process and begins to broadcast its identity.
So it seems like the cards use induction to get just enough juice from the radio waves to power their internal circuitry. No battery needed.
Basically, the idea is that if both you and the authenticator know the secret password, but you don't want to transmit it, the authenticator sends you some random chunk of data, say message M. You encrypt it using some (presumably one-way) algorithm, using your password as the encryption key to create W. The authenticator also encrypts the same chunk, and, when you send back your W, compares it do his own known-good W. Assuming they match, it means you have the password. The password itself is never sent plaintext.
You seem to be assuming that there is one secret key for the whole system. This would be completely useless, and is obviously not the case. You would need one secret key per person, as I'm sure American Express knows.
Christ. RTFA. Do you know what challenge-response is? I don't feel like repeating myself, so see here
American Express makes the RFID reader verify the card's authenticity with a "challenge-response" exchange that depends on 128-bit encryption encoded on the chip. That strength of encryption is considered safe against "brute force" attacks, in which a hacker tries every possible combination.
MasterCard says it uses a different security system but would not provide specifics.
I don't really think they're that stupid. Presumable there's a secure private key on the card (in the AmEx system) that encrypts and spits back some random chunk of data. The credit card company does the same process and verifies that the encrypted chunks match. The key is never transmitted. Perfectly secure (similar to how VNC works, if I remember right, and to Kerberos). There are plenty of alternative methods (I posted a few minutes ago detailing how to do it with PKI), but if you trust the CC company, there's no real reason to use a private key only you have, and challenge/response is perfectly good.
Of course, for traditional use, like online, you could use the traditional CC#.
But, as I pointed out in a response above, if the earth were a perfect hollow sphere, there'd be no effective force of gravity inside the sphere. So the pigs would fly just fine.
Mandrake, as I understand it (I'm speaking from hearsay here, since I've never used Mandrake) simply uses a better frontend. RedHat's biggest issue is clearly the lack of a good frontend more than the poverty of the backend. RedCarpet, up2date, or even apt for RedHat all overcome most, if not all of the problems with RPMs. And just as you'd rarely use dpkg instead of apt, you shouldn't have to use rpm in place of something like apt.
That said, I still have more faith in .debs. I've never had serious issues on a debian machine that a few changes in a sources.list, a few apt-get updates, or, heaven forbid, a dpkg --configure -a wouldn't fix. But RPMs are truly the bane of my existence (once someone screws up one dependency, it seems like the whole system just goes to hell).
I have no serious complaints with RPMs that are properly managed and have a good frontend. It's just that RH never does this, and, regardless, saying that RPMs are better than .debs because they are used by more releases is silly. They may be used by more, but there are few common software packages that aren't available in .deb.
Anyway, we're getting off topic, so I'm gonna shut up now. And you may be right. I was pissed off at the troll more than anything.