On OTP style authentication... criticism please

From: randomnumbers (randomnumbers_at_mail15-dot-com.no-spam.invalid)
Date: 03/19/04 

Date: 18 Mar 2004 20:51:43 -0600

Hi all.
Firstly apologies for asking a question I ought to know the answer to;
too many days without sleep has fuddled my brain. Feel free to beat
me with the blunt instrument of your choice if I am talking rot.
Apologies also for the length of this post, I feel it is far better to
explain everything in one hit than try to be too brief and have to
subsequently explain myself in further posts.

I have used the written convention "an OTP" rather than "a OTP". When
I think of OTP I think of the acronym as letters (O-T-P) rather than
what it stands for, thus I tend to use this method of notation. I
realise that for people who prefer it the other way around it will
mentally jar each time they read it and apologise in advance. To make
it even more confusing I sometimes refer to them as keys, which I
realise is not semantically correct but is easier on the eye..

Consider the following scenario:

Background:
A website with up to 7 million users. The users will be required to
access their "secure zone" up to 5 times a week for a period of five
years.
I have been asked to evaluate the feasibility of using an OTP method
for validating/authenticating users logging in to their "secure
zones".

Process:
Each user receives by a secure method a large list of randomly
generated numbers. This list of numbers is arrange such that they are
easier to read than whole pages of text; they may for example, be
grouped into chunks of four digits. Additionally, the chunks will be
arranged in a grid structure such that the list can be easily
navigated.

When the user logs onto the system they are prompted for their
ID/password combo (which identifies them) and the next N chunks from
their list.

Obviously such a system is not using an OTP to encrypt anything. That
is, a random sequence is not being used to generate cypher-text,
instead discrete chunks of the random sequence are being used to
authenticate the user.

The number of digits in a chunk and the number of chunks the user is
asked to input is somewhat academic. The total number of digits
requested must be large enough to avoid "lucky guesses" and small
enough to be feasibly entered without error. 8 digits would be a
practical number.
This is the system I intend to propose for authenticating users.

Distribution of keys:
In the country in which this system is to be implemented, one can send
a parcel or letter by mail that does not go direct to the
receipient's postal address. Rather, the item of mail goes to their
local post office and they are then sent a card alerting them to the
package. They are then required to visit the post office and on
producing their national identity card along with the card they were
sent, they receive the package.
This is the system I intend to propose for distributing the lists of
numbers to the intended users.

On numbers:
Over the 5 year period, assuming each user logs in the maximum 5 times
per week, they shall need 1,300 keys (5*5*52). Obviously they will
need more than this to account for those times when they fail to
enter a key correctly; in such a situation the incorrectly entered
key shall be disregarded and the next in the sequence shall be
requested. Let us be generous and say that each user shall have 3,000
keys.
Assuming the maximum number of users (just shy of 7 million) this
means a total of 2,100 million keys (7m * 3,000) or 2.1 billion
depending on your regionality.
Because the mechanism for generating the random sequence is binary in
nature (more on that below), it seems natural that each digit should
be octal in nature (that is each digit is in the range [0..7]); thus
each digit is constructed from 8 bits of the random stream. As
mentioned above the user shall be asked for 8 digits on each login so
in total we must generate 134,400 million random bits
(8*8*2,100,000,000) or, if you prefer, 1,344 billion bits (or is it
1.344 trillion?)

Randomometer:
To generate the sequence of random numbers I am veering toward using
some basic quantum mechanics to generate the stream (note when I say
quantum I am *not* talking about quantum encryption here, nor am I
talking about stream cyphers when I mention a stream of numbers).
In essence I envisage a system based upon a beam splitter and a pair
of single-photon detectors. Whilst there is some debate about whether
this kind of splitting device is *truly* random, most of that ends up
in philosophical debate regarding the deterministic nature of the
universe (or not, as the case may be) and remains to all practical
purposes "as random as one can currently get", as a quantum physicist
recently explained to me.
I am reliably informed that this kind of beam splitting can generate
numbers at approx. 1Mb/s so the entire pool of numbers can be
generated in approx. a day and a half.

And now, finally, to my questions.
1. If anyone can spot a fatal flaw in what I am proposing, feel free
to shoot me down in flames.
2. Consider this situation: The user is asked for the next eight digit
number in their list sequence. Rather than being asked to input all
eight digits, the user is asked to enter digits A,B,C,D from the
eight digits (where A,B,C,D is a randomly determined number from 1 to
8 ). Would this approach make the system more secure, less secure, or
make no difference.
It is really bugging me that I should be able to answer that
question.

Thanks in advance and apologies for the oiverly verbose post.

/rnd##

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
                http://www.usenet.com

Relevant Pages

  • Re: Random string of digits?
    ... can't trust randint() over that huge a range). ... The way I'd do it would be in chunks. ... For your actual task, I'd be inclined to take ten digits, twice, and ... enough bits to choose from a population range this large ...
    (comp.lang.python)
  • Re: Random string of digits?
    ... zeros). ... can't trust randint() over that huge a range). ... The way I'd do it would be in chunks. ... For your actual task, I'd be inclined to take ten digits, twice, and ...
    (comp.lang.python)
  • Re: Sort files collection ?
    ... My apologies, however, it was more a lack of interpretation on my part than understanding. ... To me it's not the value of digits in the year that indicate the YMD order, but the fact that there are more than two of them, plus the fact that YDM is the least likely order possible. ...
    (microsoft.public.scripting.vbscript)
  • Re: Is continuum completely filled up?
    ... such descriptive statement follows from whatever sufficiently rigorous ... I know that pi has a random sequence of digits too (and it is probably a safe bet that distinguished tomes have been written concerning the statistical characteristics of its decimal expansion) - but pi does not encapsulate an actually infinite amount of information, which is what you would require to specify an instance of the other... ...
    (sci.math)
  • Re: Plan to use area codes for local calls
    ... They should be assigned in chunks of 1000 or so. ... Bournemouth 0112 and 7 digits. ... Aberdeen 027 (02S 1st part of new area code for all of Scotland ... I think there was a suggestion to have an all Scotland area code with ...
    (uk.telecom)