headers
Simon Josefsson | 3 Jan 2012 20:03
Favicon
Gravatar

Re: OATH OCRA

Andy Crichton <andy <at> andycrichton.co.uk> writes:

> Hello OATH Toolkiters
>
> I was wondering if there were any plans afoot to add OCRA support to the
> library ? If not I am happy to work on it.

Hi Andy!  I have planned to implement it, but have not started.  Please
see if you can make something work!  It would be great to have some
discussion about what a good API would look like.

/Simon
Permalink | Reply | 1 comment |
headers
Simon Josefsson | 3 Jan 2012 20:05
Favicon
Gravatar

Re: Hashed passwords in /etc/users.oath

Frank Groeneveld <frankgroeneveld <at> gmail.com> writes:

> Hello all,
>
> I'm thinking about switching to HOTP authentication for our company
> servers. However, when using two-factor authentication, the passwords
> is in plain text in /etc/users.oath. Is it possible to used hashed
> passwords there as well?

Hi Frank.  No, it is not possible right now.

Ideally, I think the proper way to do this is to let pam_oath take care
of validating the OATH OTP part only, and let another PAM module take
care of validating the password.  I'm just waiting for someone to ask
about storing passwords in LDAP....  that would also ideally best be
taken care of by another PAM module and some fancy PAM configuration.

If someone has any ideas on how this would work, please share them.

/Simon
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 3 Jan 2012 21:18
Favicon
Gravatar

OATH Toolkit 1.10.5

I realized we had some fixes that have been waiting for way to long for
a release, so here it is (finally).

Happy hacking,
Simon

* Version 1.10.5 (released 2012-01-03)

** Build fixes.
From Linus Nordberg <linus <at> nordberg.se> and Arno Hautala
<arno <at> alum.wpi.edu>.

** Update gnulib files.

The OATH Toolkit makes it easy to build one-time password
authentication systems.  It contains a shared library, a command line
tool and a PAM module.  Supported technologies include the event-based
HOTP algorithm (RFC4226) and the time-based TOTP algorithm (RFC6238).
OATH stands for Open AuTHentication, which is the organization that
specify the algorithms.

The components included in the package is:

  * liboath: A shared and static C library for OATH handling.

  * oathtool: A command line tool for generating and validating OTPs.

  * pam_oath: A PAM module for pluggable login authentication for OATH.

The project's web page is available at:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Debian FTP Masters | 3 Jan 2012 21:47
Picon
Favicon

Processing of oath-toolkit_1.10.5-1_amd64.changes

oath-toolkit_1.10.5-1_amd64.changes uploaded successfully to localhost
along with the files:
  oath-toolkit_1.10.5-1.dsc
  oath-toolkit_1.10.5.orig.tar.gz
  oath-toolkit_1.10.5-1.debian.tar.gz
  liboath-dev_1.10.5-1_amd64.deb
  liboath0_1.10.5-1_amd64.deb
  oathtool_1.10.5-1_amd64.deb
  oath-dbg_1.10.5-1_amd64.deb
  libpam-oath_1.10.5-1_amd64.deb

Greetings,

	Your Debian queue daemon (running on host franck.debian.org)
Permalink | Reply | 0 comments |
headers
Debian FTP Masters | 3 Jan 2012 22:06
Picon
Favicon

oath-toolkit_1.10.5-1_amd64.changes ACCEPTED into unstable


Accepted:
liboath-dev_1.10.5-1_amd64.deb
  to main/o/oath-toolkit/liboath-dev_1.10.5-1_amd64.deb
liboath0_1.10.5-1_amd64.deb
  to main/o/oath-toolkit/liboath0_1.10.5-1_amd64.deb
libpam-oath_1.10.5-1_amd64.deb
  to main/o/oath-toolkit/libpam-oath_1.10.5-1_amd64.deb
oath-dbg_1.10.5-1_amd64.deb
  to main/o/oath-toolkit/oath-dbg_1.10.5-1_amd64.deb
oath-toolkit_1.10.5-1.debian.tar.gz
  to main/o/oath-toolkit/oath-toolkit_1.10.5-1.debian.tar.gz
oath-toolkit_1.10.5-1.dsc
  to main/o/oath-toolkit/oath-toolkit_1.10.5-1.dsc
