Editing S/KEY (section)

==Security==
The security of S/KEY relies on the difficulty of reversing [[cryptographic hash functions]]. Assume an attacker manages to get hold of a password that was used for a successful authentication. Supposing this is {{tt|password}}<sub>''i''</sub>, this password is already useless for subsequent authentications, because each password can only be used once. It would be interesting for the attacker to find out {{tt|password}}<sub>''i''−1</sub>, because this password is the one that will be used for the next authentication.

However, this would require inverting the hash function that produced {{tt|password}}<sub>''i''−1</sub> using {{tt|password}}<sub>''i''</sub> (''H''({{tt|password}}<sub>''i''−1</sub>) = {{tt|password}}<sub>''i''</sub>), which is extremely difficult to do with current [[cryptographic hash functions]].

Nevertheless, S/KEY is vulnerable to a [[man in the middle attack]] if used by itself. It is also vulnerable to certain [[race condition]]s, such as where an attacker's software sniffs the network to learn the first ''N'' − 1 characters in the password (where ''N'' equals the password length), establishes its own TCP session to the server, and in rapid succession tries all valid characters in the ''N''-th position until one succeeds. These types of vulnerabilities can be avoided by using [[Secure shell|ssh]], [[Secure Sockets Layer|SSL]], SPKM, or other encrypted transport layer.

Since each iteration of S/KEY doesn't include the salt or count, it is feasible to find collisions directly without breaking the initial password.  This has a complexity of 2<sup>64</sup>, which can be pre-calculated with the same amount of space.  The space complexity can be optimized by storing chains of values, although collisions might reduce the coverage of this method, especially for long chains.<ref>{{cite web|title=S/Key Dungeon Attack|date=2011-07-01|last=Samuel|first=Michael|url=https://www.miknet.net/security/skey-dungeon-attack/|accessdate =2019-12-05}}</ref>

Someone with access to an S/KEY database can break all of them in parallel with a complexity of 2<sup>64</sup>.  While they wouldn't get the original password, they would be able to find valid credentials for each user.  In this regard, it is similar to storing unsalted 64-bit hashes of strong, unique passwords.

The S/KEY protocol can loop.  If such a loop were created in the S/KEY chain, an attacker could use user's key without finding the original value, and possibly without tipping off the valid user.  The pathological case of this would be an OTP that hashes to itself.