The way to use SuperGenPass safely, however, is to use a browser plugin instead of the bookmarklet. It's unfortunate that the bookmarklet is still the most heavily promoted version as DOM-external plugins are the only safe way to use it.

AKA I gave my pass to co-worker (who quit the job), or I logged to company mail from public (aka. trojaned).

Though it's 43567634675637'n level of security, and it should never be used as a replacement for competent IDS.

Hell, I will give you an amusing example. It comes from EVE Online mmo (where btw, players employ espionage and counter-espionage strategies only found in intelligence agencies). People like to switch corporations (guilds) from time to time and some of them, sometimes* they don't change all their passwords when they join new one. Political landscape changes frequently, and even without that, it's good to have spy even within your enemies. As such, everyone will cheeck if old passwords ex-member won't start working in systems of hostile corporation. In this, random password purges are very effective.

However, there is another side - one corporation decided, that instead of spying quietly on enemy corporation directorate, they would do bruteforce-copy of their entire forum and make nastiest parts public to create some immense PR damage. Long story short - they were extremely successful, whole game lived with secrets of BoB directorate for weeks.

Similar attack was ran against my own corporation few months later. Luckily, we had form of IDS operational: it detected abnormal activity, and after several pages started feeding their web crawler with garbage. Which in fact provided nice PR win, because attackers announced they infiltrated us before they looked at what they got:D

I guess that next level would be detecting phony login and then feeding infiltrator with neatly modified data (automatically change op dates and other important details) and some nice stenographied message like "YOU'R dumb and ya mommy smells of cranberries".

*with corporations numbering up to 6000 players, someone, sometimes might iss quite a sizable group of people

for example my facebook gets my gmail password gets my twitter password gets my school password gets my work password gets my facebook password

and whenever I join something I generate a random password

All I can say is good luck with that.

Good luck. I've been an IT auditor for 12 years, and I've spent a great deal of that time harping on "The Law of Unintended Consequences" when it comes to everything from passwords to policy to perverse incentives. IT auditors, unfortunately, are often either mislead or constrained by ill-advised mandates as well.

There has been more than one time that I've had to push for a parameter that I did not agree with but my employers and clients would be subject to disciplinary action and liability if they didn't comply. Of course, I report this to the bodies, but it usually falls on deaf ears.

I'll keep fighting the good fight, but it's a tough battle.

John, CIA, CISA

I agree that things arent helped by people implementing rules without understanding why they are in place (which is why we are scared of writing down passwords because the sneaky hacker on the other side of the world can read them).

However, lots of the solutions to the "password problem" simply change where the risk takes place - there is no real reduction in risk.

(SSO / password safes are an example, effectively putting all your eggs in one basket and encouraging an attacker to expend more resources to crack that one repository)

Rather than try to overengineer a solution to a single problem, we should re-assess what our security provisions are and how *any* form of authentication feeds into that.

"I work for a phone company, not the CIA"

