ZNC has lots of nifty features that make it useful as a front-end for Enterprise systems.
Would it be possible to resurrect the passthrough_auth proof of concept?
Under the current system, I would expect:
The administrator would set this to point to a specific IRC Network to use as authentication.
Every user would "automatically" get this Network added.
Optionally the administrator could turn off the ability to add additional networks...
Here's the passthrough_auth.cpp fro the above issue, incase something happens to the source forge copy. Note, I fixed like 35 as mentioned in the comments. I have not tried it.
ZNC has lots of nifty features that make it useful as a front-end for Enterprise systems.
Would it be possible to resurrect the [passthrough_auth](http://sourceforge.net/p/znc/feature-requests/79/) proof of concept?
Under the current system, I would expect:
- The administrator would set this to point to a specific IRC Network to use as authentication.
- Every user would "automatically" get this Network added.
- Optionally the administrator could turn off the ability to add additional networks...
Here's the `passthrough_auth.cpp` fro the above issue, incase something happens to the source forge copy. Note, I fixed like 35 as mentioned in the comments. I have not tried it.
This was authored by [Psychon](http://sourceforge.net/u/psychon/profile/)
```
/*
* Copyright (C) 2004-2010 See the AUTHORS file for details.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published
* by the Free Software Foundation.
*/
#include "Modules.h"
#include "Chan.h"
#include "User.h"
#include "Server.h"
#include "znc.h"
#define PASS "__PASS_THROUGH__"
class CPassthroughMod : public CGlobalModule {
public:
GLOBALMODCONSTRUCTOR(CPassthroughMod) {}
virtual EModRet OnIRCConnecting(CIRCSock *pIRCSock) {
CServer* pServer = m_pUser->GetCurrentServer();
if (pServer->GetPass() != PASS)
return CONTINUE;
if (m_mPasswords.find(m_pUser) != m_mPasswords.end())
return CONTINUE;
PutModule("Trying to connect to IRC, but no password saved :(");
return HALT;
}
virtual EModRet OnIRCRegistration(CString& sPass, CString& sNick, CString& sIdent, CString& sRealName) {
CServer* pServer = m_pUser->GetCurrentServer();
if (!pServer || pServer->GetPass() != PASS)
return CONTINUE;
passwordMap::iterator it = m_mPasswords.find(m_pUser);
if (it == m_mPasswords.end())
return HALT;
sPass = it->second;
return CONTINUE;
}
virtual void OnIRCConnected() {
NukePass(m_pUser);
}
virtual EModRet OnLoginAttempt(CSmartPtr<CAuthBase> Auth) {
CUser* pUser = CZNC::Get().FindUser(Auth->GetUsername());
if (!pUser)
return CONTINUE;
CServer* pServer = pUser->GetCurrentServer();
if (pServer->GetPass() != PASS)
return CONTINUE;
m_mPasswords[pUser] = Auth->GetPassword();
return CONTINUE;
}
virtual void OnFailedLogin(const CString& sUsername, const CString& sRemoteIP) {
CUser* pUser = CZNC::Get().FindUser(sUsername);
if (!pUser)
return;
NukePass(pUser);
}
virtual EModRet OnDeleteUser(CUser& User) {
NukePass(&User);
return CONTINUE;
}
void NukePass(CUser* pUser) {
passwordMap::iterator it = m_mPasswords.find(pUser);
if (it == m_mPasswords.end())
return;
CString& Str = it->second;
for (unsigned int i = 0; i < Str.length(); i++) {
Str[i] = '\0';
}
m_mPasswords.erase(it);
}
typedef map<CUser*, CString> passwordMap;
passwordMap m_mPasswords;
};
GLOBALMODULEDEFS(CPassthroughMod, "Pass on the user's login password for the IRC login")
```
## <bountysource-plugin>
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/4791059-passthrough-authentication-single-server-znc?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:43926595 -->
Feel free to do what you want with that module. As mentioned on SourceForge, this module is racy, e.g. if two clients connect to the same ZNC user. Also this requires the client to reconnect to ZNC if the ZNC<->IRCd connection dies. Working around that would require znc to store the password in memory permanently. (Oh and things also go wrong if a user changes his password).
What exactly is the use case for this? Obviously this should be a security feature, but against what kind of attackers should it work?
IMO this is way too much of an inconvenience to really be useful and at the same time doesn't really protect much.
Feel free to do what you want with that module. As mentioned on SourceForge, this module is racy, e.g. if two clients connect to the same ZNC user. Also this requires the client to reconnect to ZNC if the ZNC<->IRCd connection dies. Working around that would require znc to store the password in memory permanently. (Oh and things also go wrong if a user changes his password).
What exactly is the use case for this? Obviously this should be a security feature, but against what kind of attackers should it work?
IMO this is way too much of an inconvenience to really be useful and at the same time doesn't really protect much.
<!-- github-comment-id:65376320 -->
My use case is that I'd like to use ZNC in a business/enterprise environment. The choices are:
Re-implement the authentication on the IRC server in ZNC. I'd have to leave authentication on in the IRC server, otherwise someone could pretend to be someone else. This means when users change their password every X-days, they'd have to update ZNC as well as their IRC client.
Implement the authentication on the IRC server in ZNC and turn off authentication in IRC (from ZNC only); I'd have to live with people being able to pretend to be someone else.
Let ZNC somehow use IRC's authentication mechanism (as above).
Somehow have ZNC do authentication and securely pass that identification on to the IRC server so users can't pretend to be someone else.
I'm open to any other suggestions.
Ciao!
That's fair enough.
My use case is that I'd like to use ZNC in a business/enterprise environment. The choices are:
- Re-implement the authentication on the IRC server in ZNC. I'd have to leave authentication on in the IRC server, otherwise someone could pretend to be someone else. This means when users change their password every X-days, they'd have to update ZNC as well as their IRC client.
- Implement the authentication on the IRC server in ZNC and turn off authentication in IRC (from ZNC only); I'd have to live with people being able to pretend to be someone else.
- Let ZNC somehow use IRC's authentication mechanism (as above).
- Somehow have ZNC do authentication and securely pass that identification on to the IRC server so users can't pretend to be someone else.
I'm open to any other suggestions.
Ciao!
<!-- github-comment-id:65412431 -->
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.
ZNC has lots of nifty features that make it useful as a front-end for Enterprise systems.
Would it be possible to resurrect the passthrough_auth proof of concept?
Under the current system, I would expect:
Here's the
passthrough_auth.cppfro the above issue, incase something happens to the source forge copy. Note, I fixed like 35 as mentioned in the comments. I have not tried it.This was authored by Psychon
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Feel free to do what you want with that module. As mentioned on SourceForge, this module is racy, e.g. if two clients connect to the same ZNC user. Also this requires the client to reconnect to ZNC if the ZNC<->IRCd connection dies. Working around that would require znc to store the password in memory permanently. (Oh and things also go wrong if a user changes his password).
What exactly is the use case for this? Obviously this should be a security feature, but against what kind of attackers should it work?
IMO this is way too much of an inconvenience to really be useful and at the same time doesn't really protect much.
That's fair enough.
My use case is that I'd like to use ZNC in a business/enterprise environment. The choices are:
I'm open to any other suggestions.
Ciao!