IANAL, but if you are not imposing a EULA, you shouldn't need any kind of license. End-user licenses restrict what can be done with the copy of the software that is owned. Licenses like the GPL restrict what can be done when redistributing the software, but impose nothing on the end-users. If you are not wanting to permit your end-users to redistribute, simple copyright is enough to protect your rights without the need for an additional license. If the software is not being redistributed and you aren't requiring a EULA, then the end-users are free to modify the software as they see fit (or do anything with it, except redistribute) under existing copyright law. So it seems copyright law as-is protects you from redistribution and permits your users the ability to modify the software, without the need of any license.
So you're in favor discriminating against people who are attracted to their own gender because your wife cheated on you and left you for another man, you can't get laid without paying for it and you wouldn't be able to find anyone to marry you anyway. You feel like a second class citizen so it makes sense to treat other people as second class citizens and deny them their rights. Fantastic.
Yes, because efficient government services have done such a great job at eliminating drugs, crime and poverty in the United States. And the way they provided food in China and toilet paper in the Soviet Union!! Tell me more about these wonderful government services that always do everything absolutely perfectly!...but never orders the company to pay the workers what they demand, or when it bails out the bank to prevent economic disaster, but never zeros out a person's mortgage.
Silly me, I thought most countries had the concept of bankruptcy which individuals could declare if they found themselves in a situation where they were unable to pay their bills!
How long do you think Qwest could retain customers -- especially business customers -- while cutting off access to half the Internet? I am not disputing that the Internet is highly centralized and that some jackasses can mess that up for their customers, but do you really think it would be in their best interests to do so? It sucks, but none of this is perfect. Intel could decide tomorrow that they will no longer allow Microsoft's OSes to run on their new chips, but it would be suicide. My point is that there are powerful incentives to cooperate and if someone chooses not to, they should be free to do so, but they will have to accept the consequences. I'm all for people finding out about this and complaining to Cogent and Telia. I hope it motivates them to correct the issue and ensure it never happens again.
Um, the Internet is surely important, but I wouldn't suggest it is more critical to survival than roads or food, both of which seem to be handled quite fine by private enterprise. And I take it you have never been involved in a traffic jam, because this kind of crap happens all the time in the real world. Yeah, it bites, but there are plenty of businesses who may hundreds of thousands a month of connectivity that will not be amused by this. I expect repercussions for the involved ISPs. The "answer" to me is to realize that sometimes people or organizations get into stupid disputes and it inconveniences people, but that people will find a way to work around it. This cannot turn out well for Cogent or Telia.
"Super robust Internet"? Good God, you must be one of those people who think the Internet was originally designed by the military to survive a nuclear attack. The Internet has always been fragile and highly dependent on centralized routing. It's a shame these two companies can't work together, but there are plenty of providers who have more respect for their customers. This isn't a conspiracy to undermine your rights, it's the inability of two for-profit businesses to act in the best interests of the customers who pay their bills. It sucks but it happens and we move on.
The Internet is built on cooperation. If two companies can't agree on how they will connect, then it seems they have that right. Just like their customers have the right to move to a different provider. Personally, if I was seriously affected by this I would never do business with either of the involved parties again. Hopefully people will leave and that will push them to negotiate, but I don't think they should be forced to work together if they don't want to.
Are you honestly shocked that regulatory agencies fail to uphold the ideals they were founded upon? What do you think happens when you unconstitutionally consolidate power into the hands of a few politicians, lobbyists and bureaucrats? If you've had even a rudimentary education in world or U.S. history you lose the right to act surprised when this happens. Oh, what am I saying? I'm sure Clinton's Ministry of Health will vastly improve the health of the nation! Just as I'm sure McCain's Ministry of Bat-shit Foreign Policy Decisions Expressed Through Beach Boys Songs will finally bring about world peace!
Oh, and you really are naive if you think Cheney is going to part with the sweets.
It's not being implanted in anyone, it's not being used to track personal information, it's just for inventory control. Maybe I'm missing something here, but this seems like the kind of application we should be supporting. Complaining about it seems almost as bad as the people who fought against barcodes because they contain the "mark of the Beast".
Almost every techie I've ever met who makes a broad statement like "(Linux|OS X) is way more secure than Windows" has been so security-retarded it's not even funny. I've used Linux exclusively for years but I'm under no delusions that any general-purpose execution environment is malware-proof. I used to run Win98 and Win2k without anti-virus or firewall and I only got a single virus in 6 years because I opened an exe sent to me by a friend. On my Linux box, anything worth doing can be done as me: stealing personal information, sniffing passwords and credit card numbers, running a botnet client or a daemon on a non-privileged port. I've also got SSH keys that grant me access to my own dedicated boxes, as well as dozens of my employer's servers, not to mention the source code to proprietary applications worth millions. What makes Linux safer is that most people aren't writing trojans for Linux. It's almost sad to watch the Mac market grow like it is, knowing what it will rain down on the smug little bastards. I've got nothing against Mac users, but at this point their hubris is almost Titanic in its proportions. Additionally, Linux has a steeper learning curve than Windows or Mac OS X, meaning most users are more likely to be aware of proper security concepts. Still, I've found rootkits on the servers of many *nix sysadmins. Oh, and they all believed Linux was "way more secure" than Windows.
Re:This just seems like nonsense.
on
Rails May Not Suck
·
· Score: 2, Informative
I agree that developers often try to use the wrong tool for the job. However, I think statements like "your task may not be suitable for Rails" only reinforce that. It's implying that Rails is the goal and that kind of thinking contributes to so many awful technical decisions, for any language.
You need to be pragmatic and smart to get the most out of any language, framework or tool. Rails can't make you write spaghetti code and I'm sure many people who bash Rails didn't take the time to learn how to properly use the tool, but that still doesn't mean that Rails protects against stupidity any more than PHP does.
Re:This just seems like nonsense.
on
Rails May Not Suck
·
· Score: 0, Redundant
The 'Preview' button is sometimes the right tool and sometimes I even use it.
This just seems like nonsense.
on
Rails May Not Suck
·
· Score: 4, Insightful
I am not a RoR developer, but I don't think the language or framework sucks. I've actually adopted a few ideas from it, but I still work much more efficiently in PHP as that is what I am familiar with. I have lots of respect for the guys at 37 Signals and the Ruby developers and I imagine it must be tiresome hearing about how much your language sucks. Still, this article is just worthless. The first two points seem to be saying "Rails isn't really unsuitable for your project because it is free and nothing is really perfect anyway."
Then there's the logical fallacy embedded in the statement "If Rails isn't right for your project, that doesn't mean that Rails sucks. It just means that your project isn't right for Rails." Sorry, if Rails isn't right for my project, then that means Rails isn't right for my project. It's like trying to shift the blame for inadequacy from the tool to the task. I'm not buying it.
The author then goes on to state that Rails is only for "smart people" and then makes the baseless claim like "It's much harder to fake being a good Rails developer than it is to fake being a good PHP developer." At this point, he's lost me.
Listen, folks, Rails is the right answer some of the time and it's the wrong answer some of the time. Just like any language. SQL, Javascript, PHP, Rails, C, Java: they all have things they are good at and things they are bad at. The author at least gets that part right, but then goes on to undermine it repeatedly. At the end of the day, articles like this only encourage the detractors and scare away the uninformed.
You have to wonder how many fuckups like this are never reported. Then we hear that the government can't possibly protect us when they have to follow the law.
Since it seems we could go around forever and we're not getting anywhere, I think this is going to be my last post on the subject. You're also getting a bit nasty. I should have previewed my last post, but I was in a bit of a hurry because I'm at work right now. I am a software engineer who does quite a bit of networking work and has an obsessive cryptography hobby. It seems like every few months somebody comes up with some elaborate system to avoid using iptables. Bonus points if they can somehow work cryptography into the whole thing and make TCP/IP more difficult to secure in the process.
The active port is the plaintext. That is exactly what I said. Your example with the Caesar cipher isn't half bad, but shimmer isn't encrypting a second key, it's using a cryptographic function and the current time to generate a port to listen on. Just because the plaintext is painfully easy to guess doesn't mean the system is relying on the secrecy of the algorithm. Even knowing the algorithm, I still have to brute force either the key or the plaintext. One of the biggest problems with shimmer is that the plaintext is far, far easier to guess than the key.
Imagine if instead of encrypting a port, we were encrypting a single bit and you had two attempts to guess it. I could encrypt that single bit with AES and give the result to you and ask you to guess the plaintext. Even by knowing the algorithm I used, you still have to brute force either the key or the plaintext. It's simple to see which would be easier. Obviously you would discard the ciphertext and just guess 0 and if that was incorrect, 1. Was my single bit secure? Of course not. Did knowing how I encrypted the single bit help you in guessing it? No. Now imagine if I just inverted the bit, but I don't tell you this. You are still going to have to guess, but if you knew the process I had used to obtain the "ciphertext" you would be able to "decipher" it with no work at all.
In terms of efficacy, both methods leave much to be desired. However when I invert the bit, I must keep the knowledge of the process to myself lest I save you a single calculation. With AES there is a large body of documentation of the algorithm, and yet I can rest soundly, secure in the knowledge that you must freqently guess TWICE, devouring your valuable time! Ha ha ha! So the real lesson here is that you should never encrypt a single bit, or for that matter, a 16 bit TCP port number. If you must engage in such absurdity, do not convince yourself the system is secure, even if the algorithm can be published with impunity.
Yet the set of possible active ports is not (and cannot be), and that's all one needs to get into the system. The entire point is that the key can be circumvented unless other secrets are kept.
That's like saying the AES algorithm is security through obscurity because if you have the plaintext you don't need the key.
Do you always interpret disagreement about how concepts apply as ignorance, or are you just being particularly arrogant today?
I apologize. My tone was a bit harsh but I didn't mean to offend. You are free to disagree, of course. Perhaps you fully understand the concepts represented and are missing how they apply. The active port is the "plaintext" and the key is how you find the port. There are several additional features (like the blacklisting) which do not weaken the cryptographic strength of the system, although they don't do much to enhance security either. Additionally, the blacklisting can be leveraged by malicious parties to lock out legitimate users, as I explained above. The biggest problem with the proposal is that the active port (or "plaintext") can be guessed trivially, making the cryptography pointless, also as explained by me above. That doesn't mean the system isn't cryptographically strong, just that overall it is poorly thought out and more harmful than helpful. The real lesson is that strong cryptography is no panacea, but only a piece of the security process. I should note that I haven't actually bothered to verify that the developers of shimmer haven't introduced errors in their implementation of the cryptography in question, I was only evaluating the theoretical aspects of their proposal. Since cryptography is notoriously difficult to work with and many otherwise brilliant developers have introduced glaring security holes by attempting to use it in novel ways, this is quite possible.
I would not wish to be in a situation where you ability to write networking code or evaluate the merits of a security methodology might actually matter. Not to offend, just the way it is. Hundreds of thousands of people on a daily basis rely on my ability to perform these tasks correctly. It goes without saying that I am imperfect and make mistakes, but not very frequently.:-)
The currently active port is derived from the key, via the algorithm. Just knowing the algorithm without the key would not tell you which port was in use. As evidenced by your other comments here, you are ignorant of many cryptographic and networking fundamentals. I don't mean that in an insulting way and you shouldn't let yourself be discouraged, but please educate yourself before you make broad statements that are inconsistent with the facts.
You obviously have no idea how sockets work. The daemon does not close the connection nor does it need to to open accept new connections. The client IP and port and the server IP and port all combined make a unique connection.
Then you are incorrect. You are splitting hairs with your definition and missing the real point that embedding secrets in the algorithm is not secure. The "that's security by obscurity" argument is a completely valid one to make, assuming the proposed idea really meets the criteria. That doesn't appear to be the case here, even though the proposal does suffer from an extremely small keyspace and requires sending a plaintext key across the wire. So it is insecure, but it fails the obscurity argument. Still, the very definition of "security through obscurity" is embedding secrets in the process and not the key and you can't just disagree with the definition of a term you had no part in defining.
Yes, this is a horrible, insecure idea but it is still not security through obscurity. Having access to the source code and algorithm does not allow you to guess the port any more easily than by brute force (assuming there are no flaws in the cryptographic method used to determine the port). The small number of ports makes brute forcing easy, but that still does not make this security through obscurity. Short passwords are also insecure, but that doesn't change the cryptographic strength of the underlying authentication mechanism. The ports can be sniffed, but so can any plaintext password, which is precisely why the proposed idea is about as stupid as sending unhashed, 3 letter passwords over the wire. Security through obscurity means that an attempt at security has been embedded in the algorithm itself and not in the key, which is not the case here. Please read up on Kerckhoff's principle.
That's still not security through obscurity because it requires a shared secret to work. The method for determining the next port is not completely encoded in the algorithm, but instead is dependent on an external key. Using zombie machines would be little more than brute forcing the key, although the relatively small number of TCP ports results in a very short key length.
Actually, it seems possible to lock out legitimate users as well, by sending them to a URL like http://example.com:12345/ Since it only appears to be operating at the TCP layer, requests from a web browser would accomplish the goal of blacklisting a target IP. If port 12345 was one of the honeypots at that time, the legitimate user gets blacklisted. Throw it on a malicious web page that uses several XMLHttpRequests to try various ports and you have a pretty good shot at locking the user out.
Slashdot Mirror
IANAL, but if you are not imposing a EULA, you shouldn't need any kind of license. End-user licenses restrict what can be done with the copy of the software that is owned. Licenses like the GPL restrict what can be done when redistributing the software, but impose nothing on the end-users. If you are not wanting to permit your end-users to redistribute, simple copyright is enough to protect your rights without the need for an additional license. If the software is not being redistributed and you aren't requiring a EULA, then the end-users are free to modify the software as they see fit (or do anything with it, except redistribute) under existing copyright law. So it seems copyright law as-is protects you from redistribution and permits your users the ability to modify the software, without the need of any license.
So you're in favor discriminating against people who are attracted to their own gender because your wife cheated on you and left you for another man, you can't get laid without paying for it and you wouldn't be able to find anyone to marry you anyway. You feel like a second class citizen so it makes sense to treat other people as second class citizens and deny them their rights. Fantastic.
Yes, because efficient government services have done such a great job at eliminating drugs, crime and poverty in the United States. And the way they provided food in China and toilet paper in the Soviet Union!! Tell me more about these wonderful government services that always do everything absolutely perfectly! ...but never orders the company to pay the workers what they demand, or when it bails out the bank to prevent economic disaster, but never zeros out a person's mortgage.
Silly me, I thought most countries had the concept of bankruptcy which individuals could declare if they found themselves in a situation where they were unable to pay their bills!
How long do you think Qwest could retain customers -- especially business customers -- while cutting off access to half the Internet? I am not disputing that the Internet is highly centralized and that some jackasses can mess that up for their customers, but do you really think it would be in their best interests to do so? It sucks, but none of this is perfect. Intel could decide tomorrow that they will no longer allow Microsoft's OSes to run on their new chips, but it would be suicide. My point is that there are powerful incentives to cooperate and if someone chooses not to, they should be free to do so, but they will have to accept the consequences. I'm all for people finding out about this and complaining to Cogent and Telia. I hope it motivates them to correct the issue and ensure it never happens again.
Um, the Internet is surely important, but I wouldn't suggest it is more critical to survival than roads or food, both of which seem to be handled quite fine by private enterprise. And I take it you have never been involved in a traffic jam, because this kind of crap happens all the time in the real world. Yeah, it bites, but there are plenty of businesses who may hundreds of thousands a month of connectivity that will not be amused by this. I expect repercussions for the involved ISPs. The "answer" to me is to realize that sometimes people or organizations get into stupid disputes and it inconveniences people, but that people will find a way to work around it. This cannot turn out well for Cogent or Telia.
"Super robust Internet"? Good God, you must be one of those people who think the Internet was originally designed by the military to survive a nuclear attack. The Internet has always been fragile and highly dependent on centralized routing. It's a shame these two companies can't work together, but there are plenty of providers who have more respect for their customers. This isn't a conspiracy to undermine your rights, it's the inability of two for-profit businesses to act in the best interests of the customers who pay their bills. It sucks but it happens and we move on.
The Internet is built on cooperation. If two companies can't agree on how they will connect, then it seems they have that right. Just like their customers have the right to move to a different provider. Personally, if I was seriously affected by this I would never do business with either of the involved parties again. Hopefully people will leave and that will push them to negotiate, but I don't think they should be forced to work together if they don't want to.
Patrick Dempsey? WTF?
I know this is probably redundant, but I'm drunk and don't give a shit.
Are you honestly shocked that regulatory agencies fail to uphold the ideals they were founded upon? What do you think happens when you unconstitutionally consolidate power into the hands of a few politicians, lobbyists and bureaucrats? If you've had even a rudimentary education in world or U.S. history you lose the right to act surprised when this happens. Oh, what am I saying? I'm sure Clinton's Ministry of Health will vastly improve the health of the nation! Just as I'm sure McCain's Ministry of Bat-shit Foreign Policy Decisions Expressed Through Beach Boys Songs will finally bring about world peace!
Oh, and you really are naive if you think Cheney is going to part with the sweets.
It's not being implanted in anyone, it's not being used to track personal information, it's just for inventory control. Maybe I'm missing something here, but this seems like the kind of application we should be supporting. Complaining about it seems almost as bad as the people who fought against barcodes because they contain the "mark of the Beast".
Almost every techie I've ever met who makes a broad statement like "(Linux|OS X) is way more secure than Windows" has been so security-retarded it's not even funny. I've used Linux exclusively for years but I'm under no delusions that any general-purpose execution environment is malware-proof. I used to run Win98 and Win2k without anti-virus or firewall and I only got a single virus in 6 years because I opened an exe sent to me by a friend. On my Linux box, anything worth doing can be done as me: stealing personal information, sniffing passwords and credit card numbers, running a botnet client or a daemon on a non-privileged port. I've also got SSH keys that grant me access to my own dedicated boxes, as well as dozens of my employer's servers, not to mention the source code to proprietary applications worth millions. What makes Linux safer is that most people aren't writing trojans for Linux. It's almost sad to watch the Mac market grow like it is, knowing what it will rain down on the smug little bastards. I've got nothing against Mac users, but at this point their hubris is almost Titanic in its proportions. Additionally, Linux has a steeper learning curve than Windows or Mac OS X, meaning most users are more likely to be aware of proper security concepts. Still, I've found rootkits on the servers of many *nix sysadmins. Oh, and they all believed Linux was "way more secure" than Windows.
I agree that developers often try to use the wrong tool for the job. However, I think statements like "your task may not be suitable for Rails" only reinforce that. It's implying that Rails is the goal and that kind of thinking contributes to so many awful technical decisions, for any language.
You need to be pragmatic and smart to get the most out of any language, framework or tool. Rails can't make you write spaghetti code and I'm sure many people who bash Rails didn't take the time to learn how to properly use the tool, but that still doesn't mean that Rails protects against stupidity any more than PHP does.
The 'Preview' button is sometimes the right tool and sometimes I even use it.
I am not a RoR developer, but I don't think the language or framework sucks. I've actually adopted a few ideas from it, but I still work much more efficiently in PHP as that is what I am familiar with. I have lots of respect for the guys at 37 Signals and the Ruby developers and I imagine it must be tiresome hearing about how much your language sucks. Still, this article is just worthless. The first two points seem to be saying "Rails isn't really unsuitable for your project because it is free and nothing is really perfect anyway." Then there's the logical fallacy embedded in the statement "If Rails isn't right for your project, that doesn't mean that Rails sucks. It just means that your project isn't right for Rails." Sorry, if Rails isn't right for my project, then that means Rails isn't right for my project. It's like trying to shift the blame for inadequacy from the tool to the task. I'm not buying it. The author then goes on to state that Rails is only for "smart people" and then makes the baseless claim like "It's much harder to fake being a good Rails developer than it is to fake being a good PHP developer." At this point, he's lost me. Listen, folks, Rails is the right answer some of the time and it's the wrong answer some of the time. Just like any language. SQL, Javascript, PHP, Rails, C, Java: they all have things they are good at and things they are bad at. The author at least gets that part right, but then goes on to undermine it repeatedly. At the end of the day, articles like this only encourage the detractors and scare away the uninformed.
You have to wonder how many fuckups like this are never reported. Then we hear that the government can't possibly protect us when they have to follow the law.
Since it seems we could go around forever and we're not getting anywhere, I think this is going to be my last post on the subject. You're also getting a bit nasty. I should have previewed my last post, but I was in a bit of a hurry because I'm at work right now. I am a software engineer who does quite a bit of networking work and has an obsessive cryptography hobby. It seems like every few months somebody comes up with some elaborate system to avoid using iptables. Bonus points if they can somehow work cryptography into the whole thing and make TCP/IP more difficult to secure in the process.
The active port is the plaintext. That is exactly what I said. Your example with the Caesar cipher isn't half bad, but shimmer isn't encrypting a second key, it's using a cryptographic function and the current time to generate a port to listen on. Just because the plaintext is painfully easy to guess doesn't mean the system is relying on the secrecy of the algorithm. Even knowing the algorithm, I still have to brute force either the key or the plaintext. One of the biggest problems with shimmer is that the plaintext is far, far easier to guess than the key.
Imagine if instead of encrypting a port, we were encrypting a single bit and you had two attempts to guess it. I could encrypt that single bit with AES and give the result to you and ask you to guess the plaintext. Even by knowing the algorithm I used, you still have to brute force either the key or the plaintext. It's simple to see which would be easier. Obviously you would discard the ciphertext and just guess 0 and if that was incorrect, 1. Was my single bit secure? Of course not. Did knowing how I encrypted the single bit help you in guessing it? No. Now imagine if I just inverted the bit, but I don't tell you this. You are still going to have to guess, but if you knew the process I had used to obtain the "ciphertext" you would be able to "decipher" it with no work at all.
In terms of efficacy, both methods leave much to be desired. However when I invert the bit, I must keep the knowledge of the process to myself lest I save you a single calculation. With AES there is a large body of documentation of the algorithm, and yet I can rest soundly, secure in the knowledge that you must freqently guess TWICE, devouring your valuable time! Ha ha ha! So the real lesson here is that you should never encrypt a single bit, or for that matter, a 16 bit TCP port number. If you must engage in such absurdity, do not convince yourself the system is secure, even if the algorithm can be published with impunity.
Yet the set of possible active ports is not (and cannot be), and that's all one needs to get into the system. The entire point is that the key can be circumvented unless other secrets are kept. That's like saying the AES algorithm is security through obscurity because if you have the plaintext you don't need the key. Do you always interpret disagreement about how concepts apply as ignorance, or are you just being particularly arrogant today? I apologize. My tone was a bit harsh but I didn't mean to offend. You are free to disagree, of course. Perhaps you fully understand the concepts represented and are missing how they apply. The active port is the "plaintext" and the key is how you find the port. There are several additional features (like the blacklisting) which do not weaken the cryptographic strength of the system, although they don't do much to enhance security either. Additionally, the blacklisting can be leveraged by malicious parties to lock out legitimate users, as I explained above. The biggest problem with the proposal is that the active port (or "plaintext") can be guessed trivially, making the cryptography pointless, also as explained by me above. That doesn't mean the system isn't cryptographically strong, just that overall it is poorly thought out and more harmful than helpful. The real lesson is that strong cryptography is no panacea, but only a piece of the security process. I should note that I haven't actually bothered to verify that the developers of shimmer haven't introduced errors in their implementation of the cryptography in question, I was only evaluating the theoretical aspects of their proposal. Since cryptography is notoriously difficult to work with and many otherwise brilliant developers have introduced glaring security holes by attempting to use it in novel ways, this is quite possible.
I would not wish to be in a situation where you ability to write networking code or evaluate the merits of a security methodology might actually matter. Not to offend, just the way it is. Hundreds of thousands of people on a daily basis rely on my ability to perform these tasks correctly. It goes without saying that I am imperfect and make mistakes, but not very frequently. :-)
The currently active port is derived from the key, via the algorithm. Just knowing the algorithm without the key would not tell you which port was in use. As evidenced by your other comments here, you are ignorant of many cryptographic and networking fundamentals. I don't mean that in an insulting way and you shouldn't let yourself be discouraged, but please educate yourself before you make broad statements that are inconsistent with the facts.
You obviously have no idea how sockets work. The daemon does not close the connection nor does it need to to open accept new connections. The client IP and port and the server IP and port all combined make a unique connection.
Then you are incorrect. You are splitting hairs with your definition and missing the real point that embedding secrets in the algorithm is not secure. The "that's security by obscurity" argument is a completely valid one to make, assuming the proposed idea really meets the criteria. That doesn't appear to be the case here, even though the proposal does suffer from an extremely small keyspace and requires sending a plaintext key across the wire. So it is insecure, but it fails the obscurity argument. Still, the very definition of "security through obscurity" is embedding secrets in the process and not the key and you can't just disagree with the definition of a term you had no part in defining.
Yes, this is a horrible, insecure idea but it is still not security through obscurity. Having access to the source code and algorithm does not allow you to guess the port any more easily than by brute force (assuming there are no flaws in the cryptographic method used to determine the port). The small number of ports makes brute forcing easy, but that still does not make this security through obscurity. Short passwords are also insecure, but that doesn't change the cryptographic strength of the underlying authentication mechanism. The ports can be sniffed, but so can any plaintext password, which is precisely why the proposed idea is about as stupid as sending unhashed, 3 letter passwords over the wire. Security through obscurity means that an attempt at security has been embedded in the algorithm itself and not in the key, which is not the case here. Please read up on Kerckhoff's principle.
Passwords (or any other shared secret) are not security through obscurity. http://en.wikipedia.org/wiki/Kerckhoffs%27_principle
That's still not security through obscurity because it requires a shared secret to work. The method for determining the next port is not completely encoded in the algorithm, but instead is dependent on an external key. Using zombie machines would be little more than brute forcing the key, although the relatively small number of TCP ports results in a very short key length.
Actually, it seems possible to lock out legitimate users as well, by sending them to a URL like http://example.com:12345/ Since it only appears to be operating at the TCP layer, requests from a web browser would accomplish the goal of blacklisting a target IP. If port 12345 was one of the honeypots at that time, the legitimate user gets blacklisted. Throw it on a malicious web page that uses several XMLHttpRequests to try various ports and you have a pretty good shot at locking the user out.