Interesting post at
lifehacker.com
about how John Pozadzides would go
about hacking someone’s password.

While it’s nothing new, it does revisit good advice that everyone should
follow: avoid passwords that are based on names of people close to you,
don’t think that sticking a digit at the end of your password makes it secure,
etc.

What it does do is make the same mistake that lots of “password security”
advice does - which is to assume that an attacker can test millions
of guesses per second. That’s only true if the attacker has access to
the password hashes, which usually means that he’s already got physical
access to your computer or has compromised the security database of an
application you sign into.

That’s a big assumption and I would venture that it’s almost always false.

If an attacker has to test passwords by trying to sign into one of your
accounts using a script, he’s unlikely to get more than about 1 guess
per second and he’s quite likely to trigger a lockout after a few tries.
Moreover, many on-line login systems now use CAPTCHs, so he can’t even
script the attack.

In short: protected and inaccessible password hash databases, slow
interactive login screens, intruder lockout mechanisms and CAPTCHAs
make brute force attacks, even optimized with good dictionaries, pretty
much useless, unless your password is *really* bad.

John also suggests that your bank account is linked to your e-mail
address, so a compromise of your e-mail could also compromise your bank
security. That’s a bit of a stretch, in my mind. I can’t comment about
all banks, but none of the financial institutions that I do business
with even know any of my e-mail addresses.

So here I’m just curious: does your bank use your e-mail address as an
out-of-band authentication factor?

Interesting blog entry on

serverfault.com about whether and when to grant developer access to production systems.

It’s a good read - if you’re a developer or an admin - go read it.

The one thing I can add to the discussion is simply this: it’s not an all-or-nothing question. It’s reasonable, for example, to grant developers admin-level access to a production system in the context of resolving an emergency outage, or troubleshooting a hard-to-find problem, or performing a complicated version upgrade, or even as backup resources if all the normal admins are unavailable (home sick, etc.).

Operationally, it’s pretty straightforward to do that using a privileged password management system. That’s because PPM systems randomize passwords regularly (e.g., daily or even more often), so giving a developer the admin password to a production system does not imply that he’ll still know it tomorrow, or even that he’ll know the admin password for some other systems. A PPM system can also be used for workflow authorization of the temporary access grant, audit logs, etc.

A couple of unrelated but similarly themed stories making the rounds:

• Seems that someone is trying to intimidate Julian Asange (of wikileaks fame) by fabricating and quickly withdrawing criminal charges: skunkpost.com.
• Seems like the Elections Commission of India is trying to muzzle a security researcher who pointed out that their electronic voting machines are vulnerable to tampering: indianevm.com and usenix.org

In both cases, the uncomfortable theme is that governments can use their coercive power to try to silence critics, and that especially includes critics who try to shed light on uncomfortable truths…

An interesting write-up at
technology-science.newsvine.com
and elsewhere. The original content for this appears to be here:
www.gtri.gatech.edu.

Sounds like the good folks at Georgia Tech have worked out how fast they can
crack passwords (i.e., validate whether a guessed password matches the hash
from a password database) using a GPU. They don’t seem to mention which
password hashing algorithm they are attacking, but they do point out,
in the way that responsible journalists never would, that an attacker would
of course have to have a copy of the password hashes first.

The first line of defense in most password systems is to prevent attackers
from getting the hashes. So long as that works, this whole class of attack
is irrelevant. Something sensationalist journalists (hey, that rhymes!)
fail to point out.

So what have we learned?

• GPUs can be used to more quickly brute-force passwords, if you have
  managed to compromise the password database.
• In cases where the password database remains inaccessible to attackers,
  this is irrelevant.
• Take any sensational claims about security with a grain of salt.
• Passwords are insecure! Passwords will be gone soon! (Yeah, right.
  We’ve heard that for 20 years, and it just doesn’t seem to come true).

Wow - we used to think of Microsoft as a scary company.

In just one week Oracle has promised to eliminate live source code repositories for OpenSolaris, effectively making it “not quite open” (blogspot.com) and filed a lawsuit against Google over its use of the Java programming language (www.computerworld.com).

Nice to see that they are putting Sun’s assets to good use.

To the folks at Oracle: is this the sort of behavior that your customers ask for?

Two blog posts in one day - that’s a first!

Interesting read at securityweek.com (OK, I first found it on slashdot).

The gist of it is that many users have the same password on social media sites and web-based public e-mail systems.

My first impression is …. so? Those are low-value assets, and users choose convenience over security because their (correctly) think that “well, if someone hacks any or all of these accounts, I really don’t care much about it.”

Just because we *can* make things secure doesn’t automatically imply that we *want* to make *everything* secure. Some things are basically sacrificial in nature.

A nice write-up about deploying full disk encryption to client devices:
computerworld.com

A couple of interesting tidbits:

• Key recovery is key (pun intended)
• Deployment rate seems to be about 10-25 PCs/IT staff/day. Brutal for enterprises.

