Posted
by
timothy
on Sunday May 04, 2014 @10:31PM
from the risk-versus-reward-baby dept.

Ars Technica reports on an interesting and sensible-sounding approach to password policy that I'd like to see adopted just about everywhere I have a password (which, these days, is quite a few). An excerpt:
"For instance, a user who picks "test123@#" might be required to change the password in three days under the system proposed by Lance James, the head of the cyber intelligence group at Deloitte & Touche. The three-day limit is based on calculations showing it would take about 4.5 days to find the password using offline cracking techniques. Had the same user chosen "t3st123@##$x" (all passwords in this post don't include the beginning and ending quotation marks), the system wouldn't require a change for three months."

From the article: "Passcodes that have a length of 20 or more can contain any character type an end user wants, including all lower case letters." And sites like Phil's Hobby Shop [philshobbyshop.com] have lowered "complexity" requirements for sufficiently long passwords. I'm glad the passphrase concept is catching on. To what extent can xkcd be credited [xkcd.com] with awareness of passphrases?

Not a great extent. Most of us knew the math already, but it only works well when you really select randomly from a dictionary instead of making grammatically correct sentences or even personally chosen set of "random" words (from a limited vocabulary). Mixing passphrases and complex passwords works best. battery horse correct staJ&%v1ple

As illustrated in the comic, your mind can end up constructing a "story" around whatever four words your Diceware spits out. So long as you can remember the story, it doesn't need to be grammatical.

Bingo. Funny enough, I just finished doing a security job out in western canada(provincial government office) and moved them to passphrases. Funny how the number of "passes written on post-it-notes" dropped from "everywhere" to nowhere except the firebox safe. The safe of course is in it's own room, and requires two keys to open besides the combination. This of course also cut down on the intrusions into the network, because people simply "walking in" couldn't glean passwords that were posted in the open anymore.

I think you're in violent agreement with the post you're replying to. If you tell someone "Use a phrase rather than a word", they will come up with a grammatically correct sentence, which probably even makes sense at a semantic level. Tell them to use Diceware, and they're selecting randomly from a dictionary.

I think you're in violent agreement with the post you're replying to. If you tell someone "Use a phrase rather than a word", they will come up with a grammatically correct sentence, which probably even makes sense at a semantic level. Tell them to use Diceware, and they're selecting randomly from a dictionary.

If you tell 95% of people "Use a phrase rather than a word", they will come up with a grammatically incorrect sentence, which probably doesn't even makes sense at an elementary level.

There we go, FTFY...we seem to have a strong assumption about spelling and grammar skills here. Sadly, it has probably helped, since "passwerd wun" is probably more secure than "password one".

The problem is that password crackers can now crack strings of words [arstechnica.com] relatively easily. On page three of the article it even mentions that comic specifically as an example of what crackers can now break.

Two factor authentication is the solution. If you can't use that then a long, random password stored in a password safe app is the best bet. Anything you can remember is crackable.

"To what extent can xkcd be credited?" Not a great extent. Most of us knew the math already

There is a difference between knowing the math and applying it. A nice, easy to remember story can make that difference.

but it only works well when you really select randomly from a dictionary instead of making grammatically correct sentences

Grammatically correct is not that much of a reduction in key space. I would imagine that "Adjective" "Noun" "Transitive verb" "Adjective" "Noun" yields a larger keyphrase than four random words, and it is probably easier to remember than "Noun" "Noun" "Adjective" "Noun", even for rare words.

Not sure where you got your numbers from, nor how many words you think the english langue has...

http://www.oxforddictionaries.... [oxforddictionaries.com] lemmas - Instead of talking about words, it's more useful in this context to talk about lemmas, a lemma being the base form of a word. For example, climbs, climbing, and climbed are all examples of the one lemma climb.If we talk about the base of 95% of common lemmas, we are looking at over 50,000 words for a strength of 3 chosen randomly VS 1 printable ascii chrs(of 95)125,000,00

And of course I reversed the figures here.."And i have no idea how 10 acsii chrs beats 10 lemma..90,765,625,000,000,000,000,000,000,000,000,000,000,000,000,000, VS 59,873,693,923,837,890,6259.765e+46 VS 5.987e+16"

to the point where two or three truly random characters is as strong or stronger. "battery horse correct staJ&%v1ple" is effectively no stronger than adding one additional random character to "staJ&%v1ple" and dropping the real words entirely.

