Recently in security Category

The other day a Colorado court ordered a defendant to produce the unencrypted contents of their own laptop. This is what I called "rubber hose cryptography", and previously we've heard of efforts in the UK to compel decryption. It has now happened here, and not at the US border. Unlike the UK, this decryption demand in Colorado is not based on a law that specifically says that courts can demand this.

Wired article

The counter-argument is quite clearly the 5th amendment right guaranteeing the ability to not self-incriminate. If that decryption key only exists in your head, and disclosing it would incriminate you, then you don't have to yield the key.

This judge disagreed. I'm not a lawyer, so I can't tell what legal hairs were split to come to this decision. But the fact remains that this judgment stands. The only concession he appears to have made for the defendant is to preclude the prosecution from using the act of disclosure as a 'confession', but the data yielded by the disclosure is still admissible.

Today I had an incident with biometrics that further convinces me that they are not the end-all be-all of security.

Today I had to head up to our datacenter to do some nebulous "things". Like you do. Since we colo at a large facility that has all of those security certifications, getting into it is something of a trial but a familiar one. Hand scans, double-layered man-trap, the whole deal.

Only, the hand-scanner on the cage our racks are in wouldn't read my hand today. It took 19 tries before it decided I was me. To get this far I had to pass four other hand-scaners and only had to re-enter three times along the way. When I went back to the security station to see WTF, they had me re-scan my hand. Leaning over I saw that I had managed to fill their live-log of entry/exit events with red events, and they didn't seem phased in the least.

I've had some trouble with this particular hand-scanner before, enough that I dread leaving the cage. For what ever reason, this particular scanner is far enough out of spec that the fuzzy results it returns are fuzzier than their system will accept. Since it's on a rack cage rather than the higher trafficked man-trap scanners, it hasn't been caught out and re-tuned (or something). But still, I hate that thing.

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.

A question was posted to ServerFault yesterday that raised ALL of our eyebrows.

Our security auditor is an idiot, how do I give him the information he wants?

The asker is not wrong. Really, go read the question. Any security auditor asking for a complete list of passwords, in plain-text, has got a few screws loose. The asker is understandably hiding their identity, though it has become clear that they are in the UK somewhere. The answers are high quality, and I recommend reading them.

Yes, this is something that System Administrators have to put up with from time to time.

• I have been told to do something against all good understanding of best practice, and may be possibly illegal.
• I have complained, and been told by higher authority to put up or shut up.
• Now what?

In the industry, if your boss is an (potentially criminal) idiot, and you can't change their mind, it is time to change the boss. Not everyone has that luxury though, especially in this economy, so sometimes you have to stick with it. That's the hard part.

The "fix" for this particular case is the same as the "fix" for being asked to troubleshoot a faulting legacy system you'd been studiously ignoring because it privately scares you. Hold your nose, get educated about the system, and start making some reasoned arguments/guesses about what may be the problem. The answers on that question provide the education and troubleshooting guidance for dealing with the, "my security auditor is defective," problem.

