3

I recently learned about diceware and was thinking about how it could possibly be used to create a one time password scheme. I'm thinking S/KEY is probably more appropriate, but would a system that does this be considered secure?

  1. Use a strong random number generator to create an initial seed
  2. Generate a new random number from a CSPRNG
  3. Create a diceware password from the lower 15 bits (for 5 dice, 18 for 6 dice, etc)
  4. Store the seed securely

Generating lists of passwords can obviously be done provided you have the starting seed, and you can always generate new passwords by changing the initial seed. Seems simple enough, and diceware's wordlist is > 3 times the size of S/KEY's which seems to make it more secure... However, such a simple scheme seems likely to be insecure due to something I'm missing. Has this scheme been studied before? Is it viable?

Edit: I realized my step 3 is flawed. We need multiple random numbers to extract 15 bits for each word output from diceware. In other words, we need 60 bits for 5 words, and 120 bits for 8 words. But, the point remains the same.

Improve this question
3
  • 1
    "secure" is not a binary value. "secure" is like "pretty". Is your scheme more secure than "correct horse battery staple"? Is Don King prettier than Gillian Anderson?
    – MCW
    Commented Dec 20, 2012 at 14:31
  • Great point! However, I'm not exactly sure how I could rephrase this question more appropriately. Would it make sense to think of it in terms of "how long would it likely take to break this scheme?"
    – apgwoz
    Commented Dec 20, 2012 at 18:31
  • Oddly, I've been considering the same question. I wonder whether a superior question would be, "How do I model the security of a password scheme based on diceware?" How do I model the security so that I can compare the strength of this security scheme to that security scheme? The model would explicitly assume that the attacker would attack the weakest link within scope.
    – MCW
    Commented Dec 20, 2012 at 18:35

1 Answer 1

Reset to default
1

The problem is that a random number generator is not cryptographically secure. Someone could look at the progression of passwords and potentially work backward through the algorithm to determine the seed being used. At this point, your key would be broken.

The method you describe is actually very similar to the way most two factor token devices work however. Basically, they store an encryption key securely. They then use that encryption key to encrypt a timestamp based on an internal clock. The server also knows the key and knows what the encrypted value should be. They then hash it down to a value that can be easily entered by the user. If both values match, you are given access.

Drift correction for the token's clock is done by looking for slow drift and adjusting the time offset for the token on the server. (For example, if you consistently start putting in codes that are about to be valid, then it knows that the clock on the token is running fast and can adjust accordingly.

The server also stores the most recently used timestamp and will not accept any codes that precede it. (Though they wouldn't be accepted outside about a 1 minute window anyway, but this is to prevent a quick replay after making it appear a code was denied.)

Improve this answer
4
  • Well, there are cryptographically-secure PRNGs, and there are hardware RNGs based on environmental phenomena. But you're right, most of the algorithms available for "everyday" randomness have weaknesses allowing a pattern to be exposed and exploited.
    – KeithS
    Commented Dec 20, 2012 at 16:04
  • The only requirement is that this is predictable to N passwords, as you could expire it and regenerate the seed, similarly to the hash-chaining approach. Hash-chaining like in S/KEY is almost certainly a better idea because it theoretically doesn't rely on anything predictable. But, a key scheduling algorithm, like the one used in RC4 for example, seems appropriate for this use case, except for the fact that these are capable of being broken.
    – apgwoz
    Commented Dec 20, 2012 at 18:36
  • 1
    @apgwoz - You would need a new way to synchronize the seed then. You'd still be trying to address the inherent weakness of the fact that an RNG is likely not secure against determining the seed from a large enough set of output. It doesn't offer anything over the cryptographically based symmetric key and time system that is most commonly used.
    – AJ Henderson
    Commented Dec 20, 2012 at 19:17
  • @KeithS - There are PRNGs that are cryptographically secure in that for a given key, they produce a random distribution of numbers if you can hide the variables involved, but that doesn't mean you can't work backwards from a given known output to the seed value. In order for two PRNGs to be able to generate the same value from the same seed, the other variables are going to have to be known. In this case, the PRNG should be fairly easy to reverse the logic on and get to a seed value in most cases. Do you know a particular PRNG algorithm that would be resistant to this?
    – AJ Henderson
    Commented Dec 20, 2012 at 19:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .