Recently in passwords Category

The number one piece of password advice is:

Only memorize a single complex password, use a password manager for everything else.

Gone is the time when you can plan on memorizing complex strings of characters using shift keys, letter substitution and all of that. The threats surrounding passwords, and the sheer number of things that require them, mean that human fragility is security's greatest enemy. The use of prosthetic memory is now required.

It could be a notebook you keep with you everywhere you go.
It could be a text file on a USB stick you carry around.
It could be a text file you keep in Dropbox and reference on all of your devices.
It could be an actual password manager like 1Password or LastPass that installs in all of your browsers.

There are certain accounts that act as keys to other accounts. The first account you need to protect like Fort Knox is the email accounts that receive activation-messages for everything else you use, since that vector can be used to gain access to those other accounts through the 'Forgotten Password' links.

The second account you need to protect like Fort Knox are the identity services used by other sites so they don't have to bother with user account management, that would be all those "Log in with Twitter/Facebook/Google/Yahoo/Wordpress" buttons you see everywhere.

The problem with prosthetic memory is that to beat out memorization it needs to be everywhere you ever need to log into anything. Your laptop, phone and tablet all can use the same manager, but the same isn't true of going to a friend's house and getting on their living-room machine to log into Hulu-Plus real quick since you have an account, they don't, but they have the awesome AV setup.

It's a hard problem. Your brain is always there, it's hard to beat that for convenience. But it's time to offload that particular bit of memorization to something else; your digital life and reputation depends on it.

Five years ago I published the following article:

Strong passwords in a multiple authentication environment.

The key thing I was driving at in that article, a strong password on one system is not a strong one on another system and this can significantly compromise password security if multiple authentication systems are in use, is still very much true.

That article was full of Solaris 8 and NDS. Here in 2011 those are now really old. What has changed since then?

• Old Samba versions that don't support NTLMv2 are now very rare.
• Most modern Samba now includes Kerberos support.
• LM/NTLM requiring Windows installs are now very few and far between.
  
• Linux can now leverage both LDAP and AD for back-end authentication, and such hooks are common and pretty well documented.
• Web-authentication systems (OpenID) are now much more common.
• Application-level auth is much more common and the data it protects much more significant.
  

Because of all of these, password length is beginning to trump password complexity as the surest bet for an uncrackable password. Those 8-character limits of yore are now blessedly rare.

However, some things still haven't changed:

• Older software with embedded authentication still can require older password protocols.
• Some IDM systems force passwords to be command-line safe, which restricts the allowable special-characters that may be used.
• Embedded devices, especially very expensive embedded devices, can require old password protocols long after they've been superseded. 
• The cost of paying off the IT Debt built into some IDM systems can prevent newer authentication systems from being implemented due to simple resource costs, keeping older protocols around longer than is safe.
• Arbitrarily short field-limits in databases that store passwords (16 characters should be good enough for everyone, obviously).
• Developers who decide to write their own authentication systems from scratch rather than hook into something else that's been battle-tested.

So, even now, today, in 2011, the bad decisions of ten years ago, or the hard-to-update technology of ten years ago, can significantly hamper a unified password policy for a multi-authentication system. That hasn't changed. It's all well and good that Linux (which replaced your Solaris installs three years ago) can support 200 character passwords, but that doesn't matter if the custom-built ERP application has 10-character passwords baked into its core.

However, another trend has continued since 2006: web-apps have continued to eat client/server apps for lunch.

With web-apps the option of leveraging different authentication system, or at least providing an abstraction layer to hide the old cruft from view, is possible. Perhaps there is now a web-app in front of the custom-built ERP system, put there so everyone could stop maintaining all of those terminal programs and ease the VPN/home-computer problem (everyone has a browser). That web-app could very well use an alternate authentication source, such as LDAP, and use the LDAP database itself to store the (highly entropic and automatically rotated frequently) authentication tokens needed for the old system.

