Quoting Benjamin Lutz <[email protected]> (from Thu, 12 Feb 2009
11:13:58 +0100):
Hi Alexander,
Sorry for the delay, an illness is making its rounds here and I got hit too...
On Thursday 12 February 2009 10:41:19 Alexander Leidinger wrote:
- Implement something which is similar o freeauth.org, just better
implemented and without the "not so good" stuff / design decissions.
Short: they need something you know (PIN) + something you have (e.g.
token, or mobile phone with java with some fixed key). You then enter
your arbitrary long PIN into the phone, and it will give you a time
limited key to login (so the time needs to be in sync to some extend).
On the machine you login you need the cleartext version of your PIN,
the fixed key, and ideally it saves the the PW you just used to login
to prevent a relogin with the same PW. If you've seen the remote login
tokens from RSA or similar, then you should get the idea what this is
about.
I've stumbled accross freeauth.org while researching the subject. The reason
I didn't consider it is because so far I've been just printing out my otps,
and that's no longer possible with freeauth.org. And there are situations
where I can't run a Java program on my phone, for example when I'm using
the phone as a bluetooth modem.
Nothing prevents you to write a program in C, perl, or whatever. This
way you can generate the PW on the system where you use the blutooth
modem (in case it is trusted).
I'm not saying that time-based pws wouldn't be nice to have, it just goes in
a different direction than OPIE, so it's not what I'm looking for at the
moment. Also, the thought of having to write programs in J2ME again
horrifies me :)
I wrote down a while ago the algorithm somewhere (based upon my own
thoughts how to do it, this was before I've seen freeauth, so it's
independent), and also thought about the bells and whistles (some
security pitfalls you need to think about). If you are interested in
implementing this (ideally with a BSD license for inclusion into the
base system)
While I most probably won't implement freeauth.org, I'd still like to see
your notes; the security pitfalls you considered are likely there for other
algorithms too.
The notes are in the direction of notifying the user if the PIN can
hit non-volatile storage, or that the storage area of the PIN needs to
0ed in-place after use to prevent it to appear in (provoked) crash
dumps or just plain reading from memory. There are also notes about
the valid character set (there should be no NUL byte or newline, but
apart from that there should be not much restrictions (depends upon
the device you use to enter the PIN)), that the device which prints
out the PW should also have an indication for the lifetime of the PW,
that the server should save the valid PWs of the current valid
timeframe to prevent multiple logins with the same PW (also serves as
an indicator that someone spied out the PW in case you enter the PW
correctly and the timeframe is OK too).
The algorithm itself is not 100% finished yet. The generic part is
done, but I haven't finished the details (important here is the format
of the date which is passed to the hash function, which hash funtion
to use, how long the PW can be (truncation of the hash and the
corresponding security implications... also in the light of user
convenience)). If someone really wants to put some amount of time/work
into this, I can put it up on the FreeBSD wiki and hand out
contributor access to it, but just to satisfy the curiosity of people,
I'm not interested to invest the necessary time to polish it and put
it up on the wiki.
Bye,
Alexander.
--
A sect or party is an elegant incognito devised to save a man from
the vexation of thinking.
-- Ralph Waldo Emerson, Journals, 1831
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[email protected]"
