gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim Busser
Subject: Re: [Gnumed-devel] Hosting an encrypted pythonic simplehttp GNUmed server
Date: Sun, 01 Aug 2010 17:55:29 -0700

On 2010-08-01, at 2:39 PM, Luke Kenneth Casson Leighton wrote:

> normally it would be assumed that people are not knowledgeable enough
> to set up their own yubico server, so you "trust" yubico.com,

>  and they of course
> expect you to pay money for that service.

This thread still is (also) discussing authentication...

With a yubico key, you get to call upon their validation server at no charge, 
and you bypass the problem of other smart cards, wherein your remote users 
would have to be carrying around the smart card readers (like that would 
happen!).

From "Security Now": http://www.grc.com/sn/sn-143.htm ... way down the page

The key outputs 44 characters, of which:

- it contains a write-only 128-bit AES secret key, you cannot get it to tell 
you its key

- when you press its button, it spits out 44 characters:
        - the first 12 uniquely identify the public identity for that key
        - the next are 32 characters (128 bits) outputted by the internal AES 
key
        - ciphered will have been:
                - a two-byte non-volatile session counter
                        - increments at each powerup
                - three-byte, 8 Hz (8 per second), 24-day wrap-around time-stamp
                        - always starts at 0 when you plug in
                - session use byte
                - pseudorandom data
                - CRC

- it draws on USB power, not internal power, and will not exhaust its 
generation capacity until usage on the order of 10 pplug-ins per day (unlimited 
generations per plug in) for 9 years.

Even if someone would gain the Yubico company copy of the AES key for the 
Yubikey that you own, they would either

1) also need to somehow redirect the server that is requesting authentication, 
so that the answer that the server gets back is spoofed, so that the evildoers 
who desire to connect do not even *need* to have a Yubikey, they can inject a 
phony 44 characters and say "yep, this person is authenticated", but they do 
not even need the AES key nor even the Yubikey (maybe just its public key, if 
registered by the requesting service)

2) try to impersonate the Yubikey... but they can only gain --- through breach 
of the Yubico database --- the public id of the key and its AES key, they 
cannot gain control of the actual Yubikey internal session counter nor its 
time-stamp. So even if Yubico stored, in its database, whatever had been the 
last value of the session counter and time stamp and session use byte at the 
time that the database had been cracked, these hackers would need ongoing 
real-time access to the Yubico database which they would have to read and then 
(before the user next used their key or removed and reused their key) try to 
pretend to be the user. Sure, possible, but IMO thin, no? 

So I do think it adds something that is
-- *reasonably* inexpensive (one-time $35, down to $25 for each of 10) without 
ongoing cost
-- adding something *reasonably* useful in terms of extra authentication
-- adding something the person can use for other authentication

-- Jim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]