Feature #784
NICKSERV identification.
| Status: | Closed | Start: | 11/28/2012 | |
| Priority: | Normal | Due date: | 02/20/2013 | |
| Assigned to: |  Mirco Bauer |
% Done: | 100% |
|
| Category: | Engine IRC | |||
| Target version: | 1.0 | |||
| Complexity: | Medium |
|||
| Votes: | 4 (View) |
Description
Hi,
I have noticed that some IRC servers will disconnect their services, meaning NICKSERV, sometimes and when that particular service get back on line it will request a password from me. If I do not provide it, it will in some cases change my nickname (I think,) but in all cases it will not let me (1) change nickname in channels where registered nicknames are required, (2) join channels where registered nicknames are required, (3) probably more. People will not be able to verify for sure if I am who I say I am, while I am away from the computer, and thus cannot securely send messages to me (as secure as can be under the circumstance.)
So let me describe the feature:
1pm: I join (connect) and identify with nickserv, by typing /msg nickserv identify mypassword.
2pm: Netsplit on the IRC network, nickserv is gone from my part of the network.
3pm: Netsplit is resolved, network is complete. Nickserv is back and requests or wants me to identify like I did at 1pm.
This could be interpreted in multiple ways and surely resolved or implemented in multiple ways. Events, an event system, might be used in all cases. The user could be let to handle it on their own, if there was a way to catch this event, nickserv requesting a password via a message from nickserv, or there could be an option and settings in preferences for what password I have with nickserv on various networks. Of course this mechanism would only identify with /nickserv identify mypassword for security reasons, although nickserv is probably a reserved nickname on all implementations of ircd.
Okay, I might have become to specific on implementation. Do whatever you like. I think the problem is most important to resolve. It would be feature to have this. Thanks for reading.
//Gustav
Associated revisions
Revision faa15eebf9c00be65b81e6974977bab81ae8fe8c
Engine-IRC: added NickServ authentication support (closes: #784)
Here the discussion on #ircv3 how an IRC client can rely on NickServ auth
without knowing in advance if NickServ is available or not. A simple "PRIVMSG
NickServ" can lead to information leak as some user could try to use that nick
on networks without NickServ or try to overtake that nick if the official
NickServ goes "down" and is not protected by the IRC network during that
downtime.
So the idea is to use a server-alias for NickServ called NS, if the server does
not support that, it will simply ignore it as unknown command and no harm is
done. If it does support the server-alias then the NickServ authentication will
work without relying on PRIVMSG or any other heuristic probing of services.
[2015-03-16 21:28:49] <meebey> is there a way to detect if an IRCd supports NickServ? before you well SASL to me, not all networks support SASL
[2015-03-16 21:29:22] <meebey> so far Smuxi rejects the idea of NickServ auth because it puts the user in danger, one can try to impersonate NickServ
[2015-03-16 21:29:52] <meebey> yes SASL and CertFP is the solution, but see above not all networks have SASL and/or CertFP
[2015-03-16 21:30:33] <b_jonas> meebey: isn't it enough if you just who nickserv to see if it has a service hostname?
[2015-03-16 21:30:48] <meebey> b_jonas: how do I detect a service-hostname?
[2015-03-16 21:30:51] <b_jonas> meebey: that won't work if services isn't currently online
[2015-03-16 21:31:11] <Aerdan> there is no one-size-fits-all way to do this.
...
[2015-03-16 21:36:18] <meebey> b_jonas: so your point is that PRIVMSG NickServ can/should be considered safe? not sure if I agree
[2015-03-16 21:36:32] <meebey> if you say all networks have banned it
[2015-03-16 21:36:43] <b_jonas> meebey: no
[2015-03-16 21:36:48] <meebey> because it is all about that assumption
[2015-03-16 21:36:51] <b_jonas> meebey: I'm saying that the NICKSERV command should be safe
[2015-03-16 21:36:54] <b_jonas> not PRIVMSG
...
[2015-03-16 21:37:09] <jwheare> it's safe enough
[2015-03-16 21:37:27] <jwheare> /ns is actually more widely deployed as an alias
...
[2015-03-16 21:37:39] <b_jonas> but if they don't have nickserv, then they probably won't have a NICKSERV command set up
[2015-03-16 21:37:39] <jwheare> if they're not present no big deal
[2015-03-16 21:37:44] <jwheare> they won't be pming anyone
...
[2015-03-16 21:38:10] <jwheare> if the network maps it to a nick called nickserv without services and without banning the nickserv nick, then um, that network is never going to be secure
[2015-03-16 21:38:13] <jwheare> so don't even try
[2015-03-16 21:38:21] <jwheare> just use /ns and be happy
[2015-03-16 21:42:44] <meebey> jwheare: I think NS is a good idea
[2015-03-16 21:42:50] <meebey> jwheare: thanks
History
Updated by Mirco Bauer 4376 days ago
- Target version set to 0.8.11
- Complexity set to Medium
I agree, Smuxi should provide NickServ authentication support as it's a very common feature used on most major IRC networks. Right now users need to add "/msg NickServ foo bar" to on-connect commands but that does not cover the case you described. No promise, but I will look into adding this feature to the next release (0.8.11).
Updated by Mirco Bauer 3499 days ago
Smuxi can rely on the NS server alias for auth, it should not put the user into danger. This was deeply discussed on #ircv3.
Updated by Mirco Bauer 3471 days ago
- Status changed from New to Assigned
- Estimated time deleted (
20.00)
Updated by Mirco Bauer 3471 days ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
Applied in changeset faa15eebf9c00be65b81e6974977bab81ae8fe8c.