Talk:S/KEY

Emphasis on pre-computation of passwords

From a user's perspective the passwords aren't all generated in advance. Although this can happen, most users use S/Key as a challenge-response system with the server prompting for the current iteration requested and providing a seed as well. I've tried to clarify this point, but it's late and I may have been a bit clumsy. Feel free to edit towards perfection. Also, the article does not mention the hex->ascii dictionary which is a part of the RFC implementation of S/Key. This is an interesting point and may be encyclopedic. -- cmh 05:09, 22 June 2006 (UTC)

Falling into disuse?

The statement about "falling into disuse" and its justification are somewhat questionable. While protocols such as ssh protect passwords in transit, they are vulnerable to keyboard loggers and such when used with traditional passwords. More likely, the complexity of using a password calculator at every login, the prevalence of hardware tokens in enterprise systems (ie. securid) and preprinted password lists (ie. for banking sites) and in general the relative obscurity of OTP systems is the cause of lessened use. 62.142.22.194 (talk) 13:13, 19 February 2008 (UTC)

Insufficient focus on benefits of paper

S/key can provide one time passwords on a non-digital medium (paper), which means that it can be distributed to users of untrusted systems in a capacity that will not benefit from being (and thus likely will not be) digitized. This is extremely important in multi-vendor environments where nonrepudiation is important. It isn't just a matter of secure access, but also placing responsibility on the person being provided with the _capability_ to access. A non-digital authentication medium negates the network, and the client workstation as sources of compromise, and places the responsibility of lost continuity within the overall security system, squarely on the person recieving the non-digital media. Are there any other non commercial systems that provide this capability? Subsequently I can say that as much as SecurID would like "falling into disuse" to be true, it isn't. I have new hardware shipping to colo facility this month that will be accessed by multiple vendors. It will be running openssh and s/key. —Preceding unsigned comment added by 98.249.27.125 (talk) 19:42, 14 January 2010 (UTC)

avoid confusion

Currently the article refers to 2 different passwords with the same phrase, "the first password". Sometimes it refers to H(initial secret), the first password to actually be calculated. Other times it refers to the last password to actually be calculated, which ends up printed at the top of the paper list, and is the first password to be "stored" on the server. Can we avoid that confusion?

I tried to force it to be consistent, but I don't think I succeeded.

Which would be less confusing:

• consistently use "first password" for first-calculated (at the bottom of the printed list), and the "next password" is the next one up towards the top of the list?
• consistently use "first password" for the password at the top of the printed list, and once a person uses one password, the "next password" is always the next password that person will use, the next one down towards the bottom of the list? Perhaps also using terms like "first hash value" and "nth hash value" while we are describing the calculation ... so given a particular password on the list, the "next hash value" is the one just above it towards the top of the list?

--68.0.124.33 (talk) 00:20, 6 April 2008 (UTC)

OPIE?

Why no mention of OPIE Authentication System on this page or the OTP page? --Bobbozzo (talk) 07:21, 18 August 2008 (UTC)

Subpages in Talk namespace

Since subpages are turned on in the talk namespace, Mediawiki thinks this is a child of Talk:S. Does this matter for watched pages? (This section is to test that theory) --- Autopilot (talk) 19:55, 16 December 2008 (UTC)