[NickServ] Possible enhancement via module to SASL notifications

[TehPeGaSuS]

There's one thing that I like in Freenode:
When someone connect, identifying to some nickname via SASL you receive a notification about successful/unsuccessful login attempt.

Would it be possible to enhance Anope NickServ features to have something like that?

How it would work:

1. If account has already one or more nicknames logged in, send a notification to each user logged in about the successful/unsuccessful login attempt along with the nickname that tried to login and possibly the IP address (privacy concerns here, see note below).
2. If account has no users logged in, store the attempts and send them via memo with the details of 1.

Currently anyone can hack our account and we are not aware of anything, which is also a lack of security.
This could be possibly extended to trigger on /ns id nick password, to prevent abuses and help the end user to keep his account/nicknames protected

Thoughts on this?

NOTE

While there can be some NO's about sending the IP information to the end user, this could help that same user when reporting the situation to an IRCop providing the many details as possible, and therefore, IRCops could take measures (akill, gline, etc) against the offending user/IP

[TehPeGaSuS]

I hope this can be made possible, which in some way helps to enhance Anope security levels

[KoraggKnightWolf]

Idea: For /ns identify it would only send the cloak/vhost if the IRCd supports it and the user has a cloak/vhost set. On SASL this often cannot be done, but at least on /ns identify perhaps. (It appears the only network having false SASL attempts ever is freenode for some reason).

Regards,

Koragg

[genius3000]

Idea: For /ns identify it would only send the cloak/vhost if the IRCd supports it and the user has a cloak/vhost set. On SASL this often cannot be done, but at least on /ns identify perhaps. (It appears the only network having false SASL attempts ever is freenode for some reason).

Regards,

Koragg

@KoraggKnightWolf Your comment is very confusing as it sounds irrelevant to the issue/request and doesn't really make sense beyond that either.

[KoraggKnightWolf]

Refering to the NOTE part of @TheMythPT in regards to this module potentially revealing the real IP/host of someone attempting to login into a NickServ account via /ns identify. I hope this clarifies what I meant to say and if not, I can try to elaborate further what my thoughts were meant to be.

Regards,

Koragg

[TehPeGaSuS]

I believe that the IP of the user attempting the SASL or even the /ns id should be passed to the affected user no matter what. After all, it's our identity that's at risk!
In a small network, it's easy for admins to search for the user that tries to access a certain account, but that doesn't happen if you have hundreds or thousands of users.
But, that's my 2 cents on this. 😄

[genius3000]

Anything else I know that sends notices for logins (successful or failed) will send the real IP.
Examples:

• ChatServices shows current logins to an account and "Last login from" upon logging in.
• OVH can email the account holder on any login attempts to the web manager, even successful ones.

[TehPeGaSuS]

Exactly!
That also happens with social networks and chat platforms.
Showing the IP is a way to ensure that the user owns the IP, in the case you have several machines/IPS with different services, etc.
Concerning the users shouldn't see other users IP thing, there's more ways to know the users IPS, like providing an URL for something that you host and then seeing Apache logs in example.

[KoraggKnightWolf]

It does appear that often attempted logins are by having common names/nicks registered (for example often Guest or common first names etc). Someone could use this to get IP's of people for whatever reason (and if they abuse this for DDoS even banning them won't be enough, and informing authorities wouldn't help either as they don'c care about IRC).
On SASL auth yes, the logging in does happen before registration is complete (before any modes, including a cloak mode, being set), but /ns identify always occurs afterwards.
Also, an oper could just easily "see through" the cloak (/WHOIS or /WHOWAS + compare the cloaks) anyway, as the only true solution would be to report to an oper anyway.

[KoraggKnightWolf]

Not sure if this was thought of, but perhaps also add a NickServ command to check in currently logged in nicks, e.g. /ns listlogins would show "Currently logged in Nicks: A B C" (when A B and C are logged into that account). Perhaps also auto add this info to /ns info itself as it is quite crucial, would tha be possible as well?
The extra command and/or info output is useful for those who do not have an always online connection like a BNC.

Regards,

Koragg

[KoraggKnightWolf]

Also perhaps showing the last attempted login (either last attempted at all, successful or not, OR perhaps just the last successful one?) upon logging in would also be beneficial. as well.

[TehPeGaSuS]

It does appear that often attempted logins are by having common names/nicks registered (for example often Guest or common first names etc). -- If this is the case, the attempts won't happen very often

The /ns listlogins would be nice indeed.

Showing the last login (successful or not) is covered in the original request already.

This would work almost like in Freenode, basically.

[genius3000]

Here's a rundown of what I've got started (or planned) for this:

• Two lists (backend speak) with a configurable max (per account):
  • History of successful logins.
  • History of failed logins.
• Upon logging in, you are shown the nick!user@host (ip) [fingerprint] since <time of connect and how long ago> for:
  • Last successful login.
  • Any failed logins since last successful login. This will probably be last three with notice of more.
  • Any other current logins.
• When logged in and another login occurs you are notified, same format as above.
• Commands:
  • NickServ SET LOGINHISTORY {ON | OFF}
    • Turns entire feature on or off.
  • NickServ SET LOGINFAILNOTICE {ON | OFF | DAILY | WEEKLY}
    • On: immediate/live notices of failed login.
    • Off: no live notices.
    • Daily: daily digest of any failed logins.
    • Weekly: weekly digest of failed logins.
    • Daily and Weekly plan is to send memo if no current login. Might not happen, but I like the idea.
  • NickServ LOGINHISTORY [FAIL | SUCCESS] [ALL]
    • No parameter: last three of each shown.
    • Type specified: last six unless ALL is specified.
  • NickServ LOGINLIST
    • All currently logged in users.

[TehPeGaSuS]

That looks awesome! Seems all is covered with your ideas. Looking forward to it! 😄 Na(o) Qui, 10 de jan de 2019, 08:54, Matt Schatz <notifications@github.com> escreveu:

…

Here's a rundown of what I've got started (or planned) for this: - Two lists (backend speak) with a configurable max (per account): - History of successful logins. - History of failed logins. - Upon logging in, you are shown the ***@***.*** (ip) [fingerprint] since <time of connect and how long ago> for: - Last successful login. - Any failed logins since last successful login. This will probably be last three with notice of more. - Any other current logins. - When logged in and another login occurs you are notified, same format as above. - Commands: - NickServ SET LOGINHISTORY {ON | OFF} - Turns entire feature on or off. - NickServ SET LOGINFAILNOTICE {ON | OFF | DAILY | WEEKLY} - On: immediate/live notices of failed login. - Off: no live notices. - Daily: daily digest of any failed logins. - Weekly: weekly digest of failed logins. - Daily and Weekly plan is to send memo if no current login. Might not happen, but I like the idea. - NickServ LOGINHISTORY [FAIL | SUCCESS] [ALL] - No parameter: last three of each shown. - Type specified: last six unless ALL is specified. - NickServ LOGINLIST - All currently logged in users. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYgc-9xjCWzMEDpkSrSlv2C9TtERufEKks5vBvHBgaJpZM4ZyevS> .