Hello, I run a firewall where I use OPIE one time passwords for external logins, figuring that this gives me some added protections if I ever need to access it from untrustworthy hosts. A message about the weakness of MD5 got me thinking that maybe a better algorithm could be used for OPIE, and I was delighted to see that some clever hacked has added SHA-1 support to it (although it's a bit under-documented). Then I noticed that the one time passwords don't increase in length with SHA-1. That's weird, since MD5 produces 128bit digests, while SHA-1 produces 160bit digests. So I had a closer look at how the one time passwords are used with in OPIE. I was a bit shocked to find out that OPIE truncates all digests to 64 bits, no matter which algorithm you use. Some quick research into the current speed of MD5 brute-forcing produced this result: http://img519.imageshack.us/my.php?image=eightni6.jpg This ^ was produced on a quad core machine with 4 eVGA 9800GX2 graphics cards, i.e. a top end gaming machine; it can calculate 3611.81 million md5 hashes per second. Using that machine and that speed as a baseline, it's possible to produce a rainbow table with all hashes that OPIE is ever going to use and produce within 16 years. If you can live with a thinned out rainbow table (say, because you can the observe the user enter 8 passwords), and your budget allows a small cluster of these machines, you quickly get into the range of months. Add a few iterations of moore's law... well, you get the point. So, is there an existing alternative one time password implementation that works on FreeBSD? Also, as a suggestion to the security team, maybe it's time to deprecate or remove OPIE? Cheers Benjamin
Benjamin Lutz <mail@maxlor.com> writes:> I was a bit shocked to find out that OPIE truncates all digests to 64 bits, > no matter which algorithm you use. Some quick research into the current > speed of MD5 brute-forcing produced this result: > [...] > So, is there an existing alternative one time password implementation that > works on FreeBSD? Also, as a suggestion to the security team, maybe it's > time to deprecate or remove OPIE?Our current OPIE implementation is a piece of crap. Feel free to suggest (or write) a replacement. That being said, there is no reason why OPIE challenges and responses can't be extended to 128 bits or more. The only downside is that users won't be able to use existing key calculators; they'll have to use pre-generated response sheets. DES -- Dag-Erling Sm?rgrav - des@des.no
Benjamin Lutz <mail@maxlor.com> 2009-02-09: [...]> Then I noticed that the one time passwords don't increase in > length with SHA-1. That's weird, since MD5 produces 128bit > digests, while SHA-1 produces 160bit digests. So I had a closer > look at how the one time passwords are used with in OPIE. > > I was a bit shocked to find out that OPIE truncates all digests > to 64 bits, no matter which algorithm you use. Some quick > research into the current speed of MD5 brute-forcing produced > this result: > > http://img519.imageshack.us/my.php?image=eightni6.jpg > > This ^ was produced on a quad core machine with 4 eVGA 9800GX2 > graphics cards, i.e. a top end gaming machine; it can calculate > 3611.81 million md5 hashes per second. Using that machine and > that speed as a baseline, it's possible to produce a rainbow > table with all hashes that OPIE is ever going to use and > produce within 16 years. If you can live with a thinned out > rainbow table (say, because you can the observe the user enter > 8 passwords), and your budget allows a small cluster of these > machines, you quickly get into the range of months. Add a few > iterations of moore's law... well, you get the point. > > So, is there an existing alternative one time password > implementation that works on FreeBSD? Also, as a suggestion to > the security team, maybe it's time to deprecate or remove OPIE?While I agree that OPIE can be improved, I think that the current OPIE implementation is still much better than having to use passwords from untrusted machines. I also prefer current OPIE to copying SSH private keys to untrusted machines. So until there is a more secure alternative, I really don't think removing OPIE would have a positive effect on security. -- Daniel Roethlisberger http://daniel.roe.ch/
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
Rich Healey writes:> I'm thinking about implementing OPIE, but after reading this I'm not so > sure. What's consensus on the best approach to one time logins?Why are people logging into their remote servers from assumed-untrustworthy clients at all?
On Monday 02 March 2009 03:14:15 Chris Palmer wrote:> Why are people logging into their remote servers from > assumed-untrustworthy clients at all?Because the inconvience of not using whatever service or data the server is providing is considered greater than the security risk. Cheers Benjamin