Web Interface

[kevinjos]

The screen resolution and keypad of the dial pad make adding contact information challenging. Current usage dictates this information is needed for a key that does not expire. This limits the ability of users to adding new keys with a 30 day expirey from the dial interface.

I am working on the web interface to earl, piggybacking on the HTTP APIServer, to allow users to add keys that do not expire. I forget exactly the flow discussed. This is what I have so far where User A is granting User B fulltimeuser privilage...

1. User A scans key to aquire onetime pass.
2. User A GETs earl's access page and POSTs onetime pass + user type + User B's contact information.
3. Dial pad key reader upstairs&inside listens for User B's key.
4. HTTP server responds with the status of the transaction (success/failure).

See https://github.com/kevinjos/rfid-access-control/tree/WebUI for details.

[hzeller]

Something like that should work. Though there is a race condition after the POST and whoever randomly happens to swipe the key.

Maybe we can do something (even a little simpler) to what we already do when updating a user to extend the 30 days, because then we can do it with the one-pass solution and it might be simple to implement: Current workflow:

1) Member A swipes key, gets choice of [1] add user [2] update user 2) Chooses [2] and swipes User B's key. User extended for another 30 days.

Now we can just add a little change here 1) ... as usual. 2) Chooses [2] and swipes User B's key. User extended for another 30 days. A onetime password is shown to set the user-name. That one-time is valid for a couple of minutes. 3) a Web-browser accepts that one-time password and the information to be updated for that user.

So, in step 2 we just do the same as before, but just emit the additional one-time password. No race-conditions (as it is generated at the time the User A and User B interaction happens at the terminal). And possibly the simplest to implement as well.

[kevinjos]

Sounds good. Do you see any problem with mapping the one-time password to the user when the upgrade choice is made? This would save the trouble of having to reenter the user id in the browser.

[hzeller]

I think that is the perfect solution - the one-time-password pre-configured for that particular user.

As far as one-time password generation goes, we should make it memorable. Also, we probably don't need too many bits, as this is only valid for a couple of minutes.

Say we have a list of 256 most common English nouns and 256 most common English Verbs, we can make a 24-bit strong random password Dog whistles cardboard. Church jumps shark. Bulldozer sees poem. ... whatever :) Point is, that it is easy to remember on the way back from the door to your laptop (easier than X72Yt6).

(additional constraint: the sum of any three words should not be longer than what we can display)

( https://xkpasswd.net/s/ )

[hzeller]

Any progress on this ?

[kevinjos]

The basic structure is in place, tests are needed. Please see the branch for details and review.

[hzeller]

Cool! I'll have a look this evening. Are you at NB tonight, maybe I stop by there ?