The latest NIST (United States National Institute for Standards and Technology) guidelines on password policies recommend a minimum of 8 characters. Perhaps more interesting is what they recommend against. They recommend against allowing password hints, requiring the password to contain certain characters (like numeric digits or upper-case characters), using knowledge-based authentication (e.g., what is your mother's maiden name?), using SMS (Short Message Service) for two-factor authentication, or expiring passwords after some amount of time. They also provide recommendations on how password data should be stored.
[Ed. Note: Contrary to common practice, I would advocate reading the entire linked article so we can have an informed discussion on the many recommendations in the proposal. What has been your experience with password policies? Do the recommendations rectify problems you have seen? Is it reasonable to expect average users to follow the recommendations? What have they left out?]
(Score: 2) by Scruffy Beard 2 on Saturday August 20 2016, @05:46AM
umm, GPS time is not secret; at least on human time-scales.
(Score: 0) by Anonymous Coward on Saturday August 20 2016, @01:21PM
yes, GPS time is not secret. it is even predictably changing.
however, numbers are no secret. also letters are no secret.
for your regular passwords paradigm to work, one has to agree on a set of symbols, like {1,2,3..} and/or {A,a,B,b,C,c,...}.
so it is the combo of these symbols (characters) that's the secret.
this GPS time thingy suggested isn't a password replacement but rather a simple version on how to do 2 factor authentication, instead of using SMS or another email address?
example:
the GPS time is running on server. the GPS time is running on client.
on first setup (preferably via prime numbers public-private key) after regular password, setup 2 factor by negotiating a "fudge factor". this is a number that can be added or deducted from GPS-time that is know to both server and client.
so on next login, via password also let client check GPS time, deduct/add "fudge factor" and send to server (+- transmit time of communication). server compares to its own GPS-time and the "fudge factor" and see if it fits.
on logout renegotiate new "fudge factor".
possible sequences are small with, say days (0...364), hours (0...23), minutes (0...59), seconds (first half and second half = 2, because of transmit lag) and add or subtract (2) = 364 x 23 x 59 x 2 x 2 = 1'975'792 (?)
normal 2 factor challange is for 4 places with 26 big and 26 small alphabet letters = 731'616 possibilities?
(Score: 2) by Justin Case on Saturday August 20 2016, @05:58PM
Yes, but under the best practice of "something you know" + "something you have", it proves you have a GPS!
(Score: 2) by Scruffy Beard 2 on Saturday August 20 2016, @06:28PM
Not it doesn't. You can derive GPS time within about 300ms using NTP.