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.