@mogactually

  • Google is slowly phasing out google talk. google talk client on android is no more. So much for federated and open instant messaging... Fri May 17 @ 7:13 PM
Mar 192013
 

3 Years ago I worked for a client who made use of the RSA Securid system. I was amazed by it. It seemed to add so much security to the systems I was accessing with it. I even liked watching the numbers turn over on the token feeling like a spy. I looked into setting it up for my own personal servers, and I was disappointed when I found out it was financially restrictive. It also frustrated me that I could not maintain the shared secret myself. Letting RSA authenticate my personal laptop was not going to work for me. Especially when it was disconnected from the internet.

I began to look into other two factor authentication solutions that where free software. And I found a few, Perfect Paper Passwords, being one of the more complete solutions. But carrying a sheet and updating it constantly was not a security token. So I began trying to figure out how the RSA tokens worked. I came up with a way of hashing and rehashing a secret on an arduino and then verifying it on my laptop.

/wp-content/uploads/2013/03/wpid-7disp_token1.jpg

It worked great, but not a real solution as an arduino isn’t battery powered or sits comfortably in your pocket. Tim Heath and I started work on the hardware design two years ago. Neither of us had any experience in electronics so it was pretty surprising when our first board functioned.

/wp-content/uploads/2013/03/wpid-pig_rev0.jpg

In between a few of our prototypes Google Authenticator was published. From that I found out about this rfc4226. It made me feel stupid that I had implemented this part of the protocol from scratch. But happy that it matched an IETF standard.

Below is a prototype of our current working design.

/wp-content/uploads/2013/03/wpid-pig_breadboard.jpg

It led to the building of this

/wp-content/uploads/2013/03/wpid-pig_prototype.jpg

Dustin Clark has also built pig client token code for android

/wp-content/uploads/2013/03/wpid-pig_android.png

and iphone

/wp-content/uploads/2013/03/wpid-pig_iphone.jpg

pdf describing the protocol in full in this white paper

Feb 082011
 

Lately I have been working on a second factor for authentication schemes. Pig, which stands for pig is genuine. It works as such.
Alice has a shared 256 byte secret, she has a hardware or software token that takes this secret and uses it as the initialization vector for hmac-sha256. the implementation then plugs in the time rounded to 60 second intervals to produce a 32 byte hash. This is far too much for Alice to type in a reasonable period of time or to be practical. So we take this 32 byte hash and rehash with an npv-1 hash to take it to 3 bytes. We represent these 3 bytes in hex to Alice. “86753F” for example would be generated.
Alice then inputs this hash into a pig aware application, pam, gina, securityauthorization plugin, openvpn, etc. The pig plugin will take the Alice’s username and associate it with her pig uuid. The plugin then transmits alice’s uuid and 3 byte hash to Bob.
Bob is a central pig authorization server. It takes the uuid to look up Alice’s shared secret. If Alice has not authenticated in the current window, Bob takes Alice’s hash and sees if it matches with in the time window. Bob responds with authenticated or failure. This message is signed via dsa with the uuid and hash. The plugin server has the public key to verify that the central pig server has actually verified or failed the login attempt, this is done to avoid any man in the middle attacks.

I am curious if anyone sees a problem in this approach. It seems that there is no verification between the token and the pig plugin, but if the plugin isnt trusted the machine being used probably shouldn’t be either.