Mudge writes: > Ahhh but here was my concern back in 95/96 which appears to still be > valid: > > Given that you know what machine you are connecting to, the use of the > seed in the S/key challenge is not as necessary to present to the end user > as it might be otherwise. > > Thus - server: abc123 challenge: s/key 99 K113356 > > could be reduced to server: abc123 challenge: s/key 99 as presented to the > user. This would make the current dictionary attacks largely unusable as > there is a secret that is required but unknown to the attacker. The point of having the seed (or challenge word, as I referred to it previously) in the challenge is that when the sequence number in the challenge becomes low, one can start a new sequence using a different seed without the user having to change his S/Key secret. The rationale is quite clearly described in the RFC. The seed is not anything like a secret and was never intended to identify the server being connected to, and removing it is not beneficial to the S/Key protocol. Removing the seed does not make dictionary attacks on the user's secret harder, let alone "largely unusable". At best it might force the user to choose different secrets once in a while to restart their sequences, but if the user is already inclined to use poor secrets, it's still not improving security significantly. Ultimately the security of S/Key depends on whether the user's secret remains secret. The choice of a good secret that is not susceptible to a dictionary attack, then defending the secret against exposure, is the only real way to ensure S/Key's security.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:31:31 PDT