S/KEY: Difference between revisions
(8 intermediate revisions by the same user not shown) | |||
Line 19: | Line 19: | ||
This value is stored together with the seed and the sequence number somewhere on the host that is to be authenticated to. As the passphrase must not be exposed to any attacker, the calculation should be done on a trustworthy system over a secure connection. The <math>h_I</math> however does not need to be kept secret. |
This value is stored together with the seed and the sequence number somewhere on the host that is to be authenticated to. As the passphrase must not be exposed to any attacker, the calculation should be done on a trustworthy system over a secure connection. The <math>h_I</math> however does not need to be kept secret. |
||
== Authentication == |
|||
When authentication is desired the host transmits a challenge to the user consisting of the <math>seed</math> and <math>n-1</math> (where <math>h_n</math> is the hash value that is stored on the host) and also naming the <math>H_o</math> to be used. The user then comes up with <math>h_{n-1}</math> and transmits this hash to the host. The host computes <math>H(h_{n-1}, seed)</math> and compares this value with the one in its storage. The user is authenticated, if the result matches in which case <math>h_{n-1}</math> and <math>n-1</math> are stored on the host (replacing <math>h_n</math> and <math>n</math>). Otherwise the authentication fails. |
|||
The system is secure against an eavesdropping attacker because the next authentic hash (<math>h_{n-1}</math>) can not be easily computed from a transmitted hash (<math>h_{n}</math>). For the very same reason it also is secure against read-only attacks on the host's password storage where only <math>h_{n}</math> is stored. |
|||
The user has several ways to come up with <math>h_{n-1}</math>. The most obvious approach would be a locally run program on the computer the user wants to authenticate from. This program would take the user's passphrase, the seed and the hash algorithm and compute the necessary authentication hash. As the challenge is transmitted in a machine-parseable format the latter two values can be determined automatically and a modified telnet client could make the process completely transparent to the user, simply prompting her for her passphrase. A similar approach would be to use a pocket calculator style device to user could carry with her. |
|||
The most interesting feature with regard to usage as One-Time Password system however is the fact that all the challenges are known in advance and thus the authentication hashes can be computed in advance. Thus the user can use a program on a trusted host, enter the seed and initial sequence number from the initialization process and generate a list of all (or the next 23 or so) authentication hashes. She can then print this list and take it with her. |
|||
Then, when doing authentication, the user can mostly ignore the challenge and simply take the next password from her list, marking all used passwords in some way. |
|||
== Full example == |
|||
Following is a full example of the complete process. The user's name is <var>alice</var>. The host system is a Gentoo Linux box with an S/KEY [[PAM]] module. The passphrase will be <code>Soylent green is people.</code>. |
|||
(Note: <i>Italic text</i> is keyboard input, <i><s>Striked italic text</s></i> is hidden keyboard input.) |
|||
alice@gleam alice $ <i>skeyinit -t md5</i> |
|||
Password: <i><s>unix password</s></i> |
|||
[Adding alice] |
|||
Reminder - Only use this method if you are directly connected |
|||
or have an encrypted channel. If you are using telnet |
|||
or rlogin, exit with no password and use skeyinit -s. |
|||
Enter secret password: <i><s>Soylent green is people.</s></i> |
|||
Again secret password: <i><s>Soylent green is people.</s></i> |
|||
ID alice skey is otp-md5 99 glea92484 |
|||
Next login password: JOEY BUB LIVE URGE MOOD TRUE |
|||
alice@gleam alice $ <i>su - -c "grep alice /etc/skey/skeykeys"</i> |
|||
Password: <i><s>unix password</s></i> |
|||
alice md5 0099 glea92484 a2611ac2f92be7e0 Nov 07,2004 02:54:52 |
|||
alice@gleam alice $ <i>skey -t md5 -n 5 98 glea92484</i> |
|||
Reminder - Do not use this program while logged in via telnet or rlogin. |
|||
Enter secret password: <i><s>Soylent green is people.</s></i> |
|||
94: BON JESS KANE AX DEEM GANG |
|||
95: FILE DICE INCH ELY RUBE COED |
|||
96: KLAN COOL JADE DIRT RENA SEE |
|||
97: FIR FOOT BALL GIN RAN LOOK |
|||
98: DAY LEFT BOON MAUL NO WINE |
|||
alice@gleam alice $ <i>ssh localhost</i> |
|||
challenge s/key 98 glea92484 |
|||
password: <i><s>DAY LEFT BOON MAUL NO WINE</s></i> |
|||
Last login: Sun Nov 7 02:51:40 2004 from localhost |
|||
alice@gleam alice $ <i>logout</i> |
|||
Connection to localhost closed. |
|||
alice@gleam alice $ <i>ssh localhost</i> |
|||
challenge s/key 97 glea92484 |
|||
password: <i><s>FIR FOOT BALL GIN RAN LOOK</s></i> |
|||
Last login: Sun Nov 7 02:55:50 2004 from localhost |
|||
alice@gleam alice $ <i>logout</i> |
|||
Connection to localhost closed. |
|||
alice@gleam alice $ <i>su - -c "grep alice /etc/skey/skeykeys"</i> |
|||
Password: <i><s>unix password</s></i> |
|||
alice md5 0097 glea92484 141095470b936564 Nov 07,2004 02:56:05 |
|||
In the example the user alice first initializes the S/KEY system. To be able to do this she must authenticate with her regular unix password and is then asked for her new, secret passphrase. When the process completes successfully a new entry is created in the skeykeys file giving the hash algorithm, the initial sequence number, the seed (which was created from the hostname and some number) the actual hash in hex and a timestamp. Alice then uses the <code>skey</code> utitlity to print the next authentication password(s) in Six Word Format and logs in to the machine using these passwords. Obviously at each login attempt a different password is needed. After each successful login the skeykeys file is modified to reflect the last hash (in hex) and the corresponding sequence number. |
Latest revision as of 03:02, 7 November 2004
The S/KEY One-Time Password system originally came from Bellcore and is described in RFC 1760. It further evolved through RFC 1938 and RFC 2289 under the name "A One-Time Password System". The system uses a cryptographically strong hash function to generate a sequence of One-Time Passwords from a passphrase and a system identifier or seed. There are several possible hash functions that can be used with the system — MD-4, MD-5 and SHA-1 — but only MD-5 is mandatory to support.
The output of the hash function is not used directly but rather folded down to 64 bits and then either input as a hex string or transformed to the so-called Six Word Format. For this a dictionary of 2048 short (mostly english) words is used, giving 11 bits per word. Six words make up the representation of the hash function's output. The additional two bits are used to store a simple checksum. An example for a resulting password would be TORN ACID SAD VAN RUM BEN
.
Let's define the hash function to be used as , where is the folding applied, is the original secure hash function (e.g. MD-4, MD-5 or SHA-1) and is the string concatenation.
The folding function must shorten the result of (either 128 bits for MD-4 and MD-5, or 160 bits for SHA-1) down to a fixed size of 64 bits. This is done by XOR'ing the first and the last halves of the hash for MD-4 and MD-5 and in a similar fashion for SHA-1. See the aforementioned RFC for details.
Initialization
The system must be initialized before it can be used. During this process a (also called system identifier) is generated which can be between 1 and 16 characters in length and may for example be made up of the host name's first few characters and some random numbers. The seed should be different for each system the same passphrase is used on and should not be reused during successive initializations (at least as long the passphrase is not changed).
During the initialization step the user must choose a password or passphrase () which should be at least 10 characters long and must be kept secret. Reusing the same passphrase on different systems should be safe, as long as the seeds differ from each other.
A further parameter choosed during initialization is the initial sequence number or iteration count. A good choice would for example be 100. This number is decremented at each authentication process, and the system must be reinitialized once the sequence number reaches zero.
When initializing the system, a value is computed, where is the initial sequence number. The computation is done through:
This value is stored together with the seed and the sequence number somewhere on the host that is to be authenticated to. As the passphrase must not be exposed to any attacker, the calculation should be done on a trustworthy system over a secure connection. The however does not need to be kept secret.
Authentication
When authentication is desired the host transmits a challenge to the user consisting of the and (where is the hash value that is stored on the host) and also naming the to be used. The user then comes up with and transmits this hash to the host. The host computes and compares this value with the one in its storage. The user is authenticated, if the result matches in which case and are stored on the host (replacing and ). Otherwise the authentication fails.
The system is secure against an eavesdropping attacker because the next authentic hash () can not be easily computed from a transmitted hash (). For the very same reason it also is secure against read-only attacks on the host's password storage where only is stored.
The user has several ways to come up with . The most obvious approach would be a locally run program on the computer the user wants to authenticate from. This program would take the user's passphrase, the seed and the hash algorithm and compute the necessary authentication hash. As the challenge is transmitted in a machine-parseable format the latter two values can be determined automatically and a modified telnet client could make the process completely transparent to the user, simply prompting her for her passphrase. A similar approach would be to use a pocket calculator style device to user could carry with her.
The most interesting feature with regard to usage as One-Time Password system however is the fact that all the challenges are known in advance and thus the authentication hashes can be computed in advance. Thus the user can use a program on a trusted host, enter the seed and initial sequence number from the initialization process and generate a list of all (or the next 23 or so) authentication hashes. She can then print this list and take it with her.
Then, when doing authentication, the user can mostly ignore the challenge and simply take the next password from her list, marking all used passwords in some way.
Full example
Following is a full example of the complete process. The user's name is alice. The host system is a Gentoo Linux box with an S/KEY PAM module. The passphrase will be Soylent green is people.
.
(Note: Italic text is keyboard input, Striked italic text is hidden keyboard input.)
alice@gleam alice $ skeyinit -t md5 Password:unix password[Adding alice] Reminder - Only use this method if you are directly connected or have an encrypted channel. If you are using telnet or rlogin, exit with no password and use skeyinit -s. Enter secret password:Soylent green is people.Again secret password:Soylent green is people.ID alice skey is otp-md5 99 glea92484 Next login password: JOEY BUB LIVE URGE MOOD TRUE alice@gleam alice $ su - -c "grep alice /etc/skey/skeykeys" Password:unix passwordalice md5 0099 glea92484 a2611ac2f92be7e0 Nov 07,2004 02:54:52 alice@gleam alice $ skey -t md5 -n 5 98 glea92484 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password:Soylent green is people.94: BON JESS KANE AX DEEM GANG 95: FILE DICE INCH ELY RUBE COED 96: KLAN COOL JADE DIRT RENA SEE 97: FIR FOOT BALL GIN RAN LOOK 98: DAY LEFT BOON MAUL NO WINE alice@gleam alice $ ssh localhost challenge s/key 98 glea92484 password:DAY LEFT BOON MAUL NO WINELast login: Sun Nov 7 02:51:40 2004 from localhost alice@gleam alice $ logout Connection to localhost closed. alice@gleam alice $ ssh localhost challenge s/key 97 glea92484 password:FIR FOOT BALL GIN RAN LOOKLast login: Sun Nov 7 02:55:50 2004 from localhost alice@gleam alice $ logout Connection to localhost closed. alice@gleam alice $ su - -c "grep alice /etc/skey/skeykeys" Password:unix passwordalice md5 0097 glea92484 141095470b936564 Nov 07,2004 02:56:05
In the example the user alice first initializes the S/KEY system. To be able to do this she must authenticate with her regular unix password and is then asked for her new, secret passphrase. When the process completes successfully a new entry is created in the skeykeys file giving the hash algorithm, the initial sequence number, the seed (which was created from the hostname and some number) the actual hash in hex and a timestamp. Alice then uses the skey
utitlity to print the next authentication password(s) in Six Word Format and logs in to the machine using these passwords. Obviously at each login attempt a different password is needed. After each successful login the skeykeys file is modified to reflect the last hash (in hex) and the corresponding sequence number.