Yup and those nine passwords are to keep the CIA out (or that's what the NSA told your bosses boss ;)

I work for a phone company, not the CIA.

Passwords have had their day.

"So I wonder what patterns are there in real life both in terms of transit time for credentials, and the moment they get used. (I.e., does such a"payday" effect exist or not ?"

It may not be possible to find this out due to the fact neither the merchants who lose the credentials and the Payment Card Industry who field the complaints want to go public.

However it is possible to build an adhoc model with the three phases from the time the credential gets stolen.

For the "selling phase" I suspect the two main shaping forces of the market are,

1, minimum bundle size
2, time to sell

with the addition of

3, credential transfer time.

Only when this is finished is the selling phase compleate.

From the transfer point on you are in the "realisation phase" and I suspect it depends very much on,

4, The abilities and methods used to realise money.

By the person who purchased the credentials. They may have reason to make one large one off hit or many small repeated hits depending on how they work.

Then there is the "reporting phase", which starts with the first use of the credential.

For instance with credit cards it might take upto 60days for the user to become aware of the theft with post out statments.

Also as has been seen some online banks systems get a MITM attack on the customers PC so that it does not display certain transactions, so the customer does not actually report the loss.

And the person may not recognise that there has been a loss or even report it for a whole variety of reasons.

I would expect this time to be relatively short, maybe 2-4 weeks on average.

First of all, what reasons could there be for not using the credentials immediately ? It takes time to transfer them from the credentials thief to the credentials user. It may also take time to find a buyer. Since using the credentials may reveal the theft, one may want to collect a certain number before "going public". There may be some days where the catch will be better than on others, e.g., right after payday.

Now, why not sit on the credentials for a long time ? They will rot naturally, by people closing accounts, changing passwords, etc. The more they rot, the more attacks will fail, increasing the risk of triggering an alarm. The mechanism for obtaining the credentials may get discovered and the victims or their bank may take actions. If the credentials are sold to many buyers, the risk of discovery multiplies. Once the credentials are being used, the risk of discovery and effective defense increases. Thus, if there are many uncoordinated buyers of such credentials, you'd want to be the first to use yours. An excessively large collection of credentials may just be impractical to use.

So it would seem to me that there's a strong motivation for using credentials quickly and the only thing that would slow this down would be logistics and the wait for payday.

If the wait for payday is considered unnecessary, collection of credentials is fast, and buyers can be found on short notice or even in advance, the minimum delay between theft and use may be well below one day.

If the credentials are "in transit" only for a few weeks, you'd have to change passwords very often to significantly reduce the risk. If they're in transit for only a few hours, there's little point in even trying.

So I wonder what patterns are there in real life, both in terms of transit time for credentials, and the moment they get used. (I.e., does such a "payday" effect exist or not ?)

- Werner

Zhang's group performed password cracking attacks, (with approval), against passwords collected from UNC students/employees to measure the effectiveness of password change policies. For example, they found that if they had one password for a user, they could break their subsequent passwords 13% of the time using just five guesses.

On a similar note, I'd like to point people to a paper I co-authored and presented at the same conference, "Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords" which is available at http://goo.gl/wqcX

vwm: "Someone who steals your banking credentials might not use them instantly but rather sell them in bulk. Someone else will use them some time later.
So if you change your credentials during that time, you thwart the attack."

People who look at this as "attacker steals password, attacker uses password" are oblivious to what's actually happening out there.

"Passwords always generate a storm of opinion IMHO this is because it is a simple concept that interfaces with multiple, complex, issues."

Yes and no, part of the problem is the history of passwords.

As many in the military know passwords started from the chalenge "Halt who goes there, friend or foe?"... "advance one and be recognised". This challenge-response procedure then proceads to a supposadly covert wispered password phase where the challenger whispers the first of a pair of words to which the chalenged person should reply the second or get shot / disarmed / apprehended / etc.

The whole point of the word pair was that they where easy to remember and have a life of no more than a guard / sentry shift or the time a roving patrol was due to be out.

As such they are low tech and if (and only if) carried out correctly relativly safe procedures.

The problem is most times they are not carried out correctly (ie the chalenger is not backed up correctly / more than one potential enemy aproaches / the word pair are not wispered / etc).

These problems occure because those involved don't understand why things are the way they are and the implications of not doing the steps correctly (such as the sentry may end up very dead as will some of his comrades).

The computer password system which is derived from this challenge-response system suffers from exactly the same self problems and then a whole bunch on top.

The reason actually started with laziness by humans which is encoraged by no effective punishment for those who breach the rules or fail to explain them in the first place.

This gives rise to a new generation of "rule followers" who have no idea what the system is about who then go on to implement their own system or augment an existing one.

As I said above computer passwords where a bad idea 50 years ago and still are 50 years later.

Atleast those 50 years ago had a semblance of an excuse in that the systems then where pushed to even support the simplest of password systems. Those implementing such systems today have absolutly no excuse.

If you think about it the generalised computer password system is lacking some of the precautions of the military challenge-response system. It would be better for the authentication process to be "public authentication" then "private authentication" then a one time secret exchange by both parties usually from a paper word list or other other equivalent token.

The steps being,

1, User - hits key code to get secure channel.
2, User - checks the channel is secure.
3, Comp - gives login prompt.
4, User - gives public identifier.
5, Comp - Returns public identifier,
6, Comp - Issues private challenge.
7, User - gives private response.
8, Comp - issues a secret challeng word
9, User - checks word is on list and is expected next unused word.
10, User - enters the coresponding secret response word, or duress word, or error word.

The point is both the user and the computer authenticate to each other privatly before going on to the one time word pair exchange.

The user can enter the correct word to procead normally, an error word if the secret word presented by the computer is not the correct one or a duress password if somebody is standing there with a gun to the users head.

But you are very unlikley to see such a system in practice for a number of reasons (based on human laziness).

Such systems have been proposed in the past with Trusted Computing Base systems but never progressed into the normal computing world.

On the other hand, if an attacker can steal a password file and mount an offline attack, any short (16 characters or less) password can be brute forced. However, this implies that the system has already been cracked, and should be rebuilt with all new passwords.

And, by far the biggest threat is impersonation arising from hacked computer, so hosts must be on guard for impersonation using the correct credentials. One-time passwords can defend against this, but existing sessions can still be hijacked.

So in conclusion, many organizations penalize their users with unnecessary password changes because they are not properly detecting attacks.

Passwords are ONE part of security. The majority of breaches (IMHO again) bypass the authentication process because there are normally easier to exploit vulnerabilities (SQL for example).

Password weaknesses are also often stated independently of how they are used - yes you can brute force the hashfile but that is no help at getting past the web interface.

One other thing that intrigues me is how there is frequent confusion over what makes a strong password policy (as opposed to a specific choice of password) and when this should be implemented. For example, there is a different requirement for how I authenticate myself to my phone vs my bank.

The security questions are quite clever too, not Googleable stuff like "what's my pet's name".

Of course I don't write the password itself down but the other way around; I generate a bunch of long password strings (using something like "pwgen -y -s -1 80 50") and print the result. That's the writing down part. The resulting paper can be left in plain view if necessary, and each actual password is found somewhere on the printed page. Pick a spot that you'll remember (there's always something that catches your eyes) and then move left, right, up, down or diagonally if you like, in as many steps as you want or are required to, accumulating characters for the password along the way.

