I can't comment on FTP servers, but it is certainly not the IRC protocol being to blame here.
There are several faults of freenode:
First of all, the authentication mechanism freenode employs is not written down in any IRC protocol. It is freenode's decision to use this authentication mechanism. As a proof that this can be done in a much more secure way on IRC, just look for example at QuakeNet. They are using a challenge authentication mechanism to authenticate users, yet they are still fully IRC compilant.
Thus, using a weak authentication mechanism that can be easily sniffed is a fault of freenode.
The second fault of freenode is the ability for IRC Operators to take the nickname of services bots without having access to the server computer. Other networks disallow the use of common IRC service nicks for everyone, without the possibility to override.
Was freenode not using insecure server software, this security breach could have been avoided as well.
Thirdly and fourthly, freenode supports authentication via the IRC PASS command as well as using the proprietary IRC NS or NICKSERV command extensions additionally to the PRIVMSG NickServ authentication mechanism.
Such extensions are usually supposed to be more secure than just a PRIVMSG, since the software can easily make sure that such commands are ONLY forwarded to services.
However, freenode server software will happily forward the passwords introduced via these alternate authentication comands to whichever person (service or IRC Operator) is currently carrying the correct nick.
Freenode fails to send messages to NickServ to NickServ@services.server, as well as promote this possibility (or even enforce it) like other networks do (example: Undernet, one of the largest networks).
Not only do they fail to promote this more secure alternative, but it is actually a broken server implementation that makes it impossible for them to use this additional security feature which would make sure that passwords end up only on the services servers.
Fifthly and lastly, using a hostmask of *@* in the IRC Operator line is just foolish. It serves the network head right to have been taught a lesson, but it is unfortunate that he put his users and their credentials in danger.
Such situation could also be avoided by using a more strict and secure IRC server software, but most of all this could have been avoided by simply some more cautiousness on the Network Administrator's side. Not using a blank wildcard in your IRC Operator line is like the first bold warning found on every Beginner IRC Admin tutorial.
As such, it can be very well aid that the whole situation is at the sole fault of freenode alone, and the IRC protocol - be it flawed all the way - can not be blamed for this.
On a sidenote, I am amazed that despite the IRC question time there still is no official announcement about this on their website.
Slashdot Mirror
There are several faults of freenode:
- First of all, the authentication mechanism freenode employs is not written down in any IRC protocol. It is freenode's decision to use this authentication mechanism. As a proof that this can be done in a much more secure way on IRC, just look for example at QuakeNet. They are using a challenge authentication mechanism to authenticate users, yet they are still fully IRC compilant.
- The second fault of freenode is the ability for IRC Operators to take the nickname of services bots without having access to the server computer. Other networks disallow the use of common IRC service nicks for everyone, without the possibility to override.
- Thirdly and fourthly, freenode supports authentication via the IRC PASS command as well as using the proprietary IRC NS or NICKSERV command extensions additionally to the PRIVMSG NickServ authentication mechanism.
Such extensions are usually supposed to be more secure than just a PRIVMSG, since the software can easily make sure that such commands are ONLY forwarded to services.
- Fifthly and lastly, using a hostmask of *@* in the IRC Operator line is just foolish. It serves the network head right to have been taught a lesson, but it is unfortunate that he put his users and their credentials in danger.
As such, it can be very well aid that the whole situation is at the sole fault of freenode alone, and the IRC protocol - be it flawed all the way - can not be blamed for this.Thus, using a weak authentication mechanism that can be easily sniffed is a fault of freenode.
Was freenode not using insecure server software, this security breach could have been avoided as well.
However, freenode server software will happily forward the passwords introduced via these alternate authentication comands to whichever person (service or IRC Operator) is currently carrying the correct nick.
Freenode fails to send messages to NickServ to NickServ@services.server, as well as promote this possibility (or even enforce it) like other networks do (example: Undernet, one of the largest networks).
Not only do they fail to promote this more secure alternative, but it is actually a broken server implementation that makes it impossible for them to use this additional security feature which would make sure that passwords end up only on the services servers.
Such situation could also be avoided by using a more strict and secure IRC server software, but most of all this could have been avoided by simply some more cautiousness on the Network Administrator's side. Not using a blank wildcard in your IRC Operator line is like the first bold warning found on every Beginner IRC Admin tutorial.
On a sidenote, I am amazed that despite the IRC question time there still is no official announcement about this on their website.
Other IRC networks use challenge auth mechanisms for services authentiication without problems...