forked from sbalukoff/yubiauthd
-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathTODO
14 lines (9 loc) · 3.09 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
This file contains feature requests that will be added to later versions of this project.
`yubiadmin utility`
This should be a utility for creating and destroying identities on the local server, which should work in conjunction with yubiauthd to automatically push identity creationg / destruction out to other servers in the yubiauthd network. It should work regardless of what kind of identity store is being used. (Meaning that both the identity storage models and yubiauthd API for communicating with other hosts will be affected by the addition of this feature.)
`deleted identity`
Related to the above, we need to have a way to make it clear when a given identity should no longer be used (eg. in the case of a lost or stolen yubikey). Rather that delete this identity entirely from the database (which leads to an annoying headache when it comes to idempotent synchronization of databases), I propose we set the counter value to -1, and augment the code to recognize this specific value as meaning "NOT VALID". If a given yubiauthd gets a message specifying "-1" as the counter value for a given identity, this should override any previously valid counter (ie. "-1" is "greater than" any other counter value by our definition).
`new host population`
Building off of the above, when a new host gets added to a yubiauthd network, we need to have a mechanism whereby the new host gets automatically populated with all the identities currently in use on the network. Presently, for the SQLite store, this can be done by SCPing the sqlite database from an existing host to the new host, though this seems clunky and simple to overlook for an administrator. Whether via a query (ie. new hosts request identities from existing hosts in the network), or via push (ie. yubiadmin command to push all identity information to another specific host in the network), it seems this is a problem we can and should solve within the confines of yubiauthd's messaging system.
`state summary (make system more robust against replay attack)`
All the hosts in a yubiauthd network should automatically and quickly recover from the out-of-synch scenario where a given host is isolated from the rest for an indefinite period of time (ie. due to server being down, network path problems, or isolation caused by a DOS attack of some kind). To solve this problem, have a mechanism whereby a 'state summary' is generated on the current aggregate state of the counters on all identities on the local host. (A simple md5 or sha1 sum or something ought to do.) Servers in the yubiauthd network can (and should regularly) send their state summary to all other servers in the yubiauthd network. If a server receives a state summary that differs from theirs, request a counter update for all identities on the remote server (though we might want to rethink how to perform resynchronization as this "resynchronize everything" process won't scale well). If any of the identities reported don't exist locally, request the identity details from the remote server. Note that this feature could also automatically solve the 'new host population' problem mentioned in the previous feature.