This is BS, There are 95 ascii character choices for the one character to be inserted in any one of the 12 positions of staJ&%v1ple, so the size of the space to be searched goes up by a factor of 12*95=1140.

English, on the other hand has about 10K commonly used words, so adding three words like "battery horse correct" increases the size of the space by a factor of 1,000,000,000,000.

An English word has about as much entropy as 2 random characters. So assuming you use an application to select a random non

An 11 character password drawn randomly from the 95 printable keyboard characters (which you seem to be suggesting) comes out at about 72 bits of entropy, but is very difficult to remember.

A five english word passphrase comes out at around 74 bits of entropy. I can even tell you that my wordlist for selecting those words is the set of four to seven letter entries in/usr/share/dict/american-english - there are 29,482 entries in that set, which m

Do not underestimate the complexity of grammatically correct sentences. With the average 1.3 bits of entropy per character the pass phrase "The blue none jumped over the red fence." comes out at around 56 bits of entropy. Add to the fact that the low 1.3 value comes from sentences that only make sense, so the more nonsensical the phrase the higher the entropy. This is all under the assumption that the attacker knows exactly the password scheme you are using, if he goes towards more traditional dictionary at

I have wondered if the best way to measure password complexity is with an arithmetic compressor. Train it with a good dictionary, including words in various languages and any cracked passwords from hacked servers. The compressed size is the complexity measurement.

That's fine if you only ever sign into one web site that uses two-factor authentication. But if every web site you sign into during the day insists on a different off-the-shelf two-factor solution, or if one of the solutions is pay-per-use, it could get very expensive. One such pay-per-use method that has become popular is receiving a text message on a cell phone.

The problem with the use of SMS for 2-factor auth is not that you have to pay for the messages (paying for incoming text messages is an artifact of the horridly broken pricing model for US cellphone service) but that SMS is unreliable (I have had instances of SMS messages not getting through, especially if my phone happens to be switching cells or entering a dead zone at the time) and also that with more people doing so much internet stuff on their cellphones, having the second authentication factor being the same device you are using to log into the web site makes things a lot less secure.

The problem with the use of SMS for 2-factor auth is not that you have to pay for the messages (paying for incoming text messages is an artifact of the horridly broken pricing model for US cellphone service) but that SMS is unreliable (I have had instances of SMS messages not getting through, especially if my phone happens to be switching cells or entering a dead zone at the time) and also that with more people doing so much internet stuff on their cellphones, having the second authentication factor being the same device you are using to log into the web site makes things a lot less secure.

There are very few 2 factor systems you dont have to pay for in some way (none if we're including the cost of your time).

But I'm commenting to point out the irony that I as an Australian, could receive SMS alerts from my bank on my Australian SIM whilst roaming in the US for free. In the Philippines, you can send unlimited SMS's as long as you have 1 peso in credit (US$1 = 45 PHP or there about). The cost of SMS's are largely superficial.

One such pay-per-use method that has become popular is receiving a text message on a cell phone.

Only in the US is it considered normal for the receiver to pay for incoming messages and calls. In the rest of the world, bulk users like banks get very good rates on SMS that makes it very much worth the extra security they provide, at no cost to their customers.

I'm glad people are out there thinking about this. As I understand it, though, there are a couple of drawbacks to this specific approach.

1. The unique identifier that now allows you to be tracked across each application you use. I guess this can be solved by having multiple IDs per app. You might want to consider this.2. "Pay per authentication"...3. Requirement for your phone to have connectivity. While this doesn't matter most of the time, it can be important when, for example, you're traveling abroad and

Good (read: not utterly useless security theater) card readers for computers cost money. Quite a bit thereof. And even then you still only have one channel (the computer -> internet link) to communicate, which means you have to harden it against MITM attacks. That in turn means that the reader you have there can only work for one single predetermined (read: At time of manufacture) application. In other words, you could secure your onlin

You clearly have no idea how that works. For one, let's assume that we have a passphrase that consists on 4 different words and there are no characters or numbers that aren't part of the words. A hacker knows the passphrase consists of 4 words, but that's all he knows. He has a, say, 50,000 word dictionary to use for his attack. Now, you have to remember that we have words as small as 2 letters and ranging all the way to several tens of letters, but also that you have 4 of such words of which you do not kno

Limit attempts to log in to any specific account to once every minute or so. Failure locks the account for a minute, so it doesn't matter what IP or console or program the request comes in from, etc., it's once per minute, period. That's 1440 attempts / day, max.

Attempts to try every password will take forever on even a moderately stiff PW. So ensure passwords are at least moderately stiff. Or better.

After some small number of failed attempts from one IP, blacklist the IP or console. After some small number

I'm not sure why you responded to me with that. I was talking about passphrases and you jump to server-implementations. I don't disagree with you; a well-made scheme does include limiting login-attempts and logging failed attempts and all that. Just..did you intend the reply to someone else?

The main worry with brute force is a compromising of the system that lets the attacker have access to password lists, and then needs to brute force those off sight to return latter, any system set up these days that allows a brute force on it with out a) notifying the admin and b) locking accounts is so broken that its not worth discussing.

