We continue our Password Salt adventures with PBKDF2, in order to store multiple revisions of the crypto parameters, and migrate hashes on the fly.
This morning i enjoyed an article entitled "There Is Ubuntu, There Is Linux And Then There Are Others", and here i rehash my comment there.
This provides a long overdue update to "Password Hash" from the Enigma Prequels (2007), where that article neglected to add salt, which is embarassing for whoever wrote that article... which was unfortunately me.
We present a miniscule Millis utility class for handling intervals, in milliseconds, not least because we record timestamps as per System.currentTimeMillis, i.e the number of milliseconds since the Unix epoch. As such we can skirt around the issue of the time as seen on clocks, with their time zones and calendars and what-not.
The Google Authenticator mobile apps implement an IETF time-based one-time-password standard. This hashes the time, with a shared secret using the HMAC-SHA1 algorithm, to generate a one-time password.
But besides enabling multi-factor authentication for our personal Google account, how would we employ Google Authenticator clients for our own websites?!
Last time we introduced the trivial namesake Timestamped interface, and used the excellent ArrayDeque of Java6 to collect such things, imposing a time-based capacity and some external synchronization. Now let's test this with some threads.
In this here second part of the "Timestamped" series, we introduce its namesake Timestamped interface, and use a Deque from Java6 to collect such things, and impose a time-based capacity for that.
We herewith begin a saga about monitoring with this series entitled "Timestamped: a trilogy in a few parts," this being the first part, where we introduce a map to count key things, and ensure we can order it by its integer values.
I enjoyed reading the Android=Java blog just now, and agree with Osvaldo's sentiments.
So we need to convert objects into XML and back again, eg. to store some data in the database in XML format, because otherwise maybe we just gonna have too many tables and joins and what-not.