oath-toolkit_1.10.5.orig.tar.gz
  to main/o/oath-toolkit/oath-toolkit_1.10.5.orig.tar.gz
oathtool_1.10.5-1_amd64.deb
  to main/o/oath-toolkit/oathtool_1.10.5-1_amd64.deb

Override entries for your package:
liboath-dev_1.10.5-1_amd64.deb - optional libdevel
liboath0_1.10.5-1_amd64.deb - optional libs
libpam-oath_1.10.5-1_amd64.deb - optional admin
oath-dbg_1.10.5-1_amd64.deb - extra debug
oath-toolkit_1.10.5-1.dsc - source devel
oathtool_1.10.5-1_amd64.deb - optional devel

Announcing to debian-devel-changes <at> lists.debian.org

Thank you for your contribution to Debian.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Debian testing watch | 14 Jan 2012 17:39
Picon
Favicon

oath-toolkit 1.10.5-1 MIGRATED to testing

FYI: The status of the oath-toolkit source package
in Debian's testing distribution has changed.

  Previous version: 1.10.4-1
  Current version:  1.10.5-1

--

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See http://release.debian.org/testing-watch/ for more information.
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 26 Jan 2012 10:52
Favicon
Gravatar

Re: OATH OCRA

Simon Josefsson <simon <at> josefsson.org> writes:

> Andy Crichton <andy <at> andycrichton.co.uk> writes:
>
>> Hello OATH Toolkiters
>>
>> I was wondering if there were any plans afoot to add OCRA support to the
>> library ? If not I am happy to work on it.
>
> Hi Andy!  I have planned to implement it, but have not started.  Please
> see if you can make something work!  It would be great to have some
> discussion about what a good API would look like.

Hi again Andy.  Have you made any progress here?  I'd be happy to help
you if I can.  If commit access would help, so that you can work on a
branch to implement this, that is no problem.

Of course, this offer is open to everyone who would like to work on OCRA
or anything else (OATH related) -- PSKC support would be nice. :-)

/Simon
Permalink | Reply | 0 comments |
headers
Martin Radford | 26 Jan 2012 11:17
Picon
Picon
Favicon

oathtool should not require secret key on command line


Hi,

I've just been looking at the toolkit, and so far everything is working
as expected.

However, as far as I can see, the only way to provide the secret key to
oathtool is to put it on the command line.

This strikes me as being unsafe -- on a multi-user system, the secret
key will show up in the output of the "ps" command, and hence could be
unintentionally exposed.

oathtool really needs to support a command-line option to allow the
secret to be read from a file (e.g. "-f secretkey.txt") or even from a
file descriptor (as gnupg does with its "--passphrase-fd" option).

Martin
--

-- 
Martin Radford  (Martin.Radford <at> bristol.ac.uk)
Systems and Operations Team
IT Services
University of Bristol
PGP keyID:       5D2D92E9
PGP fingerprint: 137E 0277 9D78 7447 71D0 BB3D C20D BB9A 5D2D 92E9
Permalink | Reply | 1 comment |
headers
Simon Josefsson | 26 Jan 2012 15:48
Favicon
Gravatar

Re: oathtool should not require secret key on command line

Martin Radford <Martin.Radford <at> bristol.ac.uk> writes:

> Hi,
>
> I've just been looking at the toolkit, and so far everything is working
> as expected.
>
> However, as far as I can see, the only way to provide the secret key to
> oathtool is to put it on the command line.
>
> This strikes me as being unsafe -- on a multi-user system, the secret
> key will show up in the output of the "ps" command, and hence could be
> unintentionally exposed.
>
> oathtool really needs to support a command-line option to allow the
> secret to be read from a file (e.g. "-f secretkey.txt") or even from a
> file descriptor (as gnupg does with its "--passphrase-fd" option).

Hello Martin and welcome to the list.  Good point.  Oathtool was mostly
intended as a debugging tool, but I can see that you could want to use
it in scripts and then this property is quite worrying.

The tool could be modified to read the key from standard input if the
KEY parameter is '-'.  That is not a valid hex character, so there is no
ambuiguity.  There could be command line parameters to make it read from
a file or from a file descriptor instead of from stdin.  What do you
think?

Thanks,
/Simon
(Continue reading)

Permalink | Reply | 0 comments |

Gmane