Hi,

I wonder if there is a way (a standard way, that is) to setup
one-time passwords for logging in to a Linux box (through SSH).

Ideally, I should have the same "permanent" password, which I
can use at any point in time, plus a set of passwords that I
can use at any time as well, except that as soon as I used them
they are automatically and immediately invalidated. (it does
allow me the login to proceed, but the password is no longer
valid).

Am I asking too much?

What I want to do: often enough, I have to login to my web
server to update some pages from machines in the College, which
I do not trust (that is, I do not know for sure that those
machines don't have a key logger). If I know that I'm using
a one-time password, I don't care if the machine has been
compromised; I can type the password and I don't care that
someone sniffed it through the keyboard.

Thanks,

Carlos
--

On 2006-04-28, Carlos Moreno <moreno_at_mochima_dot_com@mailinator.com> wrote:

> I wonder if there is a way (a standard way, that is) to setup
> one-time passwords for logging in to a Linux box (through SSH).

Search google on "opie" (one-time passwords in everything) and "S/KEY"

There are PAM modules for these as well.

--

John (john@os2.dhs.org)

John Thompson wrote:

>>I wonder if there is a way (a standard way, that is) to setup
>>one-time passwords for logging in to a Linux box (through SSH).
>
> Search google on "opie" (one-time passwords in everything) and "S/KEY"

Hmmm... The information seems a bit scarce. But still, from one of
the descriptions I read, it seems to be resistant to sniffing attacks,
and not to key loggers. But using SSH -- which I do -- makes me
already impervious to sniffing.

My concern is that I do not trust the keyboard where I'm typing my
password -- that's why I would like the server to have a list of
passwords ready to use, and as soon as one of them is used, it is
immediately removed from that list.

Am I getting it wrong?

Thanks,

Carlos
--

Carlos Moreno wrote:
> John Thompson wrote:
>
>>> I wonder if there is a way (a standard way, that is) to setup
>>> one-time passwords for logging in to a Linux box (through SSH).
>>
>> Search google on "opie" (one-time passwords in everything) and
>> "S/KEY"
>
> Hmmm... The information seems a bit scarce. But still, from one of
> the descriptions I read, it seems to be resistant to sniffing attacks,
> and not to key loggers. But using SSH -- which I do -- makes me
> already impervious to sniffing.
>
> My concern is that I do not trust the keyboard where I'm typing my
> password -- that's why I would like the server to have a list of
> passwords ready to use, and as soon as one of them is used, it is
> immediately removed from that list.
>
> Am I getting it wrong?

Your concern is reasonable. I've used OPIE and its like in the past, for
off-site modem access. It works rather well, although you do need to keep
your printed list of one-time passwords with you.

Carlos Moreno <moreno_at_mochima_dot_com@mailinator.com> writes:

>John Thompson wrote:

>>>I wonder if there is a way (a standard way, that is) to setup
>>>one-time passwords for logging in to a Linux box (through SSH).
>>
>> Search google on "opie" (one-time passwords in everything) and "S/KEY"

>Hmmm... The information seems a bit scarce. But still, from one of
>the descriptions I read, it seems to be resistant to sniffing attacks,
>and not to key loggers. But using SSH -- which I do -- makes me
>already impervious to sniffing.


No, it is also resistant to key loggers.
The key is never reused, so who cares if they got the current key. It will
never again work.

>My concern is that I do not trust the keyboard where I'm typing my
>password -- that's why I would like the server to have a list of
>passwords ready to use, and as soon as one of them is used, it is
>immediately removed from that list.

Precisely what Opie does, it ia more subtle and orgnaized fashion.



>Am I getting it wrong?

You are getting opie wrong.

"Nico Kadel-Garcia" <nkadel@comcast.net> writes:

>Carlos Moreno wrote:
>> John Thompson wrote:
>>
>>>> I wonder if there is a way (a standard way, that is) to setup
>>>> one-time passwords for logging in to a Linux box (through SSH).
>>>
>>> Search google on "opie" (one-time passwords in everything) and
>>> "S/KEY"
>>
>> Hmmm... The information seems a bit scarce. But still, from one of
>> the descriptions I read, it seems to be resistant to sniffing attacks,
>> and not to key loggers. But using SSH -- which I do -- makes me
>> already impervious to sniffing.
>>
>> My concern is that I do not trust the keyboard where I'm typing my
>> password -- that's why I would like the server to have a list of
>> passwords ready to use, and as soon as one of them is used, it is
>> immediately removed from that list.
>>
>> Am I getting it wrong?

>Your concern is reasonable. I've used OPIE and its like in the past, for
>off-site modem access. It works rather well, although you do need to keep
>your printed list of one-time passwords with you.

Opie is a one time challenge response system. The challenge is the number,
the response if the password hashed that many times. The next time the
challenge will be one less.

It could be susceptible to active attacks, but not passive. Ie, you log
on, it sends you the challenge. The computer you are on reads your response
but sends a wrong one back. opie then will next time issue the same
challenge, and the active attacker can then replay your correct response.
it would have to know about your opie to do that.

It is done this way to prevent attacks which comprimise your server, so
that your password (or its equivalent ) is not stored there. If that is a
lesser danger, then opie on theserver can calculate the next challenge
reponse, and can cancel a response anytime it sends out a challenge, so it
never reuses the challenge. It is a trade off on the dangers to be
protected against. Of course this would open you to denial of service-- and
attacker simply wastes all of the challenges, leaving you with no way to
logging on.

Unruh wrote:

>>Hmmm... The information seems a bit scarce. But still, from one of
>>the descriptions I read, it seems to be resistant to sniffing attacks,
>>and not to key loggers. But using SSH -- which I do -- makes me
>>already impervious to sniffing.
>
> No, it is also resistant to key loggers.
> The key is never reused, so who cares if they got the current key. It will
> never again work.

But the description I read (the way I understood it, at least)
talks about using a program on your machine (the machine from
where you're connecting to the server) that will generate the
response to the given challenge.

But generating the response to the challenge requires typing
in the "master pass phrase" -- someone logging the keystrokes
has now the "magic recipe" to know how to respond to future
challenges.

So, again -- what am I missing or getting wrong?


In my mind, the "ideal" strategy is simply: run a program on
the server, from a trusted box, using a sniff-proof channel
(e.g., via web browser using SSL, from my machine at home);
that program simply draws 50 instances of 128 random bits
(truly random -- e.g., read 16 bytes from /dev/random);
store those on a server-side database, and give them to you
(again, must be over a secure channel to a trusted machine).
Then you print them, and use them. But just that: *use them*
directly. When I'm close to using up the 50 passwords, I
run the program again to generate another 50.

Thanks,

Carlos
--

Carlos Moreno <moreno_at_mochima_dot_com@mailinator.com> writes:

>Unruh wrote:

>>>Hmmm... The information seems a bit scarce. But still, from one of
>>>the descriptions I read, it seems to be resistant to sniffing attacks,
>>>and not to key loggers. But using SSH -- which I do -- makes me
>>>already impervious to sniffing.
>>
>> No, it is also resistant to key loggers.
>> The key is never reused, so who cares if they got the current key. It will
>> never again work.

>But the description I read (the way I understood it, at least)
>talks about using a program on your machine (the machine from
>where you're connecting to the server) that will generate the
>response to the given challenge.

No, there is an alternative-- you type out a list of responses with their
number which you can enter.

>But generating the response to the challenge requires typing
>in the "master pass phrase" -- someone logging the keystrokes
>has now the "magic recipe" to know how to respond to future
>challenges.

If you do it that way. You do not need to.


>So, again -- what am I missing or getting wrong?

Reading futher.



>In my mind, the "ideal" strategy is simply: run a program on
>the server, from a trusted box, using a sniff-proof channel
>(e.g., via web browser using SSL, from my machine at home);
>that program simply draws 50 instances of 128 random bits
>(truly random -- e.g., read 16 bytes from /dev/random);

Very difficult to enter. You will be spending all your time entering them
and reentering them.

>store those on a server-side database, and give them to you
>(again, must be over a secure channel to a trusted machine).

sensitive to server comprimise.

>Then you print them, and use them. But just that: *use them*
>directly. When I'm close to using up the 50 passwords, I
>run the program again to generate another 50.

In many ways that is exactly what opie does.

Carlos Moreno wrote:
> Unruh wrote:
>
> >>Hmmm... The information seems a bit scarce. But still, from one of
> >>the descriptions I read, it seems to be resistant to sniffing attacks,
> >>and not to key loggers. But using SSH -- which I do -- makes me
> >>already impervious to sniffing.
> >
> > No, it is also resistant to key loggers.
> > The key is never reused, so who cares if they got the current key. It will
> > never again work.
>
> But the description I read (the way I understood it, at least)
> talks about using a program on your machine (the machine from
> where you're connecting to the server) that will generate the
> response to the given challenge.
>
> But generating the response to the challenge requires typing
> in the "master pass phrase" -- someone logging the keystrokes
> has now the "magic recipe" to know how to respond to future
> challenges.

I don't think so - because you need 3 different things to gain access
and at least 1 is always changing....more below;

> So, again -- what am I missing or getting wrong?
>
>
> In my mind, the "ideal" strategy is simply: run a program on
> the server, from a trusted box, using a sniff-proof channel
> (e.g., via web browser using SSL, from my machine at home);
> that program simply draws 50 instances of 128 random bits
> (truly random -- e.g., read 16 bytes from /dev/random);
> store those on a server-side database, and give them to you
> (again, must be over a secure channel to a trusted machine).
> Then you print them, and use them. But just that: *use them*
> directly. When I'm close to using up the 50 passwords, I
> run the program again to generate another 50.

Hi;
FWIW - and while older, have you seen;
<http://www.onlamp.com/pub/a/bsd/2003/02/06/FreeBSD_Basics.html?page=2>

More recent ways of securing ssh using some combo of firewalls,
port-knocking, DenyHosts, iptables, keys, no passwd, no UsePAM, etc,
etc...;
<http://geekpit.blogspot.com/2006/04/five-minutes-to-more-secure-ssh.html>