This person is in a very sticky situation. They are being asked to do something that is very likely illegal in their area and it seems like this is a serious request rather than a subtle test of some kind. And worse, their business management has bought in (see second comment on the question, you'll have to expand the comments to see it). If they do everything they can to convince business management that this is not only stupid, but potentially criminal, and management still presses ahead, they'll get to one of the hardest decisions to make in our line of work.

• Do I quietly go along with this, having done everything I can to dissuade them?
• Do I report this action to the authorities and be a whistle blower?
• Do I point management at this as-yet-unlinked-to-the-company tempest-in-an-Internet as last ditch supporting evidence of the flagrant stupidity of these actions?
• Do I resign my position and become employed elsewhere rather than do these actions?
  

Each of the above has their own consequences. The first point may end up with your butt on the line if the issue ever does get brought up legally. The second one will cause your company to be quite angry with you, probably involve extensive legal proceedings, and will be an unremovable mark on your record (for good or bad). The third will only work if management is of the right mindset to understand it, and may get you fired for talking about company policy in public. The fourth is perhaps the easiest to do, but will also involve a period of unemployment that could stretch several to many months.

I wish them the best of luck. It's the kind of thing that we all hope only happens a very few times in any career.

I do review our firewall logs, and do what I can to keep them clear of stuff coming from my network. Even so, there is still a lot of stuff there. One particular IP address had been port-scanning us very persistently for weeks. Last Thursday I finally had enough and looked into it.

The weird thing about the log-lines was that the source TCP port was TCP/443. The target ports were the usual assortment of high-order ports. Most odd.

The reverse lookup of that IP didn't give me anything. However, an openssl query to see what SSL certificate it was offering did give me information.

One of our cloud-app providers.

Wha?

Time to sniff packets. And sniff I did. I got a couple minutes and it was long enough to get a few port-scan attempt log-entries. After correlating the source/target port numbers one pattern was pretty clear:

The cloud-app provider was issuing double RST packets after receiving a FIN packet from our side. The first RST tore down the connection as far as the Firewall was concerned, which made the second one seem like a packet from nowhere with strange flags on it and therefore suspicious.

I did helpfully tell said cloud-app provider about this, and they send back a, "situation normal, nothing to see here," reply, and googling around does show some systems do use a double-RST method for tearing down connections. I'm not sure why this is a good idea in some cases, but it's pretty clear our firewall doesn't like it. At least this is a bit of log-spam I can now safely ignore.

I deal with some large file-systems. Because of what we do, we get shipped archives with a lot of data in them. Hundreds of gigs sometimes. These are data provided by clients for processing, which we then do. Processing sometimes doubles, or even triples or more, the file-count in these filesystems depending on what our clients want done with their data.

One 10GB Outlook archive file can contain a huge number of emails. If a client desires these to be turned into .TIFF files for legal processes, that one 10GB .pst file can turn into hundreds of thousands of files, if not millions.

I've had cause to change some permissions at the top of some of these very large filesystems. By large, I mean larger than the big FacShare volume at WWU in terms of file-counts. As this is on a Windows NTFS volume, it has to walk the entire file-system to update permissions changes at the top.

This isn't the exact problem I'm fixing, but it's much like in some companies where granting permissions to specific users is done instead of to groups, and then that one user goes elsewhere and suddenly all the rights are broken and it takes a day and half to get the rights update processed (and heaven help you if it stops half-way for some reason).

Big file-systems take a long time to update rights inheritance. This has been a fact of life on Windows since the NT days. Nothing new here.

But... it doesn't have to be this way. I explain under the cut.

The historic 'rdesktop' product (located here) hasn't been updated in a while, and critically lacks support for a major new feature Microsoft introduced in 2008. Network-level authentication. This enhancement requires a login to even connect the RDP session. The rdesktop client hasn't been able to support this, so for my servers that I wish to RDP to I have to remember to turn that off.

Happily, the FreeRDP fork of rdesktop now has support for NLA. It's in the GIT repo, not the stable branch, but it is there. The next stable version should have support for NLA.

Yay!

Being the person who manages our centralized file-server, I also have to deal with storage requests. The requests get directed to a layer or two higher than me, but I'm the one who has to make it so, or add new when the time comes. People never have enough storage, and when they ask for more sticker-shock means they often decide they can't have it.

It's a bad situation. End-users have a hard time realizing that the $0.07/GB hard-drive they can get from NewEgg has no bearing on what storage costs for us. My cheap-ass storage tier is about $1.50/GB, and that's not including backup infrastructure costs. So when we present a bill that's much more than they're expecting, the temptation to buy one of those 3.5TB 7.2K RPM SATA drives from NewEgg and slap it in a PC-turned-fileserver is high.

Fortunately(?) due to the decentralized nature of the University environment, what usually happens is that users go to their college IT department and ask for storage there. For individual colleges that have their own IT people, this works for them. I know of major storage concentrations that I have absolutely nothing to do with in the Libraries and the College of Science and Technology, and a smaller but still significant amount in Huxley. CST may have as much storage under management as I do, but I can't tell from here.

Which is to say, we generally don't have to worry about this problem. That problem? That's what happens when you have a central storage system that can't meet demand, and no recourse for end-users to fix it some other way.

And I'd hate to be the sysadmin who has to come down on that person like a ton of bricks. I'd do it, I won't like it, because I also hate not meeting my user's needs that flagrantly, but I'd still do it. Having users do that kind of end-run leads to pain everywhere in time.