Fair point. I can imagine a line of thought that would lead to not doing this (mostly how the code is naturally separated) but it's not a very good one.
What's interesting to me is that some entries in the database had non-null values in both hash fields. I'm not sure if Gawker kept the old hash at a password change or what.
At some point in Gawker's history, they switched to bcrypt hashes. The only problem is that people don't change their passwords a lot, so anyone who signed up before the change probably just had the old crypt(3) hash. crypt(3) is a hash, incidentally. It's just... fairly easy to compute and run through with DES as the algorithm. The reason all of those passwords were exposed was because they were cracked, not because they were decrypted.
Modern methods of hashing use multiple rounds of hash in order to slow down a cracker. Computing 1000 rounds of bcrypt is trivial for the server when someone is logging in. It slows down the cracker significantly, though, since they're trying to crack many accounts with a large dictionary. This level of security doesn't seem to be as mainstream as regular hashes, though.
They were basically using crypt. There was, in fact, a salt (though not a good one.)
Also, Gawker switched to using bcrypt at some point, but since many people didn't change their passwords after the switch, they were still storing the old DES passwords.
There was a salt. That's why of the 1.2million accounts on Gawker, only about 200,000 passwords were recovered. It's looking like Gawker basically used crypt().
The beauty of Open ID is that anyone can run a provider. Even you.
The ugliness of it is that you log in with a URL (that's a paradigm shift for a lot of people). Ever seen Google's OpenID URL? https://www.google.com/accounts/o8/id (and I can never remember if there's a trailing slash, so I often end up trying to log in twice.) And if the provider goes down, you're locked out of pretty much everything. Of course, that's a benefit, too. If someone breaks into your own OpenID server, you can pull the plug and they lose access to all of those accounts.
Definitions like this sort of necessarily change. Or else we have to do some crazy things like calling new speeds "high speed broadband" or "ultrabroadband."
Realistically, broadband should probably be indexed against some percentage of the mean data rates to homes. And that's probably what they're doing--not some orwellian scheme to make you doublethink.
Once you have a phone which is fast enough to play video and has a battery that lasts all day, the biggest improvements are going to come as software update and you won't care about the hardware any more than you currently care whether you have a 2.6GHz CPU vs. a 3GHz CPU -- both are fast enough to do whatever so nobody cares anymore.
Except that wireless providers are historically terrible at providing software updates. Apple bucked this trend a bit, and some Android phones have gotten one or two updates. Carriers are still the gatekeepers for the vast majority of phones, though. They want to sell new hardware, not provide new software.
Also, do you know anyone that just uses smartphones and tablets but never PCs or laptops? Didn't think so.
I come damned close, though, in my personal life. At work, I have to use a keyboard to get anything done (though conceivably, I could use an iPad connected to a bluetooth keyboard.) Most of my computer use at home is fairly light and based on consuming content, and as such, an iPad is perfect except for two little problems:
1) The iPad currently requires the use of a computer at least once (to activate) and any time you want to back it up. I think this will eventually be addressed, but it hasn't been high on Apple's priority list.
2) Flash (which is becoming less and less of a problem.)
My Android phone has neither of these problems, and in fact the only time it connects to a PC is to charge. It has practically replaced my laptop for day-to-day, out-of-the-house/office usage.
Actually, on AT&T, the next 2GB is only $20 more. Actually, they meter by the 1GB for overages, and 1GB is $10. So the first 2GB you have to buy at $25, and every 1GB after that is $10 extra.
With the smaller package, you simply pay $15 per 200MB. That's... pretty astounding, frankly. I hover right around 200MB per month, and so it turns out that I probably would save money by being on the smaller plan--it would average out. However there's something to be said for feeling secure in the knowledge that an app doesn't start using tons of data, unbeknownst to me, and cause my bill to skyrocket.
The iPad (with 3G) is pretty expensive. $630 minimum (but no contract on the data.) The Tab is only slightly less without a contract, but is sold subsidized for, what, about $400? Of course, forcing the data plan on you (and they are expensive) means that it's probably quite a bit more expensive in the long run.
Frankly, I think that Apple saw a new market that they could outright create, and they jumped at it. They own the tablet market right now because they did it first, they did it well, and they started with something familiar. Other companies had tried tablets before, but they didn't get all three of those right.
As for price, lots of people complained about the iPad pricing at first. There were claims that Apple had priced themselves way too high and that no significant number of iPads would be sold. Of course, those were vastly incorrect predictions, and what we're seeing now is that no one else can compete at the same price. They all have to take shortcuts somewhere.
That said, I'd argue that anyone who can buy a tablet has money to spare. They're still all toys right now. The only two that offer any reasonable performance are the Tab and the iPad, and they're still both pretty much consume-only devices. Yeah, John Gruber likes to point out that people are creating with the tablets--and that's certainly true--but the way most people create on most computing devices is by typing, and that's still far and away a better experience on a computer.
If we had it to do all over again with today's technology.
Area codes (and prefixes) were allocated based upon population and with respect to rotary phones and mechanical switching equipment. Areas with high population got area codes with the most small numbers (except for 0) because on a rotary dial phone, shorter numbers means that the call can be connected more quickly. Connecting a call more quickly means that the switching equipment is tied up for less time. That is why 0 wasn't used as much--it's the last number on the rotary dial, and thus takes the longest to use. And since high-population areas are expected to be called more frequently, it made a great deal of sense to minimize the connection time to these places.
You two are in agreement. He said that 1 large chunk is easier to transfer than lots of small chunks.
A TCP packet has a minimum size of 64 bytes. That's with no payload (no real data beint sent.) If I have 1400 bytes that I want to send to someone, my device can choose to send 1400 65 byte packets (91000 bytes total including overhead, and not including acknowledgement packets.) It could also choose to send 1 1400 byte packet (1464 bytes, with the same caveats.) These are obviously the extreme cases--it could also choose a number somewhere in between.
Of course, it's a little worse than that. Some carriers meddle with the content you receive (most noticeable when they resize an image to make it smaller just before it hits the cell tower.) Sending lots of small packets means more work for that box, too, as it has to reassemble and keep track of more chunks.
It's just like with Cable/DSL. The provider oversells their pipes and charges based upon making a profit from the average user. They take a slight loss on the people who use loads of bandwidth, but make it up in spades on just about everyone else. The cost you see on your phone bill (e.g. $25/mo for a 5GB plan) is based upon the expected usage of smartphones (way less than 5GB.)
Laptops are expected to use more of the provisioned data, so the companies would be taking a loss on most laptop plans if they were billed at the same rate as the smartphone data plans.
You have to get new service using a geographically local area code, and you can't port your number to a new carrier unless your number is geographically local to you.
You can use Google Voice to maintain carrier neutrality (mostly) but that comes with its own set of headaches.
I really have no metric for guessing at how well any given Antivirus works, because I haven't had Antivirus software fire an alert in years. I'm required to run something per corporate policy, so I run MSE because it's the most lightweight.
That's all fine and good. But, in this case, Level 3 isn't sending data to AT&T customers. They are sending data to Comcast's customers.
Two points:
1) Comcast almost certainly has multiple business units operating with their own budgets. It's pretty likely that one of the BUs is for Comcast's backbone, while another is for their residential customers.
2) CDNs (and Level 3 is acting as a CDN here) usually pay ISPs to host their servers locally. They usually do this with one ISP per geographical region, and other ISPs will still use the server. So it is very much a case where the CDN needs to pay to transport data across the network to other ISPs customers.
The benefit of Jungledisk is that the backup is online. For very small amounts of data that won't change often (e.g. a key) you don't need to make backups as frequently, and you can use physical security to protect it. For example:
Store a copy of the key in a safety deposit box at your bank.
Or keep a copy on a USB drive that is on your person at all times.
I'm not sure. Most of the time, CDNs pay for this because it can (and often does) go off network due to local peering agreements. For example, the ISPs in my town have local peering and one of them has an Akamai node. Akamai pays for the privilege of routing through the network that hosts them, and everyone in town gets closer access to the content they serve.
I still fail to see how that means Comcast needs to get more money from the upstream, when I already paid the freight charge for those bits.
Comcast had such an agreement with Akamai when Akamai had the Netflix contract. Now Level 3 has the Netflix contract, and Comcast doesn't have a commercial peering contract with Level 3 (they peered for free because it benefited both.) Akamai is expected to pay much less for their connectivity now, and Level 3 is expected to take up the slack. If Level 3 doesn't have to pay and Akamai pays less, Comcast takes the hit.
Comcast will always be a 'last mile' provider, not a backbone provider.
Except that Comcast has a backbone and transmits data across it for other networks. That's actually part of the problem--both Level 3 and Comcast have different hats in all of this--Comcast has a Last Mile Hat and a Backbone Hat, and Level 3 has a Backbone Hat and a CDN Hat. They're trying to wear the hat that's most advantageous to them when negotiating their deals. Level 3 wants to appear like a backbone provider, but with this Netflix deal, they're really fulfilling the CDN role the most, and CDNs almost always pay to have connectivity.
Slashdot Mirror
Fair point. I can imagine a line of thought that would lead to not doing this (mostly how the code is naturally separated) but it's not a very good one.
What's interesting to me is that some entries in the database had non-null values in both hash fields. I'm not sure if Gawker kept the old hash at a password change or what.
That's really, really excellent and something I wasn't aware of in OpenID. Thank you for the pointer!
At some point in Gawker's history, they switched to bcrypt hashes. The only problem is that people don't change their passwords a lot, so anyone who signed up before the change probably just had the old crypt(3) hash. crypt(3) is a hash, incidentally. It's just ... fairly easy to compute and run through with DES as the algorithm. The reason all of those passwords were exposed was because they were cracked, not because they were decrypted.
Modern methods of hashing use multiple rounds of hash in order to slow down a cracker. Computing 1000 rounds of bcrypt is trivial for the server when someone is logging in. It slows down the cracker significantly, though, since they're trying to crack many accounts with a large dictionary. This level of security doesn't seem to be as mainstream as regular hashes, though.
They were basically using crypt. There was, in fact, a salt (though not a good one.)
Also, Gawker switched to using bcrypt at some point, but since many people didn't change their passwords after the switch, they were still storing the old DES passwords.
There was a salt. That's why of the 1.2million accounts on Gawker, only about 200,000 passwords were recovered. It's looking like Gawker basically used crypt().
The beauty of Open ID is that anyone can run a provider. Even you.
The ugliness of it is that you log in with a URL (that's a paradigm shift for a lot of people). Ever seen Google's OpenID URL? https://www.google.com/accounts/o8/id (and I can never remember if there's a trailing slash, so I often end up trying to log in twice.) And if the provider goes down, you're locked out of pretty much everything. Of course, that's a benefit, too. If someone breaks into your own OpenID server, you can pull the plug and they lose access to all of those accounts.
Neat. You get 50mbps for $45/mo.
That same $45/mo gets me 3mbps. It's enough to stream OR do something else, but not really both.
I'm all for raising the standard of broadband.
Definitions like this sort of necessarily change. Or else we have to do some crazy things like calling new speeds "high speed broadband" or "ultrabroadband."
Realistically, broadband should probably be indexed against some percentage of the mean data rates to homes. And that's probably what they're doing--not some orwellian scheme to make you doublethink.
I was referring to the previous attack which was solved in the 2nd round tweaks.
It was broken, but it has been fixed.
Actually, Threefish was broken (which Skein relied upon.)
Once you have a phone which is fast enough to play video and has a battery that lasts all day, the biggest improvements are going to come as software update and you won't care about the hardware any more than you currently care whether you have a 2.6GHz CPU vs. a 3GHz CPU -- both are fast enough to do whatever so nobody cares anymore.
Except that wireless providers are historically terrible at providing software updates. Apple bucked this trend a bit, and some Android phones have gotten one or two updates. Carriers are still the gatekeepers for the vast majority of phones, though. They want to sell new hardware, not provide new software.
Also, do you know anyone that just uses smartphones and tablets but never PCs or laptops? Didn't think so.
I come damned close, though, in my personal life. At work, I have to use a keyboard to get anything done (though conceivably, I could use an iPad connected to a bluetooth keyboard.) Most of my computer use at home is fairly light and based on consuming content, and as such, an iPad is perfect except for two little problems:
1) The iPad currently requires the use of a computer at least once (to activate) and any time you want to back it up. I think this will eventually be addressed, but it hasn't been high on Apple's priority list.
2) Flash (which is becoming less and less of a problem.)
My Android phone has neither of these problems, and in fact the only time it connects to a PC is to charge. It has practically replaced my laptop for day-to-day, out-of-the-house/office usage.
Good to know that's been addressed. As recent as January of 2008, I know first-hand of a telco who refused to port.
Actually, on AT&T, the next 2GB is only $20 more. Actually, they meter by the 1GB for overages, and 1GB is $10. So the first 2GB you have to buy at $25, and every 1GB after that is $10 extra.
With the smaller package, you simply pay $15 per 200MB. That's ... pretty astounding, frankly. I hover right around 200MB per month, and so it turns out that I probably would save money by being on the smaller plan--it would average out. However there's something to be said for feeling secure in the knowledge that an app doesn't start using tons of data, unbeknownst to me, and cause my bill to skyrocket.
The iPad (with 3G) is pretty expensive. $630 minimum (but no contract on the data.) The Tab is only slightly less without a contract, but is sold subsidized for, what, about $400? Of course, forcing the data plan on you (and they are expensive) means that it's probably quite a bit more expensive in the long run.
Frankly, I think that Apple saw a new market that they could outright create, and they jumped at it. They own the tablet market right now because they did it first, they did it well, and they started with something familiar. Other companies had tried tablets before, but they didn't get all three of those right.
As for price, lots of people complained about the iPad pricing at first. There were claims that Apple had priced themselves way too high and that no significant number of iPads would be sold. Of course, those were vastly incorrect predictions, and what we're seeing now is that no one else can compete at the same price. They all have to take shortcuts somewhere.
That said, I'd argue that anyone who can buy a tablet has money to spare. They're still all toys right now. The only two that offer any reasonable performance are the Tab and the iPad, and they're still both pretty much consume-only devices. Yeah, John Gruber likes to point out that people are creating with the tablets--and that's certainly true--but the way most people create on most computing devices is by typing, and that's still far and away a better experience on a computer.
If we had it to do all over again with today's technology.
Area codes (and prefixes) were allocated based upon population and with respect to rotary phones and mechanical switching equipment. Areas with high population got area codes with the most small numbers (except for 0) because on a rotary dial phone, shorter numbers means that the call can be connected more quickly. Connecting a call more quickly means that the switching equipment is tied up for less time. That is why 0 wasn't used as much--it's the last number on the rotary dial, and thus takes the longest to use. And since high-population areas are expected to be called more frequently, it made a great deal of sense to minimize the connection time to these places.
You two are in agreement. He said that 1 large chunk is easier to transfer than lots of small chunks.
A TCP packet has a minimum size of 64 bytes. That's with no payload (no real data beint sent.) If I have 1400 bytes that I want to send to someone, my device can choose to send 1400 65 byte packets (91000 bytes total including overhead, and not including acknowledgement packets.) It could also choose to send 1 1400 byte packet (1464 bytes, with the same caveats.) These are obviously the extreme cases--it could also choose a number somewhere in between.
Of course, it's a little worse than that. Some carriers meddle with the content you receive (most noticeable when they resize an image to make it smaller just before it hits the cell tower.) Sending lots of small packets means more work for that box, too, as it has to reassemble and keep track of more chunks.
It's just like with Cable/DSL. The provider oversells their pipes and charges based upon making a profit from the average user. They take a slight loss on the people who use loads of bandwidth, but make it up in spades on just about everyone else. The cost you see on your phone bill (e.g. $25/mo for a 5GB plan) is based upon the expected usage of smartphones (way less than 5GB.)
Laptops are expected to use more of the provisioned data, so the companies would be taking a loss on most laptop plans if they were billed at the same rate as the smartphone data plans.
You have to get new service using a geographically local area code, and you can't port your number to a new carrier unless your number is geographically local to you.
You can use Google Voice to maintain carrier neutrality (mostly) but that comes with its own set of headaches.
I really have no metric for guessing at how well any given Antivirus works, because I haven't had Antivirus software fire an alert in years. I'm required to run something per corporate policy, so I run MSE because it's the most lightweight.
That's all fine and good. But, in this case, Level 3 isn't sending data to AT&T customers. They are sending data to Comcast's customers.
Two points:
1) Comcast almost certainly has multiple business units operating with their own budgets. It's pretty likely that one of the BUs is for Comcast's backbone, while another is for their residential customers.
2) CDNs (and Level 3 is acting as a CDN here) usually pay ISPs to host their servers locally. They usually do this with one ISP per geographical region, and other ISPs will still use the server. So it is very much a case where the CDN needs to pay to transport data across the network to other ISPs customers.
The benefit of Jungledisk is that the backup is online. For very small amounts of data that won't change often (e.g. a key) you don't need to make backups as frequently, and you can use physical security to protect it. For example:
Store a copy of the key in a safety deposit box at your bank.
Or keep a copy on a USB drive that is on your person at all times.
Or come up with a scheme to regenerate your key.
Financial punishment is an extremely effective way to punish. The problem is that flat fines are regressive.
Fine as a percentage of the person's yearly salary, and you've got something.
I'm not sure. Most of the time, CDNs pay for this because it can (and often does) go off network due to local peering agreements. For example, the ISPs in my town have local peering and one of them has an Akamai node. Akamai pays for the privilege of routing through the network that hosts them, and everyone in town gets closer access to the content they serve.
I still fail to see how that means Comcast needs to get more money from the upstream, when I already paid the freight charge for those bits.
Comcast had such an agreement with Akamai when Akamai had the Netflix contract. Now Level 3 has the Netflix contract, and Comcast doesn't have a commercial peering contract with Level 3 (they peered for free because it benefited both.) Akamai is expected to pay much less for their connectivity now, and Level 3 is expected to take up the slack. If Level 3 doesn't have to pay and Akamai pays less, Comcast takes the hit.
Comcast will always be a 'last mile' provider, not a backbone provider.
Except that Comcast has a backbone and transmits data across it for other networks. That's actually part of the problem--both Level 3 and Comcast have different hats in all of this--Comcast has a Last Mile Hat and a Backbone Hat, and Level 3 has a Backbone Hat and a CDN Hat. They're trying to wear the hat that's most advantageous to them when negotiating their deals. Level 3 wants to appear like a backbone provider, but with this Netflix deal, they're really fulfilling the CDN role the most, and CDNs almost always pay to have connectivity.