Re: [Gnumed-devel] Hosting an encrypted pythonic simplehttp GNUmed server

[Luke Kenneth Casson Leighton]

On Sun, Aug 1, 2010 at 9:28 PM, Jim Busser <address@hidden> wrote:
> On 2010-08-01, at 12:41 PM, Luke Kenneth Casson Leighton wrote:
>
>> it
>> may actually be the case that a yucibo server isn't actually needed
>> when you use the yubico PAM plugin: i didn't look that closely enough
>> to find out.  it may be the case that you actually want *separate*
>> machines for the gnumed server and the yubico server (if in fact a
>> yubico server is needed at all) and two would neatly solve the problem
>> of having a truly dreadful postgresql configuration
>
> I began to use a very useful (and thus far well-evaluated) tool
>
>        LastPass.com
>
> which has a partnership with Yubico as a result of which I have 2 Yubico keys 
> (each licensed), this was $CAN 45 + 5 shipping and included an upgrade of 
> LastPass from free to premium.
>
> The passwords generated by my Yubico keys are authenticated by Yubico's 
> servers
>
>        http://yubico.com/developers/intro/
>
> and using my Yubikey I can authenticate from a machine that I do not own 
> (e.g. hospital) into my LastPass or Clavid.com account

 ... ok, now i will want to be looking at the yubico protocol a
leeetle more closely, to reassure myself that there's no way that it
can be spoofed.

> (note: I stil do not yet put my banking or credit information into LastPass) 
> but anyway I would hope that a yubico PAM plugin could allow the user's 
> Yubikey to be verified by a suitable external Yubikey validation server (even 
> Yubico's)

 ok.  rrright.

 so this of course assumes that yubico's server or lastpass's server
or clavid.com's has not been compromised, or that the yubico protocol
is sufficiently robust such that the key itself or the intermediate
service (the pam plugin) can detect interference.

 normally it would be assumed that people are not knowledgeable enough
to set up their own yubico server, so you "trust" yubico.com,
lasspass.com, clavid.com, etc. to do a decent job.  and they of course
expect you to pay money for that service.

 so, jim, that's entirely your decision.  here's something interesting
that may help you not have to shell out money or enter any credit card
details:

$ apt-cache search yubico
libyubikey-dev - Yubikey OTP library development files
libyubikey0 - Yubikey OTP handling library runtime
libykclient-dev - Yubikey client library development files
libykclient3 - Yubikey client library runtime
yubikey-server-c - Yubikey validation server

oh look - a yubikey server, written in c!

$ apt-cache show yubikey-server-c
Package: yubikey-server-c
Installed-Size: 96 kbytes
Size: 13050 bytes
Description: Yubikey validation server
 Yubikeys are USB tokens that act like keyboards and generate one-time
 passwords.  The tokens are produced and sold by Yubico
 .
 This is a server that checks the validity of those OTP tokens.  There
 are servers written in Java and PHP, while this one is written in C
 .
 It implements the server side of the API as described on
 http://www.yubico.com/developers/api/ and can be used with any client
 that implements the same API.


ohhh loook, when installed, it's 96 kbytes (i assume) and has one
other major dependency (libyubikey0) which is shock-horror all of 64
kbytes when installed!

 now compare that to the php5 dependencies or the java dependencies,
which are several orders of magnitude larger... java is a whopping
100mb download - _four_ orders of magnitude larger; php5-common is 728
kbytes - one order of magnitude larger...

 first instincts say that "apt-get install yubikey-server-c" would be
a good way to go? :)

 wait.... HTTPS.  are _any_ of these server implementations using
HTTPS?  ahh.. yubikey-server-c mmm.... no.

 ARGH - yubikey-server-c one of the dependencies is libpq5 - postgresql :)


 looking further at pam-yubico, that's even weirder (but adaptable).
it's set up to do local authentication or use.... LDAP!!  *shudder*.
ok, so no HTTPS, then (but that's fairly easily fixed with the right
c-library).  it _has_ to be installed on a unix (PAM-capable)
workstation - on the *actual* user's workstation: thus, anyone using a
windows PC or a windows laptop is history.

 so.... let's see: yubikey-server-c can be placed behind an
HTTPS-to-HTTP Apache Proxy.  i _really_ don't like the idea of
yubikey-server-c using postgresql - what the hell's it for??

 ok let's take a look at e.g. the python-yubikey server
implementation, see if that's any better
http://code.google.com/p/yubikey-python/

 wtf, it's using AES, storing unprotected AES keys directly in an
unprotected database??  ok, that must be what's also used by the
yubikey-server-c, what yubikey-server-c needs postgresql for, yep...
it does...

 ok... i'm rapidly beginning to get concerned about the use of AES and
the fact that the implementations - both the python server one and the
c-based one - store the secret key unprotected in a SQL database.
that can't be good.


 jim - there has to be a better system than this - one that uses
Diffie Hellman, RSA or DSA or other public-key encryption.  there are
_really_ good reasons why you don't use symmetric key algorithms as
the basis for authentication: you still need to privately exchange an
unsniffable secret key.

 ok - let's take a look at that article you sent me.  oh fer fuck's sake.

"    Using a symmetric algorithm has the
advantage that it is typically very fast.
Also, you don't need to rely on third
parties for key management or to vouch
for identities."

 horse-shit.  absolute horse-shit.  you only have third parties for
key management if you "outsource" the key management to a third party.
 utter horse-shit.

"    If you want to be in charge of your
own AES key, you have two options.
First, you can request your AES key from
Yubico. At the time of this writing,
Yubico will send you a CD containing
the AES key"

 *ah hahahahahahahahh* sorry, i nearly laughed.  they send you the
key... in the post????  in cleartext????   which means that they've
actually been _storing_ the AES keys in an easy-to-retrieve format.

" but the company also is
working on a more convenient solution
of retrieving the key on-line."

  oh that's so much better.  i feel much happier, now.

 jim - whatever you do, don't use yubikey.  the point of failure is
the AES key, which once that's been compromised, you're toast.

 there are RSA dongles around which would be an infinitely better idea.

l.