A good read, in any case!

Seems like everyone is talking about moving everything to “the cloud” these days.

Increasingly, the conversation is turning to moving IAM systems from an internally hosted platform (i.e., on a physical or virtual server) within the corporate perimeter, to an externally hosted platform, run by a service provider and connected over the public Internet.

I wonder if there’s value to be had by doing this, or if it’s just the usual industry “buzz” - fickle and pointless. I rather suspect the latter.

Don’t get me wrong - I get the value proposition of moving some applications out of the perimeter and onto a cloud vendor’s network, where they get installed, configured, maintained and upgraded by specialized, skilled professionals. There are all sorts of advantages to moving apps out of the perimeter and onto a “cloud” vendor’s network:

• No physical hardware to buy, install, power, cool and maintain.
• No software to install and manage.
• Someone who really understands the application in question manages it for you, instead of someone on your internal IT team who has to manage 10 different apps and is an expert with none of them.

I just don’t get that every conceivable type of application belongs outside the perimeter. Consider some counter-arguments:

• The corporate perimeter is still very much firewalled.
• Firewalls are porous in one direction (outbound) and usually quite tightly closed in the other direction (inbound).
• A user provisioning, password management or other IAM application designed to manage users, identity attributes, passwords and entitlements spends much of its time connecting to your existing applications, in order to create and delete accounts, manage group memberships, read and write identity attributes, set passwords and so on.
• If the IAM system is outside your perimeter, then it will have to “reach into” your network to do all that stuff:
  • That’s a security problem - lots of holes have to be opened in your firewall.
  • Do you really want privileged credentials for your core systems stored on a database that belongs to another company? I didn’t think so.
  • That’s a performance problem - do you really think it will get the same sort of bandwidth going across the continent as it will going 10 feet from one server rack to another, at your own data center?

So long as you still have a significant set of applications installed inside your perimeter, your IAM system should stay on the inside.

On the other hand, if all your apps are outside (and by the way, where did your corporate directory go?), sure, move the IAM system out too.

Look at it this way — your internal IAM system is probably the last one you should move out of your perimeter. Right before you turn the lights off on your proprietary data center.

Does that mean there is no use case for “IAM in the cloud”?

Not really. There are still lots of reasonable use cases.

For example, you might be managing users and passwords on other apps which themselves have been moved out into the cloud. For example, do your users sign into salesforce.com? WebEx? Google Apps? Why not use your (still internal) IAM system to manage those? It’s really no different than managing users and passwords on your internal AD or SAP systems.

What about federation? You can certainly leverage user authentication inside your network to eliminate secondary logins to applications outside your network.

You can even go the other way - let your partners’ users sign into their own corporate directories and click right into your partner-facing apps in your DMZ.

That’s all well and good. But it doesn’t argue for relocating your core IAM function (you know, user provisioning, password synchronization/reset, etc.) out of your network’s perimeter.

I just read Jackson Shaw’s post responding to Oracle’s announcement about what they intend to do with the various Sun identity and access management products.

(Read Jackson’s post here)

Quite funny - and I concur. Having looked at both the Sun and Oracle identity manager products in the past, it was pretty evident that Oracle would have to go this way — Sun’s IDM product is really awful and I couldn’t see Oracle investing in two products, when one of them is this much trouble to support.

The real question now is what will all those customers do? Sun was very good at selling their user provisioning product to hundreds of unsuspecting customers, who each spent millions of dollars trying to get it to do something useful. Those guys are all in various stages of production deployment and certainly need support.

So: I think Sun customers will be happy that their slow, buggy user provisioning system will be replaced by something better, but distressed at the prospect of having to redo huge, expensive deployments. I’m fairly sure that not much of the work that they have invested in policy definition, workflow processes, etc. will be salvageable — we’re talking rewrite here, folks.

Which means that many IDM customers may go shopping soon. Oracle will likely give them a free-upgrade path (i.e., you get the replacement software for no cost), but the services engagements will be huge. More costly than the software license fees being saved, for sure.

While this is bad for those customers, it’s also an opportunity in the marketplace to replace first-generation, unstable, non-scalable software with something better.

Does anyone else see it this way?

Interesting reading:

networkworld.com/news/2010/011510-financial-firm-notifies-12m-after.html

Sounds like Lincoln National had a bunch of shared, static admin passwords and after 10 years (!!) someone was tipped off that
ex-employees still had access and may have compromised customer privacy.

Wow.

Can you imagine leaving admin passwords the same for that long, presumably spanning the departure of IT admin staff?

That’s just dumb, and the consequence these days is not “oops, lucky nothing bad happened” but rather “oops, we have to notify 1.2 million customers that we did something stupid.” Great PR.

The solution, of course, is simple. Change those passwords - often. Products such as Hitachi ID Privileged Password Manager (link below) make it even easier - they will change the password for you, automatically.

PPM Product site

Hopefully this is a lesson for someone..

– Idan