Password Generation - Security Considerations
This document describes in general terms the methods of creating passwords using random number generators, and considers how to limit the risks of a security breach in the generation process.
Why do you want to generate passwords?
The need to generate a password arises when you create a network account for a remote user. Although the Company rules may state that users must create their own passwords, when an account is initially created it still needs to have a generated password.
How are passwords generated?
Normally using the following components:
Repeatable Generation or Non-repeatable?
Random number generators may have the option to produce repeatable sequences. This means that with the same algorithm and seed the same password will be created. There is only one advantage of repeatable generation which is:
The password can be retrieved (if it is forgotten, for instance) without having to store the password in a file.
Now, your normal procedures may mean the password has been put in a file already, for example for electronic transfer to the server or to the user. If this is the case, be alert about controlling access to the file, and also about the danger of passwords appearing in deleted file space. If you are prepared to take responsibility for controlling access to stored passwords, then you should consider using non-repeatable password generation.
This is because with repeatable generation, a hacker gaining access to a copy of the program has a theoretical chance of devising a method to predict passwords. However, the hacker is unlikely to be successful if the randomiser seed contains a site-determined component, to which he has no access. In these circumstances if he was sure of the algorithm - for instance by knowing the source code of the program, the best attack he could make would be a brute force attack using all combinations for the feasible range of seed values.
It is expected that user login process would be monitored to detect brute force attacks and block the offending IP address. Otherwise there is a general risk from attacks irrespective of how passwords are created.
So - how secure can you be?
Let's summarise the risks from the point of view of the system manager, considering the various components:
|
Component |
Risk |
|
The random number generator |
If this is software, then you should assume it is public - i.e. the hacker may have the generator |
|
The algorithm |
Part of the application program. Again - assume it is public, unless you are able to amend it. |
|
The seed |
You should be able to control this. If it is purely random, for example using a time reading, it is hard to see how the user account could be attacked other than by brute force. |
Although the only component over which you have sure control is the seed, this alone gives you a good measure of control over the total security of passwords. In Visual Basic the seed is a 32-bit number, therefore without the seed, the hacker has a lot of combinations to try.
But if you want to be even more secure -
Then you can take a second of the three components completely out of the public domain by using a hardware random number generator. These can be bought from data security suppliers, for example DES (www.des.co.uk). Request from me a password generator to work with these devices.
The devices are configured so that they each produce a unique pseudo-random sequence. The supplier's claim is that the device can produce "millions of customer unique sequences, each many billions of bytes in length".
Various styles are available - one which is particularly secure fits into an ISA slot inside the PC.
And if you're still not certain because you really are the Pentagon
You could buy a number of DES devices and then choose to deploy just one of them. That way it would be impossible for anyone to know what sequence you are using. And you still have control over the seed value.
Using DES keys should make it possible to use repeatable password generation safely if this is your preferred option.
R A Whiteley
3 July, 1998