SCRAM-SHA-256 seems to be a SASL mechanism that IRCv3 thinks should be implemented.
- https://tools.ietf.org/html/rfc7677
- via http://ircv3.net/docs/sasl-mechs.html via https://github.com/ircv3/ircv3.github.io/pull/48
## <bountysource-plugin>
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29203721-sasl-scram-sha-256?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).
</bountysource-plugin>
<!-- github-sync-id:122711988 -->
Lets also mention here that no one supports it yet, but Anope will soon™. https://github.com/ircv3/ircv3.github.io/issues/49#issuecomment-165423742
<!-- github-comment-id:165431085 -->
IIRC, the only thing SCRAM-SHA-256-PLUS does is specify a larger minimum number of iterations in the PBKDF2 password hash function. So it is utterly trivial to implement once you have SCRAM-SHA-256 implemented.
IIRC, the only thing SCRAM-SHA-256-PLUS does is specify a larger minimum number of iterations in the PBKDF2 password hash function. So it is utterly trivial to implement once you have SCRAM-SHA-256 implemented.
<!-- github-comment-id:345166031 -->
Ok, n/m, I was completely wrong. I am reading up on SCRAM at the moment because I need some deeper knowledge of it to inform some preliminary choices in a side project of mine.
It would seem this is a bit of a chicken-and-egg problem. Without major networks/ircds support for scram, there isn't much motivation to update the clients, and vice-versa.
I might be interested in taking a crack at this issue at some point, but I don't know when that might be.
Ok, n/m, I was completely wrong. I am reading up on SCRAM at the moment because I need some deeper knowledge of it to inform some preliminary choices in a side project of mine.
It would seem this is a bit of a chicken-and-egg problem. Without major networks/ircds support for scram, there isn't much motivation to update the clients, and vice-versa.
I might be interested in taking a crack at this issue at some point, but I don't know when that might be.
<!-- github-comment-id:345172101 -->
It would seem this is a bit of a chicken-and-egg problem
As ZNC is a bouncer, it's not affected that much, because it can connect to itself! :)
I might be interested
Cool! Please coordinate with @MrLenin who had some ideas about SASL
PLUS is about channel bindings, and let's not do them yet, until https://www.ietf.org/mail-archive/web/tls/current/msg18263.html is resolved.
> It would seem this is a bit of a chicken-and-egg problem
As ZNC is a bouncer, it's not affected that much, because it can connect to itself! :)
> I might be interested
Cool! Please coordinate with @MrLenin who had some ideas about SASL
<!-- github-comment-id:345276730 -->
I have coded a module that uses gsasl: https://github.com/ircnet-com/misc/tree/master/znc-modules/gsasl
Anyway a native solution would be better.
Patrick
<!-- github-comment-id:886193513 -->
Great! I haven't looked into details, but why did you remove EXTERNAL?
Anyway a native solution would be better.
I don't mind gsasl being added as an optional dependency.
> I have coded a module that uses gsasl
Great! I haven't looked into details, but why did you remove EXTERNAL?
> Anyway a native solution would be better.
I don't mind gsasl being added as an optional dependency.
<!-- github-comment-id:886257016 -->
Because this module was coded to test a SASL Service on IRCnet and (unluckily) our ircd does not/will not support things like CertFP. Feel free to modify it.
Because this module was coded to test a SASL Service on IRCnet and (unluckily) our ircd does not/will not support things like CertFP. Feel free to modify it.
<!-- github-comment-id:886260672 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
SCRAM-SHA-256 seems to be a SASL mechanism that IRCv3 thinks should be implemented.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Lets also mention here that no one supports it yet, but Anope will soon™. https://github.com/ircv3/ircv3.github.io/issues/49#issuecomment-165423742
@timofonic I would ask ircs://irc.freenode.net:6697/#ircv3, I haven't been following IRCv3 recently so much.
IIRC, the only thing SCRAM-SHA-256-PLUS does is specify a larger minimum number of iterations in the PBKDF2 password hash function. So it is utterly trivial to implement once you have SCRAM-SHA-256 implemented.
Ok, n/m, I was completely wrong. I am reading up on SCRAM at the moment because I need some deeper knowledge of it to inform some preliminary choices in a side project of mine.
It would seem this is a bit of a chicken-and-egg problem. Without major networks/ircds support for scram, there isn't much motivation to update the clients, and vice-versa.
I might be interested in taking a crack at this issue at some point, but I don't know when that might be.
PLUS is about channel bindings, and let's not do them yet, until https://www.ietf.org/mail-archive/web/tls/current/msg18263.html is resolved.
As ZNC is a bouncer, it's not affected that much, because it can connect to itself! :)
Cool! Please coordinate with @MrLenin who had some ideas about SASL
I have coded a module that uses gsasl: https://github.com/ircnet-com/misc/tree/master/znc-modules/gsasl
Anyway a native solution would be better.
Patrick
Great! I haven't looked into details, but why did you remove EXTERNAL?
I don't mind gsasl being added as an optional dependency.
Because this module was coded to test a SASL Service on IRCnet and (unluckily) our ircd does not/will not support things like CertFP. Feel free to modify it.
Linked to: