{"id":1045,"date":"2015-06-07T17:26:34","date_gmt":"2015-06-07T17:26:34","guid":{"rendered":"http:\/\/fatsquirrel.org\/oldfartsalmanac\/?page_id=1045"},"modified":"2015-06-07T17:43:39","modified_gmt":"2015-06-07T17:43:39","slug":"the-joy-of-skey","status":"publish","type":"page","link":"https:\/\/fatsquirrel.org\/oldfartsalmanac\/random\/the-joy-of-skey\/","title":{"rendered":"The Joy of S\/Key"},"content":{"rendered":"

One Time Passwords (OTP) are certainly nothing new. In fact, they have been in use for
\nover ten years. The idea is essentially very simple: every time you login to a system, you use a different password. If someone were to eavesdrop on the connection, the password they captured would be
\nuseless to them.<\/p>\n

In 1994, Neil Haller of Bellcore announced the \u201cS\/KEY One Time Password System\u201d
\nat the Symposium on Network and Distributed System Security. It described a practical way to implement OTP that was both secure and simple. Over the years it has matured into strong, practical system that is now described by RFC2289. Furthermore, implementations exist for many Operating Systems, and just about all BSD flavours include it as standard. Despite this, it is still rare, in my experience anyway, to encounter people that have even heard of it. As far as I can tell, there are two main reasons for its lack of popularity:<\/p>\n

    \n
  1. In the days of SSH and encrypted traffic, people no longer think it’s necessary.<\/li>\n
  2. In order to login to a system using S\/KEY, you need a computer to generate the next
    \npassword, which raises the question of how you securely login to it.<\/li>\n<\/ol>\n

    While both points appear valid, they are both flawed.<\/p>\n

    It is true that SSH arguably does a better job of protecting passwords from eavesdroppers. In fact SSH provides for more than that, and it also protects all content from eavesdroppers. However there is one very common form of attack to which SSH is not immune: keylogging. Keyloggers record the keys you hit, and they don’t care whether
    \nyou’re using an SSH client or telnet. They have to be installed on the machine you are using, either in software or hardware. However, now that we live in the age of Microsoft and Cybercafes, using a
    \ntrojanised machine is all too easy to do. What most people don’t realise is that SSH, or at least OpenSSH, is already S\/KEY aware. So why not use it ?<\/p>\n

    As for the second point, indeed you do need a computer. However – you, dear reader, almost certainly have a computer in your pocket or on your wrist at this moment. In fact, if your mobile phone is Java-enabled , which
    \nthese days is quite likely, then you can use it to generate S\/KEY passwords. Very much like an RSA SecurID fob, only cheaper, and without a six-month lifespan.<\/p>\n

    This article gives an introduction to S\/Key, together with an example of how to start using
    \nit on OpenBSD. The final section of this article lists several links to further reading, S\/Key generators and details of using it on other Operating Systems.<\/p>\n

    The Guts<\/h2>\n

    This section explains how S\/Key actually works. Feel free to skip it if you’re not interested although, in my opinion at least, it is not only interesting, but quite beautiful!<\/p>\n

    A user wishing to use OTP to login to a server
    \nmust first initialise the S\/Key system. The initialisation consists
    \nof a short string provided by the server, known as the seed,<\/i>
    \nand a secret passphrase provided by the user. The two strings are
    \nconcatenated and passed through a hash function. RFC2289 allows for
    \nthe use of three different hash functions: MD4, MD5 and SHA-1. The
    \nchoice of hash is left up to the user.<\/p>\n

    The output of the hash function is then reduced,
    \nor folded,<\/i> to 64-bits using a method described in the RFC.
    \nThis 64-bit value, known as theinitial step,<\/i>is then
    \npassed through the hash function, and again folded. This process
    \ncontinues until the hash has been applied a number of times, let’s
    \nsay 99. The server then stores the final output, together with the
    \nseed value and the number of times the hash was applied, the
    \nsequence number, <\/i>in the server’s
    \nS\/Key database. The system is now ready to accept a login.<\/p>\n

    When the user wishes to
    \nlogin to the server, the server provides a challenge,<\/i> which
    \nconsists of the chosen hash, the seed and a number which is one less
    \nthan the sequence number stored in the database; in this case, 98.<\/p>\n

    The user then
    \ngoes through the same procedure used to produce the initial step and
    \nhashes it that number of times. The resulting 64-bit hash is
    \nthe One Time Password.<\/p>\n

    The user then conveys this password to the server
    \n(more about this later).<\/p>\n

    Remember that this is not going to be the same as
    \nthe hash stored in the server’s S\/Key database, which has been hashed
    \none more time. So, in order to compare it to that which is stored in
    \nthe database , the server must hash the password one more time. If it
    \nmatches, the user has demonstrated they know the passphrase and so
    \nthey have successfully been authenticated. The server stores the
    \npassword as provided by the user (i.e. before the server applied the
    \nfinal hash) together with the new, lower, sequence number (98) in the
    \ndatabase and logs the user in.<\/p>\n

    The next time the user logs in, the sequence
    \nnumber in the challenge will be the next lowest sequence number, in
    \nthis case 97.<\/p>\n

    From this we can infer:<\/p>\n