I have always considered plain passwords to be extremely insecure as they are vulnerable to key loggers, shoulder surfing and other techniques which instantly render them useless.
A simple defence is to make sure you only use a password once. Using a OTP token is one way to achieve this.
This page presents an OATH OTP library and test program for Python.
I have tested this library against hardware tokens (C100 OTP and C200 OTP from Feitian)
The security provided by OATH OTP tokens rests on the secrecy of the seed/key.
For event based tokens such as the C100, knowledge of the key by an attacker is not in itself useful without knowledge of the internal counter value (i.e. how many times the button has been pressed.) However this information can be obtained quickly - you need just one or two passwords from the device to be able to work out the internal counter value.
For time based tokens such as the C200, knowledge of the key enables an attacker to immediately clone the token.
Both these attacks can be demonstrated using the program below.
The tokens I purchased have had their keys set at the factory. The tokens are then delivered with this key information sent on printed paper.
For reasons stated above, this key is critical security information and it should be known only by the token and the authentication server. In this case however, the key is known and stored by at least two external parties; the factory and the vendor. There is no way for the end user to change this key.
Makers of these tokens should provide a way to set the key. Or, preferably for the device to be able to internally generate and show a new key on demand. Internal generation is preferred because it prevents someone from making a cloned token but at the same time gives them the security of a key not known externally.
I am told by the vendor that such tokens do not yet exist.
Curiosity got the better of me.
The specification for these devices describes the casing as "tamper evident." I had no trouble dismantling the token in a non tamper-evident manour with nothing more than a screwdriver.
The PCB has the battery soldered on board with a globbed CPU and the display soldered on the reverse. The 3x3 pads on the right line up with a hole in the back of the casing (normally covered up by a plastic cover.) This must be where it is programmed. (Looking closely shows indent marks on the pads.) Obviously, one has to wonder if it is possible to read the seed back out of this port. There is another port on the display side.
I deliberately reset the device by momentarily shorting the battery. After a second of displaying all 8's, the display shows as below :
This appears to show the seed has been deleted as pressing the button reads "Err 1." The only pads I can identify on the 3x3 are GND, VBAT, RESET(possibly), nBUTTON and an unknown output. One isn't connected and 3 others may be inputs. The output goes high during reset. Any clues how to re-initialise the token are welcome!
To understand how these devices work, I wrote a quick library and test program based on the applicable standards. You can import this library into your own programmes or simply run it to access the interactive test program.
Example output from test program:
I purchased my tokens from Gooze.eu. They have a range of cryptographic tools at very reasonable prices and their staff are friendly and helpful. At the time of writing, the C200 token was only EUR 9.90 including taxes.
This is a nice project. I have always wanted to set this up for my own logon services // remote access to account information for logons. Any advice on how I go about this for my own personal setup for remote working etc..?
The seeds are indeed kept in RAM. This is a valuable security feature that makes extracting them much more difficult. If there are tamper detection features, this allows them to also trigger the erasure of the seed so any mistake and the seed is lost! The token itself is not destroyed though. Clearly it starts its life in the erased state and removing the battery just returns it to that state. A fantastic feature would be to ship them this way, with a programmer for the end user to be able to program the seed. That would give a high level of confidence that the seed is not known elsewhere. But the very presence of a programming port makes me wonder if there is a 'back door' to extract the seed through it, hence the suggestion that the seed be internally generated on demand - say by pressing a recessed button with a paper clip.
In answer to your question, the seeds are kept in RAM, not ROM. After removing the battery, the seed is removed and thus the token is destroyed. This is a security issue.