Updates to the design of Veerless

In some previous posts [1],[2],[3] I discussed how bi-directional 2FA might happen and what the value of it is with regards to phishing, specifically the credential theft variety.

Since then I’ve worked on a reference implementation of this scheme called Veerless (code is at https://github.com/joekir/veerless)

1st iteration

So that I could demo what the mechanism was I thought the flow could be:


2nd iteration

Some feedback I had from a few friends was that I could use HTTP headers instead. While I could see that this would be an improvement, for some reason I thought knowing when the exchange was to occur would have many edge cases. It turns out that it was ok.

Thanks to @vkm514 for helping me refine this!

So now the demo, as it is currently at veerless.josephkirwin.com works as follows:


these are evolving the more refined the solution becomes

Future Work

The problem I thought of with client side credential management

The user needs to know which otp to use for the given server, in our example we only use the demo site so its not a problem. But if you have many otps, you don’t want to have to check them all for a match each time.

You do not want to index with the username as thats mostly the same across sites and you don’t want to index using dns as this whole design is supposed to avoid that specific dependency. So what do you index the otp’s with?

My proposed solution.

So recall from Serverside One-Time-Pad (Part2) we had the HOTP stuff, well its actually using TOTP for the implementation, but that is not the key takeaway here. So the equation is

A couple of key HMAC properties that make this great in comparison to a hash

  1. Knowing the message part of a HMAC doesn’t (or shouldn’t if its a well selected HMAC) allow you to create an existential forgery.
  2. Upon truncation HMAC is much more resilient to collisions in the same keyspace then a hash algorithm is, which is of course an un-keyed function. This is how TOTP and HOTP are relatively secure under truncation, but a SHA family hash alone may not be.

So based on these 2 concepts, we can add another X-Header into the protocol.
Called X-Veerless-Seed that contains the t0 value to compute the time step for the HMAC. The likelihood of a user creating 2 usernames at the same time would be quite rare, and this edge case could be handled via client-side rejection of t0 at the registration step with the server.

With this header in place, the client can use X-Veerless-Seed as an index into their table of available otps.

t0 username serverSecret
1234567 joe abcd135256
8901234 cool75 36cdef0561

Check out the demo at veerless.josephkirwin.com and please give me some feedback in the comments!