Token administration guidelines
Managing the tokens for your organisation is an important role. Your care and attention to detail ensures the security of your organisation’s information.
Authentication tokens provide an additional level of security. Because passwords can be guessed or extracted from compromised computers, physical tokens ensure that a password alone is not enough to log into the system.
When you’re managing the tokens, there are often several steps you need to take. While sometimes a little laborious, each of these steps is essential for maintaining the security of the system.
Issuing tokens
It’s important that tokens are issued to the right people. If you accidentally issue a token to the wrong person, you could either:
- Deny the legitimate user access to the system
- If they know the password, grant an unauthorised person access to the system.
You must always verify the identity of someone when you issue them a token. This doesn’t need to be particularly formal. If you work with that person and can recognise them, that’s more than good enough.
To issue a token, login into Haplo, then click
Click Issue next to the relevant user. You need to enter the serial number of the token, and the current code from that token. This verifies that you’re in possession of the token, and that you’ve entered the correct serial number to prevent mistakes which can prevent your colleague from logging in.
You should always give a token to your colleague yourself. This ensures that you’re issuing the token to the person you intend to.
In larger organisations, this may not be practical. You can either trust more people to administer tokens, or pass on tokens via people who are explicitly trusted to give them to the end user.
Keyrings
When you issue a token, you should encourage your colleague to attach it to their keyring immediately. This minimises the chances of them forgetting or losing their token.
Temporary codes
Sometimes people will forget their tokens, but they still need to log into the system. If your organisation’s security policy permits this, you can generate temporary codes which allow them to log in without their token.
This is dangerous. This is a loophole in the security, and you should be incredibly careful when issuing a temporary code. You must make sure you’re not giving a temporary code to someone who has discovered a password. If in doubt, do not issue a temporary code.
You should only give a temporary code to someone who you are absolutely sure is the right person.
Withdrawing tokens
If a token is lost, you should withdraw it. It should be replaced as soon as possible.
Be aware that your system may be set up to deny access if a user doesn’t have a token. You may wish to keep a spare token that you can issue on a temporary basis — but remember to be just as careful as when you’re issuing a permanent token.
Spare tokens
To prevent tampering or unauthorised use, you must store spare tokens securely, preferably in locked storage.
Social engineering
You’re the last line of defence for your organisation’s security. If someone really wants to access your system, they’ll try to trick you into allowing them access. This is known as social engineering.
You must assume, at all times, that someone else knows all the passwords for your system, and that the tokens are the only thing preventing them from accessing your confidential information. This paranoid attitude will make sure you’re doing the right thing.
When you’re issuing a token to someone, you must be absolutely sure they’re the right person. If they know the password, they’ll be able to log in.
Be especially careful when reissuing a token. Someone who knows a password may be trying to trick you into replacing a token for that account.
And most importantly, be incredibly careful when issuing a temporary code. Not only does this allow access, but it won’t alert the legitimate user by blocking their access.