|
|
| Author |
Message |
katsklaw Guru

Joined: 28 Jun 2004 Posts: 1048
|
Posted: Dec 19, 2006 10:17am Post subject: |
|
|
Jiles, ircu most certainly DOES protect nicknames from being used:
| Code: |
# As of ircu2.10.05 is it possible to Jupe nicks. As per CFV-0095 and
# CFV-0255, the following nicks must be juped, it is not allowed to
# jupe others as well.
Jupe {
nick = "A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,{,|,},~,-,_,`";
nick = "EuWorld,UWorld,UWorld2";
nick = "login,undernet,protocol,pass,newpass,org";
nick = "StatServ,NoteServ";
nick = "ChanSvr,ChanSaver,ChanServ";
nick = "NickSvr,NickSaver,NickServ";
nick = "LPT1,LPT2,COM1,COM2,COM3,COM4,AUX";
};
|
From Undernet:
| Code: |
.::11.18::. -> Server: NICK A
-
A Nickname is already in use.
-
.::11.18::. -> Server: WHOIS A
-
A No such nick
-
.::11.18::. End of /WHOIS A
|
Just because 1 or 2 ircds do not offer such protection doen't mean that they are incapable of doing so. I most certainly said "ircd's are perfectly capable ". I did NOT say all of them do. There is a difference.
This thread has gone WAY off course, so I'm done here. |
|
| Back to top |
|
 |
SyntaxIRC none

Joined: 07 Dec 2006 Posts: 27
|
Posted: Dec 19, 2006 3:53pm Post subject: |
|
|
| Take this to discussions! |
|
| Back to top |
|
 |
]Daniel Idler

Joined: 05 Jan 2006 Posts: 316 Location: Boise, ID
|
Posted: Dec 20, 2006 12:59pm Post subject: |
|
|
First of all, IF your network uses an ircd that does not support juping nicknames, I highly suggest you upgrade or choose another ircd. Im sure the ircnet ircd may not support it but then again they dont even use services AT ALL. If you plan on using services, use an ircd that supports it. If not, use whatever you want. There is no reason or excuse for an irc admin, net admin, server admin, ircop, whatever position you are to change your nickname to the services names. Doing that still compromises the privacy and safety of your users. People may use their password in other places, and quite honestly, I personally would care if it who the person was, Id be very upset if someone made me accidently give my password out.
There is no excuse to any of those actions. Im sorry to hear about your response. |
|
| Back to top |
|
 |
PingBad Guru

Joined: 05 Feb 2005 Posts: 1993 Location: New Zealand
|
Posted: Dec 20, 2006 5:29pm Post subject: |
|
|
To a point, I'm going to agree with daniel... No user (oper or otherwise) should use any services name. Most IRCds support Q:Lines - if your choice of IRCd doesn't, then maybe its time to upgrade/switch unless you're not into running services.
Why shouldn't anyone use a services name when services are down? Security of privacy. Some scripts automatically message NickServ with "IDENTIFY <password>" upon connect, while others wait for the NickServ challenge. Its also very common (albeit highly discouraged) for people to use a password many times in many areas (or variations thereof). So it'll really compromise user security for anyone to use a services nick while services are down |
|
| Back to top |
|
 |
mentor Newbie

Joined: 22 Jun 2004 Posts: 66 Location: San Diego, CA
|
Posted: Dec 20, 2006 9:50pm Post subject: |
|
|
| ]Daniel wrote: | First of all, IF your network uses an ircd that does not support juping nicknames, I highly suggest you upgrade or choose another ircd. Im sure the ircnet ircd may not support it but then again they dont even use services AT ALL. If you plan on using services, use an ircd that supports it. If not, use whatever you want. There is no reason or excuse for an irc admin, net admin, server admin, ircop, whatever position you are to change your nickname to the services names. Doing that still compromises the privacy and safety of your users. People may use their password in other places, and quite honestly, I personally would care if it who the person was, Id be very upset if someone made me accidently give my password out.
There is no excuse to any of those actions. Im sorry to hear about your response. |
I agree, there really isn't a reason to use Services' actual nicknames.
However, In practice, on the net I'm with, we routinely switch to the nicknames of Services impersonators, once we have dealt with the actual impersonator. This is done for the very reasons you listed above, as there are those who will message them with their passwords, even if the nicknames don't resemble the actual Services nick (i.e. swiftcopassmanager). It can be an educational experience -- letting the user know what they have just done, and advising them to switch their password.
Now, I'm not even sure what the original topic was about anymore  |
|
| Back to top |
|
 |
]Daniel Idler

