The story of event logging begins at sea and is related to navigation. One of the important aspects of navigation is dead reckoning: estimating your current position based on course, speed and time from a known, observed point. In the end of 15th century, speed at sea was measured with a small wooden log. A so-called ‘Dutchman’s Log’ was dropped overboard from the bow of the ship and the navigator measured the time elapsing before it passed the stern.
The technique evolved to a chip log attached to a light line which was connected the stern. As the ship moved away from the log, the length of line paid out during the emptying of a sandglass was the measure of the speed. Knots were tied to the string to increase the accuracy of measuring: the navigator counted the knots and calculated the speed from that.
Fun fact: today, sailors and aircraft pilots still express speed in knots, so in a way it all is related to event logging.
The readings from the log tossing and speed were written down to the ships logbook which could be considered as a first occurence of so called event logs. Later on, captains started marking down all other events to the logbook that were occurring on the ship: the ports the ship had visited, routine events, crew behaviour, significant incidents, weather conditions, whales encountered, other ships and other interesting stuff they noticed. Thus making the log book a pretty exhaustive source of information.
There was no reason to keep those books in the ship after they filled up, so they were archived in the docks. For example, the US ships kept their archived logbooks in the United States Navy office in Washington. As usually, logs were gathered but no-one really gave any attention to them. At least they weren’t “rotated” or “overwritten” if you get my drift.
It was until the late 1830’s when the collected and archived log files started to give some additional value besides being just historical notes in archives. Due to an accident, Matthew Fontaine Maury became a librarian of the many unorganized ship logbooks. He started to organize and analyze thousands of old ship logs and charts in order to collect information about the winds, calms, currents for all seas in all seasons and other observations in the logs, e.g. the migration of whales that have been spotted from the ships.
Maury’s work on ocean currents led him to a theory of the Northwest Passage and the hypothesis that an area in the ocean near the North Pole is occasionally free of ice. His theory was based on the old whaler ships logs which indicated the designs and markings of harpoons in whales. Harpoons found in captured whales in the Atlantic had been shot by ships in the Pacific and vice versa at a frequency that would have been impossible if the whales had traveled around Cape Horn.
Thanks to the analysed data he was able to prove his theory and showed how using the ocean’s currents and winds drastically reduce the length of ocean voyages. In other words — Maury’s work on old logs can be considered as a first occurrence of an actual log analysis to gain benefit from log books.
Fun fact: Maury’s work prepared a profile of the Atlantic seabed, which proved the feasibility of laying a transatlantic telegraph cable so in a way — log analysis helped to connect the two continent with electronic data exchange.
But anyway, back to the logbook. The term has spread to a wide variety of other usages. They were used to mark down people when they were entering or leaving the premises or certain rooms and to “clock in” when arriving to work, thus creating a log event (an entry to the logbook).
In computer science, the terms became common with the time sharing systems of the 1960s. The noun ‘login’ comes from the verb ‘(to) log in’, and with the analogy of the verb ‘to clock in’. Computer systems keep a log of users’ access to the system. ‘To sign in’ connotes the same idea, but is based on the analogy of manually signing a log or visitors’ book.
In computer security, logging in is the process by which an individual gains access to a computer system by identifying and authenticating themselves. A proper login log event should contain enough information to understand how the login process was executed and not to include information that could compromise the users’ account or session (e.g. passwords, private keys or session id-s should not be logged). The reasoning for that is quite simple: log files might get into the wrong hands thus they shouldn’t give away more information then necessary.
From a proper authentication log event you should find answers to the following questions: who, when, where, whence, what and how. You want to have the username that was used to authenticate (who), proper timestamp of the event (when), the system identifier where the user tried to log in (where), IP address or the terminal name of the device that was used to initiate the login process (whence), the fact that it was a login event (what) and device or method that was used to login e.g. password or smart-card (how). Additionally you might want to log down the result of the event (success, failure or an attempt) and additional system-specific information (user-agent, hashed session ID-s or cookies, password length or a public key serial number that was used etc that you might find relevant for later analysis).
Unfortunately due to poor logging quality there are often situations where user events (including identifying process) are not logged. Which brings us to the irony: if you don’t log your login process then aren’t you kind of fighting the whole concept of “login”. So when designing Your next information system, please be sure to at least log Your authentication process correctly.