What I never understood was that there are usually only 2 "time" policies: Either don't limit the attempts per minute or lock people out for an arbitrary number of minutes after a failed try.

Why not take into account that the normal (legit) user needs to type while the attacker would fire an automated tool against the login. Limiting it to 30 attempts a minute would not even be noticed by an average user typing his password while at the same time ensuring that it becomes virtually impossible to crack it wit

Unless the developers have taken a belt-and-suspenders approach to guarding against cross-site scripting and Bobby Tables attacks [explainxkcd.com] by not only using parameterized statements but also stripping any punctuation characters that may have special meaning in HTML or in SQL. Angle brackets, ampersands, and quotation marks become an underscore, which is a more common (that is, less entropy) character in passwords.

It is one of the few things where I simply don't agree with Bruce. While it is no less secure than your CC, I consider the CC already a horrible security problem.

What you do when you write down your password is that you turn "something you know" into "something you know OR something you have". And while security improves if you make it dependent on "something you know AND something you have" (as in ATM card+code), the OR there lowers your security.

You may have missed his point. Writing down the passwords means you can use stronger passwords that you don't have to struggle to remember. The threat from brute forcing stolen hashes is much greater than the threat of having your wallet stolen by someone who is going to know what to do with the passwords.

Having a hint or reminder to your password is OK, I'd think, as long as it's clear to you, but obscure to anybody else. As an example, my laptop is named after a planet used in an SF series I like. Even if somebody guessed that, there are enough places, people and things in that series to keep the hint from being any help to anybody except me.

Basically, security distinguishes between key and lock. The lock is the "mechanism" of the security system. The algo that does the number crunching with your password and determines whether it lets you in or whether it does not. The key is the part that you know, have or are. In this case, the password.

The key is ALWAYS something that you have to keep private. You have to keep your password secret and you have to keep your token with you and not hand it over to anyone. You might notice how I omit

For the longest time I used the serial numbers of various items on my desk. They're very convenient since they actually follow password requirements. Letters, numbers, special characters... it's all there.

I had to get a new password from IT when my coworker sitting opposite of me got a new monitor, though.

Because all you are going to get is users deciding that they they cannot come up with a 10th password that year and just going picking "123456".

"I'd like to see adopted just about everywhere I have a password (which, these days, is quite a few)"What a joke. If every site used this method I, and many other people, would need to change multiple passwords every single day of the year. The entire system would break down and become completely unmanageable

I think the idea is you'd let the user know. "This password would take approximately 4.5 days to crack. For your security, you will be required to change this password after 3 days. Alternatively, you may pick a longer, more secure password to lengthen this interval (for example, a 16 character password will only require a change after XX years)." Or something.

That will just make people use the same password for everything, or need to use the password reminder function a lot.

When most people need 20+ passwords (email, multiple PCs, forums, subscription sites, NetFlix, dozens of shopping sites, bank sites etc.) in their life the only conclusion is that passwords are not a good system. If we could get everyone to use a password safe it might help, but despite having been available for free for decades hardly anyone does.

Years ago, I worked for an ISP. Once they realized that they were able to put expiration dates on employee's passwords, they did so. Not just for things that we could access from home, but for services on the internal LAN that couldn't be reached unless you were physically on site. My response was to make them as rude and vulgar as I could, both as an expression of what I thought of the policy and because I knew that this would make them easier to remember. And, of course, a little bit of creative spell

Some of the replies to you say "well, that just forces people to make more complex passwords" so they last longer, but that's just the same-old. And anyone that deals with this from a business standpoint will tell you that the real problem with requiring customers/users to have more complex passwords is the more complex you make them, not only the more frustrated the customers get - but you also have to make it even easier for them to reset their passwords.

