Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[robertorg2005]

[katsklaw]

I moved this to Anope General because you did not make a feature request or suggestion. You asked a question which makes it support related.

Now, please rephase your question as the way it's worded now makes no sense.

[Jobe]

Do you mean how do you use MD5 encrypted passwords in the database?

If so, you will need to start with a fresh DB, and set EncModule to enc_md5 (if Anope 1.7.19) If 1.6.5 you will need to recompile, but bear in mind Anope 1.6.5 doesnt use real MD5, it uses a broken implimentation and upgrading to Anope 1.7.19 from there will require you to set EncModule to enc_old

[sdamon]

I think he means how does he do md5 login as possible on sorcery irc services.

http://www.sorcery.net/content/view/56/414/

http://www.sorcery.net/content/view/27/422/#md

and if that IS what he meant, its a feature request/module request..and i second it.

[katsklaw]

Originally posted by sdamon
I think he means how does he do md5 login as possible on sorcery irc services.

http://www.sorcery.net/content/view/56/414/

http://www.sorcery.net/content/view/27/422/#md

and if that IS what he meant, its a feature request/module request..and i second it.

Since there are nearly 1 million IRC'ers out there and only a few thousand SorceryNet users, it's not very likely that's what they are refering to.

However, if it is, you have clearly already made such a request, which off topic I can tell you will not be in the core. At least not Anope 1.6, 1.7 or 1.8. This can actually be handled with a 3rd party module and which case won't go to feature requests.

In the case of it being released as a module, there is a coder working on just such a thing with no intended release date, if ever.

Personally I feel the best security is to simply use an "irc set of passwords" that are not used fr anything else .. after all .. it IS just IRC. If you link services to a local ircd to services and have all servers use ssl connections, then there is no need for any other type of encrypted passwords in the data stream as the only place that passwords can be sniffed is as root on a box that hosts an IRCD, in which case ssl connected servers won't mean a hill of beans as packets can be sniffed after they are decrypted. Users can also connect with ssl enabled clients to said ssl enabled ircds and all traffic to and from services would then be encrypted. Such technologies already exist so no one needs to code yet another method of doing the same thing.

[sdamon]

Personally I feel the best security is to simply use an \"irc set of passwords\" that are not used fr anything else .. after all .. it IS just IRC. If you link services to a local ircd to services and have all servers use ssl connections, then there is no need for any other type of encrypted passwords in the data stream as the only place that passwords can be sniffed is as root on a box that hosts an IRCD, in which case ssl connected servers won\'t mean a hill of beans as packets can be sniffed after they are decrypted. Users can also connect with ssl enabled clients to said ssl enabled ircds and all traffic to and from services would then be encrypted. Such technologies already exist so no one needs to code yet another method of doing the same thing.

That makes sense, but your audience is an inherently paranoid bunch: IRC Admins.

To continue this in a philosophical manor, I really dont see this as a method that will be used by users as much as it would by bots.  Most people running eggdrops and various other bots prolly arn't running stunnel.  and they are often on shared shell host boxes.  So you have an insecure connection (without patching with code that has proved to be unstable, to create secure ones), on an untrusted box (in the network sense.  The file security of the box can be enforced by the user), and a nickserv account with (unboutedly) some privilege in services.  There, in that limited, but all too common, circumstance lies a need.

now we can debate the merits and abundant flaws in running a bot with privileges to services (i reference chanserv mostly.  a bot with operserv privs..well...the network that does that, deserves what it gets in my opinion), but users are going to do it anyways.  Providing a mechanism for challenge based authentication will at least remove a portion of the 'untrusted box' problem.

That said, Im a paranoid freak, and I am all for multi-factor authentication wherever I can get it.  If i could authenticate with a YubiKey (This thing makes my mouth water its so cool), I would.  I'm going to hold off on the module request for that for a while.

[katsklaw]

Relax, It's only IRC. The only thing that matters are IRC passwords. oper/nick/chan. If you are so paranoid about those trivial passwords being stolen, then IRC is not for you. I don't mean that in a bad way. There are far worse things on IRC that your NickServ password being discovered.

Your chances of having your password "hacked" is very very remote to start with. There is a far greater chance that you will accidentally compromise it yourself. I've opered on the largest nets in the world as well as have visited roughly 50% of the existing networks and have never had a problem and even if I did, the problem would be limited to IRC as my IRC passwords do not match any other password I use. I even use a dedicated email address for IRC.

In this day and age on IRC, "hackers" really could care less about your passwords anyway. If they wanted to "attack" you they just DDoS your ISP or the network into oblivion.

[sdamon]

I said i was paranoid...never said anything about being rational. 

Luckily ISPs are mostly sensitive to a user getting ddosed and usually filter it, or ISPs for data centers for that matter.  Aslong as you keep patched systems, yeah your fine...