Anope IRC Services

Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1]   Go Down

Author Topic: [FEATURE] Add a secured host option  (Read 6184 times)

0 Members and 1 Guest are viewing this topic.

katsklaw

  • Supporter
  • Anope User
  • Offline Offline
  • Posts: 537
[FEATURE] Add a secured host option
« on: February 02, 2011, 10:53:58 PM »

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.
« Last Edit: February 06, 2011, 04:36:08 PM by katsklaw »
Logged

Jan Milants

  • Team
  • *
  • Offline Offline
  • Gender: Male
  • Posts: 1372
Re: Add a secured host option
« Reply #1 on: February 03, 2011, 01:08:16 PM »

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.
Logged
If you like me donate coins to 1FBmZVT4J8WAUMHKqpWhgNVj3XXnRN1cCk :)

katsklaw

  • Supporter
  • Anope User
  • Offline Offline
  • Posts: 537
Re: Add a secured host option
« Reply #2 on: February 03, 2011, 01:38:18 PM »

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.
Logged

katlyn

  • Anope User
  • Offline Offline
  • Gender: Female
  • Posts: 7
  • i LOVE anope :)
    • Quakenet
Re: [FEATURE] Add a secured host option
« Reply #3 on: February 16, 2011, 09:44:40 PM »

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

katsklaw

  • Supporter
  • Anope User
  • Offline Offline
  • Posts: 537
Re: [FEATURE] Add a secured host option
« Reply #4 on: February 16, 2011, 09:52:19 PM »

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.
« Last Edit: February 16, 2011, 09:55:00 PM by katsklaw »
Logged

katlyn

  • Anope User
  • Offline Offline
  • Gender: Female
  • Posts: 7
  • i LOVE anope :)
    • Quakenet
Re: [FEATURE] Add a secured host option
« Reply #5 on: February 16, 2011, 10:00:06 PM »

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).
Logged

katsklaw

  • Supporter
  • Anope User
  • Offline Offline
  • Posts: 537
Re: [FEATURE] Add a secured host option
« Reply #6 on: February 16, 2011, 11:13:28 PM »

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.

Quote
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.

Quote
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.
Logged
Pages: [1]   Go Up