Joined: 05 Jan 2006 Posts: 316 Location: Boise, ID
|
Posted: Dec 21, 2006 10:40am Post subject: |
|
|
| That still doesnt justify anything. You are suppost to KILL the services impersonators, not join them. This topic is about a guy trying to get oper status somewhere, which I highly do not recommend taking his responses to these questions. I had an oper a long time ago on my older network actually kill nickserv, and then try to take the nickname, gotta love nick collision. Not the best way to run a network. |
|
| Back to top |
|
 |
mentor Newbie

Joined: 22 Jun 2004 Posts: 66 Location: San Diego, CA
|
Posted: Dec 21, 2006 2:36pm Post subject: |
|
|
| ]Daniel wrote: | | That still doesnt justify anything. You are suppost to KILL the services impersonators, not join them. This topic is about a guy trying to get oper status somewhere, which I highly do not recommend taking his responses to these questions. I had an oper a long time ago on my older network actually kill nickserv, and then try to take the nickname, gotta love nick collision. Not the best way to run a network. |
They are killed. In fact, we autokill them. However, there is no telling how many users the impersonator had tried to trick into giving out their nickname / channel passwords; therefore, we usually switch to the nickname the impersonator was using. Should a user actually message us their password, we let them know what they have done, and advise them to change their password. Since this is usually only done by a CSOp, it's not a huge issue, as we could gain the password by much easier means if we actually wanted to.
It really boils down to the policies and practices of your network. For example, it was mentioned earlier what would "you" do if Services went offline and you are the only active oper? Well, on one of the networks I oper on, we don't op individuals period. They must wait until Services return. However, judging from some posts, this is not the case everywhere else.
I, personally, wouldn't look for opers on here to begin with. If an individual truly wants to help your network out they'll check you out and try and get involved in other ways, and eventually you might even decide to grant them an O:line. From past experience, I've found the best candidates for an O:line are usually those who have been with the network for sometime. But, then again, I may just be old fashioned. |
|
| Back to top |
|
 |
]Daniel Idler

Joined: 05 Jan 2006 Posts: 316 Location: Boise, ID
|
Posted: Dec 21, 2006 3:14pm Post subject: |
|
|
| I personally still do not agree on that. Dont make them have to change their password. Your still not seeing the professional views and security of your users on this. The fact that you do that is compromising the security and safety of your users private information. Hell I dont even support the getpass command in some services packages. There is no reason an admin should ever need to get the password for someone else. Think of websites, other chats, their admins will never ask or try to get your passwords, make it the same policy. If another person gets their information, that is their fault, they must deal with it. But dont participate in that. Deal with the impersonater but dont become one yourself. |
|
| Back to top |
|
 |
mentor Newbie

Joined: 22 Jun 2004 Posts: 66 Location: San Diego, CA
|
Posted: Dec 21, 2006 4:36pm Post subject: |
|
|
| ]Daniel wrote: | | I personally still do not agree on that. Dont make them have to change their password. Your still not seeing the professional views and security of your users on this. The fact that you do that is compromising the security and safety of your users private information. Hell I dont even support the getpass command in some services packages. There is no reason an admin should ever need to get the password for someone else. Think of websites, other chats, their admins will never ask or try to get your passwords, make it the same policy. If another person gets their information, that is their fault, they must deal with it. But dont participate in that. Deal with the impersonater but dont become one yourself. |
We are not becoming the impersonators, as that would imply we have the intent of performing malicious acts with the password they have given us. This is not the case. Now, GETPASS has its uses in some situations, but I prefer to use other methods available to me, which do not require me to see the password at all.
The only real security risk is if the user has been using the same password for several different sites and services. If this is the case, I would rather be made aware of what I've done, and given the chance to correct my mistake. Imagine should the impersonator actually got that password, the consequences could have been far greater, given them access to, for example, their e-mail account, etc. So, just maybe the user sends the password after the impersonator has been removed, but have they learned from the experience? Most likely not, and will message their password once another one pops up. By at least taking the steps to educate our users, we can put a small dent in this viscious cycle. |
|
| Back to top |
|
 |
SyntaxIRC none

Joined: 07 Dec 2006 Posts: 27
|
Posted: Dec 21, 2006 4:54pm Post subject: |
|
|
| This has gone waaay off topic. Please close this thread -.- |
|
| Back to top |
|
 |
PingBad Guru