Each password is as secure as they can be because it is using all types of characters chosen truly randomly, and you don't have to remember the entire password, just remember the starting spot and direction. There's an almost endless number of possible passwords so even if you're required to change the password often, you'll have no problem, and you can always just generate and print a new page if you feel you're running out of memorable patterns.

If someone throws away the paper... Well, unless you saved a copy elsewhere you'll need to have your sysadmin reset the password for you, but at least it wasn't compromised... ;)

Although this approach may have made the systems less secure, it made my team's job much quicker. How unusual it is for a security requirement to have that effect!

It does not exclude a password / passphrase to protect your secret key (USB key?) against theft.

In which case what you have to remember can afford to be weak from a security point of view because its goal is merely to pollute the perfect security used BEFORE it.

The only real question is why things have not been designed this way -the proper way.

Of course when I finally get one that works I write it down on a post it note and hide it somewhere on my desk like everyone else.

The more unique and unlikely to be discovered, the less it needs to change. The more it has to be shared, especially for business purposes, or exposed to insecure communication channels and systems the more often it should change.

The economics of password management also should be considered; there is a cost burden on password recovery systems and helpdesks when changes are more frequent and more complicated.

Changing passwords is a security relic to me, like castles. It was an important control for shared accounts; shared accounts used to be prevalent but are far less needed now.

A mail service, for example, used to mean you had to give a password to any representative of the service and not just a single person (sick days, firings, holidays, etc. guaranteed a password would be shared). Fastforward and technology enables identity management systems to distribute unique and individual passwords that need not be disclosed and therefore need not be changed (as often).

Personally, I use LastPass, which works pretty well. One has to trust that they're unable to read one's passwords (and that's a personal choice, naturally), but for me, I'm more concerned about bad guys gaining access to my accounts than LastPass going rogue (as doing so would destroy their business model).

I like the fact that they do time-delay account lockouts when the wrong credentials are presented a certain number of times.

LastPass offers multi-factor authentication, which is also nice: if I access my account from a trusted computer (e.g. my desktop at home), I need only enter my username and master password. If I (or a bad guy) try to access my account from any other system, they need to know four randomly-picked coordinates from a grid that is randomly generated and known only to me and LastPass. The grid exists only in my wallet and in LastPass' records. (If I lose the grid, there are means of retrieving it, but that's even more of a hassle for a bad guy.)

I know there's risks to storing such information online, even if it's stored securely and the decryption is only performed locally, but for my needs it works excellently.

Disclaimer: I have no relation with LastPass other than being a user. I have no interest or stake in the company.

My credit union upgraded its security to require a second password to transfer money to someone you havent transferred money to before (which is a good thing). They also require inputting the password via an onscreen keyboard to help thwart keyloggers. But they limited the length of the password to 10 characters.

Thats poor security practice IMO.

"So why not measure the hardness of the password and then set a expiration date based on that. This would give folks an incentive to build hard would give folks an incentive to build hard passwords, which is what we really want anyway."

It sounds like a nice idea the only problem is how do you decide what is and is not a hard password.

For instance "thecatsatonthemat" is most definatly not a hard password as it is a well known piece of plain text.

