Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Feb 2009 18:21:53 +0100
From:      Benjamin Lutz <mail@maxlor.com>
To:        freebsd-security@freebsd.org
Subject:   Re: OPIE considered insecure
Message-ID:  <200902111821.53437.mail@maxlor.com>
In-Reply-To: <200902090957.27318.mail@maxlor.com>
References:  <200902090957.27318.mail@maxlor.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello,

I've been thinking about what to do about OPIE, and I see the following 
possibilities. (Note: this is mainly just a braindump to collect my 
thoughts; many details that seem obvious to me are omitted. I'm making it 
public because others might be interested in it too.)

- Enhance OPIE to use larger internal hashes. Because of the way OPIE works, 
the user needs to input at least as many bits as OPIE uses internally, 
therefore increasing the hash length increases the inconvenience. If 
5-letter words were added, this would give us 18, maybe 24 additional bits 
for a total of 82-88 bits; if two numeric digits (2-9, because 0 and 1 
might be confused with O and l) are added to every word (JOHN43 BOAT59), 
this would give us 36 additional bits for a total of 100 bits.


- Implement another algorithm: PPP. (https://www.grc.com/ppp.htm, no source 
available but algorithm is documented.)
This system appears to have one weakness compared to OPIE: the secure 
256-bit key needs to be stored on the host and is accessed frequently. 
There are several advantages though: the algorithm won't be brute-forced 
any time soon, and since the passwords have no dependencies to each other, 
they can each be very short (GRC suggests 4 characters). Also, the number 
of one time passwords that can be generated is unlimited (*).

PPP Variant 1: The problem of the secure key being compromised could be 
solved by extending the algorithm as follows: the list of one time 
passwords is precalculated on the host, each password is hashed and only 
the hash is stored. This would remove the advantage (*) and also prevent 
recreation of a password list (but that's good, right?)

PPP Variant 2: derive the secure 256-bit key from some user passphrase. This 
would allow password calculators.


- Implement another algorithm: OTPW 
(http://www.cl.cam.ac.uk/~mgk25/otpw.html, implementation is GPL, algorithm 
is documented.)
This system precalculates random independent passwords and stores their 
hashes. This then works the same as the PPP variant 1 described above. 
Password calculators are not possible.


- Use pam_sotp (http://www.cavecanen.org/cs/projects/pam_sotp/, GPL, 
algorithm not documented). Seems be quite similar to OTPW.


Some general thoughts:

- The one time passwords should definitively be independent from each other; 
this allows very short passwords, which is much more convenient than OPIE 
is now.

- I wonder if it makes sense to worry about races? (Attacker logs your key 
presses, then automatically logs in after you've entered the last character 
but before you've pressed enter.) Probably not, when there is the danger of 
the ssh binary being compromised?

- OPIE prevents concurrent logins. Is it possible to allow them securely, 
without making DOS-by-password-exhaustion possible?


Cheers
Benjamin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200902111821.53437.mail>