Joined: 05 Feb 2005 Posts: 1993 Location: New Zealand
|
Posted: Dec 21, 2006 5:26pm Post subject: |
|
|
| mentor wrote: | | For example, it was mentioned earlier what would "you" do if Services went offline and you are the only active oper? Well, on one of the networks I oper on, we don't op individuals period. They must wait until Services return. | So if I did nothing other than advise that services is down, and waited 6 hours for an admin to come along and get services back online... that would be better than spending those 6 hours defending the network users' channels? | Quote: | | The only real security risk is if the user has been using the same password for several different sites and services. If this is the case, I would rather be made aware of what I've done, and given the chance to correct my mistake. Imagine should the impersonator actually got that password, the consequences could have been far greater, given them access to, for example, their e-mail account, etc. So, just maybe the user sends the password after the impersonator has been removed, but have they learned from the experience? Most likely not, and will message their password once another one pops up. By at least taking the steps to educate our users, we can put a small dent in this viscious cycle. | I'll concede that yes there are some users who use the one password (or multiple variants) for various sites and services. I, for example, had never encountered services with "accounts" (ie: /NickServ REGISTER account password email) until I came to ]Daniel's network and accidentally used /NickServ REGISTER password email, combined with his <account>.users.<network>.<tld> vhosting policy... I instantly had my password visible to all, the same password I'd used here. If I hadn't said anything I could have avoided this account being taken over, but the fact that I'd said "crap!" in the network's official channel... well that was a 3 month struggle to reclaim this account (since whoever had taken over my account had changed the email to a yahoo address I don't even use - I have one Yahoo! account, and its strictly used for their Y! Messenger only when absolutely necessary). So yeah, lesson learnt. I now have 5 passwords: one for my online gaming accounts, one for my online banking, one for my staff nicks on a network, one for all my user nicks (where i'm not staff), and one for services such as SearchIRC. |
|
| Back to top |
|
 |
mentor Newbie

Joined: 22 Jun 2004 Posts: 66 Location: San Diego, CA
|
Posted: Dec 22, 2006 6:19am Post subject: |
|
|
| PingBad wrote: | | So if I did nothing other than advise that services is down, and waited 6 hours for an admin to come along and get services back online... that would be better than spending those 6 hours defending the network users' channels? |
I didn't say either was right or wrong. I was merely illustrating that it is entirely subjective on what the network's policies and practices are. Obviously, it is not practical to try and verify ops for 20,000+ channels; therefore, we don't op individuals, and tend to take care of the troublesome users ourselves - as they are usually violating network policy.
A lot of opering is common sense however, and the same from net to net, but then there are issues you would deal with differently depending on the net you happen be on - according to their specific policies. |
|
| Back to top |
|
 |
]Daniel Idler

Joined: 05 Jan 2006 Posts: 316 Location: Boise, ID
|
Posted: Dec 22, 2006 9:28am Post subject: |
|
|
| When did you do that and when was this struggle? I dont recall any of that. You couldnt of submitted that command on my network cause you would be missing a variable. Cause mine is requires /nickserv register account password email |
|
| Back to top |
|
 |
PingBad Guru

Joined: 05 Feb 2005 Posts: 1993 Location: New Zealand
|
Posted: Dec 22, 2006 4:04pm Post subject: |
|
|
| Happened january '06, and it was a 3-month process (not sure on the exact length of time) where I had to prove I was the account holder here |
|
| Back to top |
|
 |
]Daniel Idler

Joined: 05 Jan 2006 Posts: 316 Location: Boise, ID
|
Posted: Dec 28, 2006 3:50pm Post subject: |
|
|
I do not recall that, and my memory is sharp as a tac. for the most part that is. Although Ill discuss this more on msn with you
I will repeat this one more time...
I don't care what you think your doing is right, you are nothing but another person. On MSN they dont sit there and try to get users passwords and then tell them what they have done. Niether should you, be professional as you can be, protect the users, dont impersonate. Either way, if users keep trying to impersonate services, add nick jupes for those nicknames as well. There is NEVER EVER EVER a valid excuse for an administrator to try and get another users password, even if they think it is a good cause, it is NEVER good. You put the security and safety of your users at risk, thinking its for the good of their interest. You dont know their interests. Quite frankly, I do not, will not, never will believe in what your doing is right. All your doing is becoming a services impersonater yourself, wiether you like it or not. Try maybe when services go down set off a timed global every 30 minutes(yes for the newbs, you can do this without services. /notice $*.domain.tld notice, or with $$*.domain.tld on most flavors of hybrid and hybrid based ircd's) stating that services are down, please do not try to identify, or anyone using a nickserv like nickname could be trying to impersonate, thats still better than giving out their password. Telling them what they did? What do you tell them "You just got conned into giving your password to someone you don't know"? Either way I cant emphasize this anymore, DO NOT EVER IMPERSONATE YOUR OWN NETWORK SERVICES AS THIS IS A SAFETY AND SECURITY RISK.
that is all... |
|
| Back to top |
|
 |
|
|
| |