SiteSite1 i Has the above restrictions but requires 8 or more letters.Sitesite j only allows 8 letters- but requires 4 or moreSite k won't work with XKCD since it doesn't allow ' 'sSite L has some permutation of these rules and won't let me reuse prior passwords- or double letters, or various other sequences, or english words in the dictionary-- so my password ends up being almost completely arbitrary.

So these days-- I write algorithmic encoded passwords on paper.So you can look at the paper - and it doesn't mean anything to you. It's not a simple substitution cypher.

But it still sucks when I buy a new device and have to change all the passwords for something before I started writing down passwords.

Another thing password services (not job passwords) have is a duration of YEARS. I'm supposed to remember a password I created 7 years ago that met arbitrary rules- which they won't tell me now. Meh.

I just say 'generate' to PasswordSafe (right now my tool of choice) and have a 8-character pile of gibberish that I can't pronounce and never read. If someone points a gun to my head (the NSA?) and asks for my online banking password, I can only - truthfully- say that I have no idea.

BTW, pavlovian to me implies egg whites and sugar, mixed and then baked. Then cream.

Someone can still point a wrench [xkcd.com] to your head and ask for your PasswordSafe master password. What would be your truthful answer to the following question: "Do you know your online banking password, or any other password that can be used to retrieve your online banking password?"

Yes, and that works perfect when you need to generate your password on your phone and later use it on your PC. Or generate your password at your office (where you are not allowed to install software), and then use it on your tablet at home.

Password generators are a giant fail. They work in a very small subset of conditions but are not useable in the situations most consumers find themselves day to day. I am so sick of geeks like myself trotting out password managers as a solution - they are not. The soluti

I'd like to see sites develop password policies that reflect the value of information the passwords are guarding.

For example. if a password unlocks access to a bank account, it's reasonable for the bank to require more secure forms of access: including ones that are better than mere passwords, themselves.

However if all a website visitor has at risk is comments about stories. Comments that can be, and often are, as banal as I lik [sic] catz then even a 1 character password seems like overkill. As it is, t

The three-day limit is based on calculations showing it would take about 4.5 days to find the password using offline cracking techniques.

If you're assuming your hashed password file is public or you allow unlimited login attempts without shuttering the connections, then this makes some sense. But if your pw file is public you need to force a change far before the average crack time (like 2 stddev), which probably means hours on an average of 3 days to crack.

Yes, we're assuming that the hashed password file has a substantial probability of getting leaked, just as it was in several other high-profile breaches (Sony, Target, etc.). If it's impossible for an inside job to leak the password file, then how can the system 1. use the password file to authenticate users and 2. back up the password file in case of hardware failure?

But if your pw file isn't supposed to be public, then you're setting a policy assuming your system has been cracked and are passing bad math onto the users as annoyance.

Dude, the first step to good security is to assume you've been compromised and then construct your defenses based on that assumption.It's called a defense in depth [wikipedia.org].

Or to look at it from another angle: we all have locks on our homes, but you still wouldn't leave $10,000 in cash just sitting on the kitchen table, would you?Of course not, you'd hide it, preferably in a safe that's bolted to the floor.

Dude, the first step to good security is to assume you've been compromised and then construct your defenses based on that assumption.

Not so much. The first step is figuring out what you're protecting.The next step is figuring out what the fallout is if you're compromised.The 3rd step is figuring out the likelihood of being compromised, and potential avenues of attack.Only at that point do you construct your defenses.

Contingency plans are based on assuming the worst has happened. Security plans are not. An

A very simple problem opened up by making users rapidly change their passwords is that they will frequently forget what they just changed them to. They will change it last minute on Friday to something genius and on Monday scratch their heads and go, "Crap". So now they are going to call tech support who will walk them through some crude verifications and give them a new password.

A perfect example of this is a relative of mine who works for government. He was complaining about the frequent password changes he has to do. So I bet him that we could look under everyone's keyboard and find some passwords. Two of his people put them on post it notes under the keyboard, and another guy just had 30 passwords written on the bottom of his keyboard, which oddly provided some security as I couldn't guess which one was the newest.

But the best part was that I bet that with my relatives wallet and his most recent pay stub that I could talk IT into resetting his password. So I called them up and they promptly walked me through resetting his password; but they didn't ask me a single question. So in the end I asked them how they knew I was me (him) and they said, it was because of what phone I was calling from. I asked what they would have asked had I been home and they said, birthday, maybe the office's postal code.

So it wouldn't have mattered what genius password scheme they were using as the more genius it was the worse their social hacking problem would become.

