

As old as good: One Time Passwords - gnosis
http://www.nardol.org/2008/9/12/as-old-as-good-one-time-passwords

======
Titanous
Another (shorter length) OTP implementation:

Perfect Paper Passwords: <https://www.grc.com/ppp>

I've created a v3 compatible Ruby implementation of this for use in webapps
etc: <http://gist.github.com/74551>

------
nas
Perhaps I'm missing something but I don't see too much benefit from OTPs. If
the machine in front of me is compromised (e.g. Firefox bug, Flash bug, Adobe
Reader bug, Linux kernel bug, Windows bug, etc etc), a OTP doesn't stop a man-
in-the-middle attack. Once the attacker is on the remote system they can open
a backdoor. Game over.

Sand boxing seems to be a good idea (e.g
.[http://theinvisiblethings.blogspot.com/2008/09/three-
approac...](http://theinvisiblethings.blogspot.com/2008/09/three-approaches-
to-computer-security.html)). KVM and Xen seem pretty heavyweight. I was
looking into using Smack to do lighter weight sandboxing but didn't get too
far yet.

~~~
gnosis
_"a OTP doesn't stop a man-in-the-middle attack"_

This is true.

 _" Once the attacker is on the remote system they can open a backdoor."_

If you're using OTP's, then there's really only one way an attacker could do
that: hijack your session after you use the OTP to log-in, but before you have
logged out.

OTP's won't protect you from such a session hijack. However, they will protect
you from a simple keylogger on the untrusted machine you're logging-in from,
since recording the password you used to log-in will be useless for the
attacker (as far as future logins are concerned).

This is why OTP's are very, very important and useful for access from
untrusted systems... particularly for uses such as reading your email through
webmail interfaces while away at on a business trip or on vacation, where your
only access to your email might be through an untrusted computer at an
internet cafe or somesuch.

 _"Sand boxing seems to be a good idea"_

I'm all for it. But that is a solution to a completely different problem: how
to keep the rest of your system from being compromised further once someone
has already hacked in to a part of your system. OTP's are a way to (hopefully)
prevent that from even happening (by neutralizing the usefulness of a password
that has been compromised on an untrusted machine).

------
gnosis
Also see OTPW:

<http://www.cl.cam.ac.uk/~mgk25/otpw.html>

According to its author:

 _"OTPW is not compatible with and is not derived from either S/KEY or OPIE.
It is a completely independent and different design, which I believe fulfils
my functional and security requirements better."_

~~~
gnosis
And also see these credit-card-sized hardware OTP solutions:

[http://www.schneier.com/blog/archives/2008/12/credit_card_wi...](http://www.schneier.com/blog/archives/2008/12/credit_card_wit.html)

[http://www.dailymail.co.uk/sciencetech/article-1085642/The-n...](http://www.dailymail.co.uk/sciencetech/article-1085642/The-
new-credit-card-keypad-promises-fight-online-fraud.html?ITO=1490)

<http://www.emue.com/site/home.htm>

------
drinian
Clever, and more practical than two-factor for a lot of situations without
sacrificing security. Doesn't necessarily preclude using SSH key exchange on
your trusted (encrypted hard disk) personal computer, either. If you're REALLY
paranoid, you could use OTPs there as well -- you can't keylog a piece of
paper in your wallet...

~~~
gnosis
I've always wanted to encrypt my whole disk, but have been too worried about
disk errors making the whole thing un-decryptable, and thus losing all my data
due to some stupid (and probably inevitable) disk error.

~~~
Chronos
CBC mode and its relatives, one of which is likely the mode you have in your
head, is great for an ephemeral stream, but not well suited to permanent
storage: it's inappropriate for hard drives because it forbids random access,
and it's inappropriate for tape drives because it makes the tape too lossy.

Real disks use either CTR mode or CFB mode, neither of which has those two
problems.

CFB mode depends only on the previous cyphertext block to decode the current
block, which allows random access but amplifies a one-bit error to a one-block
error. CTR mode uses the current logical block number as IV salt, so it's both
random access and minimally-corrupting in the case of errors. AFAIK most real-
world hard drive encryption uses CTR mode, precisely to avoid the problem that
concerns you.

~~~
tptacek
This is an interesting comment, but it drastically oversimplifies the state of
the art. An actually-good Wikipedia article:

<http://en.wikipedia.org/wiki/Disk_encryption_theory>

The short answer is, "use a well-known full disk encryption product, and don't
worry about cipher modes".

~~~
gnosis
Thanks, but unfortunately that article does not address the issue of errors on
the disk possibly making all the encrypted data un-decryptable.

~~~
tptacek
What's the block cipher mode in which a small series of disk errors makes
_everything_ unencryptable? That doesn't even happen in CBC.

~~~
rbanffy
One could increase the redundancy by further reducing the data density. If all
your data is encrypted twice on two different blocks, the odds a couple failed
blocks renders all the data unreadable should be reduced.

How would this impact the secrecy of the data?

------
phantom784
I think the more practical use of this would be to still allow your normal
password and only use your one time passwords when you're on a public computer
you don't trust to not have a keylogger.

