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.

  • 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 Dec 20 '12 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 Dec 20 '12 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 Dec 20 '12 at 18:35

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.)

  • 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 Dec 20 '12 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 Dec 20 '12 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 Dec 20 '12 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 Dec 20 '12 at 19:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.