A different relative who works for a different branch of government could even log in without her key fob as all she had to do was phone IT and whine until they let her in from home.

Now you might just wave your hand and say, no problem just bolster the security by telling them not to be nitwits. But those guys weren't being nitwits. In government or any large organization if you piss the wrong person off you will lose your job far faster than if someone hacks the system. So maybe for Sally secretary they might not be so persuaded but in the case of where I phoned in a forgotten password the person who should have been sitting at that desk could have an IT person's head very quickly. As could the other relative who whined past the need for a key fob.

I really dislike any authentication system that rejects MY chosen password. It's my security, not yours, that I'm gambling on if I want a easy to type password. And the ones that make you change it x number of days are even worse.

This is outright stupid. You can't force people to choose a decent password, they either will or they won't and no 'system' is going to force it upon them. At best, you're just creating a support irritation as people forget the password they were forced into changing.

... i should change them weekly as well?To whoever was talking about the Adobe password hack. I don't think anyone cared about that password. It was forced on them by Adobe for one marketing reason or another. Or because of the idiotic cloud suite thingy.Now the passwords that really are important to me... those are hard to crack, don't worry.

Is the duty for password complexity correctly placed on the users shoulder? I think not...

The users has two jobs:

1. Select a password he can remember2. Choosing a password someone else does not associate with him

Raising password complexity requirements makes those two jobs harder. In my observation, with rising password complexity, the users tend to re-use passwords more often (which is more detrimental to security than a less complex password).

This should be the first thing you tell your mother or Aunt Tilly [tm].

If you do the occasional shopping, email and Facebook usage you only really need to know one password; your email account. The others can be stored in your browser/app or reset if you ever forget. Having to do a password reset before doing your "once-a-year" ordering of photo-books is a minor inconvenience compared to having to remember loads of different passwords or worse; using the same password for all sites.

Teach Aunt Tilly [tm] the typical password-reset procedure and tell her that she doesn't have to remember these passwords, so there's no need for the password to be simple.Shopping sites really should move away from using passwords anyway. They can store a token in your browser and perform a reset using your email address if you're using a browser without the token. They can also do periodic resets of the token.

Just make sure that Aunt Tilly [tm] knows that there is one password that needs to be GOOD and she needs some way of remembering it; her email account. Having access to your email account would give criminals many great ways of screwing you over, since they can reset nearly all your passwords that way.

If she really can't remember a complicated password, then writing it down on a piece of paper in her house is much less likely to cause her trouble than using "mathilda" or "whiskers" as her password.

People who choose "correct horse battery staple" would always choose good passwords, would not reuse the same passwords for all their accounts. People who choose 12345, if forced to choose "correct horse battery staple", would write it on a post it note and very cleverly tape it to the underside of their keyboards instead of the monitor and congratulate themselves on their devious ingenuity.

The battle to make users remember arbitrary characters isn't just foolish, it's insecure.

Which is not what this is about. The article is about varying the password expiration by whatever password grading system you have chosen

Without advocating a specific grading system.

But there are some pretty decent grading systems that use a graph-based approach to calculate an approximation of time to crack, based on application of different cracking techniques to different substrings within the password.

For example: for 3 common words strung together.
You count the number of words in all the dictionaries that each word shows up in,
and you figure time to crack for that substring as n/2; for each word, where n is the size of the smallest of the cracking reference dictionaries containing that word, and multiply those times together for the words strung together.

For common variants such as leet substitution, applying a misspelling, appending a digit, prepending a symbol,
changing a case....

Of course, then, the approximate effect on crack time of all these things can be calculated.

Appending a digit multiplies it by 10.0. Prepending a symbol multiplies it by 6.0.
Alternating the case of some letters multiplies the strength of that word by 2.0

Performing leet-speek substitution multiplies the strength of that word by 1.05

Applying a misspelling, single letter substitution, or transposition to a word multiplies time to crack that word by 26.0, etc.

+1 to this, using foreign language characters in a passphrase is a great idea, it makes things more secure since it increases the number of combinations hackers need to try (assuming they even have the foreign language characters in their data sets which I doubt they do)

+1 to this, using foreign language characters in a passphrase is a great idea, it makes things more secure since it increases the number of combinations hackers need to try (assuming they even have the foreign language characters in their data sets which I doubt they do)

