h a l f b a k e r yThis ain't rocket surgery.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
I work in IT. I work with computer systems and understand
how weak passwords can be easily compromised with
dictionary or brute-force attacks. I also work with people
and understand the frustrations of having to come up with
strong passwords and having to remember them. Some
people would rather
be allowed to have weak passwords
and change them often. Other people (such as myself)
would rather come up with a ridiculously strong password
and keep it for a longer amount of time.
Existing systems allow administrators to set password
strength and expiration requirements, but I don't believe
they allow the administrators to set these two criteria to
be set simultaneously with dependence on each other.
Proposed is a password policy system in which the
expiration of a password is automatically and dynamically
adjusted for each user's password strength. The expiration
duration would be unknown to the users and to the
administrators until the expiration drew near (since this
would be a clue about the password).
The calculation would be based on the un-obviousness of
the password as a prediction about how long a password
cracker would take to break it, employing dictionaries and
the like. Users with strong passwords would be rewarded
with longer intervals. Users with weaker passwords would
be punished with shorter intervals. (Bare minimum
requirements would still be in effect.)
The strength-to-time ratio need not be linear. Assuming a
proper encryption scheme is used, a user with a
ridiculously strong password (such as an 8kB string of ASCII
nonsense) would be as safe for the first few days of
owning such a password as they would for the remainder of
the first year of owning such a password, but they should
still change it--perhaps every decade at a bare minimum--
because of human factors. It highly depends on the
organization and environment. An account with a password
as obvious as "password" could be compromised in a
matter of seconds, but it could still be appropriate if used
for short-term internal testing on a non-critical system. I
believe this human element spoils the exactness of such a
science.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
|
On a further note, calculating the strength of a
given
password might involve its un-obviousness when
the
PREVIOUS password is known. For example,
squirrel!~3 is fairly secure, but
when it's replaced with
squirrel!~4 (and assuming
sufficient decryption time has passed with
squirrel!~3 in the open), it's
not quite as secure. (HB didn't let me post as long
of a password as I wanted, but you get the idea.) |
|
|
[+]Good idea. Im IT too, an application programmer, and having written several authentication and encryption systems (and, less fun, answered a lot of auditors questions), can get away professionally with calling myself a security expert. While Ive seen lots of password strength advisor features in password change dialogs, havent seen or heard of this idea before. Its arguably user-friendlier than the typical pass/fail or red/yellow/green password strength check, because it incentivizes the user to enter a strong password in exchange for a longer time til next required change. |
|
|
The main negative I can see is that not all threats to authentication systems are from dictionary/brute force attacks on weak passwords, so cant all be countered with stronger passwords. An account with an unbeknownst stolen strong, long expiration period password and lots of privileged authorization poses a worse intrusion than one with a shorter expiration period, simply because its a longer intrusion (one assumes its detected and ended when the stolen password expires or the intruder changes it, and its legit owner cant log in anymore).. |
|
|
What the password protects might be another datum
to incorporate into the algorithm. The more valuable
the data protected, the more likely you might need
to change it more often than, say, the password to a
discussion forum --related to how much data about
you the forum collects, of course. It seems to me
that some forums are rather more snoopy than
others. |
|
| |