1 · Why you need to know this information
DALnet encourages you to read this guide because:
If NickServ always asks you for your password and you get fed up with this, you CAN fix it, and this explains how.
If this isn't the case, it's entirely possible that some others who really wanted to could use your nickname. Even if you're not paranoid about other people "pretending to be you", consider that they could get you in trouble by misbehaving in some way with your nickname.
If your access mask is "too wide" and allows other users access, this could give them access to your rights on channels which you are AOP, SOP, or founder on.
A summary can be found in section 10, which briefly explains how to get a "correct" access list in most cases.
2 · What nickname access lists are
A nickname access list is a list of addresses from which you are recognised as the authorised user of a nickname, without needing to manually send a password. These can be exact addresses or "masks" that match a range of addresses.
There are several ways in which a user may be allowed to use a registered nickname.
In order to explain these, here's a summary of what happens when you log on, or change to nickname.
-
NickServ checks if the nick is registered. If not, then it takes no further action (i.e. you can use the nick).
-
NickServ checks if you have a username and hostname that matches one of those stored in the access list for that nick. (The username and hostname is the "something@somewhere.com" part of the information you get by typing /whois.) If there is such a match, then you are considered a valid user of the nickname, and NickServ takes no further action.
-
NickServ sends a warning explaining that if this is your nick, you should use the /nickserv identify password command. At this point, you do not have access to memos, channels, AOP rights, etc.
-
The Enforce Option is now set by default after the nickname complete registration. If nickname enforce is set on, NickServ changes your nick to a guest nick 60 seconds later, unless password identification is sent (see below). If nickname enforce is off, you are allowed to keep using the nick, with the same restrictions on access just explained. (For information about setting ENFORCE on for your nicks, see the Services FAQ question 1.3 "How do I stop others from using my registered nickname?")
-
If you type the /nickserv identify password command you get full rights to the nick as soon as it is accepted.
That was a little bit complicated, so here's another brief look at it from a slightly different perspective; a person may be using a registered nickname if:
-
Their address [username and hostname] matches one in the access list.
-
They sent the manual /nickserv identify password command.
-
Enforce is set off for the nick
-
Enforce is set on [in this case they can use it only for 60 seconds]
(Only in cases 1 and 2 is the person seen as the "valid owner" of the nickname, with access to memos, to view nickname settings, and to any channel privileges there might be for that nickname. Changing nickname settings always requires password identification, case 2.)
You can see by this that the "access list" is used for convenience, so that as long as you continue to use the same Internet service provider you won't normally need to type in the password each time you use your nickname.
3 · How do a username and hostname get added to your access list?
There are two ways in which this could happen:
-
You add it yourself by using the comand /nickserv access add mask (see below)
-
When you register your nick, the address you're using at that moment is automatically added to your access list (you may want to remove it; read on)
4 · How to change your nickname access list
Here are the commands for manipulating your access list. Before you use any of them, you should change to the appropriate nickname. You will also need to identify for the nick (/nickserv identify password) before you can do the ADD or DEL commands.
After you type any of these commands, NickServ will respond to show you the results or confirm that your command worked.
If there is no response, NickServ is probably lagged, so please be patient. If there is a message like nickserv - no such nick/channel or Services is currently down. Please wait a few moments, and then try again. then NickServ is probably not working at the moment; try again later.
/nickserv access list
Typing this command will show you the current access list
/nickserv access add mask
Typing this command - replacing the word "mask" with an actual mask - will add an "address mask" (see later) to the list so that people matching that mask will be able to use the nickname without identifying.
/nickserv access del mask
If an "address mask" is inappropriate, insecure, or no longer required, you can remove it from the list using this command.
5 · The pros and cons of having address masks in your access list
There are security advantages to clearing the access list, which means that you must always give NickServ the password so as to use the nick. Therefore, if the security of your nick is more important to you than convenience, this is the action you should take.
Note that even if somebody else does manage to use your nickname due to the access list, they still can't access any of the critical commands such as dropping the registration or changing the password. All of those require you to identify with the password first.
However, if someone gets access in this way they will be able to read your memos and send memos using your name, as well as gaining access to any rights you may have on channels (AOPs, SOPs, etc). They can also register channels in your name.
If you decide your nickname needs to be secure, the rest of this section explains how to clear your access list. Otherwise, you should skip to the next section. All the other sections from now on assume you *are* going to use the access list.
To clear your access mask list, do the following:
-
Type /nickserv identify password (where "password" is the password for your nick)
-
Type /nickserv access wipe
Once you have cleared your access list, you are going to need to identify with NickServ each time you log on to DALnet. To do this, you type:
/nickserv identify password
Do not create auto-identify scripts. It is easy to accidentally log onto another network, and forget that you had the auto-identify script on. On the other network, there may well be a user calling themselves NickServ specifically to steal passwords. Depending on your script, your password may go to them. Another problem is you may share your script with friends and forget to edit out the password. This is a real danger and has happened to dozens of DALnet users.
If you've cleared your access list, there's not much point reading the rest of this document, as it assumes you decided to use the access list.
6 · Hostnames and usernames explained
In choosing a mask for yourself, the first thing to do is, while online, to run a /whois on yourself, and look at the results. You should see something like:
YourNick is ~user@009-443.provider.com * Your Silly Message
[etc]
or perhaps like:
*** YourNick is ~user@009-443.provider.com (Your Silly Message)
The important part is the ~user@009-443.provider.com part, which you should be able to see whatever format your IRC program uses. We'll take a closer look at the various parts of this.
Before we start: if your result looks like ~user@124.45.230.123 - i.e. four numbers and no words in the "hostname" part - please see section 8 in this guide.
6.1 The username
The username part of the above address is "~user". In fact, this itself divides into two parts - the "~" which indicates you don't have an ident server, and the "user" which is the actual username.
Unless you're using a Unix or VMS computer system such as some university systems, or you use one of a few particular service providers, it's likely that you can change your username to anything you like. [Note: mIRC calls the username 'email address'.]
In the example I gave, the person hasn't changed their username from the default of the program they use, which happens to be "user". This is very common, but is not a particularly sensible idea. You should pick some other username so that not everybody has the same one.
(When picking a username, you should probably choose your username or account name at your ISP, unless you want to keep your email address secret from other users. If you choose something different for that reason, make sure it is a single word using only letters and numbers; using other symbols could cause problems.)
If at this point you change your username, you'll need to disconnect from IRC and reconnect. (It's usually best to quit your IRC program and then reload.) Then do the /whois again.
You need to know your "username" to choose a correct mask.
6.2 The hostname
The above user's hostname is "009-443.provider.com". This indicates that they are using the Internet service provider "provider.com" (which I made up), and that they are currently using the machine or phoneline at that provider which is number 009-443.
This hostname is what's known as a dynamic hostname. Dynamic hostnames include a number or similar code at the start, which is different each time you dial the provider to start an Internet session.
Some hostnames (for instance at a company or institution) may be static - that is, each time you start an Internet session, you'll have exactly the same hostname. You can find out which you are by trial and error, but a general rule of thumb is that if your internet access comes by dialing up on an ordinary domestic phone line, you probably have a dynamic hostname. Dynamic hostnames always have a number or odd code at the start; static hostnames normally are just words, but might include numbers also.
Here are some examples of static hostnames:
spelt-lib.demon.co.uk
altair.dur.ac.uk
quilt.usn.blaze.net.au
puree.ugcs.caltech.edu
And here are some dynamic hostnames:
ppp96.sagelink.net
one-pm30.norwich.net
ip022.phx.primenet.com
pc38.bgmoess-klu.ac.at
Just to confuse, static hostnames can have numbers in them (e.g cm001-13.dur.ac.uk) - if in doubt, though, and it has a number, assume it's dynamic.
You need to know which type of hostname you have before you can choose a correct address mask.
7 · Address masks explained
First, a quick note about what address masks do not include. They do not include the nickname portion *! that you might have seen in channel ban masks. They also must not include the ~ at the start of the username, which might be displayed in the /whois output. If you include either of these two things, it's likely that the mask will never work.
Address masks can be of two forms.
7.1 Exact
For instance, an address mask could be:
peter@orion.dur.ac.uk
This mask would only allow people using the exact computer or phoneline "orion.dur.ac.uk", and whose username ("email" in mIRC) was set to "peter", to use the nickname without identifying.
7.2 Wildcards
Wildcards are the * symbols you might see in address masks. A * symbol "matches" any number of characters (letters or numbers), even none at all.
For example:
- "for*"
-
would match "forest", "fortune", "for" - anything beginning with the three letters "for".
- "*st"
-
would match "forest", "best", "Bucharest" - anything ending with the two letters "st".
- "f*st"
-
would match "forest", "frost", "fst", "fast" - anything beginning with "f" that also ends in "st".
- "f*s*t"
-
would match "forest", "foresight", "frost" - anything that begins with "f", ends with "t", and has an "s" somewhere in the middle.
If you don't fully understand that, don't worry; such complex wildcards aren't usually needed to specify access masks.
A typical access mask with a wildcard might be:
CuteElf@*.netcom.com
This allows anybody whose username is set to CuteElf, and whose hostname ends in ".netcom.com", to access the nickname. (Since every Netcom user's address ends in ".netcom.com", this is not a very secure access mask.)
7.3 How to choose a correct mask for yourself
So, you know your username and hostname, and whether the address is static or dynamic. What now?
If your hostname is numeric - a set of 4 numbers, instead of "words" - you should now look at section 8, which explains how to deal with this situation - these hostnames work differently from the normal type.
7.4 If you have a static address
The correct access mask for you in this case is:
username@hostname
For instance, in the unlikely event that the example I gave was a static address, the correct access mask would be:
user@009-443.provider.com
7.5 If you have a dynamic address
Things are slightly more complicated here. You basically need to replace the part of the hostname that changes each time with a *:
username@*.part-of-hostname-that-doesn't-change
For instance, a good mask for the above example would be:
user@*.provider.com
If the 009 was always the same every time that user dialed up, and only the 443 changed, then an even better mask would be:
user@009-*.provider.com
8 · Numeric hostnames
Sometimes the hostname part of your address may appear not as a name:
username@A56.myprovider.com
but as a set of 4 numbers:
username@154.43.68.56
The set of numbers - also known as an IP address - is actually the "real" host address. The name you see normally is simply an easier-to-read way of giving the number.
The reason why your hostname sometimes comes up as a number is usually lag between your service provider and the IRC server you're connecting to. In this case, the IRC server may not get a response to the "name lookup" within a reasonable time, so it falls back on using the number.
Assuming you normally get a name, if your hostname ends up being a number one time, the easiest solution is probably just to change server, or even reconnect to the same server. If you are using a server that's geographically near to you, it is unlikely that the "number" thing will happen often. You shouldn't add an IP address to your access list just because one time your hostname appeared as numbers.
If your hostname always or often comes up as numbers, you might want to add it to your access list. Numeric hostnames are simple to deal with in the context of an access mask.
As with standard "name" type hostnames, you need to determine whether your hostname is dynamic or static; if you already know that from the format of the "name" type hostname, then it will be the same for the numeric hostname. If you have a numeric hostname and don't know which type it is, the only sure way to check is to log in to your Internet provider several times and see if the last number (of the set of four) changes. You can assume that a dialup account will almost certainly have a dynamic hostname.
If you have a dynamic hostname, you need to:
/nickserv access add username@154.43.68.*
where the username and the first three numbers are the ones from your /whois, and the * replaces the last number.
If your address is static, simply include all four numbers instead of replacing the last one with a *. In my example, that would be:
/nickserv access add username@154.43.68.56
9 · Things to remember and security advice
- If you want your nickname to be as secure as possible
-
Delete all the addresses from the access mask, and use the
/nickserv identify password
command every time you log on to DALnet. (See section 5 of this guide.)
- If you have a static address
-
If you're one of the lucky few with a static address, you should have an access list consisting of your username@hostname and nothing else. The mask in the list shouldn't have any wildcards (* symbols) since your address is always exactly the same.
Delete any other masks that might be in the list.
Because your address is static, nobody else could have a matching address, so this is quite secure; it's unlikely others will be able to abuse your nickname.
- If you have a dynamic address
-
Most of us are stuck with dynamic addressess, unfortunately. The basic principle is to have only one mask in the list, which will "allow in" as few people as possible. Delete any other masks.
The mask should include your username, and as much of the hostname as possible (all of it that doesn't change). For instance, while I was using Netcom, my default mask that NickServ assigned me allowed anybody at Netcom to use my nickname. (Provided they changed their username to the one I was using at the time.) By looking at my hostname, I noticed that part of it referred to the dialup point I was using, and didn't change. So I replaced my access mask to include that as well, which meant that only those Netcom users who used the Seattle, WA dialup point would be able to use my nickname.
As you can see, when you have a dynamic IP, access masks almost always allow large groups of people the potential to use your nickname. If you're not satisfied with this, your only option is to delete all access masks from the list, and manually identify with NickServ every time you use DALnet.
Note that even if somebody else does manage to use your nickname due to the access list, they still can't get at any of the critical commands such as dropping the registration or changing the password. All of those require you to identify with the password first. However, if someone got access in this way they will be able to read your memos and send memos using your name, as well as access any channel privileges you might have.
- If you change Internet provider
-
In this case you'll need to add new, different masks for your new address. Don't forget to delete the old masks, assuming you're no longer going to be using the old account.
- If you have more than one Internet account
-
You may want to add several masks, one for each of the accounts from which you use DALnet.
- Don't add wide access masks to your list
-
NEVER put *@* in your access list, or other access masks like *@*.net, *@*.com, *@*.uk, etc, which would let large numbers of people use your nick.
- Try to have as few access masks as possible
-
You should only need one access mask per account you use to IRC. Each access mask you include may reduce the security of your nickname slightly, so avoid having more than this minimum.
- If you have trouble with people trying to steal your nickname
-
Sometimes, if people are trying to steal your nick, you might want to add warnings to CSops (the only people who can retrieve channel and nickname passwords that might have been lost) so that they will know you have been having problems with this, and will not give out the password to anyone.
This is less significant nowadays because your nickname should have been registered with an email address. CSops will normally send passwords only to that email address. However, if you are still concerned, you can warn CSops using "fake" access masks, for example:
ATTENTION@dont.give.out.my.pass.to.anyone
or
ATTENTION@only.send.my.password.by.email
You shouldn't add this kind of "fake" mask unless you know or strongly suspect that somebody is trying to steal your nickname. If you include these, clearly the CSop will not give out the password to anyone, even you.
If you add an "only send my password by email" mask, don't forget to make sure your email address is specified for the nickname (see /nickserv help set email for more information).
10 · Summary
Here's the quick way to get a "correct" access list in most cases.
-
Type /nickserv access list
-
Type /nickserv access wipe
-
If you want your nickname to be completely "secure", stop now, don't do any other commands. You'll have to use the /nickserv identify password command each time you log on to DALnet. (Note: There is a short form of this command, /identify password, which you may find useful.)
-
Type /whois YourNick (where you replace YourNick with your nick). The result should be:
YourNick is youruser@stupidnumber.hostname * Your silly message
-
If there was some stupid number there in the hostname (after the @ symbol) then you probably have a dynamic address: type /nickserv access add youruser@*.hostname (replacing "youruser" and "hostname" with the actual values from the /whois command.)
If there wasn't a number then you probably have a static address. The result from /whois actually looked like:
YourNick is youruser@hostname
In this case, type /nickserv access add youruser@hostname (replacing "youruser" and "hostname" with the actual values)
-
That's it, you're done.
Please direct any comments or feedback about this document (only! no help requests!) to docs@dal.net. If you need help on issues not covered in this document, please see the information at http://help.dal.net.