Enjoy being locked out when you realize that UTF8 != CP-1252 != UTF16LE, etc. Oh, and god help you if you need to use a different OS to login, or don't have rights on the given machine's account to change the input charset. And all this is before you get into the potential disconnect between the webapp's stated charset vs the backend password system's charset (your password text field input isn't being passed around as raw bytes no matter how much you might wish it to be, sorry).

There is no hell like charset encoding. Yes, in some imaginary world where everyone dropped IPv4 when IPv6 came out, simply because it was the correct technical solution, your idea might work due to ubiquitous, end-to-end UTF8.

Here in the real world, well, one time I got locked out of a shitty online banking system because I used a punctuation character in my chosen password while setting it and all non-alphanumerics were stripped from input in the login password field, thereby preventing me from ever being able to submit my chosen password.

Another fun one is a password containing a backslash. To make matters worse, the customer support is not willing to reset the password, because the web site offers a way to retrieve the password already via e-mail, despite the fact that entering the exact password as it appears in the e-mail does not work. And the fact that the password can be retrieved at all (instead of only reset) is not a good sign either.

Any website that doesn't hash the passwords in their database should fire whoever on their development team is responsible for security (although to be fair sometimes its not the fault of the dev team, its the fault of some no-nothing PHB that thinks users need to be able to get their passwords back for some reason)

zxcvbn [dropboxusercontent.com] rates that as 78 bits of entropy; 72 without the ~.

But if everyone starts using some foreign words or terms with accented characters transliterated, it becomes just another part of a cracker's dictionary, and not much better than "The boy causes rain." (59 bits, still an excellent password).

I don't understand the question. Those things are all annoying. Are you implying we have to pick one?

Personally, I would say that they are more annoying than popups and popunders, because popups and popunders are conveniently encapsulated and marked as bullshit by virtue of being in their own unsolicited window. But less annoying than those autoplay audio ads for sure, which are a blight far beyond any advertising the Internet had ever seen before.

So how do you plan on carrying this "system" everywhere you go and having it interface with every other piece of hardware that you use? If you plan to use your smartphone or pocket tablet to remember your passwords, can it emulate a keyboard to key in the password? Does the machine into which you must enter your password even have an accessible USB port?

Sure, and it's nice that you can type "echo -n password | md5sum" to a shell if you forget the hex. But it might be better to keep your password secret, unless you intend to google "No one will guess... site:it.slashdot.org" to retrieve it in the future. You might as well tell everyone that a great password is "correct horse battery staple" - no one would guess THAT - and it's easier for a human brain to remember than xkcd.com/936/

Precisely what I was thinking. I'm not sure what problem they're trying to solve by forcing users to change passwords. Besides which, tying expiration dates to each password basically just tells the attacker which passwords are likely the easiest to brute force. That may not be a problem if your expiration dates are always sooner than the amount of time necessary to brute force the passwords, but what's to stop an attacker from simply making a box that's twice as powerful? It's a silly pursuit.

How exactly does the attacker know the passwords expiration date? Your argument that the attacker will make a box that is twice as powerful to brute force passwords is irrelevant, because they already are doing that to brute force passwords (to whatever extent people who try to break into websites brute force anything these days). The idea that poor passwords should be prompted to be changed more often is, on the surface, a great idea, but it all falls apart when you know that anyone that chooses "1234ABCD"

How exactly WOULDN'T they? If the attacker is doing offline brute forcing of passwords, that means they've obtained at least a partial copy of the database for the site (since they have to have the hashes and salts), at which point it's probable that they would have also obtained the expiration dates linked to each password.

Your argument that the attacker will make a box that is twice as powerful to brute force passwords is irrelevant, because they already are doing that to brute force passwords (to whatever extent people who try to break into websites brute force anything these days).

That was more or less what I was getting at. Anyone who implemented such a system would be constantly needing to tweak the expiration dates to keep up with whatever the latest password c

how?because to perform the attack they would need a copy of the passwords database. the whole server side operation of things would be suspect at that point.

this scheme fails on several levels, first it must perform analysis on how hard the password is to crack and then pester the user to change it.

the other level is that this is only going to provide any extra security _after_ the hackers already have obtained the password database and all the passwords need changing anyways in a situation like that.

The whole issue starts at "why is offline cracking possible in the first place?".

Offline cracking requires the attacker to have access not only to the machine (ok, in a time of VPN that's not as big a feat) but to the password database. If you assume or at least fear that a potential attacker can have access to the password database, and not only that but actually gain access without you noticing it immediately (else, just invalidate all pws when you notice it and be done with it), you have FAR bigger probl