But what if it was "7h3c475470n7h3m47" superficially this looks like a hard password although a human can quickly see that the onl difference between the two is numbers have be substituted for some frequent letters.

That is humans can see through simple obsfication such as substitution to the underlying pattern which computers are not so good at.

However if I took,

"7h3c475470n7h3m47"

and modified it via a simple rule to

"7h3d587693qol7q92"

Then it would probably pass as a hard password to both a human and a computer.

(the simple rule put in groups of three and add the group number starting at 0 to each char in the group mod it's alphabet size. So cat became c47 under the first rule and as it was group 1 became c+1=d 4+1=5 7+1=8 "d58" under the second simple rule).

The point being when does known plaintext become under simple rules a hard password and importantly why.

"It generates a password from your Master Password, the domain, and one of several hash algorithms. Is this actually a good Idea, or do merely *feel* safe with this."

I don't know of the system you mention, however from what you say some things can be said.

Firstly a hash function is not a maker of entropy it just spreads what there is around a bit, each time you apply it. However it has the advantage of being effectivly a one way function (if it is any good).

The downside of a publicly known hash function is that there is no secret added to the mix as with a public encryption algorithm.

Thus it is important to know how the master password is mixed in as the domain name is public knowledge.

One method to mix the master password in is to "whiten" it by exclusive oring it with another secret random number used as a salt.

That is you use the service domain name to generate a pointer to a table that is populated by random numbers. The first random number pointed to then gets exclusive ored with the master password, this gets hashed and the output from the hash then gets exclusive ored with the next random number and hashed again etc. The actual form of the hashing can be a chain or other structure such as a Fiestel round.

The final output from the mixing process is then used to generate some kind of usable plain text to use as the password.

However there is a problem with this final process humans are fairly lousy at copying a string of realy random charecters so it is better to use the random number to generate nonsense words seperated by numbers or punctuation charecters.

The form of the nonsense words are VC, CVC, CVVC, CVCVC, etc where C is a consonant an V is a vowel.

I suspect that what's going on is that these passwords are winding up in strings that are passed around inside the Web app via Unix shell commands, or something similar. This is, of course, no excuse at all. Have these people never heard of hex encoding???

The standard practice should be to allow, not just any printing ASCII character (plus Space) -- that should go without saying -- but all of Unicode.

That being said, what many people don't consider is that being compromised doesn't just mean being hacked. One simple question most people probably don't think about is how do you know the web site is storing your password in a secure/encrypted state? I would bet there are a lot of sites, especially smaller sites, that store passwords in plain text. So if you use the same password on multiple sites, you could be telling the developers of that site your credentials for other sites, no hacking required.

So why not measure the hardness of the password and then set a expiration date based on that. This would give folks an incentive to build hard passwords, which is what we really want anyway.

Their policy prevented recycling the past six passwords so that eliminates names of pets, kids, etc.

My full suggestion is way too long for this post, but it basically consists of comparing their password to a list of the 10,000 most common passwords known to be in use today (updating the list is an exercise for the reader :), comparing it to the most pertinent information about the password user for partial matches ("myname45", for example), and lastly doing comparisons to pieces of the URL, business name, and similar identifiers of wherever they are logging into, so as to catch "Comcast#23" and "Bruce#1Schneier".

Sure, the comparison may take a few seconds to minutes, especially if you are really thorough with the personal information, but why shouldn't a password test take five minutes, if it gives you a far better password?

Good passwords are hard to memorize and if I'm forced to change it every few months then I can do two things: change it as little as possible (e.g add a number or a character at the end and cycle between them as allowed) or use a weak password (and maybe do the same with it).

Now if one has a lot of accounts and passwords and tries to be safe and use an app like passwordsafe then the ignorant service operators who force frequent password changes can turn life into a really bad experience forcing us to do password changes every few days on one system or the other (or just force the user to give up on secure passwords).

It generates a password from your Master Password, the domain, and one of several hash algorithms. Is this actually a good Idea, or do I merely *feel* safe with this?

A recent example is a malware that was stealing FTP passwords from common FTP programs. Those passwords could have been 100 characters long and it wouldn't have protected you.

Save your passwords somewhere secure like a password safe.

So should we adapt the users to the system? Or the system to the user?

It really does make a lot of those other problems go away.

Focusing on password expiration tends to cause people to miss critical security errors (e.g., logging into your bank account from a hotel lobby computer). It also goes along with the obsession with 1950s-era "secret questions" whose answers can frequently be found by a simple Google or Yahoo search. And it dissuades people from changing passwords when they suspect that someone else may have obtained their passwords.