With a system like that, such an old system can still be protected by an enterprising user who has selected this:

valence NIMBOSE sequestrate absolution [953]

As their passphrase. Four dictionary words, no funny spellings, four character-sets.

Is that a good password? Consider this: The Oxford English Dictionary has over 600,000 words in it. A four-word uncased pass-phrase using random words requires 1.296x10^23 guesses to brute-force, since each position has 600K possibilities. An 8 character mixed case password requires 5.346x10^13 guesses, add in numbers and you rise to 2.815x10^14.

With GPU-based password crackers available now, even salted 8-character passwords are not that good even with fully randomized passwords. This is the march of technology. As has been pointed out, adding ever more random ASCII to a password doesn't scale. Pass phrases? Good things!

But if you restrict the word-set only to words in common usage and exclude words only used in technical settings, the word-set drops precipitously to 20K or less. Even so, a four word uncased password gives an password requiring 1.6x10^17 guesses. Throw in some irregular casing and the total guesses goes up markedly.

Which reminds me, I need to spend some time going over our own developed software for password handling safety. You should to!

"Unless a password generator is just taking raw output from /dev/random, it's using programming logic to determine the password. Programming is deterministic, so password generators are deterministic, and so are the passwords they generate.

Therefore, password generators do not produce good passwords. Q.E.D."

I saw a statement much like that one a while back. The questioner was concerned that programatic password generators were not yielding good passwords, since they were designed with deterministic logic and only took a restricted set of inputs to generate that password.

This is true to a point, but there are limits.

If you have perfect knowledge of how a password generation program works and what it uses for inputs, it is possible to derive correct passwords much faster than true random guessing would suggest. The only entropy in the system is introduced by the inputs. If that input size is (for example) only 8 bits regardless of how large a password is generated, the final password will have no more than 8 bits of entropy. You can create a table of all possible passwords this program can generate.

However, if you don't have perfect knowledge of how the password generation program works, the effective entropy can be much higher for an attacker. The effective entropy will be somewhere between the supplied entropy and the entropy implied by the password length.

So, turn this on it's head.

Take password stores. They take a user-supplied password which can have very bad entropy, perform a generally well known computation on it to get a string (frequently called a hash) that is actually stored. This is seen as effective security, so long as the computation is sufficiently robust and non-reversible. But, robustness is a moving target. MD5 is broken, WEP hashes are so broken as to be nearly cleartext these days, Windows LanMan hashes are very broken, SHA-1 is showing some weaknesses but is still pretty strong.

Password-derivation attacks focusing on automatically generated passwords are perhaps most effective when used against systems known to use generated passwords that users will actually keep. Unless they have something like OnePassword end-users will immediately change passwords that are 16 characters of random typeable-ASCII, but may keep something like, "shoes376emotional". The techniques for defending against password-guessing attacks are well known:

• Limit the rate the system will accept login attempts for user accounts (increase the time required to guess the password)
  
• Limit the number of times a login can fail before locking the account from further login attempts (increase the time required to guess the password)
  
• Force periodic password changes (move the target faster than password-guessing could find the password)
• Prevent stations with lots of bad login attempts from further access to the login process (force the attackers to use multiple stations)

No matter how you slice it, even with perfect knowledge of the password-generator an attacker is still going to have to grind through a lot of passwords to find the one that works. They'll be able to find it faster than the char-sets used in the password would suggest, but still need to plow through thousands of attempts. Most of the above methods have been baked into things like Active Directory for a very long time. The same can't be said for bespoke website authentication services.

Using a well known poorly designed password generation system that spits out passwords end-users are likely to continue using means that you need to move the goal-posts (force regular password changes) more often in order to prevent brute-force intrusions. Unless you're also supplying generated passwords for those changed passwords (I've never heard of such a system, but I suppose they could exist) the changed passwords are likely to be something slightly different ("shoes#&^emotional") to completely different than the ones the generator would spit out, which further reduces the likelihood of a successful password-guessing attack.

The biggest vulnerability presented by poorly designed password generation systems are for systems that:

• Don't rate-limit login attempts
• Don't lock-out accounts after a certain number of bad login attempts
• Don't force password changes
• Don't do any kind of IP-reputation lockouts after repeated bad logins

A lot of built-from-scratch web authentication systems don't do any of the above four points, instead they focus on keeping the password hashes secure and having a password-recovery option for people who forget their passwords. Putting an insufficiently entropic password generator on top of it compounds the bad idea.

Can password-generators produce good passwords?

They absolutely can produce cryptographically good ones (a simple one: draw 8 bytes from /dev/random, get the sha1 hash of those bytes, convert the first 16 bytes of the hash to UTF-8, rerun bytes that don't translate, bam! Good 16-character password). Producing good passwords that users will be able to remember is another much more complex problem.

Are bad password generators unusable?

Since bad is relative, it depends. Such poor generators could be sufficient for producing short-term temporary passwords, which limits their vulnerability window. Usable, but only intelligently.

XKCD hit this one on the head. I'm sure nearly all of you read it, but for those that don't...



Spot, freaking, on. As I said, it isn't anything I haven't mentioned before.But nice to see in graphical format.

This specific case is for a "plausible attack on a weak remote web service," which is a different case than cracking stolen password hashes, but one that's a lot easier to carry off. Find a web-login system that doesn't rate-limit or lockout, and you can keep grinding on it until you get through. Length trumps complexity.

However...

If you have intelligence that the target's password method is 3-5 common dictionary words, that problem is a lot easier to crack than "random string of lower-case alpha characters ranging from 16 to 70 characters in length". Still, it'll take a while. And for the remote attacker grinding on "admin", probably not a safe assumption.

This weekend my father-in-law had his email account hijacked. While I've handled this kind of aftermath at work from time to time, it really focuses the mind when it is family it happens to. It was probably an Evil-AP attack sometime last week, he failed to be sufficiently alarmed when his email client alerted about a bad SSL certificate, not phishing. Happily there wasn't much email in the account (POP3 user) for the Evil People to plunder through. Even so, every time he took a walk this weekend someone (many someones) would ironically ask him about his trip to Cyprus and express ironic gratitude that he made it home safe. Jokers, the lot of 'em.

Happily for my sleep schedule, he learned of it during a time of day that the only reason I should be getting phone calls is for a death in the family or something at work has gone fatally grink. Which means he called his email support people first, and not me.

Even so, one of the things I told him before I learned how empty his mailbox was is that control of an email account, especially a private one, is a great way to bootstrap into ecommerce accounts. General internet consensus seems to have arrived on the idea that your email address should be your username on most sites. Most non-bank password-reset processes generally involve an email sent to that very account. Add in 3+ years worth of payment receipts, and the Evil People have a nice list of ecommerce sites where that email address can likely be used to gain access. Many sites will send you the actual password in that email, others will send you a link that'll force a password change but still let you in. Either way, they're in.

Not in my father-in-law's case, big empty mailbox, but still.

It's for this reason that many of my friends have a specific email account just for paying for things on the Internet. It only gets checked via webmail, and infrequently. Therefore, that account has a smaller attack surface.

Which is to say that email-as-proxy-password is a crappy authentication environment. All three of the big email providers have a way to use their authentication services, not just having an account there, as an actual auth service. For Google and Yahoo! it's OpenID, for Microsoft it's LiveID. Microsoft has had Passport for ages and even actively promoted it, but it still failed to gain much of a foothold. It's these sorts of systems that can break us out of the bad-password-reset process trap!

ahm, no.

In this case the attacker actually had a legitimate login to one of the big three email account providers. Once the attacker had that, they could quite legitimately leverage that to login to any OpenID/LiveID sites without having to go through a password-reset process. I'm pretty sure this is why most sites that handle money aren't leveraging these systems.

Evil-AP and phishing allow attackers to use a legitimate password to log in to accounts. The only real defense is some kind of two-factor security. Two-factor can work find for web-logins, banks do it all the time, but POP and IMAP don't have native hooks that support it. Both protocols have Kerberized versions that can be used, and the Kerberos system can require two-factor; but this is a usability nightmare and will never be widely adopted. Alternately, the SSL-wrapper around the POP/IMAP service can require a Client Certificate before it even establishes the POP/IMAP session, but Client Certificates have never seen wide adoption, and mail-client support is spotty at best. Also, certificate distribution and management is another usability nightmare.

What could be done is if these sorts of per-site login engines also asked for a cell number, which would only be used to notify of password reset/lockout events. It provides an out-of-band notification method. The down side with that method is that a large majority of people will leave that field blank from the very real fear that entering a number would sign them up for SMS-Spam.  A more acceptable way would be an alternate email account that would also receive reset notices.

Usability makes this a tricky problem to solve.

Anyone who does email knows that it is really easy to intercept in-flight. Unless TLS is in use the messages are transmitted in plain text, and the SMTP protocol is designed around the assumption that untrusted 3rd parties may handle the messages between source and destination (a holdover from the UUCP days as it happens). The appliance and cloud anti-spam industries are designed around this very capability.

But how much of a risk is illicit interception? Or worse, monitoring? Everyone knows you don't send passwords or credit-card information in email, but we also send password reset messages in email. Some web-sites still send your password when asked for a 'reminder', so clearly some reset-system designers consider email secure-enough. Or maybe it's just convenience trumping security again.

To figure out how much of a risk it is we need to know 2 things:

1. How can email be intercepted?
2. How likely these methods are to be used?

Interception can be accomplished two ways:

1. Catch the messages in-flight by way of a sniffer.
2. Catch the messages in the mail-spools of the mailers handling the message.

There is another vector that is even more damaging, though. Catching the message in the final mailbox. That isn't interception, it's something else, but it really impacts the security of email so I'll be including it. Under the fold.

According to The Register, the UK police have increased the exercise of the power that allows them to compel the revealing of crypto keys. That fancy duress key you put on your truecrypt volume is only good for earning you jail time. I've mentioned this before, but crypto is vulnerable at the end-points. If the Government can point a loaded law at you to force you to reveal your keys, the strength of your convictions, not your crypto, is what is being tested. Perhaps that 2-5 year prison term is worth it. Or maybe not.

I take heart that a majority of those served with the demand notice have refused. But we still don't quite know what'll happen to them.

This is harder to pull off in the US thanks to the 5th amendment, but there is nothing stopping this kind of thing off our shores. Or heck, at our borders.

This question came up, and it got a long response out of me.

Question:

Taking in mind that being a a deterministic machine a today computer is incapable of producing random sequences and all computer-generated "random" sequences are pseudo-random actually, aren't computer-generated random passwords insecure? Isn't it more secure to just press keys randomly to create a random password than to use a digital generation algorithm?

The idea behind this question is sound, since deterministic processes return consistent results, password generators do not return random passwords and are therefore not good (or in the words of this poster, insecure). Unfortunately, it shows a lack of awareness of just what constitutes a good password.

Good passwords come in many flavors. Passwords that humans never have to type (such as those attached to batch processes) can be much more complex and long than the kind humans have to memorize. Also, if you're dealing with a character limit on passwords, a good password on such systems will look different than good passwords on other systems that lack a limit on size.

Over the years we've learned what a good password looks like:

• Long enough to make randomized guessing non-viable.
• Have enough entropy to make each character significantly non-dependent on other characters in the password.
• Able to be memorized.

There are also system-specific variables for what constitutes a good password.

• For systems with 8-character limits on passwords (old crypt-based *nix password systems), high entropy is required.
• For systems with well known methods of attacking passwords below a certain length (LanMan, NTLM, but not NTLMv2) high length is required.

In basic, length increases the number of possible passwords that have to be brute-force checked, and entropy increases the number of passwords that have to be checked at a certain length. Perfect entropy (i.e. completely random) of course maximizes the number of passwords that have to be brute forced at any given length. Unfortunately, perfect entropy always fails the memorization test of 'good password' for password lengths much above 7.

Which is a long way of saying that perfect entropy is not required to have a good password. In fact, if your password needs to be used on a system with known attacks for short passwords (Windows) length is more important since most normal humans can't memorize 16+ character passwords of four-character-set random characters. Especially if password rotation is in force so they have to do it a couple times a year.

And a final point about the determinism of generated passwords. A deterministic process can't introduce more entropy that it received as an input, this is true. When generating a 40 character password, a password generator can use a smaller amount of truly random bits (thank you /dev/random) to generate a password. The amount of entropy in this password will never exceed the number of bits that were pulled from the random source so long as an attacker knows what algorithm generated the password. If an attacker doesn't know what algorithm was used to generate a password, then the dependency of one character on another is unknown so the password will have high apparent randomness. This is called pseudo-randomness, and is how /dev/urandom and most hashing algorithms work.

Since perfect entropy is not required to generate a good password, deterministic password generators can produce perfectly fine passwords. So long as they have a good source of entropy to seed their processes with.

I just completed an order with Newegg for some personal computing equipment. That part was OK. What wasn't OK was the "Verified by Visa" thingy that popped up during the ordering process. My primary credit cards aren't Visa so I haven't seen that yet, despite shopping on sites with the verified by Visa logo on 'em. Since I hadn't used it before I had to set the durned thing up. Which meant picking a password.

My jaw dropped.

6-8 characters is stated in the 'password policy' that was posted. And no matter what I threw at it, if I used my shift key it wouldn't take the password. I don't know about you, but complex password policies have been around long enough that my fingers automatically go for the shift key when entering passwords. NOT using it took mental effort. In fact, the password I ended up with is markedly less secure than the one I use for throw-away accounts on web-sites I don't care about.

That is not a way to run a bank.

I don't know what "Verified by Visa" really provides, but whatever it is, password security isn't it.

A while back we managed to push through some new purchasing rules that required IT review of any IT technology purchases. This is needed, since end-user departments haven't the first clue what'll work with our existing infrastructure, and it helps us advise them of complications. For instance, if a product requires PHP on IIS for some reason, we really want to be able to let them know before they purchase that doing so will require a server purchase as well since we don't support that environment currently.

Unfortunately, a small number of things still slip through. Perhaps we didn't read the manuals enough. Perhaps a high enough manager expended sufficient political capital to Make It So. But complications can arise when we go to make the new thingy work.

A case in point:

For the last two weeks I've been attempting to get a certain package up and running that has email capabilities. This has to fit within our Exchange system, which is a rather common environment. What isn't so common, it seems, is our insistence on secure protocols for authentication. While Exchange 2007 is perfectly willing to support naked POP3 and even naked SMTP-Auth, we, on the other hand, are not so forgiving. We wisely have a security standard in place that says that all authentication traffic must be encrypted, and this prevents us from running POP3 and SMTP in a way that allows passwords in the clear.

This package has support for one SSLed service: POP3-SSL. We don't support POP3 since our users were forever screwing themselves thanks to the default of "Delete on retrieval" in most mailer clients, which kind of pissed them off when they got to the office the next morning and their mailbox was empty.

Thanks to the use of stunnel I was able to tunnel unencrypted IMAP to Exchange's IMAP-SSL port at least, so that channel got working.

Right now I'm trying to convince stunnel and the application to work together to get SMTP-TLS working. Sadly for me, I have to wait a couple of hours before the app attempts an SMTP check for me to see if it works.

On the 'up' side, we're charging this department by the hour to get this set up. So the labor bill on this will be fairly high.