S/KEY (was: 2 Questions)
![](https://secure.gravatar.com/avatar/e5ca092d567f80e488fb13f8c55d704e.jpg?s=120&d=mm&r=g)
Steven M Orrin <privsoft@ix.netcom.com> wrote:
Hey guys, 2 quick questions:
Are there any known hacks or weaknesses in S/Key?
S/Key has a rather limited scope, in aiming to prevent replay attacks. These are where somebody snoops on your network to obtain passwords, an uses them in later login attempts. This is undoubtedly a major weakness in most current networks. S/Key addresses this replay of data obtained in passive eavesdropping, but that is all it does. Several attacks against S/Key have been discussed [1], including: race attacks: eavesdropping most of the hash, and racing the user to provide the rest of it active attacks: impersonating the server to learn future hashes or simply hijacking an established session. Strengthening S/Key really means expanding the scope to get an authenticated and encrypted 2-way connection. [John Gilmore's S/WAN may end up achieving this. I'm not familiar with it (yet?).] Ideas for improving S/Key that involve secret data stored on the server tend to get frowned on, as the original aim was to avoid that. In any case you cannot get the full encrypted 2-way connection without getting a whole lot more complicated. Recent discussions [2] have centred on ways to rekey the list of hashes remotely when the count runs down. These changes, and S/Key itself, are better than nothing but where's the ham sandwich ? [3] Beside the protocol weakness there is potential for finding collisions in the hash function (MD4 originally). A choice of hash functions can be provided. See RFC-1938. 1) See also SecureID, which is more complicated and still subject to similar attacks. 2) Not here. 3) Old joke. A ham sandwich is better than nothing, and nothing is better than a life of complete happiness, so ...... -- Peter Allan peter.allan@aeat.co.uk
participants (1)
-
peter.allan@aeat.co.uk