4 ms·

As old as good: One Time Passwords

15 points by gnosis 17y ago

gnosis 17y ago
Also see OTPW: http://www.cl.cam.ac.uk/~mgk25/otpw.html 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 17y ago
  And also see these credit-card-sized hardware OTP solutions: http://www.schneier.com/blog/archives/2008/12/credit_card_wit.html http://www.schneier.com/blog/archives/2008/12/credit_card_wi... http://www.dailymail.co.uk/sciencetech/article-1085642/The-new-credit-card-keypad-promises-fight-online-fraud.html?ITO=1490 http://www.dailymail.co.uk/sciencetech/article-1085642/The-n... http://www.emue.com/site/home.htm http://www.emue.com/site/home.htm
drinian 17y ago
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 17y ago
  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 17y ago
    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.
    - gnosis 17y ago
      That's good to know. I'll have to look in to that. Thanks.
    - tptacek 17y ago
      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 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 17y ago
        Thanks, but unfortunately that article does not address the issue of errors on the disk possibly making all the encrypted data un-decryptable.
        tptacek 17y ago
        What's the block cipher mode in which a small series of disk errors makes everything unencryptable? That doesn't even happen in CBC.
        17y ago
phantom784 17y ago
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.
- deleted 17y ago
  [deleted]
Titanous 17y ago
Another (shorter length) OTP implementation: Perfect Paper Passwords: https://www.grc.com/ppp 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 http://gist.github.com/74551
nas 17y ago
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-approaches-to-computer-security.html http://theinvisiblethings.blogspot.com/2008/09/three-approac...). 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 17y ago
  "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).

15 points by gnosis 17y ago

Also see OTPW: http://www.cl.cam.ac.uk/~mgk25/otpw.html 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 17y ago
And also see these credit-card-sized hardware OTP solutions: http://www.schneier.com/blog/archives/2008/12/credit_card_wit.html http://www.schneier.com/blog/archives/2008/12/credit_card_wi... http://www.dailymail.co.uk/sciencetech/article-1085642/The-new-credit-card-keypad-promises-fight-online-fraud.html?ITO=1490 http://www.dailymail.co.uk/sciencetech/article-1085642/The-n... http://www.emue.com/site/home.htm http://www.emue.com/site/home.htm

drinian 17y ago

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 17y ago
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 17y ago
  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.
  - gnosis 17y ago
    That's good to know. I'll have to look in to that. Thanks.
  - tptacek 17y ago
    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 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 17y ago
      Thanks, but unfortunately that article does not address the issue of errors on the disk possibly making all the encrypted data un-decryptable.
      - tptacek 17y ago
        What's the block cipher mode in which a small series of disk errors makes everything unencryptable? That doesn't even happen in CBC.
        17y ago

phantom784 17y ago

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.

deleted 17y ago
[deleted]

Titanous 17y ago

Another (shorter length) OTP implementation: Perfect Paper Passwords: https://www.grc.com/ppp 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 http://gist.github.com/74551

nas 17y ago

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-approaches-to-computer-security.html http://theinvisiblethings.blogspot.com/2008/09/three-approac...). 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 17y ago
"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).