Print

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

[katsklaw]

What I mean is add an optional feature that will disallow a user from identifying if they are not from a known host listed in the ns access list. User issues /ns identify MyUberPass and if their current hostmask is not listed in their ns access list, NS replies "Authentication Failed: Bad Host mask".

I'm really at odds here that the only thing stopping an account take over is a simple password. Anyone that gets NS access has full access to that users account, channels and all since we were so wise to remove the additional security measure formally known as /cs identify. At least then channel founder access was protected by 2 passwords.

Right know anyone that ID's to nickserv from host *@* can use NS/CS/MS commands as said user and OS commands if the network chooses the option to not set OSOpersOnly. In my very humble opinion that is really wrong. UnderNet admin accounts have been social engineered with more security than Anope 1.9 currently offers.

What I'm asking is to at least make it optional for users to connect from a known host before identifying is successful. CS opers should also have the ability to add new hostmasks to nicks in the event of ISP changes etc .. Yes, I know social engineering can get the wrong host added and that nothing is perfect, but at least its better than blindly accepting passwords from everyone.

I can write a module for this for 1.8 if I get time even though it's rather easy but I'll have neither the time nor the skills to do this for 1.9.

[Jan Milants]

This is largely already possible with SET KILL IMMED: it prevents users who are not on the access list from using and thus identifying to the nickname.. this however can currently still be circumvented through NS GROUP.. what s described here can simply be achieved by using a module that restricts GROUP to users on the access list.

[katsklaw]

My suggestion has nothing to do with nick usage. it has to do with *Serv access. While I agree SET KILL IMMED will work as you suggest, I doubt many nets would encourage their users to us it, I know I wouldn't.

There is a difference between allowing a registered nick to be used and granting access to services for that nick.

[katlyn]

As in similar to the way srvx/x3 deals with hostmasks and authing?

[katsklaw]

As in similar to the way srvx/x3 deals with hostmasks and authing?

Indeed. As well as GNUworld, CServe/Uworld (from the 90's even), old K9 from ChatNet (again from the 90's).

DALnet still uses /cs identify
GNUworld even hostmask protects CServices access as well, although the default mask is *@*.
Atheme also takes additional steps (/os identify) to protect sensitive access. Although it don't require a channel password either.

It seems to me that Anope is taking security out, not improving upon it. It's sad that I have software from several years before Anope was forked that is more secure when it comes to *Serv access. Thank goodness we have 5 encryption methods to choose from though.

[katlyn]

Would you be against letting users recover their account via e-mail if their hostmask has changed?

Although not necessarily an issue for smaller networks, having to deal with a constant stream of queries re. getting a mask added to their account could be quite tiresome. If the email option fails for them, they then can seek support from the network's staff.

Then again, email recovery could be a config option. God knows how many people use the same password for their email address as they do for their services password (and pretty much everything else).

[katsklaw]

Would you be against letting users recover their account via e-mail if their hostmask has changed?

Absolutely not, any plan is better than no plan. Some form of auth cookie/token is good.

Although not necessarily an issue for smaller networks, having to deal with a constant stream of queries re. getting a mask added to their account could be quite tiresome. If the email option fails for them, they then can seek support from the network's staff.

Agreed, making my feature optional via config is fully acceptable too because it'll be something I can enable and those not worried about it can leave disabled. Even as a 3rd party module will work.

Then again, email recovery could be a config option. God knows how many people use the same password for their email address as they do for their services password (and pretty much everything else).

True enough, but again, it's still an extra step. User education as massive a task as it is can help here as well too.