And, you know, if I 'reverse engineer' the right bunch of binary digits I can read all the credit card information in your https transactions. That bunch of binary digits being your AES key.
If Google was in the least intelligent, that string would either be a random number or a hash (basically a random number if you don't know the exact data that went into it) of the voicemail contents plus the user and some other stuff. Personally, I expect they are in the least intelligent and that the URL is about as 'reverse engineerable' as the AES key your browser used to talk to the place you bought your latest motherboard from.
The obscurity in this case happens to be a random number that's at least 100 bits long if not a lot longer. Sure I could guess that, but I could guess your 128 bit symmetric cipher key too.
No, what happened here is that people used this extremely obscure URL to provide public links to their voicemail messages and google happily indexed those links. And, you know, when you publicize links to things, they show up in search engines.
Now, google could additionally require authorization before letting people have access to those links, but the way you find out what the big long random number is is by clicking on something saying something along the lines of "I want to share this voicemail with someone." which means that you want someone other than yourself to have access to it. Making the link require authorization to get to would completely defeat the purpose of sharing it with someone.
No, in my opinion, what google should do is have a per-voicemail switch that lets you decide whether or not the public sharable link works or not. Then you can share the link with a friend, and when you want to close up access so your friend can't share the link with their friend or post it on the internet or whatever, you click on the little check box and the link stops working.
Voicemails that you schedule for deletion should become private by default when they hit the trash can.
Actually, almost all the people I know who've successfully made money off their Open Source software have used the GPL or some equivalent. MySQL, Trolltech and Redhat are good examples.
And it's not always a matter of making money either. Personally, it's about making sure the software I create stays open and that the default version never becomes a piece of closed source.
Huh. Well, I think that attitude is really bizarre. "Hi, let's pick a license that basically allows my work to be taken, shut up in some proprietary piece of garbage that touts 'innovation' even though it's my code that does all the hard work, and sold back to me because, you know, it's simpler that way."
Sorry, but I don't think so. If that's what you want, go right ahead though. But, you might want to give me your car and house too. I mean, you aren't going to get anything for doing it. In fact, if it's not in an area of the country I like I'll just sell it back to you. But I don't think that'll matter much to you. I'll send you over all the forms and paperwork and make it really easy for you. Heck, I'll even hire a lawyer of your choice to look it all over and make sure that you're giving it to me free and clear.
I spent a good 3 weeks implementing an interesting idea that the person who came up with decided he wanted to patent. My conditions for working on it were that either the thing be treated as a trade secret or that it be allowed to be used in any Open Source application of any kind. He wanted some stupid mealy-mouthed non-commercial clause license.
In my opinion, no matter what the guy thinks of his idea, he will never make any money off of it by trying to keep such tight fisted control over it. His best bet was to create an interesting implementation with his name on it and make money from consulting. Now the stupid idea is going to languish in obscurity because he's too afraid to actually get it out there in a way people will ever use.
The best way to make sure an idea is never used is to patent it. Chaum's digital cash algorithms have a lot of interesting uses that have little to do with digital cash, but nobody will touch them because of the patents. Patenting, IMHO, is the kiss of death for an idea, especially one related to mathematics or software.
If it's a software idea, I would say you should create an implementation with your name prominently associated with it. If the implementation is any good, or the idea is pretty neat, you will find people who want you to help make the idea work for them.
If you patent it, please don't tell me about it. I don't want to know. Chances are someone will stumble across it anyway, and implement it. The more ignorance they can claim about your idea, the less money you can extract from them. The last thing I want to know about is an idea someone wants to patent, which, of course, is the opposite of how things ought to be if the purpose of patents is really to 'promote the Progress of Science and useful Arts'.
I sort of agree and sort of don't. If people try to change the situation radically without having a good handle on the problem I think that the situation is just likely to repeat itself with different people on top, like Animal Farm.
I'm a loser.:-) A bit of a peculiar sort of loser in a few ways, but definitely in that category. The thing I find most interesting about this is that I can see various instances in my career where I was examined for signs that I could be either a good sociopath or a good clueless person and found wanting for both positions.
I don't have the capacity for self-delusion it takes to be a good clueless person, nor the ruthless nature it takes to be a sociopath.
No, he was in the 'clueless' category. He knew what the game was, but felt that the way to play was to work ungodly hours and get enormous amounts of work done. That isn't how the game is played, but people who think that it is a darned useful.
I do, in fact, evaluate most women I meet that way. I assume that most women do the same to me (and I assume the answer is 99.9% 'no').
Now, I do agree that the fact that he would date her is likely not terribly relevant to this conversation. And his juxtaposition of the qualities of 'datability' and 'hirability' reveal that he perhaps links them, and that's definitely not OK.
But I don't think the problem is that he evaluates women based on datability.
I second this. I've had 2 or 3 PCs now that have begun acting very strangely only to discover that the real problem was the power supply. Replace it and the PC acts fine again.
Then I made you apply your own personal bogeyman to myself, when I haven't said one single statement in support of 'freetards.'
Classic schizoid reaction to having your own logic challenged.
Cognitive dissonance kicks in and anyone who doesn't fit in your comfort zone is a member of the same group of enemies.
There there, little broken head, it will be OK, you'll get well one day... well, probably not.
This is how I know something is seriously broken in the heads of people who argue for iron-clad copyright protection. As soon as I start arguing cogently with them they start calling me a pirate. The fact is I generally avoid being a pirate, and and much less of one than almost everybody else I know.
It's like calling me a druggie because I think prohibition is dumb.
Watching your argument with the person who has the patience to argue with you is kind of amusing.
Of course, the fact that I would've happily bought Netgear's hardware had it actually delivered the goods doesn't mean a thing to you either. Somehow, the money I'm willing to spend is fictitious or something I guess.
The default mode for IPv6 is to assign the lower 64 bits based on the MAC address of the interface. Now, that is still far from random, but there is still a lot of entropy in it.
I have this idea for an IPv6 DHCP daemon that randomly assigns addresses and has a scheme for periodically rotating those assignments. That would solve the problem right there.
Well, that may be true. But a 128 bit address space is so sparse that passive scanning like the current worms do isn't much of an option any more. Even if you know a prefix to use the chances of your hitting a host in that prefix are still woefully small.
I wonder if the planet would sort of act as a giant refinery, and after a few hundred million years all the minerals with lower melting points would be on the cold side, and all the minerals with higher melting points would be on the hot side?
Mine is because it's hosted on my own personal server and the email lives on an encrypted hard drive.:-) Unfortunately, I very, very rarely receive encrypted email, so it could easily be viewed in transit.:-(
Oh, you're right. I didn't think of that. It would be more secure, and that's a good idea. And you're right, given that idea there is no good reason not to implement it using a MAC instead of a hash.
I still don't think the plain old hash is all that insecure though.
Oh, I just thought of a reason why the AJAX idea would be even harder than I originally thought. I bet the web app doesn't even use cookies or sessions at all. That makes that kind of thing a lot harder to implement.
A hash value is 43 bytes of base64 encoded stuff. It's trivial to validate that it's still 64 bytes of base64 encoded stuff when you get it back. And verifying that it's the right set of base64 encoded stuff is fairly easy too. If it matches the result of computing the hash of what's in the database, the database hasn't changed since the form was generated. If it has, the database hash changed. The only possible attack is fiddling the hash value to be the hash of the data that now is in the database, which would require a willing accomplice who could tell you what the new values are because that's how they set them. And the result of that would be that their values are stomped on.
Also, no SQL injection is possible because the hash value itself isn't stored in the database so there's no reason to include it in a database query in any way.
So, I don't think there is an attack that could work by fiddling the hash value sent back in a hidden form field.
And, doing so gives you extra security against X-site scripting attacks involving someone having a POST that goes against the web app URL from a completely different page. They are certain to not be able to get the hash value correct and the user isn't going to be tossed back from their attempt to post with a confusing message about the database having been updated since they filled out the form.
For extra security against X-site scripting attacks you can make the hash be a MAC instead and have the key be some secret server side data from the server side session data structure. But that then starts requiring you to actually have sessions, which it doesn't sound like the original poster has.
Just because someone is using data in hidden form fields for something important does not automatically mean that they are doing something insecure. This analysis I just posted was actually done in my head before I made the original post.
Slashdot Mirror
And, you know, if I 'reverse engineer' the right bunch of binary digits I can read all the credit card information in your https transactions. That bunch of binary digits being your AES key.
If Google was in the least intelligent, that string would either be a random number or a hash (basically a random number if you don't know the exact data that went into it) of the voicemail contents plus the user and some other stuff. Personally, I expect they are in the least intelligent and that the URL is about as 'reverse engineerable' as the AES key your browser used to talk to the place you bought your latest motherboard from.
The obscurity in this case happens to be a random number that's at least 100 bits long if not a lot longer. Sure I could guess that, but I could guess your 128 bit symmetric cipher key too.
No, what happened here is that people used this extremely obscure URL to provide public links to their voicemail messages and google happily indexed those links. And, you know, when you publicize links to things, they show up in search engines.
Now, google could additionally require authorization before letting people have access to those links, but the way you find out what the big long random number is is by clicking on something saying something along the lines of "I want to share this voicemail with someone." which means that you want someone other than yourself to have access to it. Making the link require authorization to get to would completely defeat the purpose of sharing it with someone.
No, in my opinion, what google should do is have a per-voicemail switch that lets you decide whether or not the public sharable link works or not. Then you can share the link with a friend, and when you want to close up access so your friend can't share the link with their friend or post it on the internet or whatever, you click on the little check box and the link stops working.
Voicemails that you schedule for deletion should become private by default when they hit the trash can.
Actually, almost all the people I know who've successfully made money off their Open Source software have used the GPL or some equivalent. MySQL, Trolltech and Redhat are good examples.
And it's not always a matter of making money either. Personally, it's about making sure the software I create stays open and that the default version never becomes a piece of closed source.
Huh. Well, I think that attitude is really bizarre. "Hi, let's pick a license that basically allows my work to be taken, shut up in some proprietary piece of garbage that touts 'innovation' even though it's my code that does all the hard work, and sold back to me because, you know, it's simpler that way."
Sorry, but I don't think so. If that's what you want, go right ahead though. But, you might want to give me your car and house too. I mean, you aren't going to get anything for doing it. In fact, if it's not in an area of the country I like I'll just sell it back to you. But I don't think that'll matter much to you. I'll send you over all the forms and paperwork and make it really easy for you. Heck, I'll even hire a lawyer of your choice to look it all over and make sure that you're giving it to me free and clear.
*raises eyebrows* Tell me more about this interesting theory of yours. *listens with rapt attention*
Well, it doesn't have any terms in it that I'm not happy about.
I spent a good 3 weeks implementing an interesting idea that the person who came up with decided he wanted to patent. My conditions for working on it were that either the thing be treated as a trade secret or that it be allowed to be used in any Open Source application of any kind. He wanted some stupid mealy-mouthed non-commercial clause license.
In my opinion, no matter what the guy thinks of his idea, he will never make any money off of it by trying to keep such tight fisted control over it. His best bet was to create an interesting implementation with his name on it and make money from consulting. Now the stupid idea is going to languish in obscurity because he's too afraid to actually get it out there in a way people will ever use.
The best way to make sure an idea is never used is to patent it. Chaum's digital cash algorithms have a lot of interesting uses that have little to do with digital cash, but nobody will touch them because of the patents. Patenting, IMHO, is the kiss of death for an idea, especially one related to mathematics or software.
If it's a software idea, I would say you should create an implementation with your name prominently associated with it. If the implementation is any good, or the idea is pretty neat, you will find people who want you to help make the idea work for them.
If you patent it, please don't tell me about it. I don't want to know. Chances are someone will stumble across it anyway, and implement it. The more ignorance they can claim about your idea, the less money you can extract from them. The last thing I want to know about is an idea someone wants to patent, which, of course, is the opposite of how things ought to be if the purpose of patents is really to 'promote the Progress of Science and useful Arts'.
I sort of agree and sort of don't. If people try to change the situation radically without having a good handle on the problem I think that the situation is just likely to repeat itself with different people on top, like Animal Farm.
I'm a loser. :-) A bit of a peculiar sort of loser in a few ways, but definitely in that category. The thing I find most interesting about this is that I can see various instances in my career where I was examined for signs that I could be either a good sociopath or a good clueless person and found wanting for both positions.
I don't have the capacity for self-delusion it takes to be a good clueless person, nor the ruthless nature it takes to be a sociopath.
No, he was in the 'clueless' category. He knew what the game was, but felt that the way to play was to work ungodly hours and get enormous amounts of work done. That isn't how the game is played, but people who think that it is a darned useful.
I do, in fact, evaluate most women I meet that way. I assume that most women do the same to me (and I assume the answer is 99.9% 'no').
Now, I do agree that the fact that he would date her is likely not terribly relevant to this conversation. And his juxtaposition of the qualities of 'datability' and 'hirability' reveal that he perhaps links them, and that's definitely not OK.
But I don't think the problem is that he evaluates women based on datability.
I second this. I've had 2 or 3 PCs now that have begun acting very strangely only to discover that the real problem was the power supply. Replace it and the PC acts fine again.
This is how I know something is seriously broken in the heads of people who argue for iron-clad copyright protection. As soon as I start arguing cogently with them they start calling me a pirate. The fact is I generally avoid being a pirate, and and much less of one than almost everybody else I know.
It's like calling me a druggie because I think prohibition is dumb.
Watching your argument with the person who has the patience to argue with you is kind of amusing.
Of course, the fact that I would've happily bought Netgear's hardware had it actually delivered the goods doesn't mean a thing to you either. Somehow, the money I'm willing to spend is fictitious or something I guess.
And unlike Redhat?
Blaming management mistakes on the market is businessman blunder #1. There are counter examples where management got it right and continues to do so.
The default mode for IPv6 is to assign the lower 64 bits based on the MAC address of the interface. Now, that is still far from random, but there is still a lot of entropy in it.
I have this idea for an IPv6 DHCP daemon that randomly assigns addresses and has a scheme for periodically rotating those assignments. That would solve the problem right there.
Well, that may be true. But a 128 bit address space is so sparse that passive scanning like the current worms do isn't much of an option any more. Even if you know a prefix to use the chances of your hitting a host in that prefix are still woefully small.
I sort of like this balance as well. An awful lot of useful data about who's funding which astroturfing effort has come from looking at DNS records.
I wonder if the planet would sort of act as a giant refinery, and after a few hundred million years all the minerals with lower melting points would be on the cold side, and all the minerals with higher melting points would be on the hot side?
Mine is because it's hosted on my own personal server and the email lives on an encrypted hard drive. :-) Unfortunately, I very, very rarely receive encrypted email, so it could easily be viewed in transit. :-(
Many wikis have advisory locks that work like this.
Oh, you're right. I didn't think of that. It would be more secure, and that's a good idea. And you're right, given that idea there is no good reason not to implement it using a MAC instead of a hash.
I still don't think the plain old hash is all that insecure though.
Oh, I just thought of a reason why the AJAX idea would be even harder than I originally thought. I bet the web app doesn't even use cookies or sessions at all. That makes that kind of thing a lot harder to implement.
A hash value is 43 bytes of base64 encoded stuff. It's trivial to validate that it's still 64 bytes of base64 encoded stuff when you get it back. And verifying that it's the right set of base64 encoded stuff is fairly easy too. If it matches the result of computing the hash of what's in the database, the database hasn't changed since the form was generated. If it has, the database hash changed. The only possible attack is fiddling the hash value to be the hash of the data that now is in the database, which would require a willing accomplice who could tell you what the new values are because that's how they set them. And the result of that would be that their values are stomped on.
Also, no SQL injection is possible because the hash value itself isn't stored in the database so there's no reason to include it in a database query in any way.
So, I don't think there is an attack that could work by fiddling the hash value sent back in a hidden form field.
And, doing so gives you extra security against X-site scripting attacks involving someone having a POST that goes against the web app URL from a completely different page. They are certain to not be able to get the hash value correct and the user isn't going to be tossed back from their attempt to post with a confusing message about the database having been updated since they filled out the form.
For extra security against X-site scripting attacks you can make the hash be a MAC instead and have the key be some secret server side data from the server side session data structure. But that then starts requiring you to actually have sessions, which it doesn't sound like the original poster has.
Just because someone is using data in hidden form fields for something important does not automatically mean that they are doing something insecure. This analysis I just posted was